Haskell vs GC'd imperative languages
===========================
On 8/10/07, Thomas Conway
Well, C++ is not really competitive with Haskell, because C++ does not have a GC, and it's trivial to corrupt the stack/heap.
Beg to differ. I offer the following proof by contradiction. :-)
In my current job, I had a version-1 implementation in Python which had severe performance problems, and was not amenable to concurrency (The Python interpreter has a global lock, so you can only execute python bytecodes from one thread at a time. :-(). The natural alternative implementation language was C++, but I argued successfully that a Haskell implementation would be significantly easier to make concurrent.
Well, Python is comparable to Haskell to the extent that it has a GC. OTOH it is interpreted, and, well, slow. It's also got a Big Lock around the core system libraries. Trying to avoid naming it by name, because there's a lot of elitism against using mainstream languages that are used by "stupid people", but the fastest imperative GC'd language that I know of is C#. Even the opensource mono version is wickedly fast. The Microsoft version shaves another 20% off execution speed or so. See, I get the feeling that a lot of people are using Haskell not because they compared it to C# and found it better ,but because they compared it to: - C -> Haskell is easier - C++ -> Haskell is easier - Python -> Haskell is faster C# -> fast and easy ;-) Threading ======= I'm not trolling, despite strong appearances to the contrary ;-) My primary objective/goal is to find a way to make threading easy. Thread management today is like memory management in the early 90s. We kindof had tools (new, delete in C++ for example) to do it. At some point we started to use things like Smart Pointers to make it easier, but none of it really worked. Issues such as circular referential loops caused this not to work very well. At some point, someone came out with the idea of a garbage collector, which is really very simple once you know: all it does is walk the graph of variables, starting with those we know are definitely used, and delete all those objects that didnt get walked on. Simple, easy, magic. We should do the same thing for threads. Threading is going to become a major issue soon, maybe not tomorrow, but there is a GPL'd Niagara 2 out with 64 threads (I think?), so the time is now. Haskell solves a huge issue with threads, which is locking, which is a total PITA in imperative languages, it's of the same order of magnitude of problem as eliminating memory leaks, without deleting something twice etc, used to be in pre-GC C++. Nevertheless, one cannot be interested in threads without being interested in performance. There's no point in running a program in 1024 threads, if the single-core C# version runs faster than that, and often it does! Parallelizeability ============ Now, I did have kindof a shootout thread with Don and Sebastien, calculating prime numbers, where Don managed to get to within an order of magnitude of C# performance (I think he got to about 70-80% of C# performance, cool!) -> BUT, and its a big but ;-), as far as I can tell, he did that by sacrificing the Haskell ability to be easily parallelized; his solution was essentially imperative.