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.

You can't handle the Truth:
Prolog, Haskell, Lisp are just dialects of brainfuck.

>>79
The truth being that you bump shit threads? We've known that since you did it the first n times.

>>81
MIND == BLOWN

Bump for Xarn.

Bump for FV

languages like Common Lisp, Scheme, ML can be quite practical

HAHAHAHAHAHAHAHAHAHAHAHAHA

Academic languages, of which i'll call one non-specific("Blub"), suffer from major fatal flaws.
They're built to satisfy abstract rules, not some practical needs.
In C you don't want libc? roll you own replacements, take another, interface foreign code.
In Blub you don't want standard library? Tough luck kid, its grown deep into runtime and coding your own is as easy as rewriting the whole thing. Its as bad as fighting Blubbery syntax.
In C you pick what your program does.
In Blub your compiler/interpreter picks "the right thing".
in C you can see what the program does.
In Blub your program is hidden beyond the veil of textual abstractions and runtime code.
In C errors are painful, and will straight crash your program.
In Blub each error is prevented, monitored, exceptioned, traced with such layers of code that make even buggy, leaking resource hogs manageable with sufficiently powerful hardware(Blub can scale!).
C considered dirty, messy and crash-prone.
Blub is the epitome of type-safety/scalability/productivity, though its evangelists omit the ugly truth that Blub is in fact written in C(or even bits of..gasp Assembler) and uses C runtimes and libraries as if it were pure Blubbery Blub.
Blub users always try to attract people to their language, extolling it virtues, features and ease of use. At first people believe them.
They buy into the idea, until some inconvenient fact uncovers the ugly truth about Blub. In that second look...people realize that Blubbery syntax isn't so ground-breaking or productive as it seemed at first look.. Performance lags behind.. Blub begins to look intimidating and demanding.. People grow up from the Blub phase and stand there about to leave, but some stay. They either invent their own Blub or go the C++ way and try to emulate Blubbery ways in constructs of monstrous-yet-low-level design.

>>87
Blub
U MENA JAVA

Anyway, in my own work, I want to use whatever tool allows me to get the most done with the least amount of effort. This almost always means a managed environment like .NET and C#. I like the idea of trying to make my algorithms beautiful, and have someone else optimize the details for me in the runtime. I have grown so attached to visual studio that I use windows on my macbook pro more than I use osx... I came to the somewhat painful decision to target windows only after many years of struggle. I love the idea of linux, I agree with the philosophy but it is just not ready... I think in 100 years from now we will look back on this period of time in much the same way that we now look at the industrial revolution and the creation of the printing press. People who are unable to realize ideas through technology will be considered illiterate.

>>89
Nothing will change. Nobody apart from hobbyists build cars. Moore's law has passed its course; 100 years from now it will still only be programmers who write software. Normal people will still just use computers to achieve a purpose, much like they use cars to travel places.
People will be able to realise ideas through technology without having to learn .NET and C# because others will write the software for them.

In C errors are painful, and will straight crash your program.
Oh, you have no idea how much I wish it was true, not FV quality.

>>89
I like the idea of trying to make my algorithms beautiful, and have someone else optimize the details for me in the runtime.
You still need to make your algorithms beautiful in C.  Having a giant framework under the hood doesn't really change that.  There's nothing about C that requires you to do micro-optimization, but at least you can if you so choose.

>>89
the industrial revolution and the printing press

Ahh, yes; LINUX is behind the times in the same way the printing press was during the industrial revolution.

>>92
>There's nothing about C that requires you to do micro-optimization, but at least you can if you so choose.
Thats the point missed in Academic Languages.
The major difference here isn't raw speed(academic language runtimes can be very optimized and streamlined), its way the language limits your options.
In C you can do any X feature even it required writing pages of code(->which can be optimized/refactored/improved later).
In Blub you can't do X, even if you wanted. The One True Way is to do Y. Y doesn't do what X does and cannot be further "optimized", but Blub programmers don't cringe, they change their program to accommodate Y. Some inventive Blub programmers replace X by writing and reading to raw memory to escape Blub clutches. They don't like that idea since it means they don't write "pure Blub" though. Pure Blub and X just don't mix.

ITT: bullshit.

>>95
How could you tell? Was it the 3 pages of posts, or the fact that FV is posting?

http://alarmingdevelopment.org/?p=392

esoteric programming language (often Lisp or Haskell)
Stopped reading right there.

>>97
I read that a while ago, probably posted on /prog/. The obvious conclusion was that the post was bad and the author should feel bad about himself, not much unlike this thread.

>>99
Protip: if an article mentions Paul Graham (especially in the context of Lisp), it is not worth reading.

Lisp- Its like someone decided that C macro preprocessor was not enough and wanted to write a program entirely in the preprocessor.
Haskell - Its some trying to make functions chained into one big macro executed at once. like printf(STRING,func(func762(func7(3))),func2(func9(func(7))))
Prolog - Not more advanced than a chain of IF/ELSE/ELSEIF blocks.

Your toy academic languages which claim "being fast" compile to C. They use s small subset of C features. They don't allow the freedom of C. They use much more resources and valuable processor time than plain C. Their claimed "safety" is nothing compared to Ada or Pascal. Ease of use? 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. Imagine it extended via macros, preserving the minimalism and fixed feature set.

>>102
Please learn to structure your arguments and ramble less.

>>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.

>>104
stop being trolled. If I've learnt one thing in the past few weeks, it's that the current breed of Ctards are just morons.

The true nature of Lisp:
http://www.defmacro.org/ramblings/lisp.html

Lisp is a way to escape mediocrity and to get ahead of the pack. Learning Lisp means you can get a better job today, because you can impress any reasonably intelligent interviewer with fresh insight into most aspects of software engineering. It also means you're likely to get fired tomorrow because everyone is tired of you constantly mentioning how much better the company could be doing if only its software was written in Lisp. Is it worth the effort? Everyone who has ever learned Lisp says yes. The choice, of course, remains yours.

This thread is a good demonstration of why /prog/ has been sucking lately. The idiots who don't know what they're talking about but are completely convinced they're right and /prog/ is just trolling when it comes to SICP, Lisp, and Haskell (and even C and Python) are shouting louder (or at least more frequently) than the people who used to make /prog/ great.
The earnest morons (it wouldn't be so bad if they were actually trolls, but they really believe what they're saying) are a bigger problem than the few imageboard 'tards could ever hope to be.

>>108
a different, equal manner of whining about a userbase one cannot change.

>>108
Your worldly experience shines through every letter of every word of every sentence you write (parenthetical or otherwise). Please, save us from ourselves!

>>110
Go home, elliott.

Wait..are there text editors written in Lisp? Not extended via Lisp macros, but really written in Lisp?

>>112
Fucking moron

>>106
From article:
The difference is that we don't have to extend Lisp in another language (although we can) ... Lisp comes with a very compact set of built in functions - the necessary minimum. The rest of the language is implemented as a standard library in Lisp itself.
If you could distill just this little bit of brilliance out of Lisp and add it to C, you might actually get somewhere.

>>108
He thinks SICP is serious.
LULZ.  Go home newfag.

>>114
Okay, done.

>>114
It's been tried how many times now? None of them go anywhere

>this little bit of brilliance out of Lisp
C already has a macro preprocessor

>>118
A really shit one

>>116-118
A combined 0/10.  [i]Flawless Victory![i]