Hacker News new | past | comments | ask | show | jobs | submit login
PHP as sexy as Scheme using lambdas and recursion (newmediacampaigns.com)
36 points by KrisJordan on Aug 24, 2009 | hide | past | favorite | 38 comments



I for one think this is awesome - particularly for those of us who sling php for a living by day and read programming romance novels by night. My contribution in a similar vein can be found here: http://commonphp.blogspot.com/


Well, it's been written somewhere that the longer you work on anything the bigger the chance that you'll have a bug-ridden implementation of lisp in there somewhere...


Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule):

  Any sufficiently complicated C or Fortran program contains an ad hoc, 
  informally-specified, bug-ridden, slow implementation of half of Common Lisp.


Any sufficiently complicated Lisp program contains ad hoc, informally-specified, bug-ridden, slow implementations of the top 100 perl modules.


That sounds funny, but how true is it? Let me use http://ali.as/top100/ as a list of the top Perl modules. #3 on the list is Pod::Escapes which I suspect is not implemented in very many Lisp programs at all.


I think it's pretty true. That list is heavy on "plumbing" modules that are pulled in as dependencies. I don't know a good one that's more indicative of what programmers deliberately pull of the shelf for a project, which is what I was talking about.

Let's remember Greenspun used TCL for his commercial work.


To be honest, I'm not quite sure what this article is trying to point out; lambda functions (and functional-style programming) have been a part of the PHP language for a very long time -- since PHP4 to be exact. It may not be as "sexy" to look at as Lisp et al, but it's certainly been doable.

    $fn = create_function( "$a", "return $a * 2" );
    $list = array( 1, 2, 3, 4 );
    $double = array_map( $fn, $list ); // array( 2, 4, 6, 8 )
or

    function my_filter( $a ) { return $a > 10 ? true : false; }
    $list = array( 5, 10, 15, 20 );
    $less = array_filter( $list, "my_filter" ); // array( 15, 20 )


there's a real problem associated with using create_function:

It's not much more than a glorified eval(). Evaluation takes place at runtime, so you don't notice syntax errors until it's too late. Bytecode-Caches can't cache your function and as the function body is a string, you won't get syntax highlighting in most editors.

Also, create_function really creates a named (with a random name in the form lambda_number) function in the global scope. Functions in general are all globally scoped and come to life once the execution reaches the function declaration. So this actually works:

    function a(){
      function b(){ echo "gnegg\n"; }
    }
    a();
    b();
Whereas

    function a(){
      function b(){ echo "gnegg\n"; }
    }
    b();
wouldn't.

This also implies that no scope is captured and you can't access any variables of the outside body of code.

5.3 brings real anonymous functions and provides a way to conserve the enclosing scope (thus allowing you to create closures), though the syntax is a bit awkward and variables of the outer scope you want to access need to be declared one by one.


Yes, every single point you made is correct, valid, and of much concern. My point was simply that everything the article covers was already completely doable since PHP4, even if it wasn't the most optimal solution. It was more a teardown of the article than the features of PHP 5.3, which I would be taking advantage of in a heartbeat if only people would actually upgrade their PHP installs in a timely manner...


"as sexy as Scheme"?! No way.


Seriously, it's ridiculous how long this is carrying on. It's the same debate heard in all ages, all political groups, etc. The debate against change. They're used to their PHP, and are, begrudgingly, willing to accept that LISP has some "neat things", but as of yet refuse to admit that their syntax is idiotic, and their language handicapped. So they try to "put lipstick on a pig."

I'm going down... I know. But it just takes so much more effort to translate the above into a well thought out, persuasive argument, and in the end it would have been ignored anyway by those who like to cling to their language just because they know it well.


Are sure you are replying to the right message?

And yes. This "my language is better than yours" "debate" is completely misguided and utterly brainless. It is also endless fun to have because just about any argument can be made.

One can't start a discussion on how the Apple II was superior to the TRS-80 these days anymore or how the MSX was a soul-less machine designed by a committee. People have to find other topics to start endless passionate discussions.

All we need to do is to keep the discussion civilized, something akin to keeping our playground clean.


The point is not to argue some kind of replacement of scheme for PHP. Or one language's superiority to another. The point is to show its possible to write functional, good looking PHP. Letting the "neat things" of LISP influence the way you write in other languages. Internalizing concepts that are first class in other languages by trying to adapt them to a language where they aren't first class is a great way to learn. Learning and being influenced by other's great ideas is how all languages and communities make progress. This is why Scala is such an incredible language to experience. It was shameless in its influences and its desire to merge OO and FP. Making connections between disparate languages like the layman's PHP and the academian's Scheme is exercise for the mind.


"The point is to show its possible to write functional, good looking PHP"

If you say curly braces and type prefixes can ever be pretty... ;-)

Lisp is not just a collection of neat ideas - it's a cohesive whole more or less found around those neat ideas. It's damn hard to take out those ideas and to put them in a language that was not designed around them without corrupting them beyond recognition.

And mind you I label myself as a Python enthusiast, not a Lisper. But I know what my tools can and what my tools can't do.


I agree that this is a neat thing that the folks who write PHP have done, good for them (no sarcasm), they've improved their impoverished language a little bit, like giving a starving kid a bicycle.

It's just hard sometimes for me to keep my mouth shut when I see articles titled "PHP as sexy as Scheme", even when rationally I know that the author probably didn't really mean that literally. To me, it's like someone saying "DOS like OS X, now with 32-bit graphics!"


You are missing the other side of the argument. How ubiquitous/easy to setup/find cheap hosting for is lisp? Not very. That is why people still use php even when they "know better" - I feel those same people can leverage these new capabilities to write even cleaner code whilst living with the compromise. That is not a "blind spot" or out right denial it's pragmatism at it's finest.


1) It still has all those ugly sigils.

2) There is still a large body of "PHP coders" that don't code this way, don't expect others to code this way, and probably won't understand code written thus. The community is the language.


Re "and probably won't understand code written thus".

Rather than giving up on the masses of "PHP coders" by labeling them incapable of functional style programming, recursion, etc, why not try to show them? If they're capable of wading through the inconsistencies of PHP they're pretty damn capable in my book. Sure they may lack the rigors of a computer science background but that doesn't mean they're uninterested.

Showing a "PHP coder" a different paradigm of programming in a different language is going to be less effective than trying to express it in the language they know. Personally, I'm really enjoying the challenge of taking the beautiful concepts taken for granted in many other programming language circles and teaching/expressing them in a language understood by the "masses".


More power to you.

However as a former PHP programmer I had very good reasons to give up on the community. The biggest one being the sparseness of quality code. As a PHP developer trying to learn how to write good code you find yourself jumping from island to island of good ideas floating in a sea of crap. The community has the lowest signal-to-noise ratio I've ever seen.


There's also a large body of PHP coders who are smart and continue learning new things, but you don't hear as much about them because they don't publicly humiliate themselves on the internet, and aren't such easy targets for disrespect.


PHP, welcome to the early 80s. Who knows, soon you might have real datatypes!

Does the Zend engine do TCO? When I search, Google thinks I mean "Total Cost of Ownership". All I can find is http://devzone.zend.com/article/1235.


This does nothing to address PHP's biggest problem, which is the user base's lack of motivation to migrate away from PHP 4.


There's a quote about pigs and lipstick that might apply here.


Given enough lipstick, you can smother the pig.


I remember fiddling around with PHPs recursion and having it get very bad very quickly.

Why use lambdas and recursion with PHP when there's tons of languages that do it better?


Sometimes it is more practical to update a codebase than to rewrite it entirely in a different language.

From the comments here you would think it is bad that writing clean PHP is possible...


You could also generate PHP code from Scheme or Common Lisp. That way you can write in the language you like and update the codebase.


I would prefer if such approach was taken to ease a gradual reimplementation.

The risk of this just making the codebase even uglier is enormous.


I thought about that too. There are programs that can handle making PHP or C beautiful. GNU indent is one of them I think, and there's another one called TidyPHP? Something like that.

So you just generate and then run the code through that if you need it to be human readable. I assume most companies don't give a shit as long as it works ;)


I fear a Scheme to PHP code generator would turn out PHP code that's ugly beyond what any code beautifier could hope to fix. It's not make-up - it would be akin to major surgery.


I'm sure it would only require indent fixing if coded properly.


Lambdas and recursion are only a small part of the decision for a programming language. There are many, many deliberations in picking a language.

Availability on the target platform (cheap web hosters?), availability of libraries, familiarity with the language (of the entire team, both current and in the future), purpose (aiming to get to the market quickly, or trying to learn a new language?), compatibility or integration with an existing code base, et cetera.

All these deliberations taken together may lead to a decision to use PHP. If so, it is nice to have lambdas and recursion. "It's better in another language" is without meaning in that case, because the feature is so small compared to the other deliberations. It quickly turns into the better question: "is it good enough?"


no


'false' still equals 0.


wtf?

You can't say PHP is as pretty as scheme when ("false"==0) evaluates to true. It just can't happen.

And if you think I'm some lisp dude slagging PHP, I wrote a PHP framework and work with the garbage everyday.

http://getheavy.info/


I believe your criticism is equivalent to the old "macs only have one mouse button" argument. Sure, false==0 and "false"==0 both evaluate to true, but is that really a bad thing? It is well known and well documented behavior. I would even argue that this is an important feature of PHP. And if you want strict comparison, there's still the === operator, just like in JavaScript.


I think you're getting downvoted because your comment was irrelevant to the topic of lambdas and recursion. Your second comment uses a technique that I will call "ad hominem defense" from now on; upvoted for making me think of this amusing expression.


The title says PHP as sexy as Scheme.

It's like comparing McDonald's to a Gordon Ramsay restaurant.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: