13 ms·

Building a new functional programming language

137 points by signa11 4y ago

karmakurtisaani 4y ago
> The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized. Proceeds to give zero indication how to achieve this.
- jalk 4y ago
  > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I'm sure there are a multitude of different reason and likely require different conflicting tradeoffs to address
  - bslatkin 4y ago
    It's true and that is one of the largest challenges. Producing something that feels familiar (but not error prone) has been the way I've solved such conflicts so far.
- User23 4y ago
  It basically comes down to nondeterminism. Pure functional languages supposedly make it easier to exploit associativity, commutativity, and distributivity to allow many expressions to have nondeterministic semantics that are amenable to concurrent execution. Argument evaluation also can be specified nondeterministic so the runtime is free to execute something like the following with two or more CPU threads: f(g(), h()) Of course a well designed imperative language could also avoid overspecifying deterministic semantics and open itself up to similar optimizations, but for various reasons that hasn’t caught on. One example would be specifying the conditional to select a branch with a true guard nondeterministically rather than deterministically in the order of appearance in the program text. Dijkstra’s EWDs give many practical examples of why one might want such a thing. Another example would be deducing when statement composition is symmetric and allowing nondeterminism when it is. For example if f and g don’t have access to each other’s data then the following can be executed in two threads even with mutation: f(); g() Side effects will appear nondeterministically though which may or may not be a problem. As always an algorithm needs to be designed for the semantics the language has not those the programmer wishes it does.
  - alexisread 4y ago
    This makes a good case for effect systems in conjunction with FP, so they can be reasoned about as well. Something like https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html Having said that, having something like Daedelus in there as well would give a handle on temporal-based determinism, and then some allowance for delimited continuations would top things off nicely.
- worksonmine 4y ago
  In his defense the title is "why" not "how". I guess you'll have to spend some sleepless nights waiting for the follow-up.
  - bslatkin 4y ago
    I'm sorry to make you wait.
- lolinder 4y ago
  It's a four paragraph blog post answering the question "why?". I'm not sure why you expect him to delve into the how at this stage: he probably doesn't have anything fully formed yet.
  - iampims 4y ago
    https://twitter.com/haxor/status/1582878447134572544?s=20 https://twitter.com/haxor/status/1582878447134572544?s=20 Looks like the syntax is taking shape at least.
    - noelwelsh 4y ago
      No language syntax needs return in 2023.
      - bslatkin 4y ago
        How should an early return if statement work instead?
        noelwelsh 4y ago
        When if is an expression early returns aren't really a problem.
        bslatkin 4y ago
        I understand what you mean. But I expect most potential users want explicit returns because they're familiar and more approachable for beginners.
        noelwelsh 4y ago
        I disagree. You make two claims: familiarity, and beginner friendliness. 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. :-)
- karmakaze 4y ago
  Very disappointed by the non-announcement. If it were a corp, it would be FUD. I'm curious as to what these different trade-offs are. > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. My conclusion is because most everyone is taught to think empirically and 'play computer' that functional doesn't fit in their preconceived brains. I once had someone say SQL didn't make sense because it's SELECTing fields (i.e. vars) before they're defined/assigned later in the (binding) expressions. People having trouble with FP is like how people who learn databases using ORM's don't deal well with SQL as expressions of set operations. There are varying limits to how much people like and handle abstract constructs before applying the construction to the data at hand but you can do a whole lot of effective and unsurprising development before getting to such esoteric levels. Edit: I was super-excited to open the link, and now on re-reading expect this new FP language to be as much an advancement as Go was to 'systems' programming. I hope I'm mistaken. Also odd that only Haskell and Lisp were mentioned when there are so many others. On the plus-side if Google were to make F# and back it as well as they have Go, that would be a win-win.
  - karmakaze 4y ago
    After reading their other post "The case for dynamic, functional programming", I would classify this as FUD, or rather NIH. Go got support by being touted as "Not Java". I can't say that this would gain much by being declared as "Not Elixir".
  - lolinder 4y ago
    > it would be FUD I thought FUD stood for Fear Uncertainty Doubt—it's usually used to indicate that something is designed to sow fear for clicks or for some ulterior motive, not for insubstantial non-announcements. Did something in this post evoke fear?
    - karmakaze 4y ago
      The point of FUD is usually to carve out a space where existing products/solutions can't compete with idealized vapourware. I updated my opinion to NIH (though could be both)--and still hope to be mistaken.
mark_l_watson 4y ago
The article is light on details, but as a polyglot programmer, I encourage him. I am an enthusiastic, but far from expert, Haskell programmer. I wonder if Brett is thinking of a more Python-like interpreted functional language?
- bslatkin 4y ago
  Thank you! Imagine everything we like about Python, remove some warts, make it functional. It should feel familiar and appealing to a Python programmer.
  - eternalban 4y ago
    Based on above it seems you want to test the hypothesis that 'there is a python-like functional language in the space of FP'. Is there anything ~technical you can share beyond desires and disappointments that leads you to believe this is a reasonable hypothesis?
    - bslatkin 4y ago
      I've got a working interpreter and compiler for the initial language. I've had a few people take it for a spin and they were able to rapidly learn it and start contributing, despite having expressed frustration in trying FP languages in the past. All anecdotes for now!
      - eternalban 4y ago
        Ah, you already have it. Now we're all intrigued! Looking forward to the public release.
      - ch4s3 4y ago
        I'm pretty deep in on Elixir, but I'd be quite interested to take a look.
nextaccountic 4y ago
> He spoke of the potential for functional languages to provide a significant, intrinsic advantage when it comes to parallel computing. > (...) > If that were true, you'd expect that the many existing functional programming languages would have already satisfied this need. But in my opinion, they haven't Well there is https://futhark-lang.org/ https://futhark-lang.org/ - it runs on the GPU, and is awesome. On the CPU side, I think that Rust plus https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon was a huge breakthrough on writing parallel programs using both functional and imperative programming, and future languages should learn from its successes. The ownership system & the borrow checker, plus other type-level features like the Send and Sync traits, were essential to enable sharing read-only data between threads without synchronization, or sharing read-write data with synchronization, all checked at compile time for data races (which is a huge problem to solve, and is something that neither Go nor Java protects against at compile time) Indeed Futhark shares a key feature with Rust: it uses uniqueness types to enable in-place updates, which is kind like a limited form of Rust ownership: if you are the sole user of some memory, you can update it and other code will be none the wiser. This kind of thing is very important to build functional programs that are performant in practice.
- tsegratis 4y ago
  Fair point It may be better to see rust as sitting between functional and imperative paradigms
- klavinski 4y ago
  See also the Higher-Order Virtual Machine for a functional, non-garbage-collected, and parallel runtime: https://github.com/HigherOrderCO/HVM https://github.com/HigherOrderCO/HVM
  - nextaccountic 4y ago
    Hey, that's pretty cool! The lang that targets this runtime is https://github.com/HigherOrderCO/Kind https://github.com/HigherOrderCO/Kind
dimitar 4y ago
So why would Clojure or Erlang or Elixir fail to satisfy the need for a functional language capable of taking advantage of the available cores?
- davidw 4y ago
  Seems like he's talking about parallelism rather than concurrency? Erlang does the latter pretty well, but I'm not sure it's that great for "I have a lot of processing to do and I want the language to help parallelize it", especially since it's also not the fastest thing out there.
  - weatherlight 4y ago
    Have you used Broadway, its pretty fast. I think people forget how expensive it is to serialize/deserialize data between machines/nodes.
- lolinder 4y ago
  I don't think he's arguing that the existing functional languages can't take advantage of all cores, it sounds like he believes that the existing functional languages cannot reach mainstream adoption because of fundamental flaws that he hopes to address: > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized.
  - bslatkin 4y ago
    Exactly.
    - redbar0n 4y ago
      > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. What are those reasons, in your view?
nothrowaways 4y ago
Short answer, because I am bored.
- robertlagrant 4y ago
  "I want to be paid a fortune for making a programming language, so I need a reason." Of course, I would do the same in their position.
  - bslatkin 4y ago
    It's an unpaid personal open source project.
xutopia 4y ago
What language is he working on though? Can we see the initial ideas in the syntax?
iLoveOncall 4y ago
As always for those niche languages, if the answer is not personal entertainment, then the reality is that it's just poor judgement.
alexisread 4y ago
I'll drop this here: https://github.com/manuel/wat-js https://github.com/manuel/wat-js If you have delimited continuations then you can construct coroutines/threads/await/async, promises etc. I guess that this might be suitable for many scenarios thanks to nodejs, but the runtimes it relies on are not exactly small.
evanwang0 4y ago
While certainly true that functional programming provides an intrinsic advantage to programming parallelism, parallelism is limited by hardware constraints. To best take advantage of CPU architectures，”function” execution needs to optimize usage of caching layers and execution threads. This naturally lends itself to the development of event loops/schedulers in functional runtimes like node and erlang.
Hizonner 4y ago
> once asked Guido van Rossum (the creator of Python [...]) [...] Uh-oh... You know, I was just programming in Python yesterday, and I was once again reminded of how ANNOYING a language it is... how annoying it is that it's so popular that I'm essentially forced to code in it. Especially now that a bunch of (probably needed) changes have been made in half-assed ways that interact clunkily with its original rather, um, idiosyncratic structure, syntax, and philosophy, which for a long time were determined almost entirely by one person's idea of what was intuitive. I mean, it's not JavaScript-level annoying or Perl-level chaotic, but it's a pretty damned annoying language. > Although our tools have continued to improve (such as golang), Uh-oh... Another language that grabbed some popularity by fixing some things, but still fails to systematically Do Things Right, even though we're now like 50 or 75 years into this whole computer thing, and are at a point where we ought to have a mature understanding of what Right is and the time to act with deliberation. One of the ways it grabbed that popularity was, of course, by looking familiar and unintimidating to people who don't like "weird languages". > By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. Uh-oh...
- bruce343434 4y ago
  Can you explain how python is annoying?
- lillywastaken 4y ago
  I'd rather use JS than python, since at least JS doesn't actively try making programming in a functional style worse
lolinder 4y ago
> Why is the gap between these two perspectives so large? My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. Now that (nearly) every mainstream language has lambda expressions, there are very few patterns in functional programming that cannot be replicated in mainstream languages, which means that moving to a pure functional language now provides strictly fewer choices when problem solving. In order for a programmer to accept a language with strictly less expressive power, those new restrictions must solve problems that the programmer actually cares about. Rust reached adoption because mainstream systems programmers recognized that memory errors are a huge problem and dealing with the borrow checker is worth it to solve them. Static typing reached mainstream adoption because it made coordinating work in a large team dramatically easier and solved refactoring. Functional-style programming has hit the mainstream—embedded within imperative and OO code—but purely functional languages have yet to make a good case for their additional restrictions, and I'm not convinced that multiprocessing is that case. Golang mainstreamed a very effective model for multiprocessing in an imperative environment that solves most of the problems without asking programmers to completely change the way they write code, and that model is increasingly being adopted in other languages (Java's project loom, for example).
- amitport 4y ago
  I would credit this model for multiprocessing to LISP family (Scheme/Rackt/Clojure) before golang. (Probably someone else would mention an earlier references :)
  - lolinder 4y ago
    Yep, there's a reason why I credited Golang with mainstreaming the concept, not inventing it. The model goes back quite a ways, but Golang brought it into the mainstream.
- noelwelsh 4y ago
  > Now that (nearly) every mainstream language has lambda expressions, there are very few patterns in functional programming that cannot be replicated in mainstream languages I don't think this is true. Algebraic data types and exhaustive pattern matching, which implies a type system, are the things I use most in my adventures in functional programming. Mainstream languages (for some definition of mainstream) don't yet have these features. The original post doesn't mention pure FP. I don't think purity is that interesting when you can have a type system that can reason about mutation (i.e. linear or affine types, similar to Rust.)
moring 4y ago
> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I hope he is also questioning the premise that functional programming is the reason why functional languages are unpopular. Every time I wanted to dive into functional programming I was very quickly frustrated with the abysmal tooling around them and while that didn't really prevent me from trying, I simply found a better use for my time. Most recent example: Clojure wanting me to choose one of multiple package managers before starting my first project. Before that it was package management nonsense in Haskell, and before that some Scheme interpreter not being able to even give a stack trace on errors. IMHO a really underrated feature of Rust is how friendly its tooling is towards its users. I'd really like to see something like that for functional programming.
- bslatkin 4y ago
  Great examples. Another question that leads to frustration is "can I use my existing code editor for this"? People are turned off when the answer is "no"
  - taeric 4y ago
    What examples force not using an editor? Many have a "natives use this" choice, but few lock you to it.
    - bslatkin 4y ago
      Some parentheses languages are much easier to use if you're familiar with a structural editor, for example.
      - taeric 4y ago
        All languages are easier that way, though? My kids learning python are best with a ton of hand holding. Affordances that show the structure are huge.
        4y ago
klysm 4y ago
The biggest thing I find myself missing from functional languages isn’t the purity or functions - it’s the clean expression of immutable data types combined with exhaustive pattern matching. All I want is algebraic data types and the ability to use the compiler to check my work.
- adastra22 4y ago
  Most new systems languages have this now.
  - klysm 4y ago
    Yes and I’m a huge fan of the movement towards those kind of type systems. I was more commenting on this because I feel like those kind of types frequently get lumped in FP vs OO when there’s more nuance to it
andsoitis 4y ago
Without articulating what particular tradeoffs the author is balancing and sounding like they only recently realized/discovered the parallelism advantage possible to functional programming languages and paradigms, it is hard to know for sure, but I might venture a guess that Julia will be superior to what they are building: https://julialang.org https://julialang.org
- bslatkin 4y ago
  The conversation happened in ~2008. Julia has a lot of great ideas in it for sure. Why hasn't it gotten more popular?
  - lenkite 4y ago
    When it gets out of its data-science pedigree and can be used for standard apps. When it gets good tooling. When its stack-traces stop being arcane gobbledygook. When it can be compiled to a single binary at the command line without going through arcane hoops. When it gets interfaces/protocols/traits. At the moment, Julia is a nice language at v1alpha1 for scripts and data exploration.
    - dermesser 4y ago
      I agree it lacks all of these things, but in scientific computing - at the current state - it is already ahead of fortran, python, and C++ in terms of convenience. Precompilation doesn't matter as much here, and the packaging and JIT compilation as well as relatively simple FFI are making one's life a lot easier. And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds. Yet it's popular.
      - lenkite 4y ago
        "And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds" 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.
fjfaase 4y ago
Functional is a good way to 'specify' how a certain calculation/change has to be performed. When working with distributed systems with multiple actors making changes, you have to treat the whole system (distribute database) as a single value on which your functions operate. Then you can use the commutative properties of function to implement transactions. (If two operations on the system commute, they can be applied in either order on the system, to result in the same state.) But from such a specifying approach to a working system, is a long way.
PaulDavisThe1st 4y ago
I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language. Sure, there are situations where I've been grateful for the ability to use Python (because everything is so easy), or Perl (because sometimes its the right tool for the job) or Lisp (because its slippery fluidity just feels right) rather than the C/C++ that I've generally used during that time. But the hard problems I've faced writing code would (almost?) never be made easier by using functional programming, or Rust, or Go or Swift or Brainfuck. The problems are hard because the problems are hard, and typically for me over the last 23+ years, it has been the combination of generically tough programming problems with performance requirements that ultimately make the choice of language mostly irrelevant. Sure, someone could offer me a thread-safe sparse integer-to-integer mapping container in another language, but then I have to wonder about what design assumptions were made and how performant it is, and if the language was clearly created to prevent me from ever doing such things myself, then I'm going to be deeply suspicious from the outset that it could possibly have my (coding) interests at heart. I understand that I'm not the typical programmer these days, and I don't work on entirely typical problems, but I can't help but feel that sometimes the focus on "languages to help programmers" comes from programmers who just don't enjoy their work enough and/or don't have enough to do.
- naasking 4y ago
  > I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language The language can cause hard problems by itself. Arguably dynamic typing has been partly responsible for driving microservices beyond what's reasonable and thus introduced accidental complexity, largely because they don't have a typing discipline that enforces proper module boundaries. That's the most obvious example to me, but far from the only one.
- bslatkin 4y ago
  I love to swing a hammer as much as the next programmer. But if you offer me a nail gun, even with slightly lower precision, I will happily use it the majority of the time and revert to my hand tools when it's most appropriate. This is about developing force multipliers and producing leverage, not avoiding the craft.
century19 4y ago
I’m surprised he doesn’t mention Scala and Spark.
- bslatkin 4y ago
  I think Spark is a good example of where the functional paradigm has done well in a niche.
karmakaze 4y ago
This other "The case for dynamic, functional programming"[0] post may offer hints. So I suppose it will be more like Elixir/BEAM. > Theoretically, functional programs should: have fewer bugs, be easier to optimize for performance, allow you to add features more quickly, achieve the same outcome with less effort, require less time to get familiarized with a new codebase, etc. With a dynamic, functional language you could enjoy all of this simplicity. In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects. I suppose this will round-out Google languages: Go, Dart, and _, until they make their own scripting or an actual systems language. [0] https://www.onebigfluke.com/2022/11/the-case-for-dynamic-functional.html https://www.onebigfluke.com/2022/11/the-case-for-dynamic-fun...
- ch4s3 4y ago
  > In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects. In so far as I am aware, research doesn't seem to provide compelling evidence one way or the other here.
throwway23432 4y ago
There are a lot of people that have no interest in FP and hate reading functional code which involves reading and understanding recursion, fix-point style, partial application, currying, lazy evaluation, immutable data structures, lambdas, and combinators. Then you have to think of performance characteristics, and debugging, onboarding new engineers, and code reviews. I think it's easy to see why the industry doesn't use FP languages, and because of this people see no reason to even bother with it. I myself would rather use ML family languages or Clojure or BEAM but it will never happen. The majority want to use Python or Go since they are slim on abstraction and easy to pickup. There's no bullshit involved.
twen_ty 4y ago
This must be a troll post because F# already exists and used extensively in production in Azure.
cde-v 4y ago
[flagged]
rurban 4y ago
He has set, not functional. See his Twitter
- bslatkin 4y ago
  It's SSA. If you use (define) in Racket is it no longer functional?
  - rurban 4y ago
    If the setter is at compile-time it might still be functional. If it's at run-time, not. A run-time setter must be a binding (as in lambda args), not an assignment.
Max_Limelihood 4y ago
Because 14 wasn’t enough. https://xkcd.com/927/ https://xkcd.com/927/
juancn 4y ago
The problem is that those are f**king difficult problems to solve. Regardless of how you approach them. No tool or paradigm will make them easy, it may make a part of them easier (at some other cost somewhere else), but by no means will make it easy. Building large scale, low latency systems is really hard. Handling concurrency and shared state is hard. Heck, even functional programming is hard to grok for most people. The evidence is in its popularity (or lack of it). There's no large mystery why we all are not using functional programming exclusively: because it's hard. Imperative, with all it's drawbacks it's easier to grasp and closer to how hardware works. Most people find it more natural, there's no big conspiracy. But (there's always a "but"), the functional paradigm is essential to solve all those hard problems. It provides many tools where many common pitfalls are essentially avoided, but gaining a comfortable grasp of those tools takes work and it's not easy as many claim. They seem easy after you've had the "aha!" moment, but it's like advanced math, getting there takes time and a certain proclivity to it. Once you develop some sort of intuition, you tend to forget the effort it took to gain it. In any case, I love languages and new ideas, so I hope he succeeds (or fails in an interesting way where we learn something new).
pmarreck 4y ago
how did this person possibly write this entire paragraph without once mentioning Erlang or Elixir? It sounds like exactly what he's looking for
- weatherlight 4y ago
  Right?
  - pmarreck 4y ago
    Wait till he discovers it and then... "...Fuuuuck." lol
asyd 4y ago
From the article: "My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized." It's a laudable aim, and I wish you all the best with it. A new language with it's own 'zen', similar to the 'zen of python' but with a functional flavour, is something I'd love to see, and I think it'd do well. Is there something I can read that's a little more specific about the "different tradeoffs" you have in mind?
- bslatkin 4y ago
  Thank you. I think you've basically summarized the approach! If you have any specific guidance to that end please send me an email or DM with details :)
Kamq 4y ago
> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. Personally, I hate type systems. I mean, I tolerate them, but >90% of the benefit I get is via better auto-complete (an possibly better performance). Functional languages (that aren't lisp derived*) all seem to love complicated type systems. And in these systems, at some point I experience the same abstraction collapse as I do in a java code-base when I have to sift through 87 layers of interfaces and sub-classes. I'm also, self-admittedly, a devotee of the New Jersey style of design, and consider usefulness to be much more important than correctness. *The lisp ones are kinda fun, but I always end up back in dirty-old common lisp where I can do crazy do* shenanigans instead of functional lisp land.
- dermesser 4y ago
  Correctness in a program is a bit like Partition-tolerance in distributed systems, isn't it? It's not an option to write (too) incorrect software, even if doing so is a lot faster. At the end of the day, the software needs to do its work.
  - Kamq 4y ago
    Sure, but that's an impact in usefulness. I value correctness as far as it makes the program more useful, but relatively simple type systems are more than enough to get there.
- AnimalMuppet 4y ago
  A program can't be too incorrect (in certain directions) without it affecting usefulness. The type correctness of the language it's written in isn't one of those directions, though.
- voxl 4y ago
  I mean if you want to vomit up buggy software than not having a type system is a pretty good accelerator for that.
dxxvi 4y ago
There are 172 comments until now but Scala was mentioned only 3 times while it has, I think, all the features that are said to be needed for a functional programming language. Then what's wrong with Scala? I'd like Scala to be more successful although I'm using Java and a bit of Kotlin now.
- bslatkin 4y ago
  Scala has a lot of interesting concepts in it for sure! The problem is that the JVM is a deal-breaker, either because of its complexity or because of the associated licensing risk. Clojure has the same problem, for what it's worth.
  - Lerc 4y ago
    I think intrinsic to that deal-breaker is the underlying problem. Memory management in a parallel environment is a tough nut to crack. Leaning on the JVM punts on the issue. 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.
Razengan 4y ago
In my idle brain cycles I've been thinking about a hypothetical implicitly-parallel computing architecture that could be built upon the concept of processing events, instead of the current mostly-linear execution that happens to get interrupted every now and then. Everything would be an event: The computer powers on, user presses a key, an app icon is clicked, OS launches a background task, or an app wants to call its internal routine.. and a central scheduler or something sends that event to all available CPUs/cores, that could work on it simultaneously preferably without needing to worry about getting in each other's way. I'm sure this idea has been around for a while and already has a name. Does anybody know?
tomp 4y ago
It’s not just a “functional programming language”, it’s a lisp! https://mobile.twitter.com/haxor/status/1580959518984241158 https://mobile.twitter.com/haxor/status/1580959518984241158 It will never be popular.
- rurban 4y ago
  emacs-lisp is not popular? autolisp is not popular? think again
mikhailfranco 4y ago
Virding's First Rule of Programming: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

137 points by signa11 4y ago

> The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized. Proceeds to give zero indication how to achieve this.

jalk 4y ago
> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I'm sure there are a multitude of different reason and likely require different conflicting tradeoffs to address
- bslatkin 4y ago
  It's true and that is one of the largest challenges. Producing something that feels familiar (but not error prone) has been the way I've solved such conflicts so far.
User23 4y ago
It basically comes down to nondeterminism. Pure functional languages supposedly make it easier to exploit associativity, commutativity, and distributivity to allow many expressions to have nondeterministic semantics that are amenable to concurrent execution. Argument evaluation also can be specified nondeterministic so the runtime is free to execute something like the following with two or more CPU threads: f(g(), h()) Of course a well designed imperative language could also avoid overspecifying deterministic semantics and open itself up to similar optimizations, but for various reasons that hasn’t caught on. One example would be specifying the conditional to select a branch with a true guard nondeterministically rather than deterministically in the order of appearance in the program text. Dijkstra’s EWDs give many practical examples of why one might want such a thing. Another example would be deducing when statement composition is symmetric and allowing nondeterminism when it is. For example if f and g don’t have access to each other’s data then the following can be executed in two threads even with mutation: f(); g() Side effects will appear nondeterministically though which may or may not be a problem. As always an algorithm needs to be designed for the semantics the language has not those the programmer wishes it does.
- alexisread 4y ago
  This makes a good case for effect systems in conjunction with FP, so they can be reasoned about as well. Something like https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html Having said that, having something like Daedelus in there as well would give a handle on temporal-based determinism, and then some allowance for delimited continuations would top things off nicely.
worksonmine 4y ago
In his defense the title is "why" not "how". I guess you'll have to spend some sleepless nights waiting for the follow-up.
- bslatkin 4y ago
  I'm sorry to make you wait.
lolinder 4y ago
It's a four paragraph blog post answering the question "why?". I'm not sure why you expect him to delve into the how at this stage: he probably doesn't have anything fully formed yet.
- iampims 4y ago
  https://twitter.com/haxor/status/1582878447134572544?s=20 https://twitter.com/haxor/status/1582878447134572544?s=20 Looks like the syntax is taking shape at least.
  - noelwelsh 4y ago
    No language syntax needs return in 2023.
    - bslatkin 4y ago
      How should an early return if statement work instead?
      - noelwelsh 4y ago
        When if is an expression early returns aren't really a problem.
        bslatkin 4y ago
        I understand what you mean. But I expect most potential users want explicit returns because they're familiar and more approachable for beginners.
        noelwelsh 4y ago
        I disagree. You make two claims: familiarity, and beginner friendliness. 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. :-)
karmakaze 4y ago
Very disappointed by the non-announcement. If it were a corp, it would be FUD. I'm curious as to what these different trade-offs are. > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. My conclusion is because most everyone is taught to think empirically and 'play computer' that functional doesn't fit in their preconceived brains. I once had someone say SQL didn't make sense because it's SELECTing fields (i.e. vars) before they're defined/assigned later in the (binding) expressions. People having trouble with FP is like how people who learn databases using ORM's don't deal well with SQL as expressions of set operations. There are varying limits to how much people like and handle abstract constructs before applying the construction to the data at hand but you can do a whole lot of effective and unsurprising development before getting to such esoteric levels. Edit: I was super-excited to open the link, and now on re-reading expect this new FP language to be as much an advancement as Go was to 'systems' programming. I hope I'm mistaken. Also odd that only Haskell and Lisp were mentioned when there are so many others. On the plus-side if Google were to make F# and back it as well as they have Go, that would be a win-win.
- karmakaze 4y ago
  After reading their other post "The case for dynamic, functional programming", I would classify this as FUD, or rather NIH. Go got support by being touted as "Not Java". I can't say that this would gain much by being declared as "Not Elixir".
- lolinder 4y ago
  > it would be FUD I thought FUD stood for Fear Uncertainty Doubt—it's usually used to indicate that something is designed to sow fear for clicks or for some ulterior motive, not for insubstantial non-announcements. Did something in this post evoke fear?
  - karmakaze 4y ago
    The point of FUD is usually to carve out a space where existing products/solutions can't compete with idealized vapourware. I updated my opinion to NIH (though could be both)--and still hope to be mistaken.

mark_l_watson 4y ago

The article is light on details, but as a polyglot programmer, I encourage him. I am an enthusiastic, but far from expert, Haskell programmer. I wonder if Brett is thinking of a more Python-like interpreted functional language?

bslatkin 4y ago
Thank you! Imagine everything we like about Python, remove some warts, make it functional. It should feel familiar and appealing to a Python programmer.
- eternalban 4y ago
  Based on above it seems you want to test the hypothesis that 'there is a python-like functional language in the space of FP'. Is there anything ~technical you can share beyond desires and disappointments that leads you to believe this is a reasonable hypothesis?
  - bslatkin 4y ago
    I've got a working interpreter and compiler for the initial language. I've had a few people take it for a spin and they were able to rapidly learn it and start contributing, despite having expressed frustration in trying FP languages in the past. All anecdotes for now!
    - eternalban 4y ago
      Ah, you already have it. Now we're all intrigued! Looking forward to the public release.
    - ch4s3 4y ago
      I'm pretty deep in on Elixir, but I'd be quite interested to take a look.

nextaccountic 4y ago

> He spoke of the potential for functional languages to provide a significant, intrinsic advantage when it comes to parallel computing. > (...) > If that were true, you'd expect that the many existing functional programming languages would have already satisfied this need. But in my opinion, they haven't Well there is https://futhark-lang.org/ https://futhark-lang.org/ - it runs on the GPU, and is awesome. On the CPU side, I think that Rust plus https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon was a huge breakthrough on writing parallel programs using both functional and imperative programming, and future languages should learn from its successes. The ownership system & the borrow checker, plus other type-level features like the Send and Sync traits, were essential to enable sharing read-only data between threads without synchronization, or sharing read-write data with synchronization, all checked at compile time for data races (which is a huge problem to solve, and is something that neither Go nor Java protects against at compile time) Indeed Futhark shares a key feature with Rust: it uses uniqueness types to enable in-place updates, which is kind like a limited form of Rust ownership: if you are the sole user of some memory, you can update it and other code will be none the wiser. This kind of thing is very important to build functional programs that are performant in practice.

tsegratis 4y ago
Fair point It may be better to see rust as sitting between functional and imperative paradigms
klavinski 4y ago
See also the Higher-Order Virtual Machine for a functional, non-garbage-collected, and parallel runtime: https://github.com/HigherOrderCO/HVM https://github.com/HigherOrderCO/HVM
- nextaccountic 4y ago
  Hey, that's pretty cool! The lang that targets this runtime is https://github.com/HigherOrderCO/Kind https://github.com/HigherOrderCO/Kind

dimitar 4y ago

So why would Clojure or Erlang or Elixir fail to satisfy the need for a functional language capable of taking advantage of the available cores?

davidw 4y ago
Seems like he's talking about parallelism rather than concurrency? Erlang does the latter pretty well, but I'm not sure it's that great for "I have a lot of processing to do and I want the language to help parallelize it", especially since it's also not the fastest thing out there.
- weatherlight 4y ago
  Have you used Broadway, its pretty fast. I think people forget how expensive it is to serialize/deserialize data between machines/nodes.
lolinder 4y ago
I don't think he's arguing that the existing functional languages can't take advantage of all cores, it sounds like he believes that the existing functional languages cannot reach mainstream adoption because of fundamental flaws that he hopes to address: > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized.
- bslatkin 4y ago
  Exactly.
  - redbar0n 4y ago
    > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. What are those reasons, in your view?

nothrowaways 4y ago

Short answer, because I am bored.

robertlagrant 4y ago
"I want to be paid a fortune for making a programming language, so I need a reason." Of course, I would do the same in their position.
- bslatkin 4y ago
  It's an unpaid personal open source project.

xutopia 4y ago

What language is he working on though? Can we see the initial ideas in the syntax?

iLoveOncall 4y ago

As always for those niche languages, if the answer is not personal entertainment, then the reality is that it's just poor judgement.

alexisread 4y ago

I'll drop this here: https://github.com/manuel/wat-js https://github.com/manuel/wat-js If you have delimited continuations then you can construct coroutines/threads/await/async, promises etc. I guess that this might be suitable for many scenarios thanks to nodejs, but the runtimes it relies on are not exactly small.

evanwang0 4y ago

While certainly true that functional programming provides an intrinsic advantage to programming parallelism, parallelism is limited by hardware constraints. To best take advantage of CPU architectures，”function” execution needs to optimize usage of caching layers and execution threads. This naturally lends itself to the development of event loops/schedulers in functional runtimes like node and erlang.

Hizonner 4y ago

> once asked Guido van Rossum (the creator of Python [...]) [...] Uh-oh... You know, I was just programming in Python yesterday, and I was once again reminded of how ANNOYING a language it is... how annoying it is that it's so popular that I'm essentially forced to code in it. Especially now that a bunch of (probably needed) changes have been made in half-assed ways that interact clunkily with its original rather, um, idiosyncratic structure, syntax, and philosophy, which for a long time were determined almost entirely by one person's idea of what was intuitive. I mean, it's not JavaScript-level annoying or Perl-level chaotic, but it's a pretty damned annoying language. > Although our tools have continued to improve (such as golang), Uh-oh... Another language that grabbed some popularity by fixing some things, but still fails to systematically Do Things Right, even though we're now like 50 or 75 years into this whole computer thing, and are at a point where we ought to have a mature understanding of what Right is and the time to act with deliberation. One of the ways it grabbed that popularity was, of course, by looking familiar and unintimidating to people who don't like "weird languages". > By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. Uh-oh...

bruce343434 4y ago
Can you explain how python is annoying?
lillywastaken 4y ago
I'd rather use JS than python, since at least JS doesn't actively try making programming in a functional style worse

lolinder 4y ago

> Why is the gap between these two perspectives so large? My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. Now that (nearly) every mainstream language has lambda expressions, there are very few patterns in functional programming that cannot be replicated in mainstream languages, which means that moving to a pure functional language now provides strictly fewer choices when problem solving. In order for a programmer to accept a language with strictly less expressive power, those new restrictions must solve problems that the programmer actually cares about. Rust reached adoption because mainstream systems programmers recognized that memory errors are a huge problem and dealing with the borrow checker is worth it to solve them. Static typing reached mainstream adoption because it made coordinating work in a large team dramatically easier and solved refactoring. Functional-style programming has hit the mainstream—embedded within imperative and OO code—but purely functional languages have yet to make a good case for their additional restrictions, and I'm not convinced that multiprocessing is that case. Golang mainstreamed a very effective model for multiprocessing in an imperative environment that solves most of the problems without asking programmers to completely change the way they write code, and that model is increasingly being adopted in other languages (Java's project loom, for example).

amitport 4y ago
I would credit this model for multiprocessing to LISP family (Scheme/Rackt/Clojure) before golang. (Probably someone else would mention an earlier references :)
- lolinder 4y ago
  Yep, there's a reason why I credited Golang with mainstreaming the concept, not inventing it. The model goes back quite a ways, but Golang brought it into the mainstream.
noelwelsh 4y ago
> Now that (nearly) every mainstream language has lambda expressions, there are very few patterns in functional programming that cannot be replicated in mainstream languages I don't think this is true. Algebraic data types and exhaustive pattern matching, which implies a type system, are the things I use most in my adventures in functional programming. Mainstream languages (for some definition of mainstream) don't yet have these features. The original post doesn't mention pure FP. I don't think purity is that interesting when you can have a type system that can reason about mutation (i.e. linear or affine types, similar to Rust.)

moring 4y ago

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I hope he is also questioning the premise that functional programming is the reason why functional languages are unpopular. Every time I wanted to dive into functional programming I was very quickly frustrated with the abysmal tooling around them and while that didn't really prevent me from trying, I simply found a better use for my time. Most recent example: Clojure wanting me to choose one of multiple package managers before starting my first project. Before that it was package management nonsense in Haskell, and before that some Scheme interpreter not being able to even give a stack trace on errors. IMHO a really underrated feature of Rust is how friendly its tooling is towards its users. I'd really like to see something like that for functional programming.

bslatkin 4y ago
Great examples. Another question that leads to frustration is "can I use my existing code editor for this"? People are turned off when the answer is "no"
- taeric 4y ago
  What examples force not using an editor? Many have a "natives use this" choice, but few lock you to it.
  - bslatkin 4y ago
    Some parentheses languages are much easier to use if you're familiar with a structural editor, for example.
    - taeric 4y ago
      All languages are easier that way, though? My kids learning python are best with a ton of hand holding. Affordances that show the structure are huge.
      - 4y ago

klysm 4y ago

The biggest thing I find myself missing from functional languages isn’t the purity or functions - it’s the clean expression of immutable data types combined with exhaustive pattern matching. All I want is algebraic data types and the ability to use the compiler to check my work.

adastra22 4y ago
Most new systems languages have this now.
- klysm 4y ago
  Yes and I’m a huge fan of the movement towards those kind of type systems. I was more commenting on this because I feel like those kind of types frequently get lumped in FP vs OO when there’s more nuance to it

andsoitis 4y ago

Without articulating what particular tradeoffs the author is balancing and sounding like they only recently realized/discovered the parallelism advantage possible to functional programming languages and paradigms, it is hard to know for sure, but I might venture a guess that Julia will be superior to what they are building: https://julialang.org https://julialang.org

bslatkin 4y ago
The conversation happened in ~2008. Julia has a lot of great ideas in it for sure. Why hasn't it gotten more popular?
- lenkite 4y ago
  When it gets out of its data-science pedigree and can be used for standard apps. When it gets good tooling. When its stack-traces stop being arcane gobbledygook. When it can be compiled to a single binary at the command line without going through arcane hoops. When it gets interfaces/protocols/traits. At the moment, Julia is a nice language at v1alpha1 for scripts and data exploration.
  - dermesser 4y ago
    I agree it lacks all of these things, but in scientific computing - at the current state - it is already ahead of fortran, python, and C++ in terms of convenience. Precompilation doesn't matter as much here, and the packaging and JIT compilation as well as relatively simple FFI are making one's life a lot easier. And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds. Yet it's popular.
    - lenkite 4y ago
      "And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds" 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.

fjfaase 4y ago

Functional is a good way to 'specify' how a certain calculation/change has to be performed. When working with distributed systems with multiple actors making changes, you have to treat the whole system (distribute database) as a single value on which your functions operate. Then you can use the commutative properties of function to implement transactions. (If two operations on the system commute, they can be applied in either order on the system, to result in the same state.) But from such a specifying approach to a working system, is a long way.

PaulDavisThe1st 4y ago

I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language. Sure, there are situations where I've been grateful for the ability to use Python (because everything is so easy), or Perl (because sometimes its the right tool for the job) or Lisp (because its slippery fluidity just feels right) rather than the C/C++ that I've generally used during that time. But the hard problems I've faced writing code would (almost?) never be made easier by using functional programming, or Rust, or Go or Swift or Brainfuck. The problems are hard because the problems are hard, and typically for me over the last 23+ years, it has been the combination of generically tough programming problems with performance requirements that ultimately make the choice of language mostly irrelevant. Sure, someone could offer me a thread-safe sparse integer-to-integer mapping container in another language, but then I have to wonder about what design assumptions were made and how performant it is, and if the language was clearly created to prevent me from ever doing such things myself, then I'm going to be deeply suspicious from the outset that it could possibly have my (coding) interests at heart. I understand that I'm not the typical programmer these days, and I don't work on entirely typical problems, but I can't help but feel that sometimes the focus on "languages to help programmers" comes from programmers who just don't enjoy their work enough and/or don't have enough to do.

naasking 4y ago
> I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language The language can cause hard problems by itself. Arguably dynamic typing has been partly responsible for driving microservices beyond what's reasonable and thus introduced accidental complexity, largely because they don't have a typing discipline that enforces proper module boundaries. That's the most obvious example to me, but far from the only one.
bslatkin 4y ago
I love to swing a hammer as much as the next programmer. But if you offer me a nail gun, even with slightly lower precision, I will happily use it the majority of the time and revert to my hand tools when it's most appropriate. This is about developing force multipliers and producing leverage, not avoiding the craft.

century19 4y ago

I’m surprised he doesn’t mention Scala and Spark.

bslatkin 4y ago
I think Spark is a good example of where the functional paradigm has done well in a niche.

karmakaze 4y ago

This other "The case for dynamic, functional programming"[0] post may offer hints. So I suppose it will be more like Elixir/BEAM. > Theoretically, functional programs should: have fewer bugs, be easier to optimize for performance, allow you to add features more quickly, achieve the same outcome with less effort, require less time to get familiarized with a new codebase, etc. With a dynamic, functional language you could enjoy all of this simplicity. In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects. I suppose this will round-out Google languages: Go, Dart, and _, until they make their own scripting or an actual systems language. [0] https://www.onebigfluke.com/2022/11/the-case-for-dynamic-functional.html https://www.onebigfluke.com/2022/11/the-case-for-dynamic-fun...

ch4s3 4y ago
> In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects. In so far as I am aware, research doesn't seem to provide compelling evidence one way or the other here.

throwway23432 4y ago

There are a lot of people that have no interest in FP and hate reading functional code which involves reading and understanding recursion, fix-point style, partial application, currying, lazy evaluation, immutable data structures, lambdas, and combinators. Then you have to think of performance characteristics, and debugging, onboarding new engineers, and code reviews. I think it's easy to see why the industry doesn't use FP languages, and because of this people see no reason to even bother with it. I myself would rather use ML family languages or Clojure or BEAM but it will never happen. The majority want to use Python or Go since they are slim on abstraction and easy to pickup. There's no bullshit involved.

twen_ty 4y ago

This must be a troll post because F# already exists and used extensively in production in Azure.

cde-v 4y ago

[flagged]

rurban 4y ago

He has set, not functional. See his Twitter

bslatkin 4y ago
It's SSA. If you use (define) in Racket is it no longer functional?
- rurban 4y ago
  If the setter is at compile-time it might still be functional. If it's at run-time, not. A run-time setter must be a binding (as in lambda args), not an assignment.

Max_Limelihood 4y ago

Because 14 wasn’t enough. https://xkcd.com/927/ https://xkcd.com/927/

juancn 4y ago

The problem is that those are f**king difficult problems to solve. Regardless of how you approach them. No tool or paradigm will make them easy, it may make a part of them easier (at some other cost somewhere else), but by no means will make it easy. Building large scale, low latency systems is really hard. Handling concurrency and shared state is hard. Heck, even functional programming is hard to grok for most people. The evidence is in its popularity (or lack of it). There's no large mystery why we all are not using functional programming exclusively: because it's hard. Imperative, with all it's drawbacks it's easier to grasp and closer to how hardware works. Most people find it more natural, there's no big conspiracy. But (there's always a "but"), the functional paradigm is essential to solve all those hard problems. It provides many tools where many common pitfalls are essentially avoided, but gaining a comfortable grasp of those tools takes work and it's not easy as many claim. They seem easy after you've had the "aha!" moment, but it's like advanced math, getting there takes time and a certain proclivity to it. Once you develop some sort of intuition, you tend to forget the effort it took to gain it. In any case, I love languages and new ideas, so I hope he succeeds (or fails in an interesting way where we learn something new).

pmarreck 4y ago

how did this person possibly write this entire paragraph without once mentioning Erlang or Elixir? It sounds like exactly what he's looking for

weatherlight 4y ago
Right?
- pmarreck 4y ago
  Wait till he discovers it and then... "...Fuuuuck." lol

asyd 4y ago

From the article: "My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized." It's a laudable aim, and I wish you all the best with it. A new language with it's own 'zen', similar to the 'zen of python' but with a functional flavour, is something I'd love to see, and I think it'd do well. Is there something I can read that's a little more specific about the "different tradeoffs" you have in mind?

bslatkin 4y ago
Thank you. I think you've basically summarized the approach! If you have any specific guidance to that end please send me an email or DM with details :)

Kamq 4y ago

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. Personally, I hate type systems. I mean, I tolerate them, but >90% of the benefit I get is via better auto-complete (an possibly better performance). Functional languages (that aren't lisp derived*) all seem to love complicated type systems. And in these systems, at some point I experience the same abstraction collapse as I do in a java code-base when I have to sift through 87 layers of interfaces and sub-classes. I'm also, self-admittedly, a devotee of the New Jersey style of design, and consider usefulness to be much more important than correctness. *The lisp ones are kinda fun, but I always end up back in dirty-old common lisp where I can do crazy do* shenanigans instead of functional lisp land.

dermesser 4y ago
Correctness in a program is a bit like Partition-tolerance in distributed systems, isn't it? It's not an option to write (too) incorrect software, even if doing so is a lot faster. At the end of the day, the software needs to do its work.
- Kamq 4y ago
  Sure, but that's an impact in usefulness. I value correctness as far as it makes the program more useful, but relatively simple type systems are more than enough to get there.
AnimalMuppet 4y ago
A program can't be too incorrect (in certain directions) without it affecting usefulness. The type correctness of the language it's written in isn't one of those directions, though.
voxl 4y ago
I mean if you want to vomit up buggy software than not having a type system is a pretty good accelerator for that.

dxxvi 4y ago

There are 172 comments until now but Scala was mentioned only 3 times while it has, I think, all the features that are said to be needed for a functional programming language. Then what's wrong with Scala? I'd like Scala to be more successful although I'm using Java and a bit of Kotlin now.

bslatkin 4y ago
Scala has a lot of interesting concepts in it for sure! The problem is that the JVM is a deal-breaker, either because of its complexity or because of the associated licensing risk. Clojure has the same problem, for what it's worth.
- Lerc 4y ago
  I think intrinsic to that deal-breaker is the underlying problem. Memory management in a parallel environment is a tough nut to crack. Leaning on the JVM punts on the issue. 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.

Razengan 4y ago

In my idle brain cycles I've been thinking about a hypothetical implicitly-parallel computing architecture that could be built upon the concept of processing events, instead of the current mostly-linear execution that happens to get interrupted every now and then. Everything would be an event: The computer powers on, user presses a key, an app icon is clicked, OS launches a background task, or an app wants to call its internal routine.. and a central scheduler or something sends that event to all available CPUs/cores, that could work on it simultaneously preferably without needing to worry about getting in each other's way. I'm sure this idea has been around for a while and already has a name. Does anybody know?

tomp 4y ago

It’s not just a “functional programming language”, it’s a lisp! https://mobile.twitter.com/haxor/status/1580959518984241158 https://mobile.twitter.com/haxor/status/1580959518984241158 It will never be popular.

rurban 4y ago
emacs-lisp is not popular? autolisp is not popular? think again

mikhailfranco 4y ago

Virding's First Rule of Programming: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.