Lambda the Ultimate

That sounds very cool. What tools did you use for the transformation?

...I confess that I did it by hand. Since then, I've thought multiple times of trying to come up with a template metaprogramming implementation of the CPS transformation.

That's too bad. I've spent the last 12 hours imagining neat things I could do if I could say "CPS transform *this*, then wrap *that* continuation like *so*". Even having to do the transformation once, then edit the resulting text, wouldn't be too bad.

An illustrative example is sorting. I'm sure any number of FP experts here could write a beautifully elegant sorting algorithm in their favorite FP language in just a few lines...barely a paragraph.

qsort [] = []
qsort (x:xs) = qsort less ++ [x] ++ qsort more
  where less = filter (<x) xs
        more = filter (>=x) xs

I may be wrong (as I don't have working intuition for non-strict evaluation), but isn't append (++) killing complexity of this qsort implementation?

Yes. It has horrible space complexity. I was just trying to live up to the what the original poster was looking for...

But when it comes to sorting a 100 MB file, I would pit C++'s std::sort() against it any day of the week. That's because the typical FP way involves creating many many intermediate data structures and many many copies of the data, whereas the C++ version will use a very efficient merge sort or heap sort, using few heap allocations and a very minimal number of copies.

It's not a practical sorting algorithm.... but it's conceptually very clean. In fact, it was this example that turned one of my friends on to functional programming.

He was using SML for a Discrete Math class, and he was not getting it very well. So I sat down with him for an hour or two and throughly explained the basics of syntax, types, computation-by-substitution, and how to turn a recursive definition of both factorial and fibonacci into an iterative definition using accumulators. He picked up on my explanations pretty well, and afterwards he had no trouble with his programming assignment.

The next day he read "Why Functional Programming Matters," and saw that example of quicksort. He'd implemented quicksort before, but I believe that's when he first understood how quicksort actually *worked*, conceptually. After that he was a fan of SML.

While I wouldn't use this definition in anything past a demonstration, it must be pointed out that there *are* perfectly efficient ways to implement quicksort in SML and Haskell.

While I wouldn't use this definition in anything past a demonstration, it must be pointed out that there *are* perfectly efficient ways to implement quicksort in SML and Haskell.

While I don't doubt the truth of this claim, I would like to see an implementation so as to consider the sacrifices in clarity and elegance necessary to achieve performance in these languages.

Even assuming these languages need to get as ugly as C++/whatever to be efficient, it is still a gain that they can express these algorithms more concisely if that is desirable.

This is not so far from the Haskell version.
And is far more efficient.

(from http://erikhaugen.blogspot.com/)

template
void quicksort(Iter begin, Iter end)
{
if(begin == end)
return;

Iter pivot = stable_partition(begin, end, _1 

It's only valid if you include a lambda library, which kinda reinforces the point that FP is more elegant. Also, you need to translate angle brackets even within a pre block. ;>

C++ can use functional style. I was more saying "as ugly as imperative style C++/imperative style in general", so my earlier comment was inaccurate. But that was not my intention.

That is not a fair comparison. Everything that is essential to the quicksort algorithm is contained within the Haskell definition, whereas you've called a library routine to provide the bulk of your functionality. If I didn't know how quicksort worked, I wouldn't have a clue what your code did without looking at the library you are calling. Not so with the Haskell version.



And, by request, here's the definition that GHC provides for Data.List.sort:

mergesort :: (a -> a -> Ordering) -> [a] -> [a]
mergesort cmp = mergesort' cmp . map wrap

mergesort' :: (a -> a -> Ordering) -> [[a]] -> [a]
mergesort' cmp [] = []
mergesort' cmp [xs] = xs
mergesort' cmp xss = mergesort' cmp (merge_pairs cmp xss)

merge_pairs :: (a -> a -> Ordering) -> [[a]] -> [[a]]
merge_pairs cmp [] = []
merge_pairs cmp [xs] = [xs]
merge_pairs cmp (xs:ys:xss) = merge cmp xs ys : merge_pairs cmp xss

merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a]
merge cmp xs [] = xs
merge cmp [] ys = ys
merge cmp (x:xs) (y:ys)
 = case x `cmp` y of
        GT -> y : merge cmp (x:xs)   ys
        _  -> x : merge cmp    xs (y:ys)

wrap :: a -> [a]
wrap x = [x]

I'd say this is certainly competitive with a mergesort algorithm written in an imperative language.

...how it compares performance-wise.

... but the one reason perhaps that FP has not caught on in the industrial world is control. That is, for the biggest, baddest, most performance sensitive applications (like operating systems, telephone switches, financial transaction middleware, etc.) you absolutely need to be able to say where critical bits and bytes get stored and how. You don't have the luxury of hoping your tail-recursive algorithm gets properly optimized by the compiler.

Functional programming in the real world might be an interesting thing to read.

OO is a natural evolution of the imperative/procedural paradigm which tries to fix many of its shortcomings while staying in touch with how the common man thinks about problems. It succeeds to varying degrees depending on who you are and how you ask the question. It obviously hasn't delivered on all of its promises, but it works well enough that most people creating a new imperative language wouldn't dream of ignoring OO altogether (and even some FP langs have eyed OO with envy...witness CLOS, for instance).

Paul Snively has already mentioned O'Caml and Oz, googling for reactive objects gives me quite a few hits on Timber, O'Haskell, rHaskell and so on. All of them could be seen as functional languages.

I knew Erlang would be trotted out. What feature(s) does Erlang have that make it more functional than Smalltalk? Modern Smalltalks have closures, map, filter, fold. pattern matching? Someone's done that in Smalltalk as well, though I've not tried it.

OO style polymorphic dispatch, especially predicate dispatch which subsumes pattern matching, is much better at preventing nonlocal changes to code resulting from adding new implementations of types than is FP's textual order pattern matching. And OO style dispatch guarantees the most specific method will be executed, which has to be maintained manually with textual order pattern matching.

What feature(s) does Erlang have that make it more functional than Smalltalk?

Was a design goal of Erlang to be more functional (whatever that means) than Smalltalk?

What feature(s) does Erlang have that make it more functional than Smalltalk?

It's rather the features that it lacks, namely mutable state. ;-)

Erlang has plenty of mutable state. It is trivial to write the classic bad OO example of a movable point using an Erlang process.

I know, but you have to encode it using recursive processes, and the process layer is very clearly separated from the underlying pure functional core layer. Hence you are not easily seduced into messing around with state in-the-small.

You are talking about performance critical things, an example would be the AXD301, scalable 10-160 Gbit/sec ATM Switch - using Erlang. Some old notes from Joe Armstrong (via Philip Wadlers homepage).

Nice link. First of all, the presentation implies that Erlang was written with the express intent of supporting real-time systems. But how many mainstream FPs have this as a design goal? Also, on page 23 we have this very revealing comment:

Already Erlang is being chosen instead of C++, Java, even C because of "time to market" - we have examples of pre-study to product of nine months. We are now aiming at development times of less than one year. Here we have a significant advantage over conventional imperative languages. There is a "performance gap" - but we try to run on the fastest available processors, then the gap is less of a problem. We are "sufficiently fast".

That's a bit of a peculiar comment for the FP touted as being a performance go-getter. Maybe GC isn't always as fast as manual memory management. ;> Which is not to say that GC is bad; it certainly has its place. Just that my original point mostly stands.

Why do we put people through college for so many years if they are supposed to think like a common man, didn't they do that before they started college already? The common man does not worry about convolution, double integrals and other mathematical things either, yet they are excellent tools for solving certain kind of problems.

However, there is no such thing as a "commodity mathematician", whereas "commodity programmer" is unfortunately the rule rather than the exception. In an age where not so much as a calculus course is required to get hired as a "software engineer", the reality is that your average programmer is barely more mathematically literate than your average homemaker. Which is probably at least partly why Java has become so incredibly popular (that and the awesome toolchain, but establishing causality there might be tricky).

Paul Snively has already mentioned O'Caml and Oz, googling for reactive objects gives me quite a few hits on Timber, O'Haskell, rHaskell and so on. All of them could be seen as functional languages.

Ok, so I'm not current on my FP langs. Point taken.

First of all, the presentation implies that Erlang was written with the express intent of supporting real-time systems. But how many mainstream FPs have this as a design goal?

FP very much likes to make things on the fly, such that most, if not every FP language is garbage collected.

While many "mission critical" apps are also "real time" applications (such as medical equipment); there are plenty of examples of apps which are one, the other, or neither.

Some of the financial software used by banks, etc., to manage multimillion dollar transactions is mission critical. In most cases, such software is not real-time.

The software than controls the print engine in my $100 HP all-in-one is real-time software; however it isn't mission critical. If it screws up; the result is a messed-up page (and a pissed-off customer), but nobody dies or goes bankrupt.

Microsoft Notepad is neither mission-critical nor real-time.

Garbage collection is widely considered inappropriate for "hard" real-time applications (at least standard implementations of GC), as it often introduces unpredictable (and unbounded) latencies into the system; many of which exceed typical real-time limits. There are some "real time" GC implementations, but this is still an active area of research.

GC may, or may not, be inappropriate for mission-criticial work. For some mission-critical systems, ALL dynamic memory allocation is verboten; but for many other classes of systems; the reliabilty advantages of GC outweigh the disadvantages. Use of Java in critical financial apps seems perfectly acceptable; I see no (technical) reason why use of a FP language with GC would be less acceptable.

I wasn't claiming that it was. I responding to the OP's assertion that garbage-collected languages were inappropriate for "performance sensitive applications...such as finanicial transactions middleware". I am well aware that real-time GC is an active research area. However, there is a distinct difference between "hard real-time" (i.e. deadline sensitive), and "really fast" (which is presumably what the OP meant by "performance sensitive"). That is the only issue I was trying to address.

There isn't a whole lot of mystery to the real-time garbage collector. There are perfectly workable collectors that reclaim resources in a bounded period of time and are guaranteed to consume less than X amount of CPU time in Y units of clock-time.

The downside is that real-time GC consumes noticably more CPU resources. The time is more broken up, and that the garbage is guaranteed to be collected in a certain amount of time.... thus, if real-time is not a requirement, you probably don't want to use a real-time collector.

Several of HP's printers are written in Eiffel, and are garbage collected.

The point is that there's nothing inherent in FP that would preclude it from being used in real-time applications. That's not the same as saying that every FP language is suitable for real-time applications.

The point is that until FP tool authors begin to write tools that are *perceived* by the industry as being competitive with existing tools on the performance playing field, FP will remain a niche market. I never said that FP *couldn't* compete with mainstream tools. Merely that it *isn't*. That's because the FP community is concerned with things like elegance and provability and adding the latest theoretical feature, while industry is concerned with things like toolchain availability, user support, and performance.

FP very much likes to make things on the fly, such that most, if not every FP language is garbage collected.

Uh... last I checked, so was Java. And yet it seems to be perfectly acceptable for all sorts of financial middleware and other "mission critical apps".

I personally don't think it's acceptable, and I wouldn't recommend that a performance sensitive project be implemented in Java (that doesn't mean hard real-time...just that all the transactions post in the same day). My guess is that people who implement such software systems simply throw more hardware at it until the performance is acceptable. But having used some fairly beefy Java programs, "speedy" is one of the last words I would use to describe them.

My guess is that you probably mean "pure" FP languages. After all, there are many C++, Perl and Python practitioners doing FP these days.

Mainstream programmers don't dig FP languages for the very same reason they don't dig C or Perl: there are no IDEs of the same caliber as Eclipse or VisualStudio for such languages.

I believe it's indeed a very strong point. Mainstream programmers think all languages are the same, with just syntatic differences, and that what truly matters is integration and productivity tools supporting programming in such languages...

Thing is, most FP languages are very concise, small languages and their expressiveness allows for saying a lot ( doing a lot of work ) in a few sentences, thereby not really needing a huge, bloated IDE. So, development concentrates on the languages themselves and associated libraries, rather than in such "useless" tools.

Fact is, though, that that is perceived as a huge weakness by the mainstream folks, specially those managing teams of average programmers...

sad.

...just a few days ago I reiterated something significant to me to an old programming friend and colleague: having spent the weekend working with O'Caml in EMACS with Tuareg Mode and Tuareg imenu, and having also recently spent a weekend with SBCL in EMACS with SLIME, I could honestly say that the primary productivity enhancer is interactive development. Everything else pales in comparison: static vs. dynamic, interpreted vs. compiled, whatever. And this is borne out in my use of Eclipse, too: the big benefit is having the project kept consistent at every save of the code, whether it's Java code, C++ code... It's not quite "compile as you type," but it's close enough that I don't slip out of the zone while I'm coding, and that's key.

So I think it's true that oftentimes people emphasize the language per se too much (I myself am guilty as charged) and don't emphasize enough that you have tools like Tuareg Mode and Tuareg imenu to make developing in the language extremely productive and even fun.

and when i said C or Perl don't have a proper IDE, i was talking about mainstream programmers, for whom Emacs is a lousy reject.

If it isn't big, bloated, slow, graphical, with tons of little icons, drop-down menus, "intelisense" and doesn't use the "standard" notepad "ease" of use and keybindings for "common" editing operations, it isn't worth it...

...what I find interesting is how these IDEs still fall far, far short of the environments of, say, Smalltalk-80 or Genera in terms of supporting programmer productivity. To see how far you can go with a good interactive programming language and IDE in EMACS, however, you may wish to see the SLIME video available here.

"For me IntelliJ was first leap forwards in IDEs since Smalltalk. Power and usability that suddenly made everything else second rate. We had entered the post-IntelliJ era..."

- Martin Fowler

Martin Fowler: For me IntelliJ was first leap forwards in IDEs since Smalltalk. Power and usability that suddenly made everything else second rate. We had entered the post-IntelliJ era...

I'm just going to have to respectfully disagree with Mr. Fowler, having also used both Smalltalk-80 and IntelliJ.

skybrian: I'm not going to watch a 150Mb video, but the stuff on the SLIME feature list are things we already have in IntelliJ and Eclipse.

I've also used Eclipse (and still do, when I must work in Java), and no, you don't. The 150Mb video exists because in the end, feature-lists aren't anywhere near adequate means to determine how your productivity will be affected by any tool more sophisticated than ed. But remember, I wasn't talking about SLIME; I was talking about Smalltalk-80 and Genera. Maybe a 50Mb Genera video will be more palatable to you. In any case, the point remains that we're only now (Eclipse, IntelliJ), circa 2000-2005, seeing IDEs for languages like Java or C++ that might be productivity-competitive with Smalltalk and Lisp environments from 25 years ago. Unfortunately, even with IntelliJ or Eclipse, you still don't have the level of interactivity that you do in Smalltalk-80 or Lisp because these are interactive languages while Java, C++, etc. are still batch compiled (yes, I know about the scrapbook, etc. It's a start, but it's a different runtime/namespace and doesn't affect your project).

But all of this is just words and will remain so unless/until you actually try out one of these 25-year-old environments, or at least something that gets reasonably close to it like SLIME. That's not to say that IntelliJ and Eclipse aren't good environments—they are. It's merely to say that it's possible to do even better, particularly if your language design helps you to do so from the outset, and that it was done better 25 years ago using languages of that type.

For C++ Microsoft Visual Studio has "Edit and Compile" "debugging", which allows one to edit the code, recompile, and continue with the current programme state; one can also arbitrarily change the current statement. All in all, it makes for a reasonable development experience, at least after one has finished doing a lot of heavy code editing, for which I prefer to use XEmacs.

you don't have the level of interactivity that you do in Smalltalk-80 or Lisp because these are interactive languages

Smalltalk-80 (and Cincom Smalltalk, and...) provide(s) highly interactive programming environment(s).

Smalltalk The Language is no more interactive than any other chunk of text - as we rapidly learn writing chunk-format Smalltalk in Notepad for GNU Smalltalk.

"SLIME feature list are things we already have in IntelliJ and Eclipse."

except for a decent expressive programming language, of course... :)

A great programmer may be able to deliver a project quickly, reliably and cheaply using Vi (ignoring the maxim about choosing two out of the three). A 'bad' programmer may need a full IDE to help him/hir deliver the same project. I don't see how that is a bad thing.

Secondly, if these tools help an average developer become more productive, surely a better programmer could make use of them as well. If the worst crimes of an IDE are that it helps developers remember syntax, library functions, underlines possible errors on-the-fly, keeps book marks, refactors sensibly and identifies compronents of programs (interface, class, etc.) with little icons, then we need a huge crime wave for all languages. :)

Various developer tools may be many things, but 'useless' is certainly not one of them.

The original point i was trying to make was not that you won't be productive with an IDE, just that FP and other less mainstream languages don't go mainstream not for bizarre syntax or paradigms, but rather exactly because there's no IDE backing them up so that average programmers can pick them up.

Of course a good IDE helps a lot. I'm particularly fond of the interactive module and class navigation system that most IDEs call "code-completion". Other than that, one thing that truly annoys me to death is the fact that most of these IDEs come with really lame subpar code editors... gimme emacs anyday. And i'm used to VisualStudio and Delphi...

well, i guess nothing's perfect and there's always a price to pay...

I wonder if this is a self-perpetuating state of affairs - programmers who do pick up FPs and don't need IDEs have better things to do than spend their time developing fully fledged IDEs. That said, there are some very popular development modes for (X)Emacs for functional languages that their users find give them the kind of support they want, like Tuareg and Slime.

Marcin Tustin: That said, there are some very popular development modes for (X)Emacs for functional languages that their users find give them the kind of support they want, like Tuareg and Slime.

Very well put—and it's worth remembering that in the Lisp and ML communities, programming support via what would be called an IDE today has had some 30-45 years of evolution behind it, so "the kind of support they want" isn't as idiosyncratic as it might sound offhand.

The "code completion" features that most modern IDEs provide seem to exist to allow complete novices who can't even look up documentation on their own to be productive. This isn't me being snide - this is an honest observation of people I've seen who think that programming in Java is hard, but that C# is fantastic.

For library impoverished languages, code completion may indeed seem redundant. But when it's possible to pick up a library you've never used or seen before and get 90% of its functionality just by looking at the methods and constants available (plus a few examples, say), then it becomes apparent that code completion is very handy. It's also handy when you can't remember the exact spelling of a long identifier, or simply don't want to type it out.

In fact, code completion + Javadocs are probably one of the reasons why Java with a decent IDE is such an easy language to use, despite having more libraries than you could shake a trie at. The simple fact is, many well-designed libraries can communicate most of their functionality through their interfaces. So unless the library does something tricky, there is often not a need to study the documentation in detail; especially for canonical uses that are perfectly well illustrated by a few examples.

Having said that, I've never tried C#, so I don't know how code completion between that and Java fares, but I would feel pretty insecure with a programmer that says "Java is hard!" However, I suspect that people who say that simply haven't set up the Javadoc references correctly in their Eclipse projects.

I find that I can use a web browser or even man to read API documentation. As for saving keystrokes, almost every single time I want to do that hippie-expand and dabbrev-expand do just fine. The last time I needed an aid to reading was when I was following along the line with my finger; perhaps the next time I need language- and library- aware code completion will be when my memory begins to fail me.

I suspect that novices find such technologies helpful because they don't understand the way that programme elements can be composed. Unfortunately, cruddy libraries with poor documentation and very complex compositionality rules can still confuse, and code completion still doesn't help with that.

I find that I can use a web browser or even man to read API documentation.

Sure, but many times I don't even *have* to read documentation. For several handy Java libs, I've just installed a JAR, referenced the Javadocs, looked at a few examples, and wrote the necessary code to use it without ever looking at the documentation proper (or at least not until I needed to know some subtle point about its behavior).

As for saving keystrokes, almost every single time I want to do that hippie-expand and dabbrev-expand do just fine. The last time I needed an aid to reading was when I was following along the line with my finger; perhaps the next time I need language- and library- aware code completion will be when my memory begins to fail me.

Or when you go to use a library that is not in your memory because it's the first time you've used it. In which case, informative identifiers and well-designed types go a long way in making the usage intuitive and straightforward (and types + code completion can help you use the library correctly without actually knowing the library simply by limiting your available expressions to the ones matching the expected type). Also, code completion can help narrow your documentation search when you do need to actually look at the full docs.

I suspect that novices find such technologies helpful because they don't understand the way that programme elements can be composed.

It's really about productivity, not what can and can't be done.

Unfortunately, cruddy libraries with poor documentation and very complex compositionality rules can still confuse, and code completion still doesn't help with that.

True dat. But reasonably-designed libraries with good Javadocs are actually very well served by code completion.

So, your point is that you don't have to read documentation with code completion because javadoc is documentation? Pray tell what "javadoc" stands for?

Whether or not this is documentation, I still find it quite readable without support from my editor. Well designed types (and better yet sets of operations over types) are easier to use whether or not you have code completion. I really have met very few competent programmers who honestly find code-completion does more than save them keystrokes. When deprived of it, that is what they bemoan, not that they suddenly have to use their windowing environment to switch between an editor window and a browser window.

Well, Javadoc is a tricky beast. If you don't have a nice IDE like Eclipse, it's apparent why you wouldn't immediately get what I meant. Code completion in Eclipse is really more than code completion. If you type the prefix to a method, you not only get a list of available completions in a popup box, but when you highlight one of the selections, you get a small summary of the documentation for that method/value. So what most people call "documentation", as in "a set of web pages or hardcopy that describes a program/library" does not actually need to be referenced in its typical form.

So the neat thing about Javadoc is that Java IDEs know about it. You can either view it as traditional documentation, a page at a time, and look up what you need to by index or text searching, or you can just get a code completion on the relevant term, which combines searching, documentation, and code assist all in one easy-to-use and intuitive operation.

Besides the documentation aspect, I use code completion to accurately spell things for me. When you end up with identifiers like REALLY_LONG_CLASS_CONSTANT, it is easy to miss a letter or two. Code completion helps you by not making you type out every letter of an identifier whose purpose you understand, but whose exact spelling you really don't need to memorize. It's also useful when you have a lot of constants in an enumeration and you would know what the name of what you want is if you could see it, but you can't think of it off the top of your head (and if you use a lot of third party libraries, or really big third party libraries, this happens more than often enough).

And looking up documentation is more than switching between the editor and browser windows (which is annoying enough all on its own). You also have to do a search for the item in question, which may or may not involve loading a different documentation page, or even searching for the set of documentation that you need to search in. Again, when you use a lot of libraries, this happens frequently enough to be annoying.

Code completion saves me time, but being a 72+ wpm touch typist, I really couldn't care less about saving a few keystrokes. And I find that when I'm coding in C++ in an impoverished IDE, and I need to look something up, I spend a considerable amount of time doing so as compared to Java.

I fully understand how code completion/documentation browsing works - that is my entire point about supporting novice programmers. However, for people who do understand the language, it is my observation that they can cope with scanning their eye down the library documentation, where the library does not have an obscure design, and be perfectly productively with the minor difference in procedure of having to switch to a browser occasionally. Clearly, your perception is different on the matter of how much time looking up documentation consumes. In this case, only a decent study can resolve the matter. Where library design is obscure, I doubt that integrated documentation display would help, but it may be otherwise.

It's not the keystrokes that matter, it's the mental context switch needed to switch from "coding" to "reading" mode. I can code as fast as I can type as long as it has my full attention. But once I need to start looking things up, I start losing time remembering what I was just doing, and figuring out what I need to do next, and working out what I need to look up in order to do it.

I don't have any studies for you, but I have my personal experience. I find that looking up an unfamiliar method with code completion or intellisense takes about 3-5 seconds. Switching to a browser takes at least a minute (including the mental context switch), assuming I know exactly what I'm looking for. If I have to hunt, it's easily 5 minutes. That's a factor of 10-50, so I find it's often worth using Java even though it takes 3-5 times more code to accomplish the same task.

It really isn't a feature just for novices: it's a very handy tool to have in your toolchain.


import foo
import bar
...
foo.some.deeply.nested().attrib...


code-completion definetely is handy, particularly in OO environments. Actually, it makes me wonder if OO became so prevalent in the industry because of such convenient support tools like IDEs featuring such easy way to navigate through the class and module trees; or if it is the fact that such paradigm needing such powerful ( and costly ) tools that has made tool vendors push OO like mad to the market?

"OO: the solution to your problems, and ours too! hoho"

btw, still waiting for proper, semantic-level, code-completion in Emacs, other than the text-search hippie-expand: when that new function from the module you just imported isn't there yet, you either type it from scratch ( hoping it's short ) or copy-and-paste from your webbrowser ( hoping it's not Lynx, though it's so sweet to browse htmdocs ).

Both noobies and experienced programmers alike have huge productivity gains with code-completion.

Why can't you copy from lynx? I copy from my terminal all the time. As to huge productivity gains, I type pretty quickly, and find that typing is not the bottleneck in code development.

My experience is that XEmacs-style statistical expansion works far more frequently than completion in Visual Studio, which typically fails to find expansions for anything except some things in the standard library, like type names. I am pleasantly surprised when it does find methods on non-standard libraries.

"I type pretty quickly"

well, just imagine that + code-completion!

the fact is, one of the purposes of programming is to automate repetitive and boring tasks: code-completion basically reduce your whole cycle of
lookup functions in module;
choose and copy function and parameters to editor buffer;
to a single ctrl+enter after the desired module name ( or class )

"typing is not the bottlenexk in code development"

"Money doesn't provide happiness, but sure helps a lot"

^_^

I use code completion in XEmacs, and one of the reasons I like XEmacs, is because, as I said (on edit), code completion works more than it does in Visual Studio. But, I think it was pretty clear that code completion is not a big win - speeding up my typing has minimal impact, but money "sure helps a lot". Do you see the difference?

I don't look up functions every time I use one, because as I've said before, my memory works pretty well; when looking at documentation for the first time, it provides more than the names and signatures of operations.

Also, you haven't explained why you can't copy from lynx. IS IT BECAUSE YOUR ARGUMENT LACKS CREDIBILITY???????

Don't blow a gasket, we're just talking about IDEs here. Not a huge deal.
Detachment is a good thing.

How can you say that? Detachment is a tool of the UN Shadow Government. If you condone detachment, it will lead to you being forced to programme all your applications in LaTeX. The worst part is that once they're finished with you, you'll like that.

"I use code completion in XEmacs, and one of the reasons I like XEmacs, is because, as I said (on edit), code completion works more than it does in Visual Studio."

Yes, i understand: it works on text that is not code, including words in comments, for instance. That is exactly why it doesn't help much in coding: it is just a convenient backwards-text-search, not an interactive class and module browser.

"I don't look up functions every time I use one, because as I've said before, my memory works pretty well; when looking at documentation for the first time, it provides more than the names and signatures of operations."

Your memory may work well, but wouldn't it be far better if your fingers could type about just as fast as you remember the function names? Code-completion gives your that.

And that's just half of the story: for modules you've never seen before, code-completion shows you their interface in a glance. If the function names are descriptive enough, you have a win. It isn't a substitute for docs, but for people used to C headers as the only docs, it's not much of a big deal...

"Also, you haven't explained why you can't copy from lynx. IS IT BECAUSE YOUR ARGUMENT LACKS CREDIBILITY???????"

perhaps i just don't know how to? care to enlighten me? i'm using a stupid terminal called rxvt, which doesn't even seem to use xterm conventions...

it isn't important, anyway: this whole discussion is about people like you bitching on such a great interactive automation tool and editing enhacer like code-completion, urging us instead to rely on memory or manual lookups and copy-pasting...

i'm wondering if you ever used code-completion in an IDE just for purposes of comparison?...

"i'm wondering if you ever used code-completion in an IDE just for purposes of comparison?..."

I refer you to my previous comment comparing the performance of Visual Studio code completion against that of XEmacs.

Edit: Have you ever performed a comparison of your productivity using only an editor that does not support code completion as against using your IDE, not using any "integrated" features other than code completion/documentation referencing?

Or a fan of C++ IDEs in general. After 12+ years of coding in C++, I haven't found a single one that is as good as Eclipse is for Java. That's really pathetic. However, I dare you to compare Eclipse 3.1 + JDK 1.5 to your favorite FP IDE and tell me that code completion isn't useful, or is just for noobs. As someone who is more or less forced to use Java, I have to say that Eclipse is the one compiler tool I've used (of any language) that makes a barely tolerable language somewhat fun to use. I couldn't imagine trying to write Java in a raw text editor, even if I were an "expert" (though I know C++ well enough to do so and do so regularly). Even if I could do it to prove a point, I would not want to as a matter of course.

Frankly, I can't stand eclipse. The extended set-up procedure before being allowed to edit a file seemed to have absolutely no pay-off when I tried it.

...to use it to do something other than Java, then I agree that there is little to no payoff. I haven't tried the C++ plugin yet, but I don't expect high things from it. However, it's absolutely essential for Java development (though if you're allergic to Java, then there's no reason for you to try it).

I've written a lot of java in my time, for employers as diverse as engineering companies and banks, and I've never been impressed by eclipse, which I found excessively cumbersome in every single way, from staring it up and find that it required me to perform some heavy configuration before it would allow me to even open file, and them became even more confusing when I wanted to do such advanced things as manage the files in my project, even to the level of files in different directory trees. Frankly, I'd rather be using the old Visual Basic 6 IDE, to programme Visual Basic, because all I had to contend with them was incorrect documentation.

It's definitely true that Eclipse is a big beast. My installation takes a good 90-120 seconds to load up, whereas C++Builder usually fires up in seconds (except when loading a large project, of course). However, I'm not sure I know what "heavy configuration" you needed to do to open a file. I just select "File | Open File..." like I would in any IDE. If it's a file in my project, I just double-click it. I don't recall having to configure anything to get to that point. The configuration I've done is things like tweaking the syntax highlighter's colors, installing plugins, etc., which were all optional to the actual development process.

The VB6 IDE is faster, but compared to Eclipse, rather impoverished (especially the editor and syntax highlighter). I like Borland's IDEs better (though they have their own problems too).

I'm referring to being challenged to select a bewildering array of directories on first running eclipse, and then another bewildering array when attempting to start a project, something compulsory as far as I could tell, before it was possible to actually edit a file. This makes eclipse seem more like an elaborate joke than a tool.

You must be talking about the workspace. I think common practice is to set up one workspace and make that the default until/unless you need more than one. Once you do that, you don't have to select any more directories than you would in a CLI environment.

you think small. You don't seem used to big professional software projects. Perhaps you're just too young?

Fact is: no one uses eclipse to open a file, edit it, then close and wait another half hour as it initializes again to edit another one ( well, you don't do that in emacs either, do you? ).

People use eclipse to manage huge software projects covering hundreds or thousands of classes and modules scattered across several files. They start it when they get at work and close it when go home and work is done.

BTW, just to answer you: i use Borland Delphi and ObjectPascal at work and have my personal projects coded in C + GTK at home, using Emacs and hippie-expand, gtkhtm docs opened in lynx. Yes, i'm positive i'm not as productive as with Delhi's code-completion.

As i said before, manually looking up interface declarations and copying them to the text buffer is not as fast as an automation tool that does the same in one keystroke.

They start it when they get at work and close it when go home and work is done.

Usage patterns like that really test memory leaks in software (it used to be an issue only for server software, not anymore).

And unfortunately there're all too many. I regularly close and reopen Firefox, Thunderbird, BitTorrent, and Gaim because they've grown to hundreds of megabytes of RAM usage, even though my normal usage pattern is to leave them open indefinitely. The worst was AIM 4.7, which would regularly grow to over 500 megs after a couple days of usage.

Though (to drag this semi-back-on-topic) Eclipse seems fairly good in that regard. It's a pig in general, but at least it's not a pig that keeps getting piggier.

I'm not talking about opening and closing it, which is why I didn't say that. I said that it takes "too much setup". This is the second time where you have clearly failed to read what I said, and now you're thrown in a low insult for good measure.

What we do with IDEs is open files, edit them, then compile a bunch of them together, then maybe use some other tools to debug and analyse the programme. Because I've used other IDEs than eclipse, I know that they do not require an extended configuration phase before you can even start programming - I'm talking about JBuilder, Visual Studio, Borland's C++ environment, and several others I've toyed with. Oh, and if you find that opening and closing programmes is a big hit on your time, consider maybe not turning your computer off.

Please explain how I "think small".

"This is the second time where you have clearly failed to read what I said"

sorry. wasn't on purpose.

"they do not require an extended configuration phase before you can even start programming - I'm talking about JBuilder, Visual Studio, Borland's C++"

Commercial IDEs without such level of extensibility via plugins and not having to deal with such disparate external tools such as Ant or JSP servers can't really compare to an open-source tool like Eclipse. The features are all there, but you'd better take some time to tweak them.

"onsider maybe not turning your computer off"

my boss won't like it. at home i have power bills to pay for...

"how I 'think small'"

somehow, the idea of telling my colleagues to drop automatic code-completion and instead rely on memory, fast typing, manual lookup of functions in modules and then copying to the text buffer, because we'll be as productive as ever, seems kinda awkward...

"somehow, the idea of telling my colleagues to drop 'automatic code-completion and instead rely on memory, fast typing, manual lookup of functions in modules and then copying to the text buffer, because we'll be as productive as ever,"
the productivity argument in this case is always that these methods force better understanding of the objects being used by their nature, thus leading to higher productivity later.
The code-completion argument has no problem if it is assumed that one actually does read the documentation for objects being used, and does frequent manual lookup of functions. However the code-completion reality seems to be that people install x, get an example of code for x, start typing and guessing at the methods to run on x using their 'common sense'.
as problems are encountered only the manual section referencing the problematic method for x is used.

Thus there are people who observe this state of affairs and conclude that the IDE with code-completion is actually a productivity waster.

the productivity argument in this case is always that these methods force better understanding of the objects being used by their nature, thus leading to higher productivity later.

Is that actually the case, though?

I read a lot of documentation for the hell of it. Not work related stuff - I just like exploring the manuals for new languages, new libraries, and new tools that might or might not be useful later.

Only very rarely does anything I've read actually turn out to be a productivity booster.

That's okay - it's certainly more productive than watching TV or looking at porn, which is what most other people do with their free time. But I'd be skeptical of an approach that advocates reading documentation as part of a daily work pattern.

In my experience, top productivity comes from doing as little as possible to accomplish the task, and hence getting as many tasks accomplished as possible in a given period of time. You memorize the stuff that's actually important then, not the stuff you think is important. The two very rarely coincide.

Could you point to where I have told you to stop using an IDE? Instead, I have questioned your claim that experienced programmers derive a genuine increase in productivity, to which you have responded not with anecdotal evidence or even reasoned argument, but with pooh-poohing and low insults. Now, when challenged to justify your insult, you go on to an irrelevance based on a factual inaccuracy.

Anecdotal evidence? I'm giving you plenty but you don't listen to it.

No way an experienced programmer will be as productive by manually looking up functions and copying them to a buffer or relying on photographic memory and fast typing as he will be with fast typing and code-completion automating those silly steps in a keystroke. No way!

And i'm done here, since argumeting with you is as productive as argumenting with a doorstep.

Do we measure productivity in terms of volume of code produced? And is the speed of coding even indicative of the overall level of productivity for a project? Most of the evidence in this industry slants towards the anecdotal and conjectural. Excuse me if my warning bells of scepticism start ringing loudly when anyone makes claims of huge productivity gains.

In terms of anecdotes, I find writing code to be extremely easy. Between books and google, I rarely get writer's block. After I code in a language for a while, the available routines get burned into my brain. If I start coding in libraries that I have never used before, I have more problems than just locating the particular property or method that I need. I have the problem of learning that library, so that I don't shoot myself in the foot.

I do have my days where I can code up a storm - thousands upon thousands of lines of code can slip through my fingertips. Yet, these momentary bouts of epiphany can keep me busy for weeks on end, trying to clean up the messes I made in the wake.

My personal goal on any project - once I get past the prototyping stage - is that the volume of code for a project should peak early and actually come down as the product gets more mature. This in spite of the fact that the number of features become larger and larger. On a mature project, I measure success in terms of how many lines of code I can eliminate (not vice versa). As I work more and more with the software, I stumble upon better abstractions and the true patterns of the domain.

At any rate, that's just me. I've seen programmers that whip out code that makes your head spin with much cruder tools than vi and emacs. Programming is a game of logic, and good tools are no substitute for for good thought. That said, good programmers can use tools to good effect and be more productive. But I wouldn't say that the productivity is orders of magnitude. More likely to be matters of convenience than an earth shattering change in the way programming tasks are accomplished.

but tell that to managers! They love huge amounts of lines filled. Be it comments or declarations, with a few loops and conditionals here and there to spice it up.

Really, code-completion can be a blessing for allowing for quick navigation through a huge library tree of many modules and classes, new and old. But it can quickly translate into badly written code, something you just notice when you noticed during repair time.

For instance, because of such ease to navigate though classes, you can quickly endup with long sequence like this:

class.method().attribute.method( obj.attribute, obj.method() ).getSomething();

this, for the sake of clarity, should be much better if decomposed in several steps:

obj1 = class.method().attribute;
arg1 = obj.attribute;
arg2 = obj.method();
obj1.method( arg1, arg2 );

but this generally doesn't happen, since it involves declaring some more things, but specially because code-completion makes it so damn easy to write it like in the first example...

it can be a curse, at times. specially in the hands of noobies...

"I measure success in terms of how many lines of code I can eliminate"

100% agreed.

Better thought out software doesn't benefit much from code-completion: most of the time, you see the errors you commited in the first place, and then begin to see patterns here and there and to copy-and-paste chunks of code, parameterize them and put them in functions for reuse in those other parts...

class.method().attribute.method( obj.attribute, obj.method() ).getSomething();

1 line.

obj1 = class.method().attribute;
arg1 = obj.attribute;
arg2 = obj.method();
obj1.method( arg1, arg2 );

4 lines.

hmm...

The problem I see with this style is that names like obj1, arg1, and arg2 aren't useful, and often there is no useful name for them, so I consider it more concise and better to use the first style.
Although, I'm a functional programmer, and the first style is, in a sense, "more functional".

"that names like obj1, arg1, and arg2 aren't useful, and often there is no useful name for them,"

Of course, it was an example of long spaghetti line generated by too much reliance on code-completion. I find it clearer to decompose it in significant steps and giving appropriate names to them.

"Although, I'm a functional programmer, and the first style is, in a sense, 'more functional'."

But in Lisp, for instance, you hide all that confusing function calling upon function calling by properly indenting the code. There's none of that when repetitively calling methods with code-completion: you just end-up with a very long line.

It's annoying when reading code to have to side-scroll in order to make sense of such mess. It is because of this that i don't mind wasting a few more lines to be clearer in my purpose.

...with your sentiments, but must observe that there is a huge difference between products that take months or years to develop and ship out the door, and products that take weeks or months to develop and are used in-house. The difference is that the former generally are (or at least should be) crafted, while the latter are generally "manufactured". By "manufactured", I mean that they don't involve intricate and subtle program logic, they can use many off-the-shelf components, they don't need to be pretty, or even proven correct by mathematical standards.

For large, crafted projects, you definitely should spend more time thinking about and refining the design. But manufactured apps are exactly the ones that benefit from RAD features like code completion and GUI builders. Since the average programmer is a code manufacturer and not a code artiste (due to economics, skills, or whatever), I dare say that most coders do get a true productivity boost from rich IDEs that offer "noob" features like code completion.

Unlike many, I'm more than willing to admit that the kinds of software I develop are usually on the fringes - the place where some of the most interesting software is developed. I've done software projects that range from several minutes from inception-to-design-to-completion all the way to several years (a decade in one instance) - ranging from in-house apps to hosted services to packaged products. At the moment, I have the entrepreneurial bug which has its own set of characteristics. No bureaucracy to blame - just my own stoopid self. :-)

Whether the noobs get enhanced productivity out of the tools, I suppose I couldn't disagree. But the level of productivity boost is an open question. And I've found that many get addicted to the tools and the manner in which they develop software is influenced in subtle ways.

Whether the noobs get enhanced productivity out of the tools, I suppose I couldn't disagree. But the level of productivity boost is an open question. And I've found that many get addicted to the tools and the manner in which they develop software is influenced in subtle ways.

I notice that in hacker culture (and I mean "hacker" in the MIT sense, not the ABC News sense), there is a certain "warrior honor" in using impoverished tools as a sadomasochistic way of proving one's worth. I will be the first to admit that I would open up vi or emacs to prove a point to some young punk who thinks he's da bomb but never coded outside an IDE. However, I've also spent a lot of time building tools, and respect how difficult it can be, which is why I'm not above using the latest tools, even if they are perceived as enabling unqualified programmers.

I'm almost certain that if IDEs were primarily used by the programming elite, and beginners used plain text editors and CLI tools, the arguments in this thread would go the other way, holding all the technical points constant. Yes, I'm basically saying that there's a certain technical snobbery at work in the anti-IDE movement. emacs is a wonder of software engineering, but when it comes to the command line, I use jed because it looks and feels like emacs, but doesn't take 5 seconds to load. No, I can't watch Towers of Hanoi or chat with Eliza, but if I feel an overwhelming need to have an interactive Lisp session, emacs will be right there waiting. Trying to compare emacs to a richly featured IDE like Eclipse is very much like trying to argue that writing raw HTML in Notepad is superior to using the latest web authoring tools. There was a time when such tools were in such poor shape that using a text editor was actually better. But those immature tools have matured, in both arenas, and the only real reason to not use them is simple stubbornness.

David B. Heid: Trying to compare emacs to a richly featured IDE like Eclipse is very much like trying to argue that writing raw HTML in Notepad is superior to using the latest web authoring tools.

The risk inherent in this statement is that EMACS can be as richly featured an IDE as someone is willing to invest the time in making it, and in the case of something like SLIME, people are investing a great deal of time indeed. I still urge people to give that 150MB video a look to see what I mean.

The risk inherent in this statement is that EMACS can be as richly featured an IDE as someone is willing to invest the time in making it, and in the case of something like SLIME, people are investing a great deal of time indeed. I still urge people to give that 150MB video a look to see what I mean.

Eclipse can be as richly featured as people are willing to make it, and judging by the plugins available, people have been willing with a vengeance. The difference is a console app vs. a windowed app. Let me describe what I see in my Eclipse window, and you compare it to what you see in your favorite emacs mode...

Taking up most of the space is a code window syntax highlighted in my favorite color scheme (which happens to be the Turbo C++ IDE default colors). Non-essential portions of the code have been folded into one line (imports, header comments, etc.). Decorations in the left gutter indicate which methods are overriding or hiding base class methods. Decorations in the right gutter indicate the location of TODO comment items within the file, as well as the location of warnings and errors (Java may not be an interpreted langauge, but Eclipse makes it extremely interactive on the syntax level). Each source code tab has an icon indicating which editor has opened that file (the default Java editor, a Swing GUI builder, a MyEclipse editor, etc.), and a decoration on the icon indicating whether that file has any warnings or errors in it.

The remainder of the space is taken up by the project window which shows me all the files and resources in the project in a treeview. Each file with errors or warnings is decorated with an icon, and those are propagated up to the package and project levels. I can see which jar files in my project have references to source or documentation specified, so that I know whether I can hit F1 on a method call into that jar and get help or step through its implementation. For projects in source control, I can see the path to the project within SCCS, I can see which files have been changed but not committed, and which files have been added but not committed. I can also see the version number of the file and what date it was last committed, as well as by whom. There are decorations for resources that are in SVN, and for the various project types (Java, simple, or some other type).

All of this information is available in a glance in a typical snapshot of my development window. I'm fairly certain that this amount of information would be difficult, if not impossible to provide in an easily understandable format within emacs. And it's not really a fair comparison, because emacs is essentially a console program. But then, that's kinda my point.

I think you'd have to define what you mean by "essentially a console app" in an era when EMACS has been doing windows, multiple fonts, colors, and even images for about a decade now.

I honestly don't know what else to say. I use Eclipse 3.1; I use GNU EMACS 21.x.y. I tend to do my Java development in Eclipse and everything else in EMACS, and not once have I found myself saying "Gee, I wish __________ Mode in EMACS did __________ like Eclipse does." On the contrary, I have found myself having to hand-integrate processes into Eclipse painfully, but that has more to do with Java's relatively poor support for interacting with other processes in the system than with Eclipse. I also wasn't claiming that Eclipse isn't extensible or that it isn't more popular than EMACS, so I don't see the relevance of the plug-in point. My point was that EMACS + a good mode or collection of modes can be, and for some of us is, a perfectly good IDE, that's all. I fail to imagine why this is even controversial, given EMACS' longevity and popularity in hacker circles.

"EMACS has been doing windows, multiple fonts, colors, and even images for about a decade now"

but it's still a console app: you can do all that ( except for the images ) in a console as well. emacs -nw

By being a console app means that, yes, it has windows, but they are just other console outputs in big windows.

I understand that he's trying to say that a GUI-designed IDE like Eclipse does far better use of available visual space by having useful information nicely formated in the form of little icons, tabs, status bars, tooltips and drop-downs; rather than a plethora of confusing tiny windows showing nothing but loads of disparate text as in an essentially console app like Emacs...

rmalafaia: I understand that he's trying to say that a GUI-designed IDE like Eclipse does far better use of available visual space by having useful information nicely formated in the form of little icons, tabs, status bars, tooltips and drop-downs; rather than a plethora of confusing tiny windows showing nothing but loads of disparate text as in an essentially console app like Emacs...

EMACS doesn't impose "a plethora of confusing tiny windows showing nothing but loads of disparate text." I've got drop-downs, I've got icons, tabs, status bars, tooltips... I think the problem here is lack of familiarity: if you aren't using one of the better IDEs in EMACS, then you might not be aware that you can. :-)

'Do we measure productivity in terms of volume of code produced? '
a manager measures productivity that way

a programmer measures productivity in terms of how little code was produced that did the task to spec
:)
ok, maybe not, but it sounded pithy dammit.

If I start coding in libraries that I have never used before, I have more problems than just locating the particular property or method that I need. I have the problem of learning that library, so that I don't shoot myself in the foot.

I'm curious - what problems do you typically run into? My experience with libraries has been that the bulk of time goes into looking up method names, types, and parameters. Yes, there are occasional gotchas. But if I can cut method lookup time by a factor of 10, that gives me a ridiculous amount of time to read the documentation, view the source code, step through a debugger, and contact the original developers when I do run across that obscure library "feature".

"Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%."

There no IDEs for C that are of the same caliber as Visual Studio or Eclipse? What about Visual Studio? Is that not as good as Visual Studio?

wouldn't that be for C++?

anyway, there's always Emacs, which has a pretty powerful and capable cpp-mode...

or anjuta, which i hope eventually becomes really good...

Visual Studio supports C. As far as using Emacs, I'm not aware of any stand-alone debuggers that could be integrated with Emacs (or XEmacs) to provide Visual Studio's "edit and compile" interactive development, which is why I'm currently using both.

Commercial Common Lisp IDEs (Allegro or LispWorks) are very nice (no flames about how CL "is not FP").
Bigloo Scheme also has a very nice development environment. Oz (multiparadigm) has a pretty complete environment based on Emacs (goes beyond the usual stuff). So, part of the problem is that people simply don't know this stuff exists. It's hard to compete with some PR departments.
I think, eventually, the FP community will get there. However, the sheer number of people using Java is hard to beat.

Would you entertain the idea that languages that support some form of metaprogramming eases the pain of not having a supercharged IDE ?

The common understanding is to use tools when programming in such an environment. Development proceeds not so much in language X as in language X within tool Y. I think Ruby on Rails takes the opposite approach, where the underlying code is as terse as possible using Ruby constructs and metaprogramming (like has_many above), perhaps because Rails aficianados lack a custom-fit IDE like VisualStudio.NET.

Could Rails have been built without Ruby?

So it seems mainstream programmers are learning (Ruby is mainstream in my book...)

How about the inverse: Does having a good IDE (one with automated support for refactoring and other goodies, not to mention as much support as possible for incremental/interactive development even if using an edit-compile language) ease the pain of not having good metaprogramming support? Is editor meta-programming a valid notion? What about visual programming tools?

And what about environments with the best of both worlds?

First of all, the presentation implies that Erlang was written with the express intent of supporting real-time systems. But how many mainstream FPs have this as a design goal?

How many mainstream imperative languages have that as a design goal? Yet people (ab)use C in real-time systems.

That's a bit of a peculiar comment for the FP touted as being a performance go-getter. Maybe GC isn't always as fast as manual memory management. ;> Which is not to say that GC is bad; it certainly has its place. Just that my original point mostly stands.

Armstrongs notes were written in 1998 so they are a bit out of date. His thesis is a recommended thing to read. The High Performance Erlang Group at Uppsala University has done a lot of work on a Erlang compiler to native code for several platforms. I have not been able to find any claims in their articles that the GC or recursion are the big performance problems in Erlang.

... whereas "commodity programmer" is unfortunately the rule rather than the exception. ... (.. establishing causality there might be tricky).

Your causality comment was about Java, but it goes for the commodity programmer as well. Did the bad programmers show up before the bad languages, or the other way around?

First of all, the presentation implies that Erlang was written with the express intent of supporting real-time systems. But how many mainstream FPs have this as a design goal?

How many mainstream imperative languages have that as a design goal? Yet people (ab)use C in real-time systems.

The point being, naive implementations of FPs are not going to be performance-competitive, as we all know. Whereas, even a naively constructed C compiler is going to give reasonable performance. It's the nature of the languages involved.

The High Performance Erlang Group at Uppsala University has done a lot of work on a Erlang compiler to native code for several platforms. I have not been able to find any claims in their articles that the GC or recursion are the big performance problems in Erlang.

In this case, they felt that emulation was the biggest performance hog, which should come as no surprise. Also, it's the lowest-hanging fruit, from an effort perspective. There's not much optimization that can be done with the GC since it has soft real-time requirements, and tail-call optimization is the most obvious thing you can do to help recursion, and FP compilers pretty much have to implement that to be remotely competitive. But the other obvious optimization for function calls is inlining, and the HiPE paper specifically implies that this is important because hot-code loading makes it harder. On the other hand, C lived without inline functions for decades and still offered pretty good performance, while inlining in C++ is one of the things that actually makes it faster than C in many cases (as well as function objects). The point being that FPs can't really invoke inlining as an optimization because they need to do it just to get acceptable performance.

Did the bad programmers show up before the bad languages, or the other way around?

Depends on what you call a "bad language". You could blame a lot of things on BASIC, but is it really a "bad" language? The bad programmers showed up when the economy demanded more programmers and the market was not able to ramp up production while maintaining quality. Blame it on the dot-com bubble. Those dang internet market investors created a generation of bad IT professionals!

"You could blame a lot of things on BASIC, but is it really a "bad" language?"

yes.