

Forth & stack machines - ahalan
http://www.yosefk.com/blog/my-history-with-forth-stack-machines.html

======
thristian
A while ago I came across Factor¹, which calls itself "a practical stack
language"; it has the same basic (lack of) syntax as Forth, but has a Common
Lisp-inspired object system, garbage collection, and a standard library whose
scope resembles Python's.

I haven't actually written anything in it yet.

Partially, it's because of work-flow issues - Factor doesn't lend itself to
hacking on source-trees outside the Factor source tree, and I'm not sure how
I'd set up a single-button "run all the tests" command, for example. Partially
it's an issue of finding the right project - being a new language and a new
paradigm, I'd want to start off with something simple, but not so simple that
I'd be tempted to dash off a half-dozen lines of Python and move on.

A good chunk of it, however, is because of articles like this one (in fact,
probably this very article I read on Hacker News some months ago) that make me
despair of ever making code that will be as simple and efficient as the code-
samples I've seen — the Python community calls Python code that goes with the
grain of the language as "Pythonic"; I'm not sure what Factor's equivalent
adjective would be ("Factorial"?).

¹: <http://factorcode.org/>

~~~
rsaarelm
I don't have any Forth background, but have written a significant amount of
Factor code during the last year. I haven't really run into things that seem
painful or complicated to express in what I hope to be idiomatic Factor. The
project I've been working on is an interactive game, so it's neither entirely
trivial nor something that a concatenative language is obviously a
particularly good fit for.

The main difference from Forth are the ubiquitous quotations, Factor's
equivalents of a lambda expression, which make the idiom clean and quite like
a functional language. For example, Factor's `if` conditional isn't a macro
like the Forth one, it's just a regular word that takes a truth value and two
quotations, and then calls either the first or the second quotation based on
the truth value. There are also many combinator words like `bi` or `cleave`
that operate on the quotations that don't have Forth equivalents as far as I
know. A good deal of being able to write idiomatic Factor is being able to use
the standard combinators.

For tricky things like complex equations that aren't easy to express in pure
stack manipulation Factor has the local variable library, which allows easy
repeated referencing of the inputs, so doing something like a closed form
solution of a quadratic equation can be done without incomprehensible stack
acrobatics.

The work-flow is a bit tricky though. I like setting up automated machinery
running from the command line, and Factor likes to live in an image, SmallTalk
style. I guess the idea is to just write the support machinery in Factor as
well, and use the Factor REPL as the interactive workflow control site and
short Factor scripts for automated command-line stuff.

------
wollw
Ever since encountering OpenFirmware on the old PPC Macs I've been interested
in Forth but I've only started playing around with it recently (I actually
just put amforth on an ATMega328P this afternoon). It's really pretty
interesting to use as it forces me to really program in a different way than
usual. Most languages allow me, to put it one way, to break to "rules" of the
language (ie: programming imperatively in a functional language) but using
Forth really means having to learn to solve problems a new way.

In the case of running Forth on an AVR it also has the benefit of being able
to program interactively on the actual hardware instead of having to flash and
reflash every time I want to change something. Very pleasant.

~~~
stcredzero
Requirements are an information tool, just as any document is an information
tool.

Any company where software is handed down from developers to users on a one-
way street with no collaboration, refinement, and iteration is working with an
inefficient process.

Any company where requirements are handed down from users to developers on a
one-way street with no collaboration, refinement, and iteration is working
with an inefficient process.

------
_delirium
I thought this part captured it nicely:

 _Forth is not the language. [...] Forth is the approach to engineering aiming
to produce as small, simple and optimal system as possible, by shaving off as
many requirements of every imaginable kind as you can._

I actually quite like that approach, though like the author of this post I'm
not sure how well it could be applied within the context of a larger company
with requirements that you don't fully control.

------
stcredzero
_The requirement for “real world work” is almost by definition incompatible
with “the freedom to change the language, the compiler, the OS and the
hardware design”._

If "the hardware design" really means the VM for a VM based language, then I
have known people who accomplished great things in their real world work by
changing the "hardware design." There is a difference between changing such
things willy-nilly because you can versus doing pragmatic and smart things
because it makes things simpler and faster.

 _The Forth way of focusing on just the problem you need to solve seems to
more or less require that the same person or a very tightly united group focus
on all three of these things, and pick the right algorithms, the right
computer architecture, the right language, the right word size, etc. I don’t
know how to make this work._

A group that can make that work -- sounds like the sort of startup that PG
would like to fund.

------
pointyhat
Very interesting article although I think it shows a bit of confusion. The
person is also rather inexperienced both with his approach to the problem he
was solving and the outcome. I would have probably used a commercial DSP
looking at the workload.

Looking at Forth, it's a thing of beauty. It's just simple. That is all that
can be said. In a lot of circumstances, it will do the job admirably. People
tend to forget that the majority of computers out there still aren't desktop
PCs, servers, mobile devices etc. Surveying my house quickly, they are tiny
things in washing machines, cookers, fire alarms, traffic signals, process
controllers, lighting, microwave ovens, calculators, children's toys,
televisions, dishwashers, scales, cd players etc. There are literally billions
of the things all doing tiny tasks constantly 24/7. Forth fits there nicely if
you ask me :)

