This is spectacularly wrong. SMT is an attempt to reduce the effects of long memory latency by running several threads concurrently; with a bit of luck, if one thread is blocked on a memory access another will still be runnable and the processor does not need to stall (just the one thread). The question now is whether one should share the various caches between all the threads or have separate (snoopy) caches, one per thread.
First, you really wouldn't want to write an app's core in C, you'd only write small, critical code sections where you couldn't coax adequate performance out of the host language compiler.
Secondly, while several good graphical development environments exist for many "academic" languages, many programmers still prefer to use make, vi/emacs and command line tools. That said, Microsoft is very keen to have Visual Studio integration for these languages and there are several projects in the pipeline to do just this. That, coupled with the fact that many of the compilers in question are also being targetted at the.NET platform, will make it much easier for programmers and groups to experiment with these languages with, hopefully, a minimum of risk and effort.
I think the two main obstacles to a wider uptake, other than the above, are (a) a widespread belief that these languages are slow, too weird, too strict, integrate poorly etc., and (b) the lack of decent introductory material that isn't aimed at reasonably theory-savvy postgrads. But we're working on that, too!
The point about execution speed being less important than efficiency of development and robustness of code is well made. In particular
it's good to see a respected member of the community stand up and point out the advantages of automatic memory management (viz garbage collection), something that was never that costly in the first place, despite the recieved wisdom.
(Cases in point: Severance has huge swathes of its control code written in Python; many other games do similar things with Lua - both are interpreted languages, modulo bytecode).
I would like to raise two other issues. The first is that languages with powerful typing schemes make it impossible to code a very large class of errors. In particular, if you ever find yourself using a cast (especially to/from void* or Object or whatever), which you have to for
collection datatypes in C, Java, etc., then you're opening yourself up to a bugfarm. In C the compiler just assumes you know what you're doing whereas in Java it has to carry out a costly runtime check. The solution is polymorphic types (or "generics" to be vulgar) which do away with all this horridness while retaining type safety that is verifiable at compile time. [Please, nobody mention C++ templates...]
The other thing is that destructive assignment, upon which all imperative languages are based, makes life much harder for the optimizing compiler and harder still on the programmer who can never be quite sure whether a particular function call won't change the state of his program (believe me, this is a major source of bugs). The solution is not to use destructive assignment - that is, write in a purely functional style.
Modern functional languages such as Mercury and ML give you all this and are extremely efficient and have very good C and/or general foreign language interfaces. It is a myth that these languages are slow (they wipe the floor with Python and are strongly competitive with C++). The common experience amongst functional programmers is that (a) once the compiler accepts a program, nine times out of ten it does exactly what was intended and that (b) programs work, and work correctly, with something like 20-40% of the coding/debugging effort required in imperative languages. I strongly urge people to investigate these so-called academic languages for themselves, rather than jumping on whatever this year's flawed language bandwagon happens to be.
Yes, but Stephen Baxter's writing sucks like a hoover.
I was going to write a review of Revelation Space, but Hemos beat me to it. Take my word for it, Reynold's effort is a genuinely superior piece of work.
But if you run into a harder problem where you need a more powerful language, Perl will support you in that. Unlike many other computer languages, Perl supports all the high-falutin' theory without forcing it down your throat. You get to pick your own cultural context. Perl is kind of postmodern that way.
Bollocks. I have never come across a language
that put more barriers in the way of "high-falutin' theory" than Perl. For God's sake, it
doesn't even have named parameters. Perl is
kind of sub-lambda calculus that way.
You clearly haven't read the paper describing how the entries were evaluated.
Some interesting points to note from the paper:
Of the 37 entrants, 9 used C, 5 used C++, 2 used Perl, 1 used Java and 1 used assembler (total: 18 entries - 50% - used imperative languages);
7 entries were eliminated for core dumping etc. (4 C, 1 C++, 2 Perl);
9 entries were eliminated for producing semantically incorrect results (4 C, 1 C++, 2 Haskell, 1 OCaml, 1 OLabl);
the remaining 21 entries were scored according to the quality of the results they produced (ratio of optimized output size to input size). The top 6 are all functional languages, with the top two entries being written in under 24 hours in Haskell. The top 6 entries achieved ratios of 48.3 - 57.7%; the next in line was a C++ entry at 65.6%, followed by a C entry at 75.7%.
Only 6 out of the 18 imperative language entries worked - that's a 33% success rate.
Only 4 out of the 19 imperative languages failed - that's a 79% success rate.
Of course, after that it was all very subjective. The overall winner was the best optimizer, ran to a mere 376 LOC (average entry was 1500 LOC), and the programmer claims to have spent only 6-8 hours on the task. The second place winner was the second best optimizer. The remaining winner was the third best optimizer.
Slashdot Mirror
This is spectacularly wrong. SMT is an attempt to reduce the effects of long memory latency by running several threads concurrently; with a bit of luck, if one thread is blocked on a memory access another will still be runnable and the processor does not need to stall (just the one thread). The question now is whether one should share the various caches between all the threads or have separate (snoopy) caches, one per thread.
First, you really wouldn't want to write an app's core in C, you'd only write small, critical code sections where you couldn't coax adequate performance out of the host language compiler.
Secondly, while several good graphical development environments exist for many "academic" languages, many programmers still prefer to use make, vi/emacs and command line tools. That said, Microsoft is very keen to have Visual Studio integration for these languages and there are several projects in the pipeline to do just this. That, coupled with the fact that many of the compilers in question are also being targetted at the .NET platform, will make it much easier for programmers and groups to experiment with these languages with, hopefully, a minimum of risk and effort.
I think the two main obstacles to a wider uptake, other than the above, are (a) a widespread belief that these languages are slow, too weird, too strict, integrate poorly etc., and (b) the lack of decent introductory material that isn't aimed at reasonably theory-savvy postgrads. But we're working on that, too!
I would like to raise two other issues. The first is that languages with powerful typing schemes make it impossible to code a very large class of errors. In particular, if you ever find yourself using a cast (especially to/from void* or Object or whatever), which you have to for collection datatypes in C, Java, etc., then you're opening yourself up to a bugfarm. In C the compiler just assumes you know what you're doing whereas in Java it has to carry out a costly runtime check. The solution is polymorphic types (or "generics" to be vulgar) which do away with all this horridness while retaining type safety that is verifiable at compile time. [Please, nobody mention C++ templates...]
The other thing is that destructive assignment, upon which all imperative languages are based, makes life much harder for the optimizing compiler and harder still on the programmer who can never be quite sure whether a particular function call won't change the state of his program (believe me, this is a major source of bugs). The solution is not to use destructive assignment - that is, write in a purely functional style.
Modern functional languages such as Mercury and ML give you all this and are extremely efficient and have very good C and/or general foreign language interfaces. It is a myth that these languages are slow (they wipe the floor with Python and are strongly competitive with C++). The common experience amongst functional programmers is that (a) once the compiler accepts a program, nine times out of ten it does exactly what was intended and that (b) programs work, and work correctly, with something like 20-40% of the coding/debugging effort required in imperative languages. I strongly urge people to investigate these so-called academic languages for themselves, rather than jumping on whatever this year's flawed language bandwagon happens to be.
I was going to write a review of Revelation Space, but Hemos beat me to it. Take my word for it, Reynold's effort is a genuinely superior piece of work.
Ralph
-
But if you run into a harder problem where you need a more powerful language, Perl will support you in that. Unlike many other computer languages, Perl supports all the high-falutin' theory without forcing it down your throat. You get to pick your own cultural context. Perl is kind of postmodern that way.
Bollocks. I have never come across a language that put more barriers in the way of "high-falutin' theory" than Perl. For God's sake, it doesn't even have named parameters. Perl is kind of sub-lambda calculus that way.Perl: all syntax and no semantics. I weep.
Some interesting points to note from the paper:
Of course, after that it was all very subjective. The overall winner was the best optimizer, ran to a mere 376 LOC (average entry was 1500 LOC), and the programmer claims to have spent only 6-8 hours on the task. The second place winner was the second best optimizer. The remaining winner was the third best optimizer.
Ralph