

The Algebra of Joy (2008) - Rexxar
http://www.kevinalbrecht.com/code/joy-mirror/j04alg.html

======
walrus
A more modern implementation of Joy's ideas can be found in Factor[1], which
the author of this article (and of Joy) endorsed[2].

Also related:
[http://tunes.org/~iepos/joy.html](http://tunes.org/~iepos/joy.html). This
article considers the relation between Joy and combinatory logic, a topic that
enjoyed some interest in the Haskell community[3].

[1] [http://factorcode.org/](http://factorcode.org/)

[2]
[https://groups.yahoo.com/neo/groups/concatenative/conversati...](https://groups.yahoo.com/neo/groups/concatenative/conversations/topics/4873)

[3]
[http://www.haskell.org/haskellwiki/Combinatory_logic](http://www.haskell.org/haskellwiki/Combinatory_logic)

~~~
evincarofautumn
I teared up when I learned that Manfred’s last words to the concatenative
programming community were “I’ll be around again!”—and he died only twenty
days later. I’ve read a lot of good things about him, and it only cements my
high opinion of him that his last message was one praising others for their
accomplishments.

------
evincarofautumn
The practical consequences of these algebraic properties are numerous:

• It’s easy to write good tools for writing, editing, refactoring, analysing,
and visualising programs, because the language is really simple. If it’s easy
to write good tools, those tools are more likely to exist and be correct.

• Functions are good basic units of behaviour. This fact is used in most
paradigms. The fact that is _not_ used explicitly in most paradigms is that
function _composition_ is a good basic way to combine behaviours. (Functional
programming being a notable exception.)

• Small, modular parts are generally easier to understand than monolithic
wholes. Being able to really easily decompose things into small parts helps
you write correct programs more easily.

• Naming is hard. You can choose to name your intermediate state when it makes
your code clearer, but concatenative languages are the only ones that never
_require_ named state. The intent is to use names mostly to describe
behaviours and how they relate.

I have been working on a statically typed concatenative language, Kitten, for
a little while now. It’s working in the same problem space as Rust and
Nimrod—making low-level programming feel high-level by using type system
features to make high-level constructs have low-to-no runtime cost. It’s still
a research project, but you should keep an eye on it:
[https://github.com/evincarofautumn/kitten](https://github.com/evincarofautumn/kitten)

------
theseoafs
The style of this page is horrendous: there seems to be absolutely no margins
on the side. Very difficult to read when it's stretched out from side to side
like that.

~~~
roryokane
In Firefox, you can work around that with the menu item View > Page Style > No
Style.

