https://portal.acm.org/poplogin.cfm? .... etc ... (I can't post the whole URL since it's linked to my account)

It's been quite a year for Python, and Google App Engine provides the dynamic language a very high profile indeed. GAE is a cloud platform that is competitive with Amazon's S3 (much like Stratos, on the planet Ardana might compete with Cloud City on Bespin ). GAE provides Django and other major Python frameworks, but I imagine that the real appeal is (a) the free hosting and (b) the CPU budget.

At PyCon, Microsoft demoed Django running on IronPython. This blog post detailing the code says "not quite complete but ... [good enough to] get Django's tutorial running." From a language geek standpoint, I prefer Ruby (those object-oriented grooves run deep), but IronPython is very clearly on the cusp of adulthood.

In other DLR news, Dermot Hogan has begun a series on writing a DLR language using ANTLR, the compiler-construction tool that I prefer.

Personally, I'm trying to figure out a way to get someone to pay me to write a DLR generator for ANTLR. ANTLR generates abstract syntax trees and this function works fine and is very flexible, allowing you to plug in your own tree-generators. All that needs to happen is the creation of new templates that create DLR expression trees.

My first-quarter project is coming to an end and although it's been overtime to make our deadline, it's beginning to look like we'll deploy next Friday, right on schedule. I'd dearly love to be able to get back to something that had technical and not personnel challenges.

Ted Leung has joined Sun to help support Python "in a similar fashion" to the JRuby project.

This is not just about Python on on the JVM. Sun will try to make its platforms, OpenSolaris and the JVM, the best place to develop and deploy Python applications.

But it's mostly about Python on the JVM. With IronPython approaching "fully baked" status, Python book sales up 31% over last year (http://radar.oreilly.com/Language_all.jpg), and applications like ResolverOne, Python is stealing some of the dynamic language thunder from Ruby.

The relative pace of Jython/JRuby and IronPython / IronRuby ought to provide plenty of ammunition for undoubtedly-overly-broad conclusions about the technical merits of the managed platforms and corporate cultures.

http://barrkel.blogspot.com/2008/02/langnet-symposium-videos-are-up-in-wmv.html

Recommendations :

http://langnetsymposium.com/talks/Videos/1-05 - Lively Kernel - Dan Ingalls - Sun.wmv

http://langnetsymposium.com/talks/Videos/2-01 - Newspeak - Gilad Braha - Cadence.wmv

http://langnetsymposium.com/talks/Videos/3-08 - Cobra - Chuck Esterbrook.wmv http://langnetsymposium.com/talks/Videos/3-09 - Intentional - Magnus Christerson.wmv

http://langnetsymposium.com/talks/Videos/3-00 - IronRuby - John Lam.wmv

http://langnetsymposium.com/talks/Videos/3-03 - Parsing Expression Grammars in FSharp - Harry Pierson.wmv

(follow image link to Zazzle store...)

While I talked about being blown away by certain talks at Lang.NET, from a pragmatic standpoint I very much enjoyed the practical talks, such as those given by Harry Pierson and, especially, Martin Maly. Martin is one of the IronPython / DLR developers and hand-wrote a compiler for a language called "ToyScript." This compiler is now part of the IronPython distribution. Harry wrote an F# PEG parser (is that redundant?) of ToyScript and I wrote an ANTLR-based parser. The hope is to show 3 different approaches to building the compiler front-end, but all using the same backend ("Hand off the AST to the DLR").

Now, on the way to that, I started yesterday writing a series of examples that do things exactly backward: start with the handoff to the DLR ("GenerateNopFunction()"), add nodes (Using XML to represent the AST), and then say "Oh, and you create that AST using compiler front-end techniques." The sad thing is that all of this will have to be in my copious spare time, since my language stuff isn't supported by paying articles (I did the Lang.NET conference on my own dime).

Like Charles Petzold, my first reaction to Jeff Atwood's question "What Can You Build in 600 Lines of Code?" was along the lines of "5 articles!"

But actually, I think 600 lines is just about the right benchmark size for a language, because it's:

• Small enough to develop in a weekend
• Large enough so that "finger typing" is neither dominant nor drowned-out
• Large enough to exploit a language's particular idioms and strengths

A caveat though: the use of libraries and frameworks can grossly distort this discussion. Frankly, the quote "commercial project written in less than 600 lines of Ruby code" (ibid.) is wrong: it ought to be "of Rails code." It's akin to saying "In DOS batch I can create a spreadsheet in a line of code -- all I have to do is type 'excel'!" (I know it's not exactly the same, but there's a similarity.)

This is one of the reasons why writing a parser has always been a measure of a programming language -- it involves complex pattern matching, the creation of a complex datastructure, transforms of that structure, and a fair amount of IO.

Harry Pierson's F# PEG parsers (is that redundant?) are a good example: I don't doubt he'll complete a parsing front-end to the "ToyScript" language in less than 600 lines of code. The first night at Lang.NET, I wrote an ANTLR parser for ToyScript (# lines in ANTLR, expands to # lines of C#!). From the impression I got of Newspeak, I think it would take significantly less than F#.

Although concurrency was laid out by Jason Zander as one of the overarching themes of language work moving forward, it was not at all emphasized as a primary concern in any of the talks I saw. There was some talk about language features that a "sufficiently smart compiler" could handle but no one took off their shoe and banged the table and said "We must focus on this!"

I button-holed Erik Meijer and Brian Goetz on the topic: Erik is a great believer in Software Transactional Memory and Brian is "cautiously optimistic" about it. Both were very quick to acknowledge that we don't really know how people will react to the complexities that emerge when the behavior of memory transactions starts to necessarily diverge from the familiar world of database transactions. When I mentioned the Actor model as being intuitive, Brian astutely diagnosed me as having a Smalltalk background and said that message-passing would be confusing to a population that viewed objects as -- I think his phrase was -- "glorified structs."

Yesterday I went swimming on a coral reef in 100' visibility with whales singing so loud that I almost expected to see them underwater. For the next 3 days, I'll be in Seattle, where I assume they have this thing I hear about called "heating."

Actually, after canceling the trip because I had such a non-productive, unlucky, and generally lousy January I decided at the last minute that the best thing in the world for me was to be in a room filled with people who totally out-class me.

My plan had been to spend, like, 6 weeks developing something and then saying "Well, I threw this together on the flight over..." and then have people say "well, it sucks of course, but for a plane flight, it's not bad." Now I'll just sit quietly in the corner. I'll be the guy wearing three layers of sweater over an aloha shirt....

Haskell is a language that is pretty hard to "just pick up" (especially if you are mostly familiar with mainstream, C-derived languages). Perhaps "Real World Haskell" by Bryan O'Sullivan, Don Stewart, and John Goerzen will help the language (much beloved in academia) increase in popularity.

When I can shake some time free to actually learn F#, this awesome series of blog posts on "Practical Parsing in F#" is definitely something I'll revisit. Parsing is one of the better tasks for shaking free a large number of concepts about a programming language, since it invariably involves large and dynamic data structures, abstraction strategies, IO, etc.

The biggest problem with tag-based languages (<h1><% someCode %></h1> : the ASPs, the ColdFusions, the PHPs...) is that they facilitate monolithic code. This is related the big criticism of XML and DOMs for data structures, too: they facilitate the creation of hierarchies, not graphs. (As always with programming, the issue is "facilitates" not "possible"...)

My dear friend "Bob" creates horrific pages that are hundreds and even thousands of lines long, with <cfif> at line 100, and then a <cfelse> at line 837 and then a ... and ColdFusion isn't valid XML and there's a combination of HTML indentation and ColdFusion code indenting.

Just absolutely impenetrable stuff, and while I'm more than willing to blame many problems on Bob, I think this is a problem that the tool he uses (ColdFusion) is facilitating.

Sounds like a great opportunity to hang out with compiler geeks. Since someone's already beaten me to an LOLCode compiler for the DLR, I'll have to put in some work on my other projects: Excel# and a more serious language I've been noodling around with called Rinq, a REST-Oriented Language that supports LINQ.

Wes Moise's musings on Supercompilation led me to this discussion of the the myth of the sufficiently smart compiler.

The "sufficiently smart compiler" is still trotted out regularly, even though the market has moved away from demanding even moderate attention to performance at the compiler level. Have you timed your rectangular arrays in C# lately? Or, to be inclusive, have you looked at what's (not) hoisted out of loops in Java?

The existence of the Iron* languages from Microsoft stems from Jim Hugunin's discovery that adding moderate smarts allowed dynamic languages to run fast on the CLR:

1. Use native CLR constructs whenever possible. These constructs are all heavily optimized by the underlying runtime engine. Sometimes these constructs will have to be used creatively to properly match Python's dynamic semantics.
2. Use code generation to produce fast-paths for common cases. This can either be development-time code generation with Python scripts creating C# code or run-time code generation using System.Reflection.Emit to produce IL on the fly.
3. Include fall-backs to dynamic implementations for less common cases or for cases where Python's semantics requires a fully dynamic implementation.
4. Finally, test the performance of every CLR construct used and find alternatives when performance is unacceptable. Type.InvokeMember is a great example a a function that must never be used in code that cares about performance.

That's hardly the stuff of PhD theses (don't misunderstand me: Hugunin's paper, which actually said something important, is more valuable than 99% of CS theses).

The point, though, is that we are in a time of high tension between what is possible and what is practiced. This gives me hope that we might see true breakthroughs in programming languages. Fred Brooks spoke of a silver bullet defined as a "single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity." [my emphasis]). I don't believe in silver bullets, but I think there's a possibility of shiny buckshot.

On the discouraging side, I think there are great difficulties to building such a system: the development of a shiny shotgun is, I think, the work of double-digit person-years. It's work that's too far over the horizon for VC funding, too pragmatic for grants, and too dependent on brilliant execution by a small, high-performance team for Open Source.

"AT&T Invents Programming Language for Mass Surveillance" is Wired's absurdly bad headline describing how Hancock, "a C-based domain-specific language designed to make it easy to read, write, and maintain programs that manipulate large amounts of relatively uniform data," was used by AT&T to aid the NSA (allegedly, but c'mon).

In fact, Hancock looks like a good language for Wide Finder, Tim Bray's logfile analysis program that exemplifies the culture of hashtables and regular expressions, and which is bouncing around the blogosphere as a benchmark.

As a benchmark, Wide Finder is as problematic as previous small benchmarks like Fib and Tak. I could write a lot more about that, but instead I wanted to highlight Bray's observation that there is an entire culture of programming relating to regex and hashtables. This culture is the remnant of the antediluvian Little Languages culture which, in turn, traced its heritage to the cyclopean Ye Olde Compiler Scribes.

Today, the regex+hashtable crowd is basking in the limelight. Although I'm wholly in favor of promoting language-like techniques, one ought not to believe an emerging meme, which is that "you need a dynamic language to write a language-like program." As a matter of fact, it doesn't take long for a regex+hashtable program to grow to the point where a custom parser (generated by a tool, of course, from a regex-like grammar) becomes more efficient. Once you've gotten to that point, the utility of dynamism is greatly lessened and you're well into a situation where many people might prefer the clarity of explicit types (when walking a tree of many thousand nodes, it can be very helpful to know exactly what type of node is at hand).

Tools like ANTLR make language-recognizing programs easier to write than ever. And, as I wrote recently, writing a unit-tested compiler is the most fun you can have programming.

Is this a strictly true statement? 

"One can freely download command-line compilers for all Microsoft languages and never use Visual Studio."

Specifically, don't you need VS to develop for Smartphones and / or Windows Mobile?

With the release to public beta of Popfly, Microsoft's mashup editor, I'll reiterate my theory that mashups are the UNIX shell of the Internet. The corollary is that we need a suite of command equivalents:

Right now, everyone's concentrating on what output the mashup editors can produce or what the component manipulation looks like. I think the winner of the mashup evolution will be the one that provides the most flexible suite of components.

I'm tempted to label as "shocking" the announcement that F# will become a product fully integrated into Visual Studio, but I suppose it would be hard for anyone to ignore stuff as compelling as this.

F# is a derivative of OCaml and is a functional programming language. Those who delve into my language-related or concurrency-related posts will be familiar with the concept that one of the great advantages of functional languages are characteristics that lend themselves to automatic parallelization. Microsoft is making more and more noise about functional approaches (Eric Lippert's "aside" that "Immutable data structures are the way of the future in C#." is telling.) and this endorsement of F# is another sign that Redmond is throwing its weight pretty heavily behind this approach.

F# has been well-received among the hardcore language nerds but you have to give Microsoft credit for getting out ahead of the market on this one. F# is a very different beast than the Iron* languages (Python and Ruby). This isn't Microsoft reacting to market demands, it's Microsoft putting a not-at-all-well-known language into the spotlight.