tag:blogger.com,1999:blog-593191658179452263.post8481199567635054596..comments2010-05-22T18:41:16.980-05:00Comments on On Numbers and God: Developing in "impractical" languagesCoryhttp://www.blogger.com/profile/07752328226179627747noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-593191658179452263.post-36857265330294444292008-12-29T20:40:00.000-06:002008-12-29T20:40:00.000-06:00Oh, indeed! I hadn't considered overhead for keepi...Oh, indeed! I hadn't considered overhead for keeping programmers on staff, and my "analysis" (if it is sufficiently thorough to deserve the title) is devoted entirely to C/C++, which Haskell is closer to in speed than I originally thought (I'm new at this!), Ruby/Python/Perl are far too slow for this-- but they are also labeled as "impractical toy languages", and are also the primary reason for the bias against non-C languages with higher level features: the critiques are mostly correct when applied to Ruby and Python. (But still miss the point that development is faster).<BR/><BR/>I hadn't considered debugging... a vast oversight.<BR/><BR/>This was mostly a thought experiment for my own benefit, and I figured others may take interest... I'm still surprised that it has actually raised any interest at all-- I get the feeling that Don prowls the blagosphere looking for posts about Haskell that he can comment on. :)<BR/><BR/>Thanks for the comment,<BR/>cheers!Coryhttps://www.blogger.com/profile/07752328226179627747noreply@blogger.comtag:blogger.com,1999:blog-593191658179452263.post-36026072534950351892008-12-29T10:22:00.000-06:002008-12-29T10:22:00.000-06:00Sorry for the late comment.1) I think you're way u...Sorry for the late comment.<BR/><BR/>1) I think you're way underestimating the cost of developers. Given all the ancillary cost- support staff, office space, insurance and benefits, etc., it's not unusual for a programmer to cost $50K or more above and beyond their take-home pay. So costs more in the $100-$150K a year to put a developer into a seat isn't unusual.<BR/><BR/>2) I also think you're underestimating the productivity enhancements of functional languages such as Haskell and Ocaml. Strong static typing is a huge win, as it catches bugs early and cheaply- 90-99.5% of bugs are caught by the type checker in my experience. Projects have to vague phases- writing the code, and debugging the code. When the Ocaml/Haskell programmer has finished writing the code, they're most of the way done with the project- but when the C/C++/Java programmer is done writing the code, they're less than half way done with the project. <BR/><BR/>3) While C/C++ are the fastest languages, most development is not done in them. Haskell's performance is quite comparable to Java or C#'s performance (Haskell is faster on some things, slower on others, but overall comparable), and it's pwns languages such as Ruby, Python, or PHP for performance (even if written in a "high level" fashion).<BR/><BR/>Note that all of the above just reinforces your point.<BR/><BR/>BrianBrianhttps://www.blogger.com/profile/04480120615233575630noreply@blogger.comtag:blogger.com,1999:blog-593191658179452263.post-86607806637521143172008-11-25T08:22:00.000-06:002008-11-25T08:22:00.000-06:00Nice. Thanks. As far as libraries, I was actually ...Nice. Thanks. As far as libraries, I was actually talking about scheme in particular. I'm a rather young programmer, and am rather new to functional programming in particular, so scheme and Haskell are the only two for which I can justly argue. Haskell libraries are ridiculous... "Oh, you're implementing a turing machine simulation in the game of life? Isn't that on Hackage?"<BR/><BR/>As far as multi-core things: I forgot about this entirely. I really don't know what I'm talking about, but I assume functional languages can really take advantage of this...<BR/>If we have f (g h x y) = (g x) . (h y)<BR/>Then we can send (g x) and (h y) to different cores, and send their results back to f, right?<BR/><BR/>Anyway, the point of the post was to give C the benefit of the doubt at every point... And then come back through and point out the absurdity of the situation I described.<BR/><BR/>CheersCoryhttps://www.blogger.com/profile/07752328226179627747noreply@blogger.comtag:blogger.com,1999:blog-593191658179452263.post-53463170014299106482008-11-24T21:47:00.000-06:002008-11-24T21:47:00.000-06:00I think you could be a bit more concise :-)Check t...I think you could be a bit more concise :-)<BR/><BR/>Check the performance of functional languages on the multicore shootout,<BR/><BR/><A HREF="http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all" REL="nofollow">here</A><BR/><BR/>And then check the numbers of libraries for Haskell,<BR/><BR/><A HREF="http://hackage.haskell.org/packages/archive/pkg-list.html" REL="nofollow">on Hackage</A>.<BR/><BR/>So we're neither short on speed, nor libraries. Making the equation more attractive than in the past.Don Stewarthttps://www.blogger.com/profile/08476737262404343154noreply@blogger.com