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.<p>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.<p>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).<p>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?!<p>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.<p>In short, the manual is a maze of cross-references with no head or tail.<p>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<p><pre><code> 10
"Less than 10"
"Greater than 10"
[ < ] 2dip if ! 2dip is a stack combinator, guess what it does!
</code></pre>
you could write<p><pre><code> IF 10 < THEN "Less than 10" ELSE "Greater than 10" END
</code></pre>
(Postfix conditionals were available for the rare cases where they were the most convenient form.)<p>Last but not least, it supports only cooperative threads.