

Show HN: Plumb, a functional language embedded in PHP, JS and Python - chriswarbo
http://chriswarbo.net/plumb

======
smt88
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
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](http://chriswarbo.net/posts/2014-08-18-edsl.html)

~~~
smt88
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.

