Why Concatenative Programming Matters (2012) • Hacker News Board

Re: Why Concatenative Programming Matters (2012)

#21

Post by mjn » Sat, Apr 13, 2013, 3:43 PM UTC

tmcw wrote: post #19

This would be much better reordered. The lead 'why concatenative programming matters' is only answered halfway through, after the reader is expected to trudge through lambda notation. Why it matters: it's the basis for interpreters of languages you use. Then explain why, then explain what it is.

For some audiences I'd agree, but I think the current presentation works well if the target audience is people who already believe that functional programming matters, but are skeptical that concatenative programming is an interesting or important concept. For that audience I think the presentation starting from the familiar type-signature notation is effective.

Re: Why Concatenative Programming Matters (2012)

#22

Post by raganwald » Sat, Apr 13, 2013, 3:43 PM UTC

jacquesm wrote: post #16

raganwald wrote: post #14

Earlier quoted context omitted.

It's exacerbated by the tendency to factor a single function into many simpler ones. That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"

I think this is closely related to why 'naming things' is hard. Small functions do one thing and are easy to name, larger things do more than one thing and are harder to name. But very small functions, smaller than useful leads to harder names as well! This does not directly answer your question but I think a good sign that you're on the wrong track is when naming things gets harder, that's when you've decomposed too…

Great answer, thanks. It makes me think about sudden domain shifts. "Fetch the list of users. Locate the user matching the description. Push the user object onto the stack." The last item shifts from the business domain into implementation details, and it probably shouldn't be "close" to the others.

Re: Why Concatenative Programming Matters (2012)

#23

Post by smosher » Sat, Apr 13, 2013, 4:46 PM UTC

This is impossible to do with any other type of language. With concatenative programming, a parallel compiler is a plain old map-reduce!

This statement (in context) draws a defining line around what is and isn't concatenative, and the statement by Norman Ramsey should have been refuted succinctly with a derived definition: Composable expressions with associativity.

Re: Why Concatenative Programming Matters (2012)

#24

Post by abecedarius » Sat, Apr 13, 2013, 5:13 PM UTC

evincarofautumn wrote: post #4

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

This is true, but it’s also important to realise that Forth is not the only direction. ;) It’s been a while since I wrote this article, and there are a number of things it doesn’t address, such as the practical concerns you mention. It’s much the same issue as comes up when dealing with large assembly projects, or dynamically typed ones for that matter. Knowing what’s going on can be difficult to discern without a de…

Did you know Robin Popplestone designed a type system for Forth? It involved what I think he called 'regular types' (like regular expressions), IIRC, to handle (disciplined use of) words like ?DUP.

Re: Why Concatenative Programming Matters (2012)

#25

Post by dkersten » Sat, Apr 13, 2013, 6:34 PM UTC

jacquesm wrote: post #16

raganwald wrote: post #14

Earlier quoted context omitted.

It's exacerbated by the tendency to factor a single function into many simpler ones. That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"

I think this is closely related to why 'naming things' is hard. Small functions do one thing and are easy to name, larger things do more than one thing and are harder to name. But very small functions, smaller than useful leads to harder names as well! This does not directly answer your question but I think a good sign that you're on the wrong track is when naming things gets harder, that's when you've decomposed too…

I think this is closely related to why 'naming things' is hard.

I find this especially problematic in exploratory and experiment-driven programming because naming things often gets in the way until code has stabilized somewhat.

For this reason, I've found working in Max/MSP extremely pleasant because you don't need to name things unless it makes sense to. Yes a lot of Max code you see online is a mess of lines, but I found the key is that if you do, in fact, split related things into their own named components, then I hit the sweet spot between not being required to name things that don't have natural names (or at least deferring doing so until I'm done experimenting and trying things) and still maintaining good software practices, maintainability and abstraction.

Re: Why Concatenative Programming Matters (2012)

#26

Post by fizx » Sat, Apr 13, 2013, 7:49 PM UTC

raganwald wrote: post #14

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

It's exacerbated by the tendency to factor a single function into many simpler ones. That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"

I've always thought of a hyper-abstracted codebase being like a binary tree, lazy code being like a linked list, and optimal code being like a B-tree tuned for the page size and seek latency of your particular brain.

Re: Why Concatenative Programming Matters (2012)

#27

Post by snprbob86 » Sat, Apr 13, 2013, 7:59 PM UTC

Warning: Shameless self promotion

I implemented a concatenative DSL for Clojure called Factjor [1] inspired by Factor [2]. Clojure is to Lisp what Factor is to Forth. I used Factjor to implement DomScript [3], which is sorta like jQuery re-imagined as a concatenative language like PostScript. I also gave a talk on both Factjor and DomScript at Clojure/West. Slides are available now [4] and a video will be available on InfoQ soon.

[1] https://github.com/brandonbloom/factjor

[2] http://factorcode.org/

[3] https://github.com/brandonbloom/domscript

[4] https://github.com/strangeloop/clojurewest2013/raw/master/sl...

Re: Why Concatenative Programming Matters (2012)

#28

Post by Someone » Sat, Apr 13, 2013, 8:32 PM UTC

bun-neh wrote: post #12

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

You should look in to Factor, a higher level concatenative language.. http://factorcode.org/ There is a package for lexical variables for those instances where stack shuffling is absolutely not the way to implement your algorithm. This page http://docs.factorcode.org/content/article-locals-examples.h... compares the stack shuffling vs lexical variable approaches. Oh, and those lexical variable have essentially no com…

"This snippet of a high level function is self describing. 1) Check to see if movement keyboard entry is pressed and move the player"

I disagree. I do not see anything there that can even remotely be explained to imply the 'check to see if movement keyboard entry is pressed' part. Something like 'handle-player-movement' would be better.

Similarly, 'fire' could fire a gun, simulate fire in the way 'waves' (apparently) simulates waves, etc.

Re: Why Concatenative Programming Matters (2012)

#29

Post by jmmcd » Sat, Apr 13, 2013, 8:40 PM UTC

evincarofautumn wrote: post #4

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

This is true, but it’s also important to realise that Forth is not the only direction. ;) It’s been a while since I wrote this article, and there are a number of things it doesn’t address, such as the practical concerns you mention. It’s much the same issue as comes up when dealing with large assembly projects, or dynamically typed ones for that matter. Knowing what’s going on can be difficult to discern without a de…

It's a very interesting article. I wonder if you've heard of Push (a stack language) and PushGP (an evolutionary automatic programming system for which Push is designed)?

http://faculty.hampshire.edu/lspector/push.html

Re: Why Concatenative Programming Matters (2012)

#30

Post by GhotiFish » Sat, Apr 13, 2013, 8:54 PM UTC

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

>To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it.

I don't understand this. I don't need to know how add works to know it pops two bytes off the stack and pushes them added together. Likewise for my own functions. I don't need to know how they do it, just what they do.