lesscode.org

Peter Norvig: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern.

A few of the 16 patterns Norvig counts rely on a fluid macro facility like those found in various Lisps, but Python, Ruby, Perl, etc., still do very well on those patterns rendered useless by first-class functions, dynamic typing, and other niceties.

This Joel on Software Thread shows that the notion that “LAMP can’t scale” is alive and, apparently, still quite popular.

The big issue I have with rails scalability is admittedly based on some prejudices I have about large scale webapps. Rails doesn’t really have a model of a stateful server, primarily because there is no threading, connection pooling, etc. You have one lighthttpd/apache/whatever thread, and it has one rails instance, which has one db connection, etc.

Oh, wait, that comment is just plain old disinformation and/or ignorance of how these systems actually work.

This comment does a far better job of representing the popular your-stuff-doesn’t-scale mindset:

scalability is an important issue when choosing a development environment. If it is not scalable, you made the wrong decision and you will be rewriting your app into something that is scalable once you start getting customers. And this is just the wrong time to have to start worrying about rewriting your app. It is always better/cheaper/faster to do it right the first time rather than plan for a rewrite in a new environment once you start getting busy.

Required until proven unnecessary in all its glory.

David has a nice rebuttal that sums up nicely the place I think many of us have reached with regards to the scaling issue: it’s a boring problem that’s been solved for years. Maybe we should tell others?

Along with the usual set of “that’s not for the enterprise” posts, there are also some insightful posts. I’d encourage you to join the discussion, especially if you have a cluestick similar to Ged Byrne’s:

I think I should start posting on all those enterprise server forums with comments like ‘I’m concerned that this won’t scale down very well. Could a team of 3 provide 24/7 support while extending functionality? We only have a couple of thousand users and at the rate the market will accept a bigger team would not be economical. The thing is, we 3 really want to do this rather than ending up as corporate drones wasting our existance in a cubicle.”

Anyway, here’s something IBM/Zend or other members of our community toating around a fair amount of spare cash and resources could do to help the poor hippies out in gaining a bit of acceptance: slay this cow once and for all, formally, by setting up an environment to simulate the kinds of “enterprise class” loads we’re seeing in even the most demanding environments. You can use David’s basic setup or perhaps this one from circa 2000. If, upon being weighed we’re found wanting, we’ll find a way to fix it like we’ve been doing forever. But we would feel more comfortable if the burden of proof was placed appropriately. Our repeated attempts to show the scaling capabilities of LAMP/friends seem destined to be repeatedly deflected by the Enterprise Class Distortion Field.

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…

I’m just now getting around to reading John Anthony Hartman’s inspiring lockergnome article: LAMP -Shine On, You Crazy Diamond:

Linux, Apache, MySQL, and PHP, Python, and Perl - a mixture that seems to have moved beyond the fossilized carbon stage. With heat and pressure, it has molded this stack into a beautiful diamond. Linux has grown from a group of tinkering hobbyists to a multibillion dollar industry. Apache dominates the Web server market with an almost three times margin over its closest competitor, IIS. MySQL has over six million installs, and if you include PostgreSQL, its Berkeley DB growth in open source databases is growing like wildfire. This brings us to PHP, Python, and Perl. If you add up the click statistics based on Google searches, these components of the lamp stack make up the largest percentage, supplanting C as the language(s) with the most hits. This also holds true for the most programming jobs that have openings.

There’s no denying it folks, we’re movin’ on up.

Tim Bray posted a doozy a few minutes ago on the changing face of PR, analysis, and trade press:

The Old Public Relations

The mechanism was easy to write down, it went like this:

1. Senior management, with a lot of input from marketing people, would work out a company’s message and talking points.

2. Internal marketing people, working with PR consultants, would try to burn the message into the retinas of the trade press and analysts.

3. The journalists and analysts would do what they do: the whorish segment of the profession regurgitating the company messages to the attention of very few, the independent thinkers producing sometimes-useful analysis of what the companies were really up to.

It never worked that well; to start with, it was expensive and slow. Also, there was a huge conflict of interest: the journalists and analysts, who positioned themselves as independents, were in fact mostly on the payroll of the companies trying to push the messages.

The New Public Relations

The new PR pipeline is a lot shorter, simpler, and wider:

1. Senior management works out a company’s goals and messages.

2. Management works hard to make sure that the employees understand them.

3. The people who are really doing the work tell the story to the world, directly.

It’s important to realize that this change in authority is partially responsible for the rise of LAMP/friends as a viable platform for building real applications. That is to say, these technologies have always been a capable platform but the change in how people receive and participate in information has allowed these technologies to step up and finally begin claiming the problem areas they fill so well.

Our biggest problem is that we don’t talk loud enough.

As an example, would 37signals have been possible even two years ago? I really don’t think so; at least, not in its current form. As much as I love the technical and methodological stuff those guys are pushing out, what I think is most interesting is how well they understand The New Public Relations.