The ergonomic drawback of concatenative languages is that when you see `a b c d e`, you don’t know whether it means `e(d(c(b(a))))`, or `e(b(a), d(c))`, or `e(a, b, c, d)`, or `b(a), e(c, d)`, etc. The answer depends on the types of a, b, c, d, and e. The syntax `a b c d e` is a linearization of the call tree, whose node structure can be recovered from the types of the symbols (assuming the language is statically typed). As a human reader, it means you have to know the types to understand the structure of the expression. This imposes a cognitive load that other types of languages don’t.<p>It also removes redundancy that can be helpful to prevent programming errors. While the type checker verifies that the types match <i>a</i> structuring of the expression, that derived structure is not directly visible to the human programmer, and the programmer cannot easily see whether it actually matches the programmer’s understanding.
I completely disagree with this analysis:<p>> The reason “Why Functional Programming Matters” was necessary in the first place was that functional programming had been mischaracterised as a paradigm of negatives—no mutation, no side-effects—so everybody knew what you couldn’t do, but few people grasped what you could.<p>The issue with functional programming, and the reason for that referenced piece, aren't because people don't know what you can do with functional programming languages.<p>It's because people don't know why they should <i>care</i>.<p>Things like "immutability, referential transparency, mathematical purity" are pretty, and it's neat to see the machinery applied in practice, but in the end people pick their tools because they help them get their jobs done more effectively, and it's exceedingly difficult to explain to a working programmer why "referential transparency" is gonna meaningfully improve their lives.<p>This piece, then, starts from this basic misunderstanding and proceeds to make precisely the same mistake.<p>Yes, what the author demonstrates in this piece is pretty neat. But why should I <i>care</i>? What would motivate me to move off of the imperative languages I'm already familiar with?
I can understand why people get excited about the concatenative paradigm, but I’ll concede that my personal take is “Sounds like some bits of LISP married to the point free obsession of some Haskell programmers”
If you're interested, this article by Henry Baker draws a connection between permutation stack machines and linear types/GC-free memory management: "Linear Logic and Permutation Stacks--The Forth Shall Be First"<p><a href="https://www.plover.com/~mjd/misc/hbaker-archive/ForthStack.html" rel="nofollow">https://www.plover.com/~mjd/misc/hbaker-archive/ForthStack.h...</a>
I didn't see it linked from the article, Jon Purdy has a great talk about this too: "Concatenative Programming: From Ivory to Metal" (2017)
<a href="https://www.youtube.com/watch?v=_IgqJr8jG8M" rel="nofollow">https://www.youtube.com/watch?v=_IgqJr8jG8M</a><p>There's also "A Conversation with Manfred von Thun" <a href="http://archive.vector.org.uk/art10000350" rel="nofollow">http://archive.vector.org.uk/art10000350</a> which is worth reading (IMO) if you're interested in concatenative languages. He's the creator of Joy.<p>I've been working with Joy over the last few years now and I really think there's something there. It seems to combine the best features of both Forth and Lisp.
Author ended up doing a lot of work on Kitten <a href="https://github.com/evincarofautumn/kitten" rel="nofollow">https://github.com/evincarofautumn/kitten</a>
I'm writing a concatenative language with a C-similar syntax. As a first language (to write) I've found it very pleasant. Following the forth models, I start with an extremely lean (~2000 lines of C) VM and assembly and that builds a macro-based language in a few thousand lines -- all in a single build+execute step.<p>I'm currently implementing function syntax, and the type system will be next (also C like with a bit of interface-like "Role" objects and type extension)<p>GitHub.com/civboot/fngi
<a href="https://www.concatenative.org/" rel="nofollow">https://www.concatenative.org/</a> might be interesting for some folks