Tuesday, July 25. 2006
Googles Summer of yawn.
Google's "Summer of Code" has started and they have announced a few PHP projects. Some of them look interesting and useful. However, I am going to pick apart one in particular, that to be honest, looks neither interesting or useful: The PHP Macro Preprocessor. This (as described) sounds exactly like a rewrite of the C preprocessor, which one can work with fairly easily in a PHP environment. To see this duplication of effort on something so boring and useless makes me question just how much PHP is its own language, versus a Frankensteins monster of language clones; see PHP 5's object system for a perfect example.
Creating a function to create the list looks like this:Now it is one thing to just simply trash the hard work of others and say "you're doing it all wrong!". It is another thing entirely to come up with a different idea. One of the first ideas that I had was to use PHP to preprocess PHP. Lisp and some Scheme implementations already use this process of taking the host language to process the macros in said language. They operate on the code as data first, and then that data becomes the code that is operated on. For Lisp and Scheme it works really well because the code is formatted like one of their key data-types: s-expressions (for an example of sex-pressions, see the sidebar).
Why does the PHP Preprocessor need to be stuck in a world of #ifdefs and #includes? Instead of blindly copying what the C preprocessor does, why not focus on the languages strengths and deficiencies? The object system of PHP needs to be looked at, and see if it can be improved upon through a method of code transformation. Imagine being able to tell your preprocessor that you were writing a facade pattern, and having it fill in 90% of the details, leaving you with the last 10% of implementation. The reason that the PHP community (and similarly the Java community) are so all upon the pattern bandwagon is that both languages lack the facility to gracefully express the patterns in abstracted code; if there was a way for a preprocessor to deal with this deficiency, then a fundamental flaw of the language is fixed. So why not use a subset of PHP to transform PHP? Just as you use PHP to transform an X(HT)ML document, you could use a speedy subset of PHP to transform a PHP document.
The focus on an inline preprocessor is quite limiting as well. All of the processing capabilities are simply skipping over and replacing small sections of code. Why not take a page from the very powerful syntax-rules processor of R5RS Scheme? In fact, its template matching rules would probably make a lot of sense to PHP developers, it is like using a website template in reverse!
Like I said before, my problem with the macro system as described is that it just copies existing functionality from somewhere else without looking at the problem of creating dynamic, maintainable websites quickly; or looking at the issues surrounding macros and meta programming.
Now a Language on top of Scheme that builds PHP applications would be cool.
Scheme Code and Lists
Here is an example of a "list" in Scheme:(1 2 (3 4))This is a list of 3 elements, the numbers 1, 2, and another list containing the numbers 3 and 4.
Creating a function to create the list looks like this:
(lambda () (list 1 2 (list 3 4)))This perfectly exemplifies how similar code and data really are. There is an amazingly powerful set of functions to cope with and take care of lists, which makes building lists to later execute as code an absolute breeze.
Why does the PHP Preprocessor need to be stuck in a world of #ifdefs and #includes? Instead of blindly copying what the C preprocessor does, why not focus on the languages strengths and deficiencies? The object system of PHP needs to be looked at, and see if it can be improved upon through a method of code transformation. Imagine being able to tell your preprocessor that you were writing a facade pattern, and having it fill in 90% of the details, leaving you with the last 10% of implementation. The reason that the PHP community (and similarly the Java community) are so all upon the pattern bandwagon is that both languages lack the facility to gracefully express the patterns in abstracted code; if there was a way for a preprocessor to deal with this deficiency, then a fundamental flaw of the language is fixed. So why not use a subset of PHP to transform PHP? Just as you use PHP to transform an X(HT)ML document, you could use a speedy subset of PHP to transform a PHP document.
The focus on an inline preprocessor is quite limiting as well. All of the processing capabilities are simply skipping over and replacing small sections of code. Why not take a page from the very powerful syntax-rules processor of R5RS Scheme? In fact, its template matching rules would probably make a lot of sense to PHP developers, it is like using a website template in reverse!
Like I said before, my problem with the macro system as described is that it just copies existing functionality from somewhere else without looking at the problem of creating dynamic, maintainable websites quickly; or looking at the issues surrounding macros and meta programming.
Now a Language on top of Scheme that builds PHP applications would be cool.
(Page 1 of 1, totaling 1 entries)