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.
I think you hit the nail on the head. I haven't actually used Factor, but I spent 4 years writing and debugging in a concatenative proprietary language, and this was my experience too. It was very productive to write in but required great discipline in terms of structure and documentation to be debuggable, and debugging felt very "interactive", where it was easier to catch problems live by watching the data than to solve them analytically. This put a lot of weight on the quality of the debugging tools, which were lacking to the point where it was all about logging values to a file with a tail log on it, and made it sometimes difficult to separate bad data from bad code, which put more weight on the specs being there. But when all the pieces were in place it was the most terse and beautiful code to read.
At risk of shameless self-promotion let me mention an interpreter for Joy I've written (in Python) https://code.google.com/p/joypy/
Joy is one of the major inspirations for Factor (I think it is considered the first "concatinative" language but I may be mistaken about that) and I think it deserves serious consideration from anyone interested in language design and formal systems. In a word, it's name is apt.
I have added a trace ability that lets the interpreter print out a complete description of the steps in an evaluation, like so (the bullet mark indicates the current interpreter "position", items to the left are on the stack, items to the right are the expression to be evaluated):
joy? 3 range_to_zero
# frame start
• 3 range_to_zero
3 • range_to_zero
# .. range_to_zero == unit [down_to_zero] infra
# .. frame start
3 • unit [down_to_zero] infra
# .... unit == [] cons
# .... frame start
3 • [] cons
3 [] • cons
[3] •
# .... frame end
# .... unit done.
[3] • [down_to_zero] infra
[3] [down_to_zero] • infra
# .... frame start
3 • down_to_zero
# ...... down_to_zero == [0 gt] [dup pred] while
# ...... frame start
3 • [0 gt] [dup pred] while
3 [0 gt] • [dup pred] while
3 [0 gt] [dup pred] • while
# ........ frame start
3 • 0 gt
3 0 • gt
True •
# ........ frame end
# ........ frame start
3 • dup pred
3 3 • pred
3 2 •
# ........ frame end
# ........ frame start
3 2 • 0 gt
3 2 0 • gt
3 True •
# ........ frame end
# ........ frame start
3 2 • dup pred
3 2 2 • pred
3 2 1 •
# ........ frame end
# ........ frame start
3 2 1 • 0 gt
3 2 1 0 • gt
3 2 True •
# ........ frame end
# ........ frame start
3 2 1 • dup pred
3 2 1 1 • pred
3 2 1 0 •
# ........ frame end
# ........ frame start
3 2 1 0 • 0 gt
3 2 1 0 0 • gt
3 2 1 False •
# ........ frame end
# ........ while done.
3 2 1 0 •
# ...... frame end
# ...... down_to_zero done.
3 2 1 0 •
# .... frame end
# .... infra done.
[0 1 2 3] •
# .. frame end
# .. range_to_zero done.
[0 1 2 3] •
# frame end
-> [0 1 2 3]
joy?
It's a little hard to follow but it is complete and visible.
> 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.
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.
> 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).
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.
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.