Show HN: Plumb, a functional language embedded in PHP, JS and Python

smt88 · on Aug 22, 2014

It's very possible I just don't get this. I don't have a CS degree, and I develop backends for web apps. Maybe I'm not the right audience.

I'd love to find out why I've needed it in my life, though, if you can explain further. Right now, here's why I wouldn't use it:

1) It makes code less readable. It's anti-sugar. It's not obvious what code using plumb will actually do.

This right here from your PHP examples is just insanity:

--

$f = plumb(['strlen' __([] , "foo")]); $f(null) === 3 $compose = plumb([[[2 , __(1 , 0)]]]);

--

I have absolutely no idea what that does, and in 10 years of writing backends, I don't think I've ever written code that I'd want to replace with that.

There are so many brackets and parentheses, it makes my eyes hurt. What if there were 1 nested bracket in the third line instead of 2? If I were scanning for bugs, I might not catch that quickly.

2) It makes code less usable. This is similar to the above, but has more to do with handing code over to someone new. If I were scanning some code and saw:

--

count = plumb([len , "baz"]) count(None) == 3

--

I'd say, "What the hell?" And then I'd have to look up what the plumb() function does I thought I was looking at Python syntax, but I'm actually looking at Python + plumb syntax, which takes time for me to learn.

3) It doesn't seem to add functionality. What am I missing here? What task were you previously coding that was so difficult that you decided to create plumb?

This reminds me of "PHP functions in [insert other language]" libraries or "OOP for JavaScript" articles. Instead of figuring out how to do what they want in a native way, people coming from another language will try to shoehorn the lexicon they're familiar with into a new language. That hurts readability, portability, and performance.

Yes, it sometimes makes sense to add a new "syntax" (in the form of sugar) to a widely-used language. jQuery and its competitors are the only successful examples of that I can think of, though.

Again, really, really curious about the reasoning behind this. It seems like you do have a CS degree, so you could probably teach me a thing or two.

chriswarbo · on Aug 22, 2014

I admit the examples need some work. Note that the features are introduced one at a time, and each example tries to be self-contained in a few lines. This limits what they can convey. I'll definitely revisit them!

As for what the examples do, the lines with "===" show you what happens, eg.

    count = plumb([len , "baz"])
    count(None) == 3

The first line defines a "count" function, the second shows how it behaves. In this trivial example, "count" is just applying the "len" function to the string "baz". Since this call is happening in a function (ie. in [square brackets]), we need to actually call it in order to get the result. In other words, it's showing how to define thunks.

This is obviously silly for calculating a length, but can be handy for delaying expensive function calls.

> What if there were 1 nested bracket in the third line instead of 2? If I were scanning for bugs, I might not catch that quickly.

Did you read the intro? The "When not to use Plumb" section says "When your Plumb spans more than a couple of lines" ;)

smt88 · on Aug 22, 2014

The "delaying expensive function calls" part gave me more of a clue than anything. I still have to admit that I don't get the benefit of plumb over existing lambda syntax, and that benefit still would have to be weighed against the additional requirement of learning plumb syntax for someone new to my code base.

I did read "When not to use Plumb" but, from the example, was looking at a single line. I meant that that single line is difficult to look at and say, "My bug isn't in that line."

chriswarbo · on Aug 22, 2014

I originally wrote Plumb for PHP, which has much more cumbersome lambda notation than Python, so the Python port is less useful; it's more for completeness (I'm playing with a Haskell version too, which is even less necessary).

Since the main point of Plumb is that its syntax is compatible with other languages, we might as well embed it in anything that works :)

As a bonus, the Python version will curry everything you give it. This is nice, since non-curried functions are unnecessarily painful to work with, but you could do that without using Plumb.

chriswarbo · on Aug 22, 2014

Addressing your points individually:

1) On its own, Plumb is exactly an implementation of Lambda Calculus (like an extremely simplified form of Scheme or Haskell); its only novelty is its syntax, which makes it embeddable in scripting languages. It may be unfamiliar, but it's mainly useful for defining functions which shuffle their arguments around and pass them on to other functions.

2) Everything takes time to learn. Thankfully, Plumb has few rules, and they're applied consistently.

3) Nothing is "added", in the sense of Turing-completeness. Plumb is meant to work around awkward function-definition syntax. Some more sensible examples might be the following:

    $compose = plumb([[[2 , __(1 , 0)]]]);

    $z = plumb([[1, [1, 1, 0]],
               [1, [1, 1, 0]]]);

These functions are really simple: compose functions and find a fixed-point. Compare them to raw PHP:

    $compose = function($f, $g) { return function($x) use ($f, $g) { return $f($g($x)); }; };

    $z = function($f) {
       return call_user_func(function($x) use ($f) {
                               return $f(function($v) use ($x) {
                                           return call_user_func($x($x), $v);
                                         });
                             },
                             function($x) use ($f) {
                               return $f(function($v) use ($x) {
                                           return call_user_func($x($x), $v);
                                         });
                             });
     };

I've also written a blog post which introduces Plumb incrementally, in the context of PHP: http://chriswarbo.net/posts/2014-08-18-edsl.html

smt88 · on Aug 22, 2014

Thanks for the response.

"Compare them to raw PHP" -- that's exactly what I was looking for.

This is theoretically interesting. As I suspected, though, I'm just not the right target audience. For the web backends I work on, I'm taking HTTP requests, manipulating inputs, mixing in values from a database, and then outputting the HTTP response.

I've never had to write anything remotely like the PHP in your example. Maybe my life would be easier if I did, but at the moment, my biggest pain point (in code) is that ORM abstraction sucks, and there's no great alternative. That's not even in the same solar system as the problems you seem to be trying to solve.