3 ms·

The Algebra of Joy (2008)

32 points by Rexxar 12y ago

theseoafs 12y ago
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 12y ago
  In Firefox, you can work around that with the menu item View > Page Style > No Style.
walrus 12y ago
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/conversations/topics/4873 https://groups.yahoo.com/neo/groups/concatenative/conversati... [3] http://www.haskell.org/haskellwiki/Combinatory_logic http://www.haskell.org/haskellwiki/Combinatory_logic
- evincarofautumn 12y ago
  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 12y ago
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

32 points by Rexxar 12y ago

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 12y ago
In Firefox, you can work around that with the menu item View > Page Style > No Style.

walrus 12y ago

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/conversations/topics/4873 https://groups.yahoo.com/neo/groups/concatenative/conversati... [3] http://www.haskell.org/haskellwiki/Combinatory_logic http://www.haskell.org/haskellwiki/Combinatory_logic

evincarofautumn 12y ago
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 12y ago

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