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.
languages like Common Lisp, Scheme, ML can be quite practical
HAHAHAHAHAHAHAHAHAHAHAHAHA
Name:
FrozenVoid2010-07-23 13:21
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.
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.
Name:
Anonymous2010-07-23 18:39
>>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.
Name:
FrozenVoid2010-07-24 7:03
>>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.
>>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.
Name:
Anonymous2010-07-25 11:10
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.
Name:
Anonymous2010-07-25 11:43
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 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.
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
Your worldly experience shines through every letter of every word of every sentence you write (parenthetical or otherwise). Please, save us from ourselves!
>>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.
>>116-118
A combined 0/10. [i]Flawless Victory![i]
Name:
Anonymous2010-07-25 17:02
There is a subtle flaw in macro preprocessor.
It doesn't handle regular expressions. If this could be added as extension it would be as powerful as LISP(and half as powerful as JavaScript).
Let's add a pre-pre-processor to C. It would be easy to do, would break no existing standards, and doesn't even require changing any existing compilers.
>>121 If [regular expressions] could be added [to the C preprocessor] it would be as powerful as LISP
wat
Name:
Anonymous2010-07-26 0:30
>>126
Imagine, one #include with regexps
and your Lisp source is now translated to brainfuck or haskell.
Or ascii art inserted all over the place. Or it compiles the .c files into raw machine code chunks purely through text->\x32\x23 replacement.
>>127
It'd be very easy to imagine, if s-expressions were a regular language, which they are not.
Name:
Anonymous2010-07-26 2:32
>>124-128
Having some sort of inline, embedded scripting language added to C that is processed at compile time would be powerful. But it would be messy. It would not do much to improve maintainability or readability of code. Something more elegant is needed.
You can compile Blub to C, but you can't compile C to Blub.
If Blub can reach C speed, C can replicate the code and leapfrog away.
C is about algorithms you can optimize, Blub is about algorithms you can purify.
Blub follows the rules, C follows the needs.
Blub manages memory, C uses it.
Understanding a random line of Blub is hard, C can be understood immediately.
Elegance of Blub is elegance of pretty text, elegance of C is state-of-art performance.
>>137
As a reponse to FV, I admit IHBT, so: You can compile Blub to C, but you can't compile C to Blub.
You can compile C to other languages other than ASM just fine, even highlevel languages. Sometimes the underlying architecture is better suited for less C-ish languages. If C is fast, it's only because C maps close the the platform's assembly, which is the case for x86. If Blub can reach C speed, C can replicate the code and leapfrog away.
See previous reponse. Understanding a random line of Blub is hard, C can be understood immediately.
Subjective. Understanding code written any language completly depends on how well you know it and on the language's own syntax, semantics and overall design. I'd say lots of highlevel languages are even easier to understand than C. You can write obfuscated code in any language.
>139
Yes, it doesn't apply to Lisp (there are C->Lisp compilers, and a good Lisp compiler can approach C speeds, also Lisp is easily understandable, if you took the time to study it, just like C), however one can't deny that Lisp is traditionally garbage collected (and that's perfectly fine).
Name:
Anonymous2010-07-27 13:28
>>138 Sometimes the underlying architecture is better suited for less C-ish languages. If C is fast, it's only because C maps close the the platform's assembly, which is the case for x86.
I think this is the case for just about any modern CPU. This is really the primary argument for C. It's thin and therefore efficient and nicely debuggable.
If Blub can reach C speed, C can replicate the code and leapfrog away.
What is this supposed to mean? If you had some high-level, elegant language and it performed as well or better than C in all practical, real world cases, then there would be no need to "replicate the code" in C...
>>142 Effect, meet cause.
I'm glad that's not completely true. It dominates though... you get more experimentation in non "CPU" PUs.
Still, C still doesn't seem to know eg. SIMD very well.
Name:
Anonymous2010-07-27 17:00
>>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.
Ever heard of emacs?
Name:
Anonymous2010-07-27 17:01
Still, C still doesn't seem to know eg. SIMD very well.
ISO C doesn't, but GNU C does.
Cool story bro. I'm still in University and still can't give two flying fucks about functional programming.... but I have to question why their intro to programming courses are in Ada.
Name:
Anonymous2011-06-30 5:20
TL;DR
OP probably majored in english and has nothing to do with programming.
Name:
Brain2011-06-30 7:31
>Now the drooling lab rats have escaped from the lab.
To take over the World.
:GJS1M 67dcbdbce4a0b67c4b48e86a6ae29205a95e4b83024a9d947213d1231800e8d9
:67 b53dc481eb3147a140f3535b49e3d382
:1279308622 1309433484 >>121 <-- that's cool and all, but check 'em
Name:
Brain2011-06-30 7:32
>>166
Shutup, Pinky and get into the cardboard car.
Name:
Anonymous2011-06-30 11:53
after learning smalltalk, lisp, and haskell, I got so much better at C/C++/Java that I forgot for a few weeks why I hated them after going back.
For instance, I'm way more productive at C# than most others, and it's due to the fact that I use delegates wisely. I do this because of my experience in Scheme.
And I'm better at statically typed languages because I don't use the type checker as a crutch and I write more test cases.
I don't think it's really possible to get WORSE at a low level language by exploring high level languages.
Name:
Anonymous2011-06-30 11:54
pretty sure OP's post is made up. google doesn't respond to it. Anyone have a cached page of it?
>>168 I don't think it's really possible to get WORSE at a low level language by exploring high level languages.
Sure, you can't become worse at programming than you already are, buddy.
>>172 Ad hominem is a fallacy only if instead of attacking the presented argument one points at an unrelated deficiency of the person making the argument.
For example, "Your opinions about lithp are invalid because you gobble members" would be an ad hominem.
If however a colour-blind person makes a statement regarding a certain quality of photographic apparatus, it would be absolutely correct to point out that the person is question is, in fact, colour-blind.
Similarly, when a person takes the fact that he haven't become worse at programming after being exposed to Lithp, Chitchat, and Haskal, and claims that this must be a universal rule, it's worth pointing out another possibility: that he is already so bad that nothing short of a brick to the face could make him worse at programming (and even that's debatable). It's a perfectly cromulent argument that has nothing to do with the fallacy of ad hominem.