Hacker News new | comments | show | ask | jobs | submit login

Parentheses, tuples, for loops... my first impression is it doesn't look very concatenative.

The Levenshtein example isn’t the best. It’s also using an older version of the language with things like mixfix operators (“from()to(){}”) which have since been removed.

Anyway, Kitten is concatenative at the term level (all terms denote functions, juxtaposition is composition) but not the token level as in Forth (e.g., “{” and “}” are not meaningful words on their own).

Interesting, I am curious as to why you are concatenative at the term level only. Is it trying to make syntax more palatable to ALGOL family programmers?

PS: I loved your "why concatenative programming matters" article

Sorry but I have to be negative here because I love Forth.

People tried to make Lisp/Scheme less 'prefix', and it didn't fly. People tried to make Forth less 'postfix', and it didn't fly.

The whole point of concatenative languages is the simple syntax and implementation.

I wrote a Forth dialect in C - actually I wrote many over the years because it's a refinement and adaptation process, but I'll talk about the one I'm currently using. Its core is a little less than 2K SLOC that compile into a ~30Kb (yes, kilobytes) (~60Kb for Windows 32bits) . It uses a very straightforward direct threaded scheme - something like (ip++)() - but that's plenty fast already (think Lua-fast).

It's easy to modify because, well, I wrote it from top to bottom. At some point I wish I had separators for number and binary numbers. In an hour or so I could write things like 0b1010_1001. At one point I was tired to write "test.4" load*. I hacked the interpreter so that when it sees a word that ends with ".4" it tries to load the file with that name. Very handy. At some point I wish I could embed my interpreter into a large embedded application to help with debugging. No problem either.

It's easy to extend. Need more accurate time stamps? Here you go:

    static void p_getms(void)
	struct timeval t;
	gettimeofday(&t, NULL);
And then you add the function in an array to "register" it, like you do in Lua.

I can write bindings to libraries almost on-the-fly thanks to the braindead API which consists mainly in push() and pop(). No FFI required. It's also trivial to translate a piece of code from Forth to C when you need speed. I think it could even be automated.

THIS is what Forth is really about. I don't see the point of having people "think concatenative" if they don't have all this in return.

You want static typing? I can understand, because Forth is quite unforgiving and will segfault if you make a mistake and that can be annoying. Actually, when I started to write the interpreter I'm currently using, my plan was to write some kind of "linter" to help with that. However as an embedded systems programmer I'm pretty used to printf() debugging (it might be a bad habit) and Forth is pretty good at that because you can invoke a REPL very easily. So I have yet to find the motivation to write that Linter.

Clojure syntax looks like a cross between common lisp and javascript, but it manages to be the most popular lisp around by a country mile. On the one hand I find it distasteful, on the other hand it hasn't seemed to hurt adoption. I don't know if it drove adoption though - it's probably more likely due to the fact the inventor of the language is a charismatic and prolific speaker. But I digress...

I kind of agree with you. I don't think "softening" the syntax of a concatenative languages is going to help much, and is more likely to drive away the kind of PL dabblers who are interested in concatenative languages in the first place. The vast majority of programmers will never try anything that doesn't resemble ALGOL at least a bit. It's a lost cause to try and reel them in.

IMO, the best way for nice languages to thrive is to be simple enough that it's easy for a small number of people to maintain, and powerful enough that the implementation and standard library can be constructed in as few LOC as possible to minimize bugs. Being able to attach itself to an existing large ecosystem with a minimum of fuss (ie, embedable in C or Java interop) also seems to be a great trojan horse.

> The whole point of concatenative languages is the simple syntax and implementation.

That’s a major part of it, and certainly the selling point of Forth—you can build, understand, and extend everything yourself, from the ground up.

But the reason I came to concatenative languages in the first place was that I saw the power of a compositional style of programming in Haskell, and I wanted to bring that high-level thinking over to a lower-level language with a simpler performance model than laziness+GC.

Remember also that the Forth family and the Joy family are a case of convergent evolution: Manfred Von Thun chose postfix syntax and a stack-machine implementation for Joy because it was a natural way to reason compositionally about programs. The Forth similarity was discovered soon after, and certainly had an influence on the design. But Joy wasn’t really a Forth, and neither are its descendants: Factor is more of a postfix Lisp, Kitten a postfix ML.

Yes, that’s basically it. Most programmers are unfamiliar with the paradigm, so I figured I should keep the syntax as familiar as possible to get people in the door. But it’s mostly syntactic sugar for regular stack machine code, with a mildly fancy type system on top.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact