How do you blur read/compile/run time when one of your goals is to have a complete type system?
By putting all of the type system in the parser, but leave the runtime as a fully dynamic late-bound JIT VM. There is already a precedent for this in Java and in the Strongtalk variant of Smalltalk. To complete the picture, we just need a way to map the types before the code-change to the types that exist afterwards. There's already been some work towards this. (Java/Eclipse)
Omega is undefined when the relative weights of [expressiveness, terseness, maintainability, readability, flexibility] are undefined. For any given set of weights you could perhaps come up with a reasonable answer (even then you have to try to quantify things like maintainability), since some languages are more terse but less readable, or more readable but less expressive, etc.
If all the weights are equal, then I'd argue for Python, though I'm sure plenty of Rubyists and Lispers and Haskellians would disagree.
This is true, and I don't have extensive enough experience to weigh those correctly (and even if I did, I would be heavily biased by the languages I currently use). This is why I opted to wuss out rather than risk getting it horribly wrong.
And yes, from what I've seen/heard, plenty of Rubyists, Lispers, Haskelliens, etc. would certainly disagree with you.
I don't think there's one true set of weights - rather, I think it's a matter of personal preference (and, to a certain extent, the task at hand - maintainability is irrelevant for some tasks and vital for others).
I could see this in the extremes (a one-of data-munging script has no maintainability requirement, for example), but accepting the weights as completely subjective seems dangerously close to saying "All languages are equally powerful, and it's just a matter of preference", which I disagree with because it would invalidate the Blub Paradox.
It may be the case that the weights are affected by individual tastes and requirements, but the construction of the language (and therefore some inherent property of the language, rather than of the user or of the situation) would almost certainly affect those weights as well.
>accepting the weights as completely subjective seems dangerously close to saying "All languages are equally powerful, and it's just a matter of preference"
I don't agree with this statement...I would say that Java is worse than Python for just about any given set of weights.
The reasons why these languages are created is because they are meant to solve your problem the correct way.
Java is a scalable language, for example, and using it correctly makes a good programmer. This goes for every language, whether it's C, Python, Javascript, ect. Good programmers know a wide variety of languages and when it comes to 'Omega' I think it's the combination of the languages used what they are meant for.
That's the argument I fundamentally disagree with.
It may be true for things like SQL (or PS or the many, many DSLs out there), but general-purpose programming languages are implicitly (perhaps tautologically) supposed to be good for the general case.
It goes without saying that if your list of requirements includes something like "our deployment environment will have 16 kb of memory and an 8 mhz processor and no network interaction", you don't want to use something like Erlang. But except for such extremes (which I probably should have explicitly stated I'm not thinking about), it is possible (and necessary) to distinguish between two languages on the basis of power.
I probably should have just linked to http://www.paulgraham.com/avg.html instead of writing anything, because the "Blub Paradox" section makes the above argument much more eloquently.
"Omega" was a reference to the Seibel talk I quote from, in which he casually postulates Omega as the most powerful language that might be built for current architectures.
your first link points to Tim Sheard's Omega, a dependently typed programming language. Dependent types allow the programmer to codify arbitrary invariants in the types of the expressions. Some notes on depend types: http://axisofeval.blogspot.com/2010/10/notes-on-dependent-ty...
He indicates Haskell and Lisp as the two leading candidates for Omega, but I think that just illustrates the wrongness of the premise that there is a singular end-game as far as languages go.
The thing is, you couldn't have a convergence of Lisp and Haskell without destroying what makes them good at the same time. The essence of Lisp is that it is endlessly dynamic, the essence of Haskell is its insanely strong type system. I can't think of any way these could be effectively combined.
These languages aren't converging on a as-yet-unknown Omega point, they started at more or less the same point and then took off in completely different directions, and they aren't looking back.
Agreed, except with the "they aren't looking back" part. If that were true, Lisk and Liskell wouldn't exist (and people wouldn't be wondering aloud "How can I get pattern matching-definitions or point free style in Lisp?")
The conclusion of the article was more or less that you can't get a perfect combination of the two, and that any unification that might emerge will have to make decisions about which features to cherry-pick.
I'm also not clear on what you mean by "they started at more or less the same point".
Point taken about Lisk and Liskell. But I think that that is, as you say, cherry picking features, not actually merging the philosophies of the two languages.
As for the same starting point, both had their origins in academic programming language research. It's true they don't have a direct common ancestor, but the point I was making was that their creators were aware of the issues, and chose very different directions as solutions to basically the same problem.
Lisp and ML (as in Haskell) are dark magic from the early days of computing that are continually rediscovered. Currently they form an undercurrent, not just of language features but programming philosophy, that is shaping the new and emerging languages of today. Many of us have observed how learning a language like Lisp and becoming familiar with the idioms of programming with it can have a profound impact on how we write in other languages.
In this spirit, consider a lesser-mentioned language from the same era- Forth. Discard any preconceptions you may have about stack-oriented languages and take a few days to sit down and read "Thinking Forth"[1], which delves deeply into the architectural philosophy that goes along with the language. Forth is at once mind-numbingly close to hardware and surprisingly well-suited to readable, high-level expression.
I haven't had a chance to play with it seriously yet, but I went over a "getting started" tutorial a while back. forth-mode is installed and ready on Emacs in case I get some spare time; it's on my to-do list along with some more serious Python, Clojure, Scala and Smalltalk experimentation.
And yes, this is specifically why I opted to redefine "power" in my post; the standard definition leaves out some points that I've found to be essential.
20 comments
[ 2.2 ms ] story [ 41.5 ms ] threadBy putting all of the type system in the parser, but leave the runtime as a fully dynamic late-bound JIT VM. There is already a precedent for this in Java and in the Strongtalk variant of Smalltalk. To complete the picture, we just need a way to map the types before the code-change to the types that exist afterwards. There's already been some work towards this. (Java/Eclipse)
If all the weights are equal, then I'd argue for Python, though I'm sure plenty of Rubyists and Lispers and Haskellians would disagree.
And yes, from what I've seen/heard, plenty of Rubyists, Lispers, Haskelliens, etc. would certainly disagree with you.
It may be the case that the weights are affected by individual tastes and requirements, but the construction of the language (and therefore some inherent property of the language, rather than of the user or of the situation) would almost certainly affect those weights as well.
I don't agree with this statement...I would say that Java is worse than Python for just about any given set of weights.
Java is a scalable language, for example, and using it correctly makes a good programmer. This goes for every language, whether it's C, Python, Javascript, ect. Good programmers know a wide variety of languages and when it comes to 'Omega' I think it's the combination of the languages used what they are meant for.
It may be true for things like SQL (or PS or the many, many DSLs out there), but general-purpose programming languages are implicitly (perhaps tautologically) supposed to be good for the general case.
It goes without saying that if your list of requirements includes something like "our deployment environment will have 16 kb of memory and an 8 mhz processor and no network interaction", you don't want to use something like Erlang. But except for such extremes (which I probably should have explicitly stated I'm not thinking about), it is possible (and necessary) to distinguish between two languages on the basis of power.
I probably should have just linked to http://www.paulgraham.com/avg.html instead of writing anything, because the "Blub Paradox" section makes the above argument much more eloquently.
"Omega" was a reference to the Seibel talk I quote from, in which he casually postulates Omega as the most powerful language that might be built for current architectures.
The thing is, you couldn't have a convergence of Lisp and Haskell without destroying what makes them good at the same time. The essence of Lisp is that it is endlessly dynamic, the essence of Haskell is its insanely strong type system. I can't think of any way these could be effectively combined.
These languages aren't converging on a as-yet-unknown Omega point, they started at more or less the same point and then took off in completely different directions, and they aren't looking back.
The conclusion of the article was more or less that you can't get a perfect combination of the two, and that any unification that might emerge will have to make decisions about which features to cherry-pick.
I'm also not clear on what you mean by "they started at more or less the same point".
As for the same starting point, both had their origins in academic programming language research. It's true they don't have a direct common ancestor, but the point I was making was that their creators were aware of the issues, and chose very different directions as solutions to basically the same problem.
In this spirit, consider a lesser-mentioned language from the same era- Forth. Discard any preconceptions you may have about stack-oriented languages and take a few days to sit down and read "Thinking Forth"[1], which delves deeply into the architectural philosophy that goes along with the language. Forth is at once mind-numbingly close to hardware and surprisingly well-suited to readable, high-level expression.
[1]http://sourceforge.net/projects/thinking-forth/
There might be room for some unspecified mix of these qualities on an argument over the "bestness" of a language.
But I'll quibble here and mention that power is conventionally defined as ONLY expressiveness/terseness with no consideration of maintainability.
In the J programming language:
http://en.wikipedia.org/wiki/J_(programming_language)Now that's raw power... (and may not fit all requirements!)
The traditional snippet associated with that argument is the Game of Life in APL. http://www.youtube.com/watch?v=a9xAKttWgP4
And yes, this is specifically why I opted to redefine "power" in my post; the standard definition leaves out some points that I've found to be essential.