There's no reason JavaScript couldn't transparently implement parallel map/filter/etc. Other than the fact it is really hard to do. On the other hand a lot of the things JavaScript engines do today are also really hard, so maybe one day it'll happen.

Best I've seen so far (outside of lisp) is elixir, but it really bogs down the entire thing by requiring a bunch of extra information and metadata that common lisp can infer by position and an extra layer of indirection.

For the first, I think it's a mistake to perpetuate the mistakes of the past. I don't think JS developers have had problems adjusting to the lack of return in arrow functions.

Beginners have no preconceived notions of how a programming language should operate, and return makes the language model more complex.

1 + 1 evaluates to 2, but (in a language that requires return)

def foo = 1 + 1

foo

doesn't for no good reason. This breaks the simple substitution model of evaluation.

These claims could be addressed emperically, but I guess neither of us are going to do the research. :-)

For example, which of these is more clear to people who don't know Lisp? I'd argue the second one because of the early return if guard.

    ---- THIS ----

    (defun sum-helper (items total)
        (cond
            (items
                (sum-helper
                    (cdr items)
                    (+ total (car items))))
            (t total)))

    (defun sum (&rest items)
        (sum-helper items 0))

    (print (sum 1 2 3 4))

    ----- OR -----

    (defun sum-helper2 (items total)
        (if (not items)
            (return-from sum-helper2 total))

        (sum-helper2
            (cdr items)
            (+ total (car items))))

    (defun sum2 (&rest items)
        (sum-helper2 items 0))

    (print (sum2 5 6 7 8))

(It should be readable but hasn't had a final editing pass.)

Thread-safe lock-free sparse integer-to-integer map? No CNC for that.

Translating time between two domains, one of which is linear and monotonic, and the other is non-linear and non-monotonic. No CNC for that.

Generating and caching the right versions of different segments of audio waveforms at different zoom scales, in multiple threads? No CNC for that.

I could go on, but you get the point.

What tends to be more like a CNC machine are libraries. For example, realizing that you need some sort of reference-counting system for lifetime management, preferably combined with pointer-like behavior ... and then discovering boost::shared_ptr (later to be std::shared_ptr) ... now that's like getting a new CNC machine. But it doesn't require a new language (and realistically, it didn't even require the library - the library just made it possible to not implement it locally).

I think what I'm really trying to say is that I rarely come across problems where I think that the kind of help offered by the putative "new CNC machine aka new language" is anywhere nearly as substantive as the help offered by an actual CNC machine to a cabinet making company. Put differently, the new tool (language) still leaves the problem essentially as hard as it was before.

p.s. a good friend runs a high end wood shop, and I'm fairly aware of the impact their first CNC machine made to what they could do.

This problem is arguably harder than the example problems you gave and this problem was solved by language primitives that now exist in basically every popular language. These primitives, when used basically change the nature of the language they are used in.

These primitives (async await) are more than libraries. They intrinsically change the nature of your code. (Though technically they could be made into libraries for languages without async await it's just the syntax would be extremely busy)

This only occured because the web was popular and the specific problem of servers and IO changed from a specific problem to a general one. So when someone wants to create a new language it's to attack a general problem.

Your issues in your example look to be somewhat domain specific, so new languages won't really help you in these specific areas you need to handle.

>Generating and caching the right versions of different segments of audio waveforms at different zoom scales, in multiple threads? No CNC for that.

I would say that for this example there are enough general issues here that modern languages CAN help you with. For example do you want to program in a language that can guarantee with helpful static error messages that your code will never have a data race or a seg fault or a buffer overflow or a dangling pointer?

Well there's a language that can help you here. In the same vein I've seen languages go even further then this and guarantee that the compiler will never ever let you write code that will make your program crash.

I think we can both agree that these general features that improve safety WILL make the issues you face easier.

The problem was called "the thundering herd": if you had N threads all sleeping/waiting on a condition, and then that condition was raised/signalled, there were no OS primitives available that would wake only a single thread. Instead they all woke up, tried to get whatever work was available, only one succeeded, the rest go back to sleep. Incredible waste of cycles. These days, you can signal a condition in a way that will only wake a single thread that is waiting on it. Problem solved, for every language, without language modifications.

This was NOT fixed at the language level. It was fixed by adding new OS-level primitives that did the right thing.

Async-wait is another wrinkle in this, but for those of us old enough to remember life before pthreads, that was already effectively taken care of using threads (whatever the API) and existing OS-level sleep/wait primitives.

Doing this without threads is popular among the cool kids these days, but that's even harder than doing it with threads. Consequently, various languages have wrapped this sort of code into builtins in the language. Yes, that makes thread-less async wait easier to code, but it doesn't actually address the design problems where you might be using thread-less async wait to accomplish something.

The problem with waveform caching is not data races etc (though of course, those issues are hard enough). It's figuring out what you should cache and when. The best answers vary depending on user behavior, so you need an adaptive approach that isn't particularly linear, and you also a need way to recognize when user behavior means you should clear out everything in the cache and start over.

Re. CnC, how about something like:

    @thread-safe @lock-free @sparse
    map map[K,V] 

> What tends to be more like a CNC machine are libraries.

If a language or library gives you composable semantics, you may have a programming CnC on your hand. CnC requires minimally one degree of disconnect between the artefact and the artisan. A language compiler/runtime (or library) that applies composable semantics to logical & computational abstractions.

But the syntax is precisely the only thing a language can give you that a library cannot.

This might be true on a similar level to all Turing-complete languages being equivalent, but I’m not sure how useful it is beyond that level. For example, the features that a language provides as directly supported building blocks and the guarantees a language makes about how certain entities will or won’t behave and relate to each other profoundly affects the developer’s experience. That remains true even if some of those features could eventually have been recreated with a library modulo syntax and even if a perfect programmer would always use them properly and never rely on the language to prevent a mistake.

The idea that the compiler could somehow pick "the right" implementation of a sparse unordered map based on a list of constraints that combine to create potentially dozens of versions strikes me as far-fetched. Even specifying "lock-free" for example is very, very far from providing enough detail about what is actually required. Wait-free? Readers-not-blocked-by-writers? Writers-not-blocked-by-readers? etc. etc.

I don't dream of a future when compilers (or something) can somehow do all this, and I'm not convinced it will arrive. But I've been (very) wrong before.

This was fixed at the OS level. But the usage of new system calls involved fundamental shifts in basically every language to account for the new paradigm.

Julia has a lot of great ideas in it for sure. Why hasn't it gotten more popular?

At the moment, Julia is a nice language at v1alpha1 for scripts and data exploration.

And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds. Yet it's popular.

Python has tools for both of these - including virtualenv in standard Python. Nuitka if you want native compilation to a single binary. Julia has none.

Weird, since we ship natively compiled single binaries with Julia to customers all of the time using the standard open source tooling...

    julia -e 'using PackageCompiler; create_sysimage(["MyPackage"], sysimage_path="MyPackage.so"; precompile_execution_file = "MyScriptOfWhatToCompile.jl")'