lesscode.org

I’ll take it as a given that if you’re reading this then you agree that, for the sake of sanity and productivity, it’s time coders gave up on roll-your-own, and moved over to modern frameworks where one can concentrate on business logic rather than request parsing (and get all those AJAX goodies for free ;-) ).

I’ve been looking on with interest for the last year and a bit, and as I’ve watched the pioneers blaze their XP, RoR, lesscode trail across the web-firmament, I’ve begun to suspect that I must have missed something. Yes, it’s powerful stuff, and yes it isn’t all smoke and mirrors - there really is “gold in them thar hills…” - but, and for me it’s a big but, we seem to be missing the big picture. Where are the map makers? Where’s the documentation for the second (or third) wave?

Self-documenting code is all very well, and having a common vocabulary of design patterns helps when discussing solutions to individual problems. But what second-wavers really need (and I include myself here - no, actually, put me down as a third-waver) are more pictures. More exposition. Road maps.

Is there a way to add XD (eXtreme Documentation?) back into the XP mix? Writing elegant code is hard, and people who do it earn the admiration they received. But I would argue that writing good documentation is harder, and that it shouldn’t be left for the second-wavers to do.

People who’ve moved to XP have already gone thorugh the pain barrier of

• write the tests
• then write the code
• (then refactor)

and have proved that in the long run, it means better code, less debugging, in less time. But having proved that that works, might there be some benefit in switching to;

• write the spec
• then write the tests
• then write the code
• (then refactor)
• then write an overview!!!

Might this result in (my h-nought) more easily modfied code, quicker adoption by other coders, greater community support?

I’m genuinely interested in other people’s views on moving documentation down(?) the food-chain, so that it’s non-optional, and as integral to writing new code (and frameworks) as writing good tests. Yes, there are good auto-doc tools and methodologies out there, but that right now they still seem to be seen as secondary to the process by Joe Frontiersman, and they only deal with what’s in the file, not what’s in the coder’s/architect’s head. (There’s the nine diagrams of UML, yes, but who on the bleeding-wrist of open-source technology is actively using/sharing designs via UML?)

Let me know if I’ve missed a trick somewhere.

[A few thoughts for the pot: I believe the that the reason the Open Source model works because it’s based on non-coercive collaboration. But Source Forge is littered with unfinished, half-baked projects because someone didn’t think to check that there wasn’t already a project out there that they could use. (How many PHPUnits does the community really need?) Should there be a ‘requirement’ for documentation before a project gets listed? Perhaps it’s time for ‘ideaforge’, or ‘architectureforge”?]

This chart showing the number of requests for different languages on O’Reilly’s Code Zoo is interesting:

Yesterday we added two new languages to CodeZoo: Python and Ruby. You can see from the language requests graph, above, the languages for which we got more than a few requests (I’ve left off Cobol and the others that only were requested a couple of times). From this, the choice of Python is completely obvious — it was the winner in the request race, beating out C++ and many other languages that might be considered “larger” by other metrics. In addition to the clear demand for it, Python is a natural fit for O’Reilly, since we publish a great deal of treeware and online material about Python, and cover Python extensively at our conferences (especially at the Open Source Convention taking place this week).

Ruby, however, is tied for fifth on the list, and in raw component counts on our site, it is the smallest of the languages we support. As we’ve discussed on Radar over the past few months, we see Ruby as an emerging force in the open source world, driven by interest in Ruby on Rails, and by the excellent books on Ruby written by the Pragmatic Programmers…

I was actually really surprised at how strongly dynamic languages showed up on this chart. I’m eye-balling it as there aren’t any numbers but Python, PHP, Ruby, and Perl seem to have taken down almost 50% of the requests with C{,#,++} taking down a large majority of the rest. Is this a fair sampling of the general development population? Developers with a web/UNIXy background seem to be over-represented at O’Reilly so its probably a bit skewed, no? Still, the amount of acceptance dynamic languages are gaining is pretty staggering at this point.

I’d like to advise everyone attending OSCON with an interest in dynamic languages to not miss Sam Ruby’s pie-thon Update:

OSCON 2004 was the home of the pie-thon challenge, which pitted Parrot against CPython on a test of speed using a bechmark that Guido van Rossum designed. This presentation provides an update–not only on performance, but also on language compatibility, as well as an outlook on the potentials for inter-language interop that can be acheived by a common language runtime for dynamic languages.

I was lucky enough to chat with Sam about this a bit and the little I got out of him was intriguing. The blurb doesn’t go into a lot of detail but one of things he’ll be talking about is compatibility between dynamic languages at the runtime level. Here’s a sneak peek:

<rubys>    There is a big difference between Python and
           Perl. Ruby might be someplace in between.
<rtomayko> that's interesting. I've been seeing reports of 
           the same thing from the CLR and JVM crowds
<rubys>    my favorite example: what does 
           """ print  '1' + '2'; """ do?
<rtomayko> ahh
<rtomayko> and so the strong/weak thing is down at that level?
<rubys>    it is not just that.  "+" is a function in Perl.  It 
           accepts two arguments which have types.  It coerces them 
           to numeric values, and adds them.
<rtomayko> python = '12', perl = 3, ruby = '12' (i think)
<rubys>    "+" is a synonym for "__add__" in Python.  It merely is 
           the name of a method.  What it does is up to the first 
           argument.
<rtomayko> right, I see. and so all of these languages will have 
           to shift a bit.
<rubys>    shifting all the language a bit is what .net did.  And 
           you end up with "Visual Fred" (look it up)

Visual Fred was the name proposed for Visual Basic.NET by MVPs who quickly realized that VB.NET had nothing to do with VB due to the syntactic and semantic changes forced on the language by the common runtime.

Ruby-styled blocks in Python have been something to be a bit anxious about. After spending even a little time working with Ruby, it’s really hard to get the idioms that blocks facilitate out of your head. Dealing with certain types of problems with coroutines just feels right:

File.open("bla.txt") do |file|
   file.read()
end

With the equivalent Python being roughly:

file = open('foo.txt')
try:
    file.read()
finally:
    file.close()

Eewww. What attracted me to Python was its ability to make code read very closely to its intent as it would be described by a human. Resource aquisition/release is one of those things that I’d rather not have to read about when I’m trying to extract the essence of what a piece of code is doing.

Of course, you can get close in most cases by using normal callable passing…

def with_open_file(file, block):
    try:
        block(file)
    finally:
        file.close()

def do_stuff(file):
    file.read()

with_open_file(open('bla.txt'), do_stuff)

… but the Ruby block syntax reads better to these eyes and it seems I’m not the only one. A few weeks ago, Guido had this to say about the block style in relation to recent PEP activity:

That was all before I (re-)discovered yield-expressions (in Ruby!), and mostly in response to the most recent version of PEP 288, with its problem of accessing the generator instance. I now strongly feel that g.next(EXPR) and yield-expressions are the way to go.

So I’ve been following the succession of PEPs that have led us to PEP-342, Coroutines via Enhanced Generators, and PEP-343, Anonymous Block Redux and Generator Enahncements, with great interest.

It looks like there’s a decent chance that we’ll be able to stuff like this in Python 2.5:

 @with_template
 def opening(filename, mode="r"):
     file = open(filename, mode)
     try:
         yield file
     finally:
         file.close()

 with opening("/etc/passwd") as file:
     file.read()

This is accomplished not by adding an implicitly passed block construct like Ruby’s &block, but by adding a basic message passing protocol for generators. Generators will have two new methods: send and throw. The important one here is throw, which tells the generator to raise an Exception at its suspension point. All of this is hidden behind the implementation of with_template (sample implementation in PEP-342).

What I’m interested in understanding more fully is how the PEP proposed enhancements to generators will work in iterative cases or whether that’s planned at all. The examples seem targeted toward resource aquisition/release (which is fine, there’s definitely a strong set of use cases in that area). But I’m interested in understanding how cases similar to Ruby’s IO.foreach will be handled:

IO.foreach("testfile") { |line| puts line }

Note that this is different from Python’s…

for line in open('testfile').readlines():
    print line

… for a few reasons. First, resource aquisition/release is handled within IO.foreach where in the preceding Python snippet, it isn’t really handled at all. Second, IO.foreach reads the file iteratively, calling the block each time, where as an approach using Python generators, such as follows…

def lines(filename):
    f = open(filename)
    try:
        line = f.readline()
        while line:
           yield line
           line = f.readline()
    finally:
        f.close()

for line in lines('foo.txt'):
    raise Exception("this doesn't work")

… falls apart because the exception raised in the iterating block is not automatically signaled back to the generator. There’s no guarantee that the finally block will execute when the iterating block exits.

I have a feeling there’s some aspect of this that I’m not fully grasping. Perhaps Phillip (PING) or someone else with a good understanding of the proposed generator enhancements can stop by and comment; inquiring minds want to know…