I’ve programmed in LISP before (well, a long time ago), and I remember feeling highly productive while using it. However, I was using it on a high end machine.
I haven’t tried FORTH. Is uLisp comparable to FORTH for microcontroller programming, or is one language decidedly better than the other for that purpose?
FORTH I found super annoying.
Imagine it a bit like a “one-dimensional list language” if you will.
The stack-based notation is what is most hyped about it as “unusual”, though in reality, you will get used to that really quickly, just like to LISP’s parentheses. “Looks weird”, but is not really that much of a deal.
What * is * a big deal for me is the sheer amount of babysitting this language needs. “You can define anything” translates directly to “barely anything is ever compatible, you must do everything yourself, the amount of detail is mind-blowing”. The famous stack really means you must yourself pay attention to what is on it at all times; in LISP, you call a function, it does something, then it collects its garbage and gives you somethibg else. FORTH really feels like having one C-array in which anything you want is done with two pointers.l, and sometimes the array gets changed in some parts, and sometines it doesn’t.
That is the very reason why FORTH systems tend to be small: they are outsourcong all sorts of micro-management to the user, to YOU. And no, it is NOT all that fun to handle it.
One of the things I’m liking about uLisp is the ease of doing c-extensions to it. Since most embedded microcontroller libraries for sensors and such seem to be written in c, that means being able to leverage those libraries without having to rewrite them. So, a big kudos for that. :)
I’m not sure if Forth can do that. However, what peaked my interest in Forth was this guy (https://www.youtube.com/watch?v=dvTI3KmcZ7I) who gave a tantalizing overview of how he uses Mecrisp Forth on an ARM Cortex M microcontroller (a “blue pill” in his example). For instance, I was impressed that it can do its own on-the-fly inline optimizing compilation of Forth, all on the target microcontroller itself. The result appears to be compact and reasonably efficient code. Can uLisp also be made to do that too?
I am new to the forum and new to Lisp. I am a long time Forth user.
To be very honest Forth is better understood as a clever macro assembler for a two stack machine. This is a very low level starting point. Comparisons to a ultra hi-level language like Lisp will always be one-sided. That means yes, there is a lot of detail to manage out of the box. The Forth strategy to deal with that detail is similar to Lisp. Abstraction.
A good Forth programmer writes a custom language for themselves in the first few pages of code to hide that detail and then writes their program in the new language. This takes a while to learn as most people assume if I am using language X that I should program in Language X. But it is very similar to the way Lisp programs work and of course the REPL lets you test everything as you go.
It finds a niche in resource constrained machines because of the small footprint. It also allows interactive Assembler programming (really). Assembler is not popular these days but for some low level time critical solutions it is essential and again having a REPL for Assembly language is amazing.
I have used PostScript (a close relative of FORTH) quite a bit on HP Laser printers and photo typesetters. It is a very difficult to work with directly. But it isn’t too bad when you have tools that generate .ps output. Debugging them is only a small step up from poring over hex-dumps.
Personally, I prefer programming Lisp/Scheme. When the code is written such the the indentation reflects the nesting of s-exprs things are quite easy to follow (well at least for me).
Does Postscript restrict source code indenting/format? I have never used it.
Reverse Polish notation does take some time to adapt to for sure. However it’s a little bit like riding a bicycle; once learned it’s simple. I am not sure why some of us push through that painful early period with Forth. I think because we taste the potential to do “anything” on the machine. It seems to be mored favoured by low level eng. types rather than C.S types.
Or maybe we’re just masochists.
With Postscript newline, tab, carriagereturn and space are “white spaces” they are collapsed into a single whitespace when being parsed.
A really nice way to “play” with Postscript is using GhostScript (it is installed by default on Ubuntu). You get a graphical window, that shows the results of your input and a REPL to enter code.