Having been a long-time user of HP series of calculators (HP48g, HP50g), postfix notation is not foreign to me. So I tried Factor, and gave up on it for several reasons.

First, there were obligatory stack effect declarations on each word. Want to refactor your program? Sure, rewrite your words, together with stack effect declarations. That part was extremely annoying when it came to exploratory programming. For the uninitiated: stack effect declarations are akin to function prototypes in C, only lacking type information. IMO, once you have them, and they're obligatory, you get all the drawbacks of postfix languages, and no benefits.

Second, the language and standard library rely heavily on stack combinators. Reading the standard library code requires intimate familiarity of what words like bi, bi@ and bi* do (among a whole lot of others).

Third, I find Factor's documentation extremely confusing. For example, there are "Vocabulary index" and "Libraries" sections, with little or no overlap between them. But vocabulary is a library (or package, whatever, same thing), so WTF?!

Then there are important and powerful features like generic words, but if you click on the "Language reference" link on the docs homepage, you get a menu with no mention of generics, and you have little clue in which section to look for them. (It's under objects.) Then you eventually find out (sorry, I was unable to dig up reference to the docs) that generics support only single dispatch, and only "math" generics (plus, minus, etc.) support double dispatch.

In short, the manual is a maze of cross-references with no head or tail.

Fourth, I dislike writing control structures in postfix. This is the part that, IMO, RPL on HP's calculators got right. Instead of forcing you to write something like

    10
    "Less than 10"
    "Greater than 10"
    [ < ] 2dip if ! 2dip is a stack combinator, guess what it does!

    IF 10 < THEN "Less than 10" ELSE "Greater than 10" END

Last but not least, it supports only cooperative threads.

It takes a few hours to get used to, but once you get the hang of it it becomes an amazing language. For most things postfix notation that Factor uses reads better than applicative (prefix) notation other languages uses. It's like jQuery's or linq's method chaining, only better :) and with less syntax. For example here is the solution to problem 22 in Project Euler (http://projecteuler.net/problem=22):

    : names ( -- seq )
         "names.txt" ascii file-contents [ quotable? ] filter "," split ;
    : score ( str -- n ) [ 64 - ] map sum ;
    : solution-22 ( -- n )
        names natural-sort [ 1 + swap score * ] map-index sum ;

I must say, that the syntax and semantics are not intuitive at all. I've spent half an hour trying to learn how does this thing work, and have not been able to. I guess, a damn good tutorial is in order. I think one of the primary reasons Python took off really well, was because of very good tutorials available. The language of Factor's documentation is still only tuned for language designers, not language users.

Its interesting how Factor avoided "library fragmentation" by trying to include everything in the main distribution - definitely a win here, given that in the smaller communities you can't afford duplication. The average quality of the libraries is higher because of that...

I could never get over the syntax though - even though the #factor folks say its a matter of getting used to and theoretically not "harder" than Lisp, Lisp feels very natural to me, but Factor always required a big overhead.

For those looking for "Why Factor" material you might like to look at some of Manfred von Thun's writings on the Joy programming language [1]. Joy is similar to Factor and Manfred wrote a lot of theory on the "why" of concatenative programming languages.

[1] http://www.latrobe.edu.au/humanities/research/research-proje...

This is really cool!

I have always admired the engineering work on Factor, but had thought the project would die when Slava Pestov took his job at Google. Great to see it continue to improve.

I like the old logo better, http://re-factor.blogspot.com/2012/11/new-logo.html is waaay too busy.

My TA for a cryptography class worked on this. I had the pleasure of messing with it one afternoon. Pretty cool stuff.

As cool as an approach that Factor has, I cannot fathom why it is being developed for x86 for the life of me. (Besides claims of cross-platform native executable compilation.)

On ARM it would be interesting- or if it had a highly modular structure that would allow it to be "easily" ported to other microprocessors.

But on x86? What niche is it trying to serve? Is it a language-lover's-language? I guess what I'm asking is, why would I use a "high-level" Forth on x86? There has to be a reason, I'm just missing it.

Under new libraries I see a reddit API lib listed. Why are they including things like this in Factor itself. Doesn't it kind of bloat things? Factor can strip this out if it isn't used of course, but can you really maintain all of these libraries? If you just add random things to Factor itself you're eventually going to end up with something that is impossible to maintain without a very large number of invested people.

Where is Slava Pestov now? Haven't seen him for a long time.

Is there a HelloWorld example I can try?

Anyone knows how one could compile to Factor VM? Slava once said that would be a good idea - imagine having a Lisp in that modern environment? (I love Slime don't hit me).

What is it? Why should I learn it? What are its "killer" features? Ain't nobody got time to learn about every new prog. language.. :)

Looks very interesting. What distributions package it?

Oh look, they're basically dissing this community to hell in the irc logs. For instance,

"10:10:24 <RodgerTheGreat> another HN gem: "I must say, that the syntax and semantics are not intuitive at all. I've spent half an hour trying to learn how does this thing work, and have not been able to.""

It's horrible to watch when a language community has this sort of a elitistic attitude, especially when it's doubtful that the language has any future.

Source: http://bespin.org/~nef/logs/concatenative/13.04.21