The uncomfortable truth about academia

Got sent this in an e-mail, thought you guys might like it. From some objectivist's blog, I think.

At work today I discussed a new rule of thumb with the hiring manager, in an effort to stave off more fuckups like the guy we just had to fire. I provided her with a list of theory buzzwords and academic programming languages. If an applicant lists any of these on his resume, from now on she will not call him in for an interview. If he volunteers a mention of them during an interview, she will end it immediately.

For the naive among you: An academic programming language is by definition a language in which you cannot do real work. These languages are easy to identify because academics write papers about them. I think most people are unaware of the distinction, which is confusing because just four or five years ago it was glaringly obvious and nobody would take such a language seriously or ever try to use it to write an actual program. If some retard wanted to spend the rest of his life trying to write a working text editor in LISP, that was his business and all the people with homes and jobs could safely ignore him. Long story short? This is no longer true. Now the drooling lab rats have escaped from the lab. Now they're on my front lawn demanding to replace my Porsche with a cardboard box attached to a skateboard with organic barbed wire. Now they are literally in my actual business, wasting my time as well as theirs.

When a viral infection escapes from a lab, it's a disaster, a plague. It's the fucking armageddon. I think we should treat the theories of academia exactly the same way. God knows we've seen this happen in other fields-just look at the Gulf of Mexico. But at least that's a poison we can see with our eyes. Usually when academics poison industry with their impossible ideas, it goes completely unnoticed, and the world treats disasters as mysterious.

My industry is one of these. American programmers don't understand why nobody ever hires them. They complain about this on web pages like Reddit and Y Combinator, where they also discuss functional programming, monads, and web frameworks written in Ruby and Python. And nothing about this strikes them as ironic or hypocritical.

The good news (for me) is that programmers from other countries are actually serious about their work. All the Chinese and Indians we interview know that in the real world, we are worried about real computers that exist, with real hardware and real performance limitations.

Meanwhile, academic heavyweights like Mr. Don Stewart brag about the great things that they can do in Haskell, like write a display server called X Monad. Actually it's not a display server, it's a window decorator. Actually it's not written in Haskell, it's written in C, with a thousand lines of convoluted Haskell necessary to use the foreign function interface and call the C code that it's written in. Actually everything Mr. Stewart writes is like this. "Superior performance, safety, and ease of use?" So says Mr. Stewart, in the Haskell book that he's selling to all the people who think Haskell sounds like a good idea. Why yes, he's making money on this deal. Did he forget to mention that?

Overselling one's snake oil is hardly unique to Mr. Stewart. It's like the foundation of academia as a concept. The university itself is snake oil, and the whole community is a giant pyramid scheme for keeping afloat those who buy into it. I do mean "buy." The veil of learning and education is a front for the conspiracy of industrial sabotage, the vast plot to bring down all of society in order to "prove" that the bearded professors in their poorly ventilated hidey-holes were Right All Along. That's a self-fulfilling prophecy, by the way-a common ailment of mongoloids and schizophrenics.

>>102
Your toy academic languages which claim "being fast" compile to C.
No, they don't, well actually I don't know, since I don't consider Common Lisp academic, but out of like around 11 implementations that I've used, only one compiles to C, one compiles to bytecode which is interpreted or JITted, and the rest compile to native code(some support multiple backends, like bytecode too) and they have their own pure Lisp-written assemblers and compilers for various platforms. C is used by some of them to write some glue code for the runtime, gc and a code/data object loader (this is usually done for efficiency reasons as the alternative is either: 1) writing the nonportable routines in assembly or 2)making an efficient low-level lisp compiler (some implementations do this)).
They use s small subset of C features.
They actually allow a superset of C features. Many of which you wouldn't think of, unless you already learned those languages.
They don't allow the freedom of C.
I can actually do anything I can in C using a good Lisp implementations. Portably (FFI) or not (implementation specific APIs or VOPs(compiler's "opcodes", for example, you could do pointer operations with them easily).
They use much more resources and valuable processor time than plain C.
Maybe a cost of 2-3 times speed on average, unless I give many hints to the compiler, hints I have to explicitly specify in C(like the types of variables). The cost has never bothered me as whenever I see something being slow, I profile it, see an algorithmic error or whatever I did to make it slow, and fix it, sometimes yielding increases of speed of orders of magnitude, and usually at low costs and much ease of use.
However, I won't disagree here fully, they do take a lot more memory than tiny C applications that only use libc and usually link libc externally. If you don't count the runtime sizes, you can get pretty tiny executables. I don't really think it's that important when most ENTERPRISE languages eat much more and offer less. If you're willing to use a smaller subset, you can reduce the size by quite a bit (this may be useful if you want to embed it).
Their claimed "safety" is nothing compared to Ada or Pascal.
What. Now, you're just being ignorant here and don't know what you're talking about.
Please, a monkey can learn C, but using anything above 3 line fibs in Haskell requires a Phd in type theory and intimate knowledge of Simon  Peyton-Jones coding habits. About their "purity": the most pure language is brainfuck.
While I can't say much of Haskell, I don't find ML hard to use.
As for Lisps, they're much more easier than C. They're only hard to understand, if you've locked yourself into a pure imperative mindset, however if you have an open mind or a "beginner's mind", you should be able to understand them with ease.

In the end, I'm much more productive writing Lisp code than C code, mostly because I'm free to eliminate and kind of repetitive pattern in the code and make it as general as possible(for example I make up my own DSL's all the time. I can describe a complex problem with many variables in a simple DSL, which is then compiled to native code, or interpreted(if i feel lazy)), while still writing less code in less time than it would have taken me in C, not only that, but debugging is easy and doesn't involve me tracking elusive memory leaks, double free's, buffer overflows, random memory/heap corruptions, format string vulnerabilities, pointer alignment issues, and other errors in a low-level debugger. That's not to say I won't write C when I need to, because I will, just that I prefer using high-level tools for high-level tasks and low-level tools for low-level tasks.
Imagine it extended via macros, preserving the minimalism and fixed feature set.
The C preprocessor is terrible and it's the reason a lot of people misunderstand simple concepts as true macros.