
Factor – A practical stack language - wuschel
http://factorcode.org/
======
bcheung
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 study human computer interaction and cognetics the human brain can only
remember so many short term memory "variables" at once. Programming in Factor
uses up too many of those spaces.

I think the problem can be solved though if the development environment shows
the stack at each point in time; that way the computer does the thinking
instead of the programmer.

One way to do this is to supply some arguments to the word (function) and as
you manipulate it in real time you can see how it is transformed. Your steps
get recorded as the word.

This solves the problem of programming blind and having to play interpreter in
your head as you are programming. Thus, freeing up cognitive space and making
the programmer more efficient.

~~~
innguest
> I think the problem can be solved though if the development environment
> shows the stack at each point in time; that way the computer does the
> thinking instead of the programmer.

If you're up for it I have some code that I wrote with this very idea in mind,
in Factor. I'll put it on github later today and put the link here anyway. I
agree with you 100%. If Factor were transparent that way and interactive that
way (to the point it's almost like a dialog, which it already almost is with
its Listener but you and I want stack transparency) then it would probably be
one of the most productive languages for fast prototyping (at least).

~~~
bcheung
I'd be curious to take a look.

I have plans to do something similar but in the browser in Javascript.
Basically, build up the AST based on the commands that are issued against the
stack. Then use the Mozilla Parser API to generate Javascript code.

Additionally, with the example arguments supplied you have test driven develop
built right in. Not only do you get tests, but it helps you visualize things
as you program.

~~~
innguest
Sorry for the delay:
[https://gist.github.com/anonymous/6ec7128c10e9ea1f63ad](https://gist.github.com/anonymous/6ec7128c10e9ea1f63ad)

I agree with you 110%, in fact I can't understand why this hasn't been done
yet.

------
doublec
I used to use Factor as my main programming language for a few years and
really enjoyed the language and environment. It feels like a mix of Forth,
Lisp and Smalltalk. I wrote a number of blog posts about it which might help
give a feel for what can be done in the language:

[http://bluishcoder.co.nz/tags/factor/](http://bluishcoder.co.nz/tags/factor/)

~~~
openthedamper
Chris, amazing body of work at your blog. What are your thoughts on the
continued maintenance factor and long term viability? what caused you to drop
out?

------
samatman
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 a few other stack chips out there.

For a Forth that's pleasant to use and retains that feel, I suggest Retro. The
Ngaro virtual machine is pure art, and the additions, particularly the [ and ]
quotation words, are thoughtful contributions to the Forth lineage.

~~~
e12e
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/](http://www.forthworks.com/retro/)

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

[http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html](http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html)

------
swah
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/](http://factor-
language.blogspot.com/)).

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

~~~
swah
I did not know about the bcache thing - interesting!

------
LBarret
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.

~~~
gyim
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/4940)

[http://article.gmane.org/gmane.comp.lang.factor.general/4505](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](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.

------
pseudonom-
I wonder what makes them say this in the FAQ: "a flexible enough type system
for concatenative languages has not yet been designed. However, Factor 2.0 may
include optional static typing, if a suitable type system can be found."
[http://kittenlang.org/](http://kittenlang.org/) gives the impression of
having a fairly sensible static type system.

~~~
evincarofautumn
Hey, I’m the author of Kitten. The site & repo are a bit out of date, but I’m
currently working on a release. Would be happy to answer any questions. :)

I think the problem is that you want some words with dynamic/value-dependent
stack effects. It’s hard to intermingle static and dynamic typing well, and
hard to bring the utility of dependent typing for enforcing program properties
into the realm of properties that are actually useful to enforce while
remaining usable.

------
undrcvr-lagggal
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?

~~~
breckinloggins
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.

~~~
kbenson
There's a always been more than just those. E.g. declarative languages, such
as prolog.

~~~
avmich
Yes, and even "FORTRAN" side represent several approaches - for example,
straightforward imperative, like in assemblers or classic BASIC, or structural
- which was a big step forward at the time - like Pascal.

Then you have object-oriented languages, which are still different from
structural, string-oriented Tcl, array-oriented APL...

------
Zikes
It's entirely my own failing, but I just can't get the hang of postfix
languages.

Feels too much like coding in Yodaspeak.

~~~
swah
Some short functions look so beautiful... but I have a hard time as stuff gets
more complex.

[https://github.com/slavapestov/factor/blob/master/extra/anag...](https://github.com/slavapestov/factor/blob/master/extra/anagrams/anagrams.factor)

IMO this:

    
    
        MEMO: dict-words ( -- seq )
        "/usr/share/dict/words" ascii file-lines [ >lower ] map ;
    

is beautiful.

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

~~~
swah
I think so sir - I had only a couple beers and can't parse the function below.

    
    
        : <color-picker> ( -- gadget )
            vertical <track>
                { 5 5 } >>gap
                <color-sliders>
                [ f track-add ]
                [
                    [ <color-model> <color-preview> 1 track-add ]
                    [
                        [
                            vtruncate v>integer
                            first3 3dup "%d %d %d #%02x%02x%02x" sprintf
                        ] <arrow> <label-control>
                        f track-add
                    ] bi
                ] bi* ;

~~~
doublec
It helps to be familiar with the words (Factor term for functions) in use. You
can use [http://docs.factorcode.org](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 '<color-picker>' 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. '<track>' 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.

'<color-sliders>' 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).

------
mjackson
Maybe of interest: Zed Shaw, creator of Mongrel, gave a talk a few years back
where he mentioned that he was using Factor to create the slides in his
presentation.

[http://vimeo.com/2723800](http://vimeo.com/2723800)

~~~
swah
Sample "presentation"
[https://github.com/littledan/Factor/blob/master/extra/galois...](https://github.com/littledan/Factor/blob/master/extra/galois-
talk/galois-talk.factor)

------
orbifold
One thing I find interesting about stack languages is that if you imagine the
stack tilted by 90 degrees, you realize that you are doing operations in some
monoidal category.

------
Francky
Maybe of interest too : oforth language

