> Perf bottlenecks are being addresses in Clojure already but not a > the expense of expressiveness. > And that is perfectly fine...
I agree completely with everything you're saying, and I too find fft1976's obsession hard to relate to. But I think that one problem with many modern languages is that the implementors aren't concerned with performance beyond a certain level of practicality. There are people out there like fft1976 who are motivated to squeeze the most out, and the theory for making highly-optimizing compilers for functional languages is also well-researched at this point. Haskell's GHC implementation, for example, has benefitted tremendously from having a team of implementors who went way beyond ordinary practicality for compiler optimization. So consider this my vote for fft1976's involvement in adding new optimizations to the compiler. I agree with him that unadorned functional code should perform well, but I don't have the motivation or the skills to improve it. If he does—and I suspect so—then I hope we can maintain a dispassionate eye towards the issue of performance and perhaps improve it rather than driving off the meticulous souls who have the combination of skills and inclination to do something about it. This is what seems to me to have happened with Ruby and various other high level languages with mediocre performance. — Daniel Lyons --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
