Ben-oni wrote: Jplus wrote:
WarDaft wrote:Functional and garbage collected (which is universally implied by functional AFAIK) languages are known to be more efficient use of programmer's time.
I've heard this claim many times, but I've never seen it backed by actual numbers. It's a dubious claim, [...]. Again it totally neglects that there are many other factors that affect programmer efficiency, such as [...].
I'm not sure there can
be objective studies concerning this, but functional tools at least allow programmers to create things they could not otherwise have thought of.
This is true, but it's equally true of OOP, generic programming, autoiconicity, message passing and any other innovation you can think of. This does nothing to support the claim that functional or GC'd languages are inherently more productive for the programmer.
Ben-oni wrote:It's not all about declarative style and compile time assurances. We wouldn't have things like monads if not for functional programming.
This is not true, the monad is a theoretical construct that was invented before it was introduced in any programming language. For what it's worth, you can also implement monads in C++ and in fact the C# team used continuations as a tool for implementing asynchronous calls.
Ben-oni wrote:As for real-life programming, you've never done OpenGL programming until you've done it in Haskell the way it was meant to be done. Spend just one day on that, and I think you'll be convinced that functional programming increases productivity.
This reminds me of the kind of argument that Jehova's witnesses give when they assure you that you'll be just as convinced as they are after you've read the Bible. Granted, your proposal should be less time-consuming.
Ben-oni wrote:As for your particular concerns, solving problems that have already been solved is easy. Trivially easy. The language doesn't matter anymore. Once the solution is seen, anyone can do it. Work on true research solving problems you've never encountered before, and the existence of a vast array of standard libraries will seem quite inadequate.
Suppose that this is true, and the kind of language you're advocating here is best fit for tackling new, unexplored problems. Then you've still only identified a single type of situation for which it is more fit than other languages. There is no way you're going to infer from that that it is most fit for all
WarDaft wrote:Of course memory management makes coding faster. Imagine C, exactly as it is, except now it's memory managed. All the time you've ever spent debugging memory leaks and segfaults just basically vanished. How is that not making you more productive?
It seems you completely ignored my previous long post. I already said this: C is not representative of "all languages without GC". Your argument doesn't apply to C++, Ada or ATS at all. Here's what I said about C:
So to return to my earlier point that there are many ways to manage resources, here's what I think is a more complete overview and fairer comparison of different approaches.
- Manage everything manually everywhere, like in C. Obviously this is the most error-prone as well as the most labour-intensive strategy. Nonetheless, with enough effort it can produce safe and bug-free software. Zero overhead unless you manage your resources clumsily (which admittedly is likely to happen once in a while).
I wouldn't be surprised if there are circumstances in which Fortran is a more efficient use of the programmer's time than Haskell. Heck, I can think of one: when you're a physicist and you just need to crunch a lot of numbers in linear algebra.
I sincerely doubt that, Haskell excels
at math. I haven't looked into it, but if there aren't libraries to do things like matrix multiplication (which, yes, I know is a primitive operation in FORTRAN) then it's a one-time cost to make one and no one else will need to again because they can just type "cabal install linear-algebra". It will also be vastly more extensible, so sooner or later someone will probably generalize it to algebra over arbitrary kinds of traversable data or some such.
Why write an entire linear algebra library for Haskell if Fortran has BLAS and you just need to run some calculations for your research project? The claim that a similar library for Haskell would be "vastly more extensible" is completely unfounded. Furthermore, in Haskell the calculations would be only half as fast as in Fortran, at best (refer to the language benchmarks game if you think otherwise).
WarDaft wrote:Also, the part about needing more thinking... thinking makes you learn, and so think faster and more effectively in the future. People have time and again demonstrated that the upper bound on this has not been reached.
This is relevant for advanced students, not for people who just need to get work done.
WarDaft wrote:Typing bazillions of lines of code will only make you type so fast however, and once you reach the point where you don't need to take breaks in typing as you're coding up your concepts, then the language is slowing you down.
Firstly, this is irrelevant because you never code without thinking breaks, and secondly, you're grossly exaggerating the difference in amount of typing between functional languages and procedural ones. Refer to the "code used" metric in the language benchmarks game to see what I mean.
WarDaft wrote:Note also that you don't have to use high level concepts that you have to think about more in functional languages, you can easily use very simple things and mimic the operation of any control structures of imperative languages - you just have to use slightly different syntax.
So basically what you're saying is that functional programming is great for productivity, but if it isn't you can always switch back to procedural? Then why not take C++ or Python and switch to functional when you feel like it? How can you even maintain that one is inherently better than the other if you advocate switching between the two?
WarDaft wrote:After this though, you have more control over how things work, and if you notice patterns, you can exploit that much more easily.
Bullshit. Languages differ in the amount of modularity and abstraction that they support, but functional languages do not inherently support such things better than procedural languages. Remember that Turing machines and lambda expressions are two sides of the same coin.
WarDaft wrote:There is also no real upper bound on the level of abstractions you can build effectively in a functional language, which lets you do even more with less.
Apart from this not being entirely true (as there is a practical limit), you can keep on building abstractions in any language. That's why, for example, you can implement Haskell in C.
WarDaft wrote:Imagine if, say Haskell and C/C++, switched places in usage levels throughout history. All of the time spent on making better C/C++ compilers was instead spent on making better Haskell compilers. All the time spend on C/C++ libraries was instead spent on Haskell libraries. We're talking a nearly two order of magnitude increase in time invested. How do you think they would compare then?
The difference would be almost the same. Language implementers borrow techniques from each other and libraries take only a few years to set up. Haskell has pretty good standard libraries, by the way. For your reference: ATS is safe, functional and very young, but it's exactly as fast and at least as efficient as C.
WarDaft wrote:Do you think there would there be as many arguments for using C/C++ in that world as there are for using Haskell in this one? More? Less?
This is turning ridiculously religious. Also, stop conflating C and C++.
Sc4Freak wrote:There has always been the argument that high-level languages often trade performance for programmer time (which then arguably allows for more time spent performing optimizations). But that's always a tradeoff. No doubt managed languages may make you more productive in the short term, but automatic memory management isn't free and can have associated long-term costs.
I was just reading a blog yesterday about this... Back in the day (the argument goes) CGI scripts were written in C. This was all very good because the internet was a new and exciting place, and most pages were static HTML anyways. And then the perl hackers came along and starting hacking together CGI scripts in perl. The C programmers railed against the very idea: "You can't write efficient code in perl!" they screamed. But as it turns out, perl is a language designed for text processing, and the internet was built upon text so it worked pretty well. And while the C folks were bitterly resisting perl, the perl (and python, and php) folks were building the internet.
So stick with C if you want, but in the real world, high-level languages are more profitable.
First off, C is
a high-level language. Secondly, you're making a false induction: from "Perl is better for hypertext processing than C" to "GC languages are more profitable than non-GC languages in all situations".
Ben-oni wrote: Xeio wrote: sourmìlk wrote:
With a garbage collected language, infinite coding time will never achieve the same efficiency as an unmanaged one in cases where memory is scarce.
Doesn't matter, nobody has infinite development time, they do happen to have oodles of memory though (especially given the memory requirements of your average application).
Okay, that's not fair. There are too many kinds of programming for that kind of blanket to be meaningful.
For everyday applications programming, I agree wholeheartedly: memory and clock cycles aren't scarce, so choose tools to minimize development time.
I disagree. If it were not for resource hogs like Java and Flash I could run twice as many applications in parallel without things getting swapped (and note that the majority of my applications has nothing to do with Java or Flash). By choosing tools like Java, application developers are needlessly depleting my RAM and I take offense of that. I would mind much less if they took Python, because I don't notice it when my apps take a few milliseconds longer to respond.