Design Patterns in Dynamic Programming

Tweet

Via reddit (great site if you suffer attention defecit): Design Patterns in Dynamic Programming by Peter Norvig (Director Research at Google).

In slide form it’s somewhat tricky to extract anything more than the gist of what’s being said but there’s some really interesting stuff here. It’s perhaps easiest to understand in context of this old but (unusually) insightful post on /.;

The dirty unacknowledged secret of design patterns is that they’re strongly coupled to a language. For example, switching from a statically typed language like Java to a dynamic one with forwarding substantially changes the approach to Factory, Proxy, Singleton, Observer and others. In fact, they’re often rendered trivial.

This is the first serious attempt I’ve seen to identify patterns specific to dynamic languages and found myself nodding. For example Partial Evaluation [slide 1] and slide 2;

Intent: Write literate code, compile to efficient code

A prime example of that in PHP would be WACT’s template components which turn declarative template tags into “runtime” PHP spaghetti (that you don’t need to care about). Believe this is also a big selling point in Rails, which has made good use of Ruby’s macro capabilies for stuff like defining object relationships in active records – by way of comparison there, perhaps the closest PHP can get to that is illustrated by EZPDO, which has you place those statements in PHP comments alongside your code, which EZPDO extracts.

That said, not all of this talk fits well to PHP, which doesn’t claim “everything is an object”; functions, for example are not objects and support for programmatically modifying a class at runtime is, essentially, non-existent. There’s a kind of bitter pill here methinks – at the time when PHP5’s object model was being designed, Java had OOP cornered and PHP5 makes it’s pitch in that direction. With languages like Ruby, Python and Javascript (Lisp in C’s Clothing) hitting the mainstream, you might ask “Is PHP dynamic enough?”

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • gaialucien

    yeah and with ruby design patterns are somewhat “invisible”. The factory can be implicitly a constructor, the Observer can be a Proc etc.

  • Dr Livingston

    well done harry for bring this to our attention… to me, slide 4 must be the clearest description of what a design pattern is, that i’ve seen so far :)

    very informitive,

  • soso

    PHP has
    * no lambdas (like Ruby, Perl, Python)
    * no blocks (like Ruby, Smalltalk, Lisp etc.)
    * no closures (like Ruby, Perl, Smalltalk, Lisp etc.)
    * no generators (Python)
    * no list Comprehensions (like Pyton)
    * brocken OOP Support (http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/)
    * lame Introspection

    is PHP dynamic enough? definitly NO.

    PHP does to many things at compile-time (like the whole “static” “self::” stuff) instead run-time.

  • Ren

    Yeah, just found myself wishing PHP5 was more dynamic.

    Was fiddling about with some designs, and just wanted a decorator for something.. why can’t PHP have a function that takes a className, and a destination className, and magically build a Decorator class to subclass from.

    Even looked at runkit, but no functions for adding classes programmatically.

    If (java|ecma)script was popular on the server, it’d be definately my choice of the current scripting languages.

  • gaialucien

    well an example in ruby doing Decorators uses the method_missing approach, so i guess you could use __call ?

  • maximus

    PHP has in coparison to real dynamic languages like Ruby, Perl, Python, Lisp absolutely no metaprogramming support.

    As php.net says “PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”

    Now then PHP is a dynamicaly typed *scripting* language. It lacks all advanced dynamic features. Otherwise Ruby and Python are strong (not static) typed *dynamic* langugaes.

    PHP will always stay only a scripting language, because PHP-Devs constantly reject all andvanced features. Current discussion at internals-mailinglist about named arguments shows it perfectly.

  • Fenrir2

    Factory:
    the_class = Integer
    var = the_class.new
    the_class = String
    var = the_class.new

    Kinda list comprehensions:
    arr = [3, 4, 5, 7, 2]
    arr.select{|i| item

    Generators:
    class SomeGenerator

    Introspection is not read-only:
    a = 4

    def a.say_hello
    print "hello!"
    end

    a.say_hello

    ;-)

  • Ren

    Or in javascript with its superior C style syntax ;)


    the_class = Number;
    v = new the_class();

    the_class = String;
    v = new the_class();


    arr = [3, 4, 5, 7, 2];

    Factory

    a = 4;
    Number.prototype.say_hello = function () { alert('hello!'); }
    a.say_hello();

  • http://www.lopsica.com BerislavLopac

    If (java|ecma)script was popular on the server, it’d be definately my choice of the current scripting languages.

    You nailed it, man — I’ve been craving for it for ages. mod_js, anyone?

  • http://www.phpism.net Maarten Manders

    Harry, please don’t call it dynamic programming. It reminds me of dynamic programming from my ‘data structures and algorithms’ lecture. *cringes* :-)

  • bonefry

    Could Harry Fuecks post a blog without mentioning Java not even once ?
    Nope. Not going to happen.

  • maximus

    bonefry

    it is not about Java: Python and Ruby are killing PHP

  • http://fbronx.dotgeek.org fbronx

    You nailed it, man—I’ve been craving for it for ages. mod_js, anyone?

    This is something on my todo-list for wxJS (http://wxjs.sourceforge.net)

  • http://www.phppatterns.com HarryF

    http://wxjs.sourceforge.net

    Wow – that’s one of those links that changes my view of things. More so for leading to E4X, which I’d completely missed and is already available in Firefox 1.5

  • bonefry

    it is not about Java: Python and Ruby are killing PHP

    Well yes, I knew that from the moment I took a look at Python.
    And then with Ruby, which is a pice of cake, PHP looks really …. static.
    What I mean is … I love Java, but PHP is not Java, and the way PHP evolved gives a bad taste in my mounth.

    About my comment above … it’s just a tiny detail I noticed :)

  • http://www.ezpdo.net nauhygon

    this reminds me of what jeff moore, the wact architect, said in his posts (1, 2).

    looking at the history of php, one shouldn’t be surprised to see why php in general lacks the ‘dynamicness’ that python and ruby provide. it was the dominating objectless c culture in its early days. following the java suit, the later introduced object model almost eliminated any possibility of functional programming. by design.

    but hey, shouldn’t we be happy already at least php has create_function() – a little more than nothing to quench your ‘lamdba’ thirst. ;)

    at the end of the day, we all know php is still the tool that’s making many of our sites running and we cannot thank the php devs enough. the question is, will it always be? or, will the world eventually be pulled toward the lisp’ish side? what then with php? okay enough, i hear you say, “don’t worry. be happy.” :)

    p.s. harry, thanks for the honorable mention of ezpdo.

  • http://mgaps.highsidecafe.com BDKR

    it is not about Java: Python and Ruby are killing PHP

    This reminds me of something Harry posted a long time ago. Something to the tune of “A Natural upgrade path for ASP”? Ah yes,
    here it is.

    Anyway, in there I quipped that the natural progression for PHP is most likely Python. This conversation seems to be leading in the same direction.

    Now let me qualify this and say that my comment in the story referenced above spoke of taking PHP out of the browser (or should I say off the web server) and doing desktop development. PHP-GTK. It’s in this arena where Python is kickin’ PHP’s arse.

    The web on the other hand is a different story of course.