lesscode.org

Chris Wine left this as a comment and I thought it deserved a page of its own. — Ryan

In a recent meeting with a BEA developer, I was told how a small non profit recently converted their website from ASP to PHP. Why I immediately asked? Because the resources for the implementation were less expensive, and there were thousands of CMS, blog and wiki applications to choose from, rather than just a few in the Microsoft environment. Application availability used to be the Achilles heel of platforms that competed with Microsoft. I remember UNIX vendors not having “enough” applications running on their OS, and paying big bucks to ISVs to port product to their platform. Now these scripting languages with zero marketing budgets have flipped the tables on Microsoft. I am impressed.

Scripting languages are winning the mind share for developers, because recent grads know and like these languages. They are easy and inexpensive to deploy, and you get results fast. While some say they are not scaleable, developments at Google and Yahoo say otherwise. For those that still want a more proven solution for large deployments, Java has its place in companies that have requirements for thousands of concurrent users. That said, there are many more companies that do not have requirements for thousands of concurrent users. And as Joel Spolsky says, “It is easier to start small and cheap and scale up, than to start big and expensive and scale down.”

I ran some quick searches, to determine what people in the technology universe are talking about. While my survey is by no means a scientific random sample, I still believe it has some merit. Also, I used less than ideal search parameters for the scripting languages as some of them are common words (Python and Ruby).The merit is not in the absolute values, but in the ratios. I believe that the number of relevant posts on these scripting languages is 300-1000% higher than what I show below.

Google Suggest (as of July 22nd)

J2EE Results

• JBOSS J2EE 518,000 results
• BEA J2EE 999,000 results
• Oracle J2EE 1,920,000 results
• IBM J2EE 1,950,000 results
• Sun J2EE 3,690,000 results

Scripting Results

• PHP Software 30,000,000 results
• Perl Software 14,100,000 results
• Python Software 8,850,000 results
• Ruby Software 4,780,000 results
• Jython Software 0 results

Dot Net Results

• .Net Software 32,300,000 results

Totals

Total .NET Results: 32,300,000
Total J2EE results: 8,610,800
Total Scripting results: 23,458,000

Technorati

.Net Posts

• .Net Software 55,046 posts

J2EE Posts

• BEA J2EE 687 posts
• BEA Portal 415 posts
• JBOSS 991 posts
• JBOSS Portal 215 posts
• Oracle J2EE 1,534 posts
• Oracle Portal 1,221 posts
• IBM J2EE 1,456 posts
• IBM Portal 1, 936 posts
• Sun J2EE 1,791 posts
• Sun Portal 4,376 posts

Scripting Software Posts

• PHP software 15,829 posts
• Perl software 6,828 posts
• Python software 4,704 posts
• Ruby software 2,037 posts
• Jython software 143 posts

Totals

Total .Net Posts - 55,046
Total J2EE Posts -14,622
Total Scripting Posts – 29,398

Conclusions

The revolution is here. It may not be televised (yet!) but it is being blogged, and otherwise documented. BEA may of may not get bought. I don’t know, and now that I am wrapping up this post, I think my original uninteresting. The more interesting question is “Will the scripting languages assume the role of Linux in the mid-nineties?” Can scripting languages be a mindshare leader in 10 years, with growth outpacing all of the J2EE vendors and .NET combined? In 2015, will we talk primarily about .NET, and some scripting language(s)?

Does anyone even doubt this hyposthesis?

End of rant.

CW

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.

Lots of people talking about this Meijer / Drayton paper (warning: PDF, sane HTML version here) coming out of Microsoft Corporation. The paper is titled, Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages.

We are interesting in building data-intensive three-tiered enterprise applications. Perhaps surprisingly, dynamism is probably more important for data intensive programming than for any other area where people traditionally position dynamic languages and scripting.

That’s the first part of one of many paragraphs I found intriguing and, IMO, is dead on. Unfortunately, that leads us to the sentences that are meant to support that claim:

Currently, the vast majority of digital data is not fully structured, a common rule of thumb is less then 5 percent. In many cases, the structure of data is only statically known up to some point, for example, a comma separated file, a spreadsheet, an XML document, but lacks a schema that completely describes the instances that a program is working on. Even when the structure of data is statically known, people often generate queries dynamically based on runtime information, and thus the structure of the query results is statically unknown.

I’m not sure I follow the logic here. Dynamic languages like Python, Ruby, and Perl have a more powerful set of data manipulation facilities that require less code and read easier than their statically typed analogs in Java, C#, and C++ but they’re no more aware of the data’s underlying type system. I have a bad feeling they really wanted to go down the same old SOAP/RPC and XML Schema (see: gHorribleKludge) data binding path here and figure out how we can just abstract away the entire concept of data and make everything look like nice little objects. If it didn’t work with our current languages, it must be a problem with the language, right?

Anyway, the paper received a pretty thorough beat-down over at Lambda, which is always a bad sign when you’re talking at the type/language theory level. I personally have mixed feelings on the paper - while I think anything that puts dynamic languages on equal ground with the more accepted statically typed languages is a good thing, I’m not sure that inventing a new peacefully integrated language and discarding the ones we’ve actually observed working for so long is the best way forward.

How about you guys just drop your types for now and we’ll add them back in later. :)

I just stumbled on, not one, but two separate weblogs dedicated to comparing and contrasting various Python template languages. The Python Template Blog by Tim Underhill and The Python Template Weblog by… another Tim? Neither have actually progressed so far as to make actual comparisons but if they end up being anything like the PyWebOff blog, which compares Python web frameworks, they’ll be a tremendous resource for the community.

Go Tims!

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.