Frank Carver’s musings about software and life
It’s a long-running argument. Are modern, dynamic, languages such as Ruby and Python really much more concise than more mainstream languages such as Java? What constitutes “big” in each case? Stephan tries to flush out some hard facts, and gets a lot of comments.
Ted Leung reports on the broad spread of interesting languages available on the JVM these days. Several that I had not heard of, too.
The First Annual JVM Language Summit at Ted Leung on the Air
This article has been in my “must blog about this” pile for a while now, so I decided to post it anyway.
I have encountered a problem several times in my career where people involved in software development simply assume that making something easier to understand is the same thing writing it in a natural language. As I have worked almost exclusively with English-speaking developers, that language has always been English, so I have worked with coding and configuration standards which jump through hoops to simulate English phrasing, but inevitably fall short.
What this approach misses in its naivety is the reason we work with programming languages at all: natural language is ambiguous and often wordy, adapted more for social bonding and collective storytelling than for precise descriptions of the interactions of abstract software entities.
Dave Thomas makes this point in the context of creating a DSL (domain specific language), but it is equally applicable to structuring and documenting any software. In many cases a concise and specific new term or grammar is far more useful and expressive than attempting to ape an existing natural language, once a small initial hump of unfamiliarity is surmounted.
A long tract on several aspects of programming language design, tied together (sometimes somewhat loosely) by the concept of “orthogonality”.
I have been working with Python a fair amount recently, and really miss a lot of the tool features I use when working with Java. In particular, lacking the ability to automatically apply common refactorings and auto-complete obvious code really “cramps my style”. In most cases I have a pretty clear idea of what I want to do, and how I want to get there, but I find that the process of using Python is just more laborious.
I guess that puts me squarely in Ted Leung’s group of “experienced developers” rather than the “early adopters” who are happy to use more generic tools in order to gain the benefits of a new language and its abilities.
This looks like a really useful idea. A central directory of APIs for software development, organised by function and by language/OS
www.apifinder.com - the essential directory for application programming interfaces
Smalltalk is not at the top of my list of languages to practice with right now, but if you are interested, this seems like an excellent resource - a whole collection of legit Smalltalk books as free PDF downloads.
Despite several brushes with it over the years, I have never really worked with Lisp enough to “get it”. It’s certainly interesting that this language from the relative dawn of software is still around and still compelling enough to prompt new implementations and new support tools. Maybe I should try again and take another look.
I have just sat through an hour-long video of a conference presentation on language design from 1998. Normally I find such things fairly tedious, but this was enthralling! Even though some of the particular issues he covers have been resolved since, the overall point is surprisingly relevant, and he presents it with a unique style. Well worth a watch.
Growing a Language, by Guy Steele
From a link by Ulf
Ted Neward on different programming languages, the benefits of trying idioms from one in the context of another, and a neat list of his recommendations for consideration.