Turbo Ruby: Strong Hints From CodeGear / DevCo

The new spinoff from Borland, CodeGear, is strongly hinting that they will produce at least one dynamic language:

CEO Ben Smith: “We’re also working on plans that can help developers take advantage of growing and emerging areas like web services, Ruby, Python and Ajax. ”

David I: “We are not limited to just a few programming languages (Delphi, Delphi .NET, Java, C++, C#)….[CodeGear will be driven by languags that are ] compiled, managed, scripted, dynamic and more…What will be the next CodeGear programming language?”

CodeGear FAQ: “The emergence of web services and new development capabilities from Ruby to Python to Ajax provide an opportunity for even more substantial innovation.”

Obvious interpretations: a stack for JavaScript programming and debugging (Ajax) and at least one of Turbo Ruby or Turbo Python.

Charles Nutter Hints at a JRuby Release By The End of the Year

In comments, Sun’s Charles Nutter hints that JRuby may ship by the end of year. Or he may be taking a swipe at the Perl 6 guys: you decide. Ruby on at least one of the two major managed platforms: huge for Ruby. (In that post, I caution that it took Jim Hugunin something like 2 years to move IronPython through beta to 1.0. Nutter and Thomas Enebo, the core JRuby developers, only joined Sun two months ago. A year-end release would be pretty darn impressive!)

Borland Developer Tools Become CodeGear, nee DevCo, a Wholly Owned Subsidiary

Borland’s Developer Tools Group, including the Delphi, C++, C#, and JBuilder tools and the Interbase database tools, have been spun off into a new company called CodeGear to be headed by Ben Smith (Byte’s old tech editor?). Contrary to all previous reports, CodeGear will be a wholly owned subsidiary, not sold off.

While Alan Zeichick is skeptical about the confusion (and I share his dismissal of “ALM” as a market separate from the development tools market), I take a measure of hope in my April observation that “if Borland corporate saw a way for a self-sufficient company to keep the balance sheet in the black, it would be spinning the division out, not selling it off.”

Jolt Awards Need Your Input: Best Languages, Development Environments, Books…

Dr. Dobb’s Journal has taken over the Jolt Awards now that Software Development is no more. Once again I’ll be judging and, actually, serving as Moderator of the Development Environments and Languages category.

Given that we considered VS2005 last year (but, hey!, XNA) and given that Callisto is certainly going to be nominated, what other languages and development environments have or should have “Jolted” the industry in the year 2006?

IronPython went to 1.0 a few months ago. 

The re-released Turbo products? Were they just a reboxing of existing tools?

Perl 6 may beat the Dec 31 deadline, but JRuby won’t.

I wonder if I can sneak in consideration of Piet, the programming language in which programs look like abstract paintings. (via Harry Pierson)

What new tools and books have helped you kick butt and take names this year?

Am I The Only Geek Still Running 484I (Or is it 486i or 480i)?

I don’t have an HDTV and I don’t think I’m going to buy one in the foreseeable future. I watch TV every evening for a couple of hours. I like TV fine.

I have analog basic cable that requires no set-top box and for which I pay around $40 a month (it’s bundled with my cable Internet, so it’s hard to say). I live in a rural area on an island — I really doubt that I get any HD programming over the air. If I bought an HDTV, my cable rates would climb a minimum of $20 as I would have to pay for digital cable, set-top box “rental,” and an HDTV package.

Every broadcast show I watch — everything — I watch via time-shifted Tivo. If I had HDTV, I would either have to buy a new DVR ($$$) or give up 20 minutes per hour to commercials.

My favorite channels are old-time movie channels (TCM and AMC) and Comedy Central, which I don’t think broadcast in HD. My understanding is that non-HD shows look somewhere between worse-than-before to terrible on an HDTV.

I have a 27″ diagonal set. HDTVs are 16:9, so I believe that a 36″ HDTV would provide around the same picture size for broadcast TV.

I watch DVDs from Netflix. DVDs are, what?, 720P? And presumably, you can somehow set them up so that the 16:9 HDTV shows them fullscreen. So those would look better.

So, I buy an HDTV for, say, $2500. Plus maybe $50 per month in recurring charges. In order to get a no-better picture for my favorite shows, watch new HD shows with commercials and without time-shifting, and get an incremental improvement in DVDs?

<GeekTone value=”Spock”>Highly illogical.</GeekTone>

Update: I grabbed 486i from some Google search for “NTSC” but after being mocked, I double-checked. So I guess standard TV is 484i. And HDTV’s are 9:5, not 16:9? And DVDs are only ~480 resolution?

What Makes A Programming Language?

Bill de h?ra’s post on the language’s he’s used in the past year contains the provocative thought “…some people are looking at things like HTTP and Ant and CSS and wondering whether they are really programming languages….[T]hey are either replacing or reducing the raw coding I used to do….[A]t least, if you start thinking about HTTP as a language, the job of using it becomes far easier….”

To me, the definition of a programming language has always been simple: Is it Turing complete? More practically, I skip any type of formal analysis and look for control structures and recursion. By my criteria, not only is HTTP not a language, SQL (as it’s generally used) isn’t either. This definition has two advantages: it’s pretty bulletproof from a theoretical standpoint and, pragmatically, something feels “right” about assigning looping and recursion as the uniquely “program language-y” thing. Lots of things are complex or reduce complexity and lots of things have state that evolves over time, but solving problems by looping is what makes a solution feel like programming.

On the other hand, this view seems a little out-of-touch, if not anachronistic. Much of the “action” traditionally associated with language development ( conceptual mappings, problem-solving models, etc.) has shifted to framework development. Part of this is the evolution from “libraries” (generally, a group of related functions at the same abstraction level, such as a library for trigonometry or statistical analysis) to “frameworks” (a set of components of different abstraction levels covering an entire problem domain). Objects unified the vocabulary for discussions of behavior, data, and structure. Once that was established, patterns gave us a channel for professional discourse that previously might have required a shared language background (indeed, they’re called “pattern languages.”)

Further, something is wrong with actually writing a programming language. As Bjarne Stroustrup puts it, “On the order of 200 new languages are developed each year and…about 200 languages become unsupported each year.” So on the one hand, you have the great value of expressing domain reasoning directly in code and on the other, you have a task that requires a large effort and which is almost certainly doomed. Perhaps one is smarter to simply embrace studying frameworks.

But ultimately I cannot believe that that’s the right answer: frameworks are great, but I don’t think they shift your reasoning in the way that a language does. I was fortunate enough to spend some time in my early professional years shifting back and forth between C and Prolog: two radically different languages. It was obvious to me that different parts of my reasoning were engaged by the different languages; I could be exhausted in C and fresh as a daisy in Prolog and vice versa. (In retrospect, it’s probably fair to say that in C I was dealing with “housekeeping” and in Prolog I was solving “higher-level” problems, but in those days, low-level coding for data acquisition, transformation, and speed-ups was not optional.)

Stroustrup advocates Semantically Enhanced Libraries as the route forward. I note an echo of the modular compiler meme that Harry Pierson has mentioned (essentially: start from a complete language and extend/restrict it rather than start with a grammar and fire up lex/yacc). Those familiar with Lisp will naturally point out that extending/restricting the base language is precisely what Lisp macros do; the disadvantage being that the language being extended/restricted is Lisp (which I don’t mean in a snide way, but simply in the way of acknowledging that the market has declined to embrace Lisp over the course of forty-five years).

Given my belief that the shift from single- to multi-to many- core is going to be the issue in programming within a half-decade, I naturally think we need tools for exploring new semantics. To me, it still seems that the best tools for that are new languages, not new constructions built on sinking foundations.

Tim Bray on Frameworks (But Not .NET)

Tim Bray compares Frameworks (Source: Still done seeking). I largely agree with Tim Bray’s analysis, particularly the point that all major web frameworks will scale sufficiently and that, in the long run, maintainability is likely to be the most important factor in the attractiveness of a framework.

 By that token, Bray recommends Rails and Java, and is skeptical of PHP.  I think this is probably right, and that ASP.net, using C# or Visual Basic, would compare to Java.  The Rails advantage, according to Bray, derives from Ruby’s increased expressiveness: fewer lines of code means clearer code.  While that’s often true, it ain’t necessarily so (metaprogramming can be very hard to understand). Further, implicitly typing language has disadvantages for maintainability.  Further, one should not ignore the ease with which one can hire a maintenance programmer, which will be certainly easier if one chooses a Java or C# framework.

In my opinion, the jury is still out on the relative maintainability of Ruby on Rails versus Java/Struts and ASP.NET.

Puerto Rico Board Game (hReview)

A Board Game That Adults Can Play

11/9/2006

by Larry O’Brien

product Image of Puerto Rico

Puerto Rico

?????

Visiting friends gave me the opportunity to coerce a try of Puerto Rico, a very well-reviewed board game. Unlike most people who review board games, we are not “into” the genre, so this was very much a new experience for us. Basically, we ended up playing every night and, after the third night, Tina turned to me and said, very intensely, “We have to get [our neighbors] addicted to this.”

For those like us new to this new type of board game, the rules are initially pretty opaque. The core of the game is a SimCity-like resource cascade: to gain victory points and money, you ship goods. To ship goods, you produce goods. To produce goods, you must have appropriate production facilities and plantations. Facilities and plantations must be populated with colonists. (For instance, to produce sugar, you need to build a sugar plantation and a sugar mill and populate them with workers.)

The initially confusing key to the the game, though, is that the game state evolves by way of an “inner loop”:

 

while Game.playing == true

{

foreach Player

{

  Player chooses Role in [various roles]

  {

    foreach Player

    {

      Player advances his resource-creation according to the chosen Role

    }

  }

}

}

The “Role” chosen determines the game state: one Role (“Mayor”) produces colonists, another (“Builder”) allows production facilities to be built, etc. The first time you play the game (we were smart to play two “practice” games, the first just to get a sense of the rules, and the second to think out loud about strategy and tactics) you concentrate on the inner loop and pretty much just choose the Role that brings you the most immediate benefit. But the interesting part comes when you start anticipating the Roles that others will choose (“The ‘Mayor’ role is so beneficial to Danni that I know she will choose it when her turn comes around. Therefore, I can choose ‘Settler’ with the confidence that I will soon get colonists to populate it.”)

The rules are written fairly densely — they’re very good about specifying “may” versus “must” and the order of things — which makes them initially very opaque. But after an hour or so of frustration (or, I bet, being introduced to play by an experienced person) things come into focus.

An aspect that’s very enjoyable is that every game we’ve played has played out in a very different way: there doesn’t appear to be any simple optimal strategy. I’m sure that with experience you get better and gain advantages, but the complexity seems to even the playing field significantly.

Highly recommended.