Python Performance

Good news, but let's not get too sweaty over this...

IronPython is markedly faster on PyStone than CPython.

...remembering the CPython VM does not really push the envelope of VM techniques.

IronPython at PyCon

Technorati has dug up a list of items on IronPython at PyCon this week. I've not consumed any of them yet, but hopefully they will be enjoyable.

It looks like the new release of IronPython depends on the Yukon CLR. So for now it looks like CPython with the Python.Net assembly bridge is the approach of choice for "real" uses. With a bit of care Python code could then port over to IronPython.

Not sure what the language level of IronPython will be vs. CPython when Yukon is released.

Alan Kay (again) on Software Engineering

Kay's interview has made the rounds more than once, but with recent posts on software as engineering or craft, let's go back to the guru...

If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves...

I would compare the Smalltalk stuff that we did in the ’70s with something like a Gothic cathedral. We had two ideas, really. One of them we got from Lisp: late binding. The other one was the idea of objects. Those gave us something a little bit like the arch, so we were able to make complex, seemingly large structures out of very little material, but I wouldn’t put us much past the engineering of 1,000 years ago...

I finally understood that the half page of code on the bottom of page 13 of the Lisp 1.5 manual was Lisp in itself. These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over...

All of these ideas could be part of both software engineering and computer science, but I fear—as far as I can tell—that most undergraduate degrees in computer science these days are basically Java vocational training...

In a history of Smalltalk I wrote for ACM, I characterized one way of looking at languages in this way: a lot of them are either the agglutination of features or they’re a crystallization of style. Languages such as APL, Lisp, and Smalltalk are what you might call style languages, where there’s a real center and imputed style to how you’re supposed to do everything. Other languages such as PL/I and, indeed, languages that try to be additive without consolidation have often been more successful. I think the style languages appeal to people who have a certain mathematical laziness to them. Laziness actually pays off later on, because if you wind up spending a little extra time seeing that “oh, yes, this language is going to allow me to do this really, really nicely, and in a more general way than I could do it over here,” usually that comes back to help you when you’ve had a new idea a year down the road. The agglutinative languages, on the other hand, tend to produce agglutinations and they are very, very difficult to untangle when you’ve had that new idea.

One clear implication is that language you use has a significant impact on your ability to do software engineering. Your language is your most highly used tool.

Do Good for America - Use Lisp

(via Lemonodor)

François-René Rideau implores...

The obsession with parsing and syntax in computer science curricula is hurting America.

SPLJ Part 2.

Mark Baker suggests...

The resource oriented (RESTful) solution would exhibit greater degrees of architectural properties such as scalability, visibility, and simplicity than the service oriented solution, because RESTful solutions embody architectural constraints which induce those properties.

SPLJ

In the raw...

Applications remain largely discrete things, whether they’re wired together with RPC, SOAP or REST. Only slightly, (particularly around the blogosphere) are we seeing the pieces joining together.

Preventing Death

Somewhere around 13,000 children die of hunger-related causes every day around the world. I wonder when the US congress will subpoena them to come testify. Certainly they will get at least a snack on the airplane.

Certainly the congress can do something to save at least one of those lives each day. That's at least 364 more lives saved each year than can be saved in the case in Florida.

How much longer can our "culture of life" continue to ignore millions of deaths a year?

New for Who?

Depends on what the meaning of "new" is...

I firmly believe that the new advances in languages will borrow heavily from languages invented three decades ago such as Lisp and Smalltalk.

According to Alan Kay, computer professionals were smarter back then, because computing was still an esoteric technology. Now, we have a pop culture when colleges are essentially vocational schools.

...from Wesner Moise.

The Damage Done

James Robertson hopes for the best...

I guess the only good things about binary XML and WS* is that the people involved aren't doing greater harm somewhere else.

Seems like a fairly wide swath of damage from this vantage point.

I have a feeling things are just getting started too. Look out. CORBA took a long time to get to a moderately usable interoperable condition. For better or worse (we'll see) that increasing utility and popularity ultimately led to its current status, dying a slow death.

Math

(via Paul Graham)

I found, when I was studying mathematics, that 2 things were true: (1) the teacher was not too good and (2) the book was not too good. So I would always buy a half-dozen books on the topic and try to get the full picture by reading the same sections in each book. The combination helped me understand much more than the sum of the content. Also, I was never opposed to reading something as much as 10 times until I squeezed everything out of it.

I had the same problem, but I was not as diligent in overcoming it.

Old World Distributed Computing

Steve Loughran writes...

By adding all the functions of CORBA to SOAP, WS-* replicates the old world of distributed computing, only with underpinnings (HTTP, XML) not designed for that particular role.

Opposites

James Robertson writes about problems with the "common" language runtime. Some of the comments are suggesting you gotta take the good with the bad. I don't buy it and don't believe the commentators know about which they speak. Read on...

If you want the best of Smalltalk (or Python or Lisp) and access to dotnet as well then use a bridge between runtimes. (Smalltalk bridge, Python bridge, Lisp bridge)

I see no reason that all languages have to run in a crippled VM like the CLR or the JVM when you can get to these via bridges that keep them at arms length. The alternative is you cripple the language and lose most of the tools that make you productive in the first place.

I think any "common language runtime" has to be built at the foundation on good technology. Crippled languages can then be built on top rather than vice-versa. This was demonstrated on Lisp machines where Fortran, C, Pascal, Ada, etc. compilers were ported.

Funny that when good languages are ported to crippled runtimes, the good languages suffer. But when these languages were ported to the Lisp machine, the crippled languages became *more* capable than their original designs.

I've used C on the Lisp Machine. I can say, and everyone I know with the same experience agrees, this is the *best* environment for developing C programs. The same is never true for good languages ported to the CLR or JVM.

Maybe they'll get there some day. Maybe.

GoDaddy and Free DNS

Like Dave I use GoDaddy for inexpensive domain registration. I have for several years. I use it for sites they host (e.g. my son volunteers time and helps with web stuff for Arin's House) and sites I host elsewhere.

Dave's wondering about DNS for sites hosted elsewhere. I use ZoneEdit.

Croquet or Cannon?

I've got to put Croquet on my list of things to do. Every so often I see another post and look around, and wonder why I haven't tried it yet.

Here is an example of a window containing Flash content. Flash and other media forms may rendered on any polygon or combination of polygons within a scene. It should be kept in mind that it is not at all necessary for the frame of any window to be rendered. Therefore it is possible to have flash animations or media output of any size be rendered in any orientation or configuration within the Croquet space.

Being There

Update: added reference for W.Cunningham quote.

Bill de hÓra writes how keys to software success can be found in the business and operating models you adopt. Heed this advice.

We can be successful with the latest "service orchestration" software or with Smalltalk and relational databases, both decades old. (I think the latter may provide an advantage.) The keys are in how we form teams, communicate, and do work.

I would ban the phrase "service-oriented anything" until my organization understood this paragraph...

The reason in the past we needed to worry that 'it will never X' is because there is an assumption built into the procurement, requirements and development phases that systems of this kind get finished and that's it - no more money for active development. You have one shot to get it right. In turns out that one shot is an operational myth and a dangerous one at that - business systems are never really finished, but thinking that they are radically affects thereafter how budget is dispensed and for what.

Test-driven development is proving to be the operating model for continuously adding value to a system. We need equivalent models for the business that surrounds development.

• Whole teams.
• Communication.
• Frequent feedback.
• Test-driven.
• Continuous integration.

Ward Cunningham illustrates that the burden will land on middle and upper management as developers get their act together...

A common management mistake is to keep everyone busy by giving them different things to do. This basically tells people to work alone, and that is an easy way to fall prey to exactly [all] sorts of fears.

Agile asks the team to work together on only a few things at a time. That way, once someone gets over the wall, they can help everyone else over after.

Customers ask for a lot because they don't think they will ever get a chance to ask for more. Regular delivery of capability that doesn't go away will erase this fear in customers.