I’ve had the “luxury” of maintaining Forth programs with poor factoring, and it’s these kinds of programs that results in Forth’s “write-only” conception. This is absurdly false; Forth is no more write-only than Java, which I’ve also had to maintain, particularly programs with six page-long methods. You read that right — SIX PAGES LONG. I’ll take write-only Forth over a six-page method definition in Java any day.

I’ve also had the abject pleasure of maintaining (and even authoring) Forth code that follows the aforementioned guideline, along with the “one definition, one line” guideline, which resulted in a plethora of positive e-mails suggesting how readable the code was — less than HALF of the respondents were proficient in Forth (many claimed it was their first exposure to the language). So what does this tell us?

It tells me that people who b***h and moan over RPN syntax and how oh-so-hard it is to “get it”, blah blah blah, really needs to wake up and evaluate how they write their own code. Nearly always, these are the kinds of programmers who don’t give a hoot about the quality, readability, or stability of their code, because they feel that their proficiency in the language of their choice and training is such that they can do no wrong. Therefore, RPN languages are useless toys, and can’t possibly be used for grunt programming in real-world situations.

(Except that UPS and Fedex use digital signature tablets coded in Forth. Power companies use electrical switches coded in Forth. GE released a SONET switch whose OS **IS** Forth — plug in a serial console, and you’ll get the OK prompt! Half of the orbiters around Mars run on Forth. Our space shuttle’s robotic arm and flight nav computers are programmed in Forth. Etc. Etc. Etc.)

A program written well in a concatenative language will be shorter, easier to understand, and easier to reason about than a comparable program in an applicative language. Because the stack replaces the use of local variables in most cases (of Factor’s entire codebase, for example, locals were used in only 60 places, IIRC), issues concerning aliasing and update order disappear. The explicit DUPs and SWAPs and so forth make register allocation somewhat easier, since the compiler now has unequivocal knowledge of the lifetime of a register’s value. It encourages a more lucid style of programming that isn’t so math-centric (so-called “fluent” style of coding). Ironically, concatenation is simply function composition, and as such can be reasoned about in a functional manner.

While I respect other’s opinions on concatenative languages, to which they’re free to express, I can’t help but feel quite upset and even threatened when people make such absurd notions as the “difficulty” of learning such languages public. Research shows people *naturally* follow a noun-verb order when communicating with others without a common language, and one need only remember just how difficult it was for you to learn algebra during highschool to understand the “difficulty of learning” infix notations! Prior to your algebra lessons, learning about the semantics of variable substitution, the difficulties of memorizing the FOIL method and factoring, et. al., is something that concatenative notation would have TOTALLY eliminated from the get-go. I’ve seen five year olds do some mighty sophisticated arithmetic using concatenative notations, but few understand how to properly parse the quadratic formula.

So give me a break with this hard to learn stuff. It’s not hard to learn. What *IS* hard is your inability to break out of your intellectual gutter.

Both forms work just fine. In fact, the Scala parser turns them into the same thing under the surface. I tend to prefer the curly-brace form for stylistic reasons (I think it’s more clear that a closure is involved, rather than just a normal construct). There are times that I use the ()=> form, but not many.

val plus = (x: Int, y: Int) => x + y
plus(2, 3)

Running that through the interpreter seems to work fine. I’m wondering if there is any difference in meaning between the two forms. Was that just for grouping, or does it mean something very different?

2 3 plus
10

I think Cat’s main weak point is that some algorithms that require random-access variables can be extremely clumsy to express. It’s not terribly hard to think in terms of the stack, but that doesn’t mean that it’s the cleanest way to do things.

I’m also unsure whether or not Cat has any meaningful integration with the common object system. If not, then it is absolutely not worth looking at for any real work.

I believe that programming is about trade offs. I think that almost every principle, rule, guideline, model, paradigm, you name it, has its pros and cons. Focusing on PL paradigms then one can say (forgive me for the over simplification) that FP languages are good for writing computations/algorithms but not as natural for handling I/O. Given your experience with Cat, could you highlight its weak points? (its strong points are obvious).

Nope, Cat isn’t one of the supported languages. I had to write a custom GeSHi mode for it based on the language specification. I’ve had to do that a few times now, including with Scala and SML. Most of the time I just base the mode on jEdit’s highlighting, but even that editor doesn’t have a Cat mode that I know of.

Of course the bytecode nonsense was sarcasm. More importantly, I was trying to differentiate between commonly used high-level languages and rarely used low-levels. Bytecode is an awesome stack oriented language, but it is rarely written by hand. At least, hardly at all in proportion to the amount of auto-generation which takes place. Also, it’s filled with a number of low-level operations more reminiscent of assembly than ML.

@Itay

Actually, I’ve been playing with stack-based languages for a few weeks now on-and-off, and I’ve found very much to my surprise that the stack “goes away” over time. It’s like the parentheses in Lisp. I can’t say that it’s as natural as writing code involving named variables with random access, but it’s not too bad. One thing Cat has going for it that the JVM lacks is higher-order functions (quotations). These simplify things tremendously. In fact, so much so that Cat doesn’t have separate stacks and entirely lacks any variable mechanism (unlike Forth and Factor).

@Barry

Thanks for the clarification on RPN! I threw in the reference half for coolness sake, I really know absolutely nothing about the language.

With regards to your comments on typing, just wait for Part 3. It is true that conventional stack-based expressions are very easy to type: it just falls out without any effort whatsoever. The first problem is in polymorphic arguments (e.g. pop, swap, dup). That’s easily overcome by adding universal types to the stack typing, but it doesn’t solve every problem. It turns out that higher-order functions are the real issue. If you’re impatient with regards to why and how it is resolved, I suggest you play around with Cat a little bit: it is a statically typed stack-based language with full inference.

http://www.ece.cmu.edu/~koopman/stack_computers/index.html

-m