Of course, Bothner observed, everybody wants to combine best of both. Bothner mentioned JSR 292 ("Supporting Dynamically Typed Languages on the JavaTM Platform"). In fact, one of the "themes" of JavaOne 2010 has seemed to me to be along the lines of retaining Java's power but bringing more advantages commonly associated with scripting languages to Java.
One observation that Bothner made that I have also observed is that performance is often not as important in many scripting situations with today's faster hardware and small scripts. However, he pointed out, these scripts often become much larger and then performance begins to matter. An example he cited here was the emphasis from each major browser vendor on coming up with a faster JavaScript now that much larger JavaScript libraries are available and JavaScript-based applications are getting much larger.
One "semi-solution" to deal with the trade-off between scripting languages and compiled languages is to use the "appropriate language for each job."
Bothner went through several slides on different languages trying to bridge the gap between scripting languages and compiled languages or exhibiting language features he wanted to call out. I am guessing I'm missing some here, but I'll summarize some of them. He referenced Scala as a strongly type language similar to Java with interesting concepts that some people refer to as "The Better Java." Clojure is LISP-like JVM language suited for concurrency.
Bothner referenced a language I had never heard of: Thorn. He referenced an OOPSLA paper on it. The abstract for that presentation states about Thorn: "Thorn is an object-oriented scripting language with support for concurrent and distributed computing and robust program evolution." The Thorn page describes Thorn this way:
Thorn is a dynamically-typed concurrent language in which lightweight isolated processes communicate by message passing.
. . .
Thorn is a joint effort between Purdue University and IBM Research T.J. Watson Research Center.
Currently there are two different implementations of Thorn. We have a compiler that targets the JVM and an interpreter written in Java. The interpreter implements the full language, while the compiler currently implements a subset.
Bothner briefly introduced his own language, Kawa, which is a dialect of Scheme. Among other advantages, it features a true compiler and is fast. He also stated that Scheme is where first class closures got their start.
Until this presentation, I was not aware of The Computer Languages Benchmark Game. The main page for this game describes it briefly as: "Compare the performance of ~30 programming languages using ~12 flawed benchmarks for 4 different combinations of OS/machine. Contribute faster more elegant programs." Bothner warned that the normal performance benchmarking caveats apply here: a particular language's performance depends on the cleverness of the developer's solution and on the fit of that language for each of the potential problems being solved. In short, one cannot necessarily say one language is faster than another just because of overall better marks in this game.
Bothner provided his "Performance Factors in Language Design." I'm not listing them all here and recommend seeing his slide for all of them. However, there were a couple points that stood out to me that I thought delivered mention here. He stated that the language should make type specification available but optional. He referred to "optimistic static typing" in which the language only rejects an attempted assignment if it can prove that the assigned value cannot match. He prefers this to more strict static typing in which it must be proven that the assignment can be made.
Bothner believes that a language should be required to declare variables to avoid typos and because doing so is basis for most optimization and error checking. I cannot agree more with another of Bothner's assertions: Avoid String-based APIs. He pointed out that String APIs present security risks and easy opportunities for breakage. He emphasized functionally generating output Strings rather than passing around Strings directly.
Until this presentation, I was not aware of The Computer Languages Benchmark Game. The main page for this game describes it briefly as: "Compare the performance of ~30 programming languages using ~12 flawed benchmarks for 4 different combinations of OS/machine. Contribute faster more elegant programs." Bothner warned that the normal performance benchmarking caveats apply here: a particular language's performance depends on the cleverness of the developer's solution and on the fit of that language for each of the potential problems being solved. In short, one cannot necessarily say one language is faster than another just because of overall better marks in this game.
Bothner provided his "Performance Factors in Language Design." I'm not listing them all here and recommend seeing his slide for all of them. However, there were a couple points that stood out to me that I thought delivered mention here. He stated that the language should make type specification available but optional. He referred to "optimistic static typing" in which the language only rejects an attempted assignment if it can prove that the assigned value cannot match. He prefers this to more strict static typing in which it must be proven that the assignment can be made.
Bothner believes that a language should be required to declare variables to avoid typos and because doing so is basis for most optimization and error checking. I cannot agree more with another of Bothner's assertions: Avoid String-based APIs. He pointed out that String APIs present security risks and easy opportunities for breakage. He emphasized functionally generating output Strings rather than passing around Strings directly.
Another good point that Bothner made is that there are cases where static typing can make your programming more productive and easier. When implemented correctly and in the right situations, static code can actually be even less verbose than dynamically typed code.
Bothner talked about Expression-Oriented Programming. He stated that expressions are less verbose and more composable than the alternatives. He used SQL's use of expressions as an example and stated that although "SQL may be a mess," its use of expression-oriented programming is an advantage.
Bothner talked about Expression-Oriented Programming. He stated that expressions are less verbose and more composable than the alternatives. He used SQL's use of expressions as an example and stated that although "SQL may be a mess," its use of expression-oriented programming is an advantage.
Bothner then rounded out his talk with a conclusion and summary. I found this presentation to be interesting in several ways, but particularly enjoyed the opportunity to think a little "bigger picture." I tend to prefer presentations with technical details that I can apply immediately, but I want presentations like Bothner's sprinkled in their because they are challenging in a different way. They force me to think about bigger picture ideas and what I like and don't like in the languages I commonly use. I doubt that I'll begin writing a language of my own anytime soon, but Bothner's presentation helps me to better understand why I like certain languages better than others, how to better judge which languages are worth further effort, and how to decide which language is best for the job.
No comments:
Post a Comment