Live data from Hacker News

Factor – A practical stack language

factorcode.org

31–40 of 42 posts

Re: Factor – A practical stack language

#31

I've always wanted to learn a Lisp, but I've found Scheme too academic, so I ended up learning other variants such as Common Lisp and Clojure. Could the same thing be said about Factor vs Forth?

Yes. Factor definitely has a much more modern feel but loses a lot of the purity. That said, Factor is still pretty "pure" by the standards of most languages. Forthish languages are very interesting. I feel they might even represent a "third way" from the normal LISP / FORTRAN dichotomy.

You get Lisp or Fortran by adding discipline and using the stack language as a back end. Then instead of "pop three things off the stack and put one back", that stuff is hidden and generated by the compiler, so (on the plus side) the stack pointer is never wrong. You don't have to worry about: if I take this branch of the conditional, will the stack be left at a different height. Or worse: be tempted to exploit that somehow as a feature. The stack basically disappears from view. And then (on the minus side) you can't do things any more like replace a function that pops three things, by a sequence of two functions where each pops two and puts one back. On the plus side again, because the stack has disappeared, you can really change how it is represented. Like pass and return in registers; aggressively inline functions, etc.

Re: Factor – A practical stack language

#32
post #2

I want to like Factor. I've tried to use it a couple of times, and found at least under OSX that the samples I tried to compile (tetris and one other) didn't actually function. More relevantly, I feel like Factor has lost the literal relationship between machine and software that is Forth's distinctive contribution. Our processors have drifted away from that mapping as well, though there are of course GreenArrays and…

Thank you for the pointer to retro[1] and related[2] projects!

I also sort of found Factor interesting -- but much of the point with Forth, is a high-ish level of abstraction on bare metal hardware. If you're going to be using a vm etc... why not program in something that is much more abstract, like Smalltalk, Lisp, Python -- whatever really? Retro I can get, apparently it is small and very portable -- that makes sense (perhaps not more sense than Smalltalk, though).

[1] http://www.forthworks.com/retro/

[2] http://www.forthworks.com/parable/

http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html

Re: Factor – A practical stack language

#33
post #27

Earlier quoted context omitted.

I believe the same is true of other paradigms. Of course complexity is difficult. Do concatenative languages exaggerate the effect?

I think so sir - I had only a couple beers and can't parse the function below. : ( -- gadget ) vertical { 5 5 } >>gap [ f track-add ] [ [ 1 track-add ] [ [ vtruncate v>integer first3 3dup "%d %d %d #%02x%02x%02x" sprintf ] f track-add ] bi ] bi* ;

It helps to be familiar with the words (Factor term for functions) in use. You can use http://docs.factorcode.org to look them up. All the help is also available from within Factor itself. You can click on word definitions and it comes up.

In this case there is a word called '' being defined. It takes no arguments off the stack and leaves one, gadget, on it.

Now working from left to right, 'vertical' is a constant. '' creates a new GUI object called a track that requires the orientation to be on the stack. That what 'vertical' is. It's the orientation.

Now that there is a track object there we fill in the slots of that object. That's what '>>foo' does. It stores something in the 'foo' slot of the object on the stack. So "{ 5 5 } >>gap" stores the 2 element vector containing the integer 5 twice, into the 'gap' slot.

'' creates a gadget and a model that is left on the stack. This is what 'bi-star' is now operating on.

'bi-star' is a combinator. It requires two objects and two quotations (quotations are factors term for anonymous functions or closures). It applies the first quotation to the first object, and the second to the second object. This system of combinators is described in the Joy language writings, although I think under different names.

"[ ... ]" is the syntax for the quotation. So "[ f track-add ]" is the first quotation. "bi-star" call this with the 'track' on the stack since that's the first object that "bi-star" gets access to.

The rest of the code can be worked through in a similar manner. In general you learn to recognise things like "" for creating objects, ">>foo" for setting slots, "[ ... ]" for quotations and combinators to reduce stack management (like dup, rot, pick, etc).

Re: Factor – A practical stack language

#34
post #12

IIUC the creator, which had already written a popular text editor (jEdit), and now a successful programming language, considered his objectives complete with Factor and moved on. AFAIK he still works at Google, and never posted in his blog again ( http://factor-language.blogspot.com/ ).

I think the current rumor is that he's now doing lots of drugs and working full time on bcache.

Re: Factor – A practical stack language

#35
post #12

IIUC the creator, which had already written a popular text editor (jEdit), and now a successful programming language, considered his objectives complete with Factor and moved on. AFAIK he still works at Google, and never posted in his blog again ( http://factor-language.blogspot.com/ ).

I think the current rumor is that he's now doing lots of drugs and working full time on bcache.

I did not know about the bcache thing - interesting!

Re: Factor – A practical stack language

#36
post #8

I really love the power of Factor. It is probably the most powerful language I have ever come across. That being said, I think there needs to be a more interactive method where you can see things on the stack in real time as you are programming. I found myself not being able to focus on the problem I wanted to solve and instead was spending too much of my brainpower on remembering what was on the stack where. If you…

FUEL, the Factor mode for Emacs, allows you to do almost exactly this: it shows you the stack effect of any given word when you're hovering over it, and you can ask what the cumulative stack effect is at any given point. The only thing missing here would be providing names to what's on the stack, but you can do that by using the lexical vocabulary along with the above.

Re: Factor – A practical stack language

#37
post #4

It's entirely my own failing, but I just can't get the hang of postfix languages. Feels too much like coding in Yodaspeak.

Firstly, I think that some problems just do not map well to the concatenative space. E.g., complex mathematical expressions are a total bitch to try to do entirely with stack shuffling and whatnot. Thankfully, the Factor team agrees, so Factor has a full lexical variable vocabulary that performs just as well as the concatenative variety, and which is used even in the stdlib to do exactly this kind of thing.

Second, there's a mental hurdle to overcome to fight the Yoda speak, which is making sure that all of your words (i.e., functions) are tiny and well-factored. In most languages, having functions that run ten lines isn't a big deal. In Factor, that's a major problem I'd reject in code review. My best functions only run one line. Two is tolerable. In very specific circumstances, if it really makes sense, I'll bust out lexical variables and allow an extra line or two. Anything longer than that means I seriously messed up.

This makes a huge difference, because the thing about having such short functions is that the Yoda speak isn't any worse than when you're doing a builder pattern in Java or the like. There isn't really that big a difference between

    foo.Where(x => x > 0).Select(x -> Math.pow(x, 2));
and

    (->> foo (filter positive?) (map #(^ _ 2)))
and

    foo [ > 0 ] filter [ 2 pow ] map
These two things combine to make Factor downright pleasant to work in for me.

Re: Factor – A practical stack language

#38
post #8

I really love the power of Factor. It is probably the most powerful language I have ever come across. That being said, I think there needs to be a more interactive method where you can see things on the stack in real time as you are programming. I found myself not being able to focus on the problem I wanted to solve and instead was spending too much of my brainpower on remembering what was on the stack where. If you…

> I really love the power of Factor. It is probably the most powerful language I have ever come across.

What does that really mean? The power to compute any function? Or expressive power?

If you mean the former, it is certainly no powerful than any other Turing-complete language. Anything that can compute primitive recursive functions is as powerful as anything else (though not requiring the same time and space resources).

If you mean expressive power, then you seem to be saying that "the most expressively powerful language I have ever seen takes away my ability to focus on the problem, and spend my brain power remembering what is on the stack where".

Even decently well-structured assembly language doesn't have this problem! You do the subroutine frame linkage dance on entry and exit into your function, and then things are nicely at fixed offsets which can be given symbolic names.

Re: Factor – A practical stack language

#40
post #21

Slava created an interesting language but I never saw an explaination of why he moved away from Factor. He just stopped (writing and caring ?) about it.

It took me a while to find at least some explanation of what happened:

http://article.gmane.org/gmane.comp.lang.factor.general/4940

http://article.gmane.org/gmane.comp.lang.factor.general/4505

Still, it's so strange to me: not only Slava disappeared, but most of the original authors stopped participating in the development and even stopped blogging about Factor. See http://planet.factorcode.org - most blogs have been abandoned for years, some of them are dead links... Also, I have not found any public announcement about who will maintain Factor in the future.

I really like what I know about Factor, and I have tremendous respect for Slava and others who created this language. I looked into the code a little bit, and it looks a very well-thought and very serious work, and I have no idea how they could create it in such a short time.

Still, you can't manage a project like this. No matter how great the language is technically, I won't start using it for any serious work if I don't see any vision, any chance that the project will not get stuck in this stage. I really hope that Factor will overcome these challenges. It would be so sad to see such a brilliant piece of work to be abandoned.

Post reply on HN