Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. Secondly, you have to infer everything else that was requested and will be needed but was not originally specified.

Alright, now you have your list of requirements. Firstly, you must break each requirement down into a long series of small steps that perform exactly one operation - such as add 1 and 1 together. You must also find the correct order for all of the steps, as well as the operations to store and manage all required data in memory as meeded.

Finally, the list must either be translated to the native language of your computer's CPU or ran by a program running on the CPU.

As you can see, this is actually a large and difficult task, even if you manage to not encounter any unsolvable problems along the way. I would think the following comes naturally: The difference between your language and the 'dumb-as-rocks' ones is that the latter are implementable and usable.

>Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. [my emphasis]

If that were true it would be impossible to make a flow-chart based interface to a "compiler" that produces an executable based on the flowchart (without any keywords, variable names, etc). But plainly it is possible to make such a flowchart->executable compiler+visual IDE, so you are incorrect regarding the claim that the specification needs to be parsed lexically. Functionality does not depend on lexical parsing. It's that simple.

> A language should just be a super tiny syntactic framework that elegantly lets library writers rewrite the same thing they already wrote in C++, Python, Perl, Go, Java etc libraries for - but this time in my language!

The rewrite issue is exactly why it makes sense to avoid putting things in the language if it doesn't need to be part of the language.

Consider that a more generic way of offering what you suggest is to punt most of it to the OS and have the language/runtime instead "just" offer you a way of having it pre-allocate sufficient space from the OS. Many do in some way or other, either by getting out of the way (e.g. C, C++, any other language with "manual" memory management) or by offering switches or known behaviour to coerce the allocators to act how you want (e.g. in most VM based languages you'll find options to tune the allocation/GC patterns in various way).

In practice there are ways of doing what you want in most language/OS combinations, if not always as cleanly as you might like. If you want functionality like that as part of the language, a more flexible approach would be to e.g. do things like support cross-cutting (effectively inserting hooks before/after function/method calls) or method/function aliasing and provide a means to switch out the object/memory allocator. Doing so would be far more generic, and would allow the functionality you want to be written as library code instead of adding specialised language construct for a specific memory allocation strategy.

>It shouldn't really "do" anything. Who needs a programming language with any abilities! That's not what languages are for!

Everything you have available in software (and/or hardware) is the result of some of those languages that "don't do anything" and don't have "any abilities".

You want a "a language that lets [you] just describe what [your] executable should do - and then give [you] that executable".

That's exactly what existing languages already do -- the description happens in the language's syntax.

If you want a declarative description in physical language, you actually want a programming team, not a language. And the description is called a "design document" or "functional requirements".

You will get those when AI replaces programmers. And even then only as much as any set of loose language can be translated to a precise behaving program.

Don't hold your breath for either.

For all the misplaced sarcasm I don't think you understand how computers work.

I, and many others in here, can write a language like one of those you mention (Perl, C, etc). Can you write one like you described you want? You know, to show us all how it should be done, and how we're idiots for now offering it to you?

Reminds me more of those freshmen that hear about assembly being faster and want to rewrite everything, OS, apps, etc in assembly, because faster.

You can return to this comment in 20 years and compare the state of languages then with the features programming languages implement in 2017. Today it is my opinion that languages differ most markedly in their syntax and some of the primitives, but generally speaking implement largely similar functionality.

For this reason there are source-to-source compilers (transpilers) and it is very common to host one language in another, in the way that Wordpress was ported to .NET: https://news.ycombinator.com/item?id=13753445 The way in which this was done was to expand .NET to run php.

Languages just don't do very much today, in my opinion. Everything is hard. If you disagree with me then we ca return to this in 20 years and compare the state then and now.

I am not designing another language at the moment. The above is just my opinion.