Factor 0.96 now available – over 1,100 commits (opens in new tab)

Factor is an impressive piece of work for sure, but, in my opinion, like many "modern" derivatives of Forth it loses the major strength of Forth, brutal simplicity. It has drawbacks, but it also has advantages. Introducing new "modern" features to Forth adds complexity, changes this balance, and I doubt these hybrids will ever attract 'hardcode' Forth programmers or non-Forth programmers. At least traditional Forth systems are small and simple enough for someone to understand (I learned myself from a tiny Forth named PygmyForth, but there are many others); it provides you with a kit you can modify and customize at will once you've absorbed it.

The postfix notation even for conditionals is really not an issue when you dive into the language. However, with most systems you should be able to translate IF into 'nop', THEN into IF, and END into THEN and it should do the trick. But then there are DO WHILE loops. etc. But everyone prefers to preserve the postfix logic at the end of the day. It's like infix notation systems in Lisp and Scheme that never caught up (and, I believe, never will).

About your second point: most of the library code, in any language, looks like gibberish and like a mess of arbitrary idioms. One simply cannot hope to inspect and understand non trivial library code just just by casually reading it. With Forth the situation is indeed even worse, because implementers generally cannot resort to spaghetti code too much, whose continuous nature, at least, helps the casual reader.

On the topic of cooperative multithreading, I think that the trend in recent programming languages in general is that, nobody wants to deal with pre-emptive threads anymore. It hurts kitties, it is dirty. It is like manual dynamic memory management. Cooperative threads (if I'm not mistaken, they're also sometimes called "lightweight threads", "green threads" or "fibers"), avoid most of the problems of preemptive threads (because the programmer controls when execution can switch to another thread and when it should not very easily), while retaining some benefits (background execution of low priority tasks). For a "modern" Forth system, I think it could be interesting to keep cooperative threads at user level (really hardcore implementers may just remove them completely, because it is expected that the programmer may prefer to implement some sort of cooperative tasking fitted to his needs), and use preemptive/OS threads in library code (typically implemented in C).

Now that's the point of view of a 'hardcore' kind of hobbyist Forth user (and implementor). There is another category that finds brutal simplicity simply not practical and I can understand that. But really for educational/curiosity purposes I would recommend the hardcore way. Like, abandon all the bloat you're addicted to, shut the up, try hard and sincerely. I tried Forth this way because I was very sceptical when reading Moore (inventor of Forth) and Fox (one of his collaborator and friend; Moore isn't very good at communication, so Fox [RIP] was sort of his Plato) that their approach could work. These experiments in extreme simplification brought me a lot when I was a young programmer.

You wouldn't write a conditional like that, you'd do:

    10 < [ "less than 10" ] [ "greater than 10" ] if

This is pretty easy to read. If the boolean condition is true, run the first quotation, if it is false, run the second.

The unusual names lke 'dip', 'bi', etc are just common names that once learned make code easier to read. 'dip' is from Joy IIRC.

I do agree that combinator heaviness can make things difficult for a beginner. Especially if code uses a combinator that isn't common it requires time to look up and see what it does. You really need to immerse in Factor development for a while to get familiar with them.

Stack effect declarations exist to make refactoring safer. Prior to having them enforced by the compiler it was common to change a words stack effect only to find it broke random code using it elsewhere. Making the check enforced provided a safety check that you hadn't forgotten to change word usage elsewhere.

>(It's under objects.)

That would be because Factor is OO.

Reverse polish notation means you have to start reading from the end of the expression:

    "hello world" print

This is also why ternary expressions in C like languages is hard to read.

Concatenative language syntax is actually pretty easy at the basic level. I don't know Factor, but I used to dabble a lot in Forth. The single syntactical rule with Forth is that a symbol (called a "word") is one or more non-space characters, delimited by spaces. So the following three things are all words: SWAP ." -1

Next, there's the idea of the stack. Every word is executed, one after the other, and the words operate on the stack. So the four-word sequence 3 4 + . puts a 3 on the stack, then puts a 4 on the stack, then pops the top two numbers from the stack and puts their sum on the stack, then prints the top number on the stack. So the result, naturally, is 11. (Well, it is if you're operating in base 6 at the time. Didn't want to make it TOO easy for you!)

Oh, and there's also the concept of interpreting vs compiling. The colon word, which is spelled :, reads the very next word from the input and begins the definition of that word. Every word it encounters up to the next semi-colon is compiled, not executed. So if I did this

    3 4 + : FOO SWAP DROP ; .

... it would still print out the sum of 3 and 4, but in between it would also define a new word called FOO. Which would be a silly way to program, but it demonstrates the point.

So the short form is: begin reading at the top left, continue rightward and downward until you reach the bottom. There's no syntax as such, like Perl's die "Can't open file" unless $fileopen; because Forth-like languages don't read ahead to the end of the line.

[Edited: HN doesn't do Markdown. WTF? Also, I don't know my left and right.]

That's what's cool about the Forth idea, and why it can be so effective. It's not that it's unintuitive, it just doesn't take Algol-style semantics as a given as we do today. (It was being used before C was even developed.) If we're interested, it's our job to see if we can fit our thought process into the Forth idea, not vice versa.

And it's a very coherent idea. It's meant to respect processor architecture while maintaining a good level of comprehensibility to the human. And it keeps a MUCH closer correspondence between "word" (essentially a routine) and actual instruction. That got WAY lost with C, enter the beast-compiler.

I think of it as a concept layer above assembly, that has features far beyond just mnemonic value. It's like Lisp to me- a language whose "syntax" is dictated by the functional necessity of a computing methodology, not the decisions of language designers. For me at least, the approach leads to much higher productivity for a variety of reasons.

There's also a very high probability that Forth is the first thing to be run when you turn on the computer or cellphone you're reading this from.

Now as to Factor... see my post above and help me out!

Actually, Forth (the predecessor of concatenate languages) has the best tutorials I've ever read - Starting Forth and Thinking Forth by Leo Brodie.

http://www.forth.com/starting-forth/

http://thinking-forth.sourceforge.net

To be fair Factor/Forth's way of thinking is really foreign to the usual Pascal/C derivatives. Learning how to program from scratch certainly too you more than 30min.

It has nothing to do with python being particularly intuitive and everything to do with it being very similar to every other imperative language you already know. If your first language was forth or PS you'd find factor intuitive too.

>> I guess, a damn good tutorial is in order.

Firing up the Factor GUI environment you can access help via F1 where two options are the cookbook and the "Your First Program" tutorial.

This same documentation available in the environment is also available online[1].

[1] http://docs.factorcode.org/content/article-first-program.htm...

I think that's true. Forth is so called "ultimate low-level language".

Or "Why Factor?": http://concatenative.org/wiki/view/Factor/FAQ/Why%3F

Ah, the new logo is hideous! I don't see anything better about it other than the fact that it fits in a square. What's the purpose of the late-90's computer graphics style round triangle button thing? It's like a big skeuomorphic upvote button with an airbrushed Mario level in the background. Just get rid of it!

That nitpick aside--wow! Factor is getting more and more impressive every day.

Factor the language or factor the Unix command?

Factor used to run on ARM [1]. Back then Windows Mobile only had 64MB of ram and it wasn't quite enough to do anything useful in Factor.

I used to run a video sharing website written in Factor [2], sadly the server crashed a few weeks ago and I haven't recovered the data from the disk yet.

Factor feels more like a Scheme than a Forth to me when programming.

[1] http://web.archive.org/web/20111117015025/http://www.bluishc... [2] http://web.archive.org/web/20130118204336/http://tinyvid.tv/

They are working on reimplementing ARM support in the next release. It is in an incomplete state ATM.

The 'extra' directory basically acts as a package manager. The "Batteries Included" approach Factor uses here makes it much more likely that libraries work out of the box.

This was very useful in the early days of Factor when language and base library changes caused bitrot in contributions. If the contributed library wasn't updated it was moved to an 'unmaintained' directory for later correction.

Because there are like 10 person using it. Until the language grows and acquires a package manager it's easier to just put everything in the stdlib.

He got a job at Google back in 2010 and pretty much handed over the reins at that time due to lack of free time to work on Factor. He still posts on the mailing list though periodically.

  "hello world" print

...although, more realistically, you're probably interested in something like the gettings started section of the docs [1]. There are also some great short example posts on the planet feed [2] from various blogs.

EDIT: I'll plug my own blog for this too, as I started writing a Beginning Factor series of posts a long time ago [3], but never got beyond a couple entries.

[1] http://docs.factorcode.org/content/article-handbook.html

[2] http://planet.factorcode.org/

[3] http://elasticdog.com/2008/11/beginning-factor-introduction/

My suggestion is that learning to write programs in a concatenative language will teach you to think in combinatorial logic, a fundamental basis for computation. I outlined this idea a while back and mentioned Factor in "Finding Joy in Combinators:"

https://github.com/raganwald/homoiconic/blob/master/2008-11-...

You don't have to learn it. It is probably mostly interesting to users of concatenative languages, or those who just want to broaden their horizons..

Personally, I've fallen in love with it a few years ago. Even though I don't use Factor for anything practical, the language itself (as well as Forth) has taught me a completely new way of thinking about problem solving. Something that I benefit from in other languages I use.

So if there is one reason you should at least check it out, it is that it will make you a better programmer. And I think anyone who's been writing code long enough, will know that there is always room for self-improvement.

Arch Linux has it in AUR, I'm currently in process of updating it to 0.96.

If a person says that something is a gem, they can be sincerely saying that they think it has positive value. Your interpretation was that the phrase was being used in a sarcastic manner. That may well have been the case here, but it doesn't have to be so.

That's not the case at all. We are anything but elitist...