One "semi-solution" to deal with the trade-off between scripting languages and compiled languages is to use the "appropriate language for each job."
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.
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.
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.