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.
People use what you call 'academic languages' to do real world work. For some of them, it even takes less time and effort while still achieving good performance. I won't say anything about how true this is for Haskell, as I don't know it too well, but languages like Common Lisp, Scheme, ML can be quite practical when you know what you're doing, while still getting excellent performance. Real companies also use them, sometimes even for flagship products.
I don't live in the US, I live in a country like the ones you like to outsource work to. I don't like to waste my time writing redundant code.
I'm actually glad that he turns down the applicants for mentioning those languages, as it's better than companies who advertise asking for academic "types" and then when they hire them, they just have them write Java (the trick is to try to pick above average programmers then have them work with average languages which can be maintained by anyone).
>>12 The COBOL specification was created by Grace Hopper during the second half of 1959. The scene was set on April 8, 1959 at a meeting of computer manufacturers, users, and university people at the University of Pennsylvania Computing Center.
>>13
That does not in any way make it an academic language, particularly not in the sense the person quoted in >>1 was using it.
The argument in >>1 is almost incredibly poorly thought-out, and you're going to attack a straw man interpretation of ``academic''?
>>14
Javascript was heavily based on Scheme, and had a C-like syntax to please the masses.
Perl is just a syntactic soup, and PHP is its even more badly designed clone.
I'm not even sure what kind of company the person who wrote the original text works in, but I'm guessing it's something which writes a lot of C and asm, possibly something embedded, as in other parts of the industry (and outside the industry) programmer time is more valuable.
Real expert programmer here. I agree with the OP and his source. Academic languages can have their use in the real world, but it is generally quite insignificant. Often, functional languages are relegated to being used as a DSL or high-level scripting language to glue the rest of a system together, if used at all.
Even The Sussman has switched over to teaching Python rather than Scheme in his programming courses at MIT.
Most people who brag about how great they are in Common Lisp or Haskell or some other functional language, while downplaying the importance of say C, C++, Java, C#, etc. during a job interview generally will end up being a terrible programmer when it comes to programming in an imperative language.
I don't mind hiring people who mention functional languages in their portfolio or interview, but they had better place precedence on at least one or two common imperative languages and have the skills and experience to back up their claims.
>>23
Common Lisp isn't functional, but it supports the paradigm.
And most of us who mainly use other highlevel languages also know C and assembly and some other mainstream languages. We use the right tool for the job. If C makes something easier, I'll use C. If I need to write some unportable asm, I'll do it, but I usually won't do it, unless I really need the extra performance, or what I want to achieve isn't possible otherwise.
Even The Sussman has switched over to teaching Python rather than Scheme in his programming courses at MIT.
MIT switched, that doesn't mean Sussman fully supports it.
>>19 >>1 wasn't intended as a troll, I think, but just as a ``haha, let's all laugh at this moron'', which a lot of idiots missed. >>23, now, that's a legitimate troll.
>>23
Anyone who learned assembly, C, or C++ and didn't move on to a better language voluntarily should be dismissed immediately with extreme prejudice. It isn't that C doesn't have a place. Even shit has a place. But people don't generally hang out in sewers, even if we all need sewers, and we all shit.
Even The Sussman has switched over to teaching Python rather than Scheme in his programming courses at MIT.
The Sussman doesn't teach the new course. And he does still teach Scheme: His symbolic programming class used Scheme, and I believe the classical mechanics course did too.
>>28
While I'm at it, I'm pretty certain that GJS didn't teach the SICP course either (or at least not for a while)
Name:
Anonymous2010-07-16 18:35
>>23 here
Sadly, I'm not trolling. I have 14 years of industry experience in C, C++, x86 assembly. I have 10 years of experience in Java experience, 8 years in C# and Python, 7 years in ARM assembly language, and 4 years of Objective-C. And that's just your core general-purpose languages. I'm also fluent in Fortran, various SQL dialects, CUDA and I'm currently learning OpenCL.
I also know Scheme, S/ML, Ocaml, and few other declarative/functional and imperative languages to varying degrees of proficiency. But I've never once used them to write real software in the industry.
I've worked in the games industry, aerospace industry, financial industry, and more recently as systems-level programmer on small-form factor consumer devices.
I will reiterate my viewpoint, and that is if you consistently proselytize a declarative/functional language while simultaneously bemocking traditional imperative languages, chances are, you're not very good with languages used in the real world. And you probably have less experience at actually getting real work done.
>>31 But I've never once used them to write real software in the industry.
If you think that's even related to the point, you don't know those languages nearly as well as you think you do.
>>31
I program microcontrollers in C and assembly for embedded systems. It's fucking garbage, but it's the only realistic choice. When I write automated testing programs for these systems, it's Scheme. What I can accomplish in two pages of Scheme is several orders of magnitude more than I can accomplish in C or C++ in the same amount of space and time, is safe, works right the first time (most of the time), and is easily extended.
You've mucked about in all that shit for over 10 years and you still haven't found a place for a decent language? My god. My god.
Name:
Anonymous2010-07-16 18:50
>>34
So let me get this straight. You're implying that knowing Lisp/Scheme/etc. is really more about seeking acceptance in the functional circle-jerk on various online text boards, forums, and other communities?
>>36
Don't think he was implying that.
I don't give a damn about what people in other circles think.
I just use Lisp for general purpose programming because it saves me a lot of time.
>>2,3,4,9,17,18 et al.
Holy shit. /prog/ is ridden with these idiots and faggots of the ``academic'' Haskell/Scheme/(insert new trend here) circlejerk.
>>40
There's a few embedded lisps around. I rarely had to use them myself, and usually just write C when I need C (low-level tasks). I'd probably consider an embedded lisp if I had massive amounts of C to write.
>>47 uninterestingly, if you google for "neckbeard scheme", a /prog/ thread from 08 is the only result
Name:
Anonymous2010-07-16 21:06
>>48
And if you navigate to that discussion on /prog/, you'll see it's also a response to a post mentioning Armpit. Interesting how history repeats itself.
>>47 Following this trend
No, that does not trend with ``Armpit'' in any clever sense.
Name:
Anonymous2010-07-16 23:01
>>50
someone should post this fucker on hacker news and proggit
here its the bees knees
there it would eat the bees and use its godlike soul funk strength to fight god and break his kneecaps, which would really sting
Name:
Anonymous2010-07-17 19:35
accademic languages
I don't understand what you mean by this?
Whether langauges were the result of a thesis or of an R&D team in some corporation wouldn't they still try to reach maximum performance and usabiltity?
Or are you referring to those languages that in your opinion are shit and therefore inappropiate for anything else but boasting and hipster faggorty?
Also as a newbie to the who field, how am I to know about all this? And who am I to listen too?
>>53 I don't understand what you mean by this?
I don't understand why people abuse question marks like this. Not being a native speaker is no excuse; there is no language in which this is acceptable.
>>56,58
You were unable to figure out what was wrong with the quoted line. Your grammar isn't even good enough to construct a decent grammar troll. Congratulations.
>>59
The quoted line was about misusing the question mark in a sentence that looks like a question but in reality it is either one level higher (``I don't understand what you mean by this?'') or is a question only in its form and not its function (``Could you please get over it?''). And >>56 is a cretin.
>>64
You're an idiot. The quoted line was a simple declarative sentence, and there was no reason for the question mark to be there. >>58 was a rhetorical question, but a question nonetheless, and the question mark was justified there; your nonsense about being ``one level higher'' is just confused blather. >>56 is a cretin, but so is >>58, and so are you.
>>71
Note the ``usually'' and the caveat that it really only applies to very long requests.
Of course, it would also be a good idea to note the centuries of usage the good people at Capital Community College in the United States of America are ignoring by suggesting it's can be alright to leave out the question mark occasionally, but that's really neither here nor there.
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.
Wow the OP must have felt pretty bad about hiring shitty outsourced programmers to save money.
Don't worry OP, it'll blow up in your face soon enough.
Also fyi, what we program on in our spare time is none of your business.
Name:
Anonymous2011-06-30 20:24
>>169
OP here. It's not made up, but I admit I plagiarized it from another source. It was posted on someone's serious blog a while back. I forget the source. If I recall correctly, I found it amusing and realized it would be good shit storm material for /prog/, hence the reason I created this thread.
Name:
Anonymous2011-06-30 23:34
>>106
>LISP is attempt at executable XML with less syntax.
Name:
Anonymous2011-06-30 23:55
>>183
yes, you've grasped the essence of it
what you don't understand are the implications.
Name:
Anonymous2011-07-01 0:34
>>184
Unreadable semantic soup which executes at runtime?
Name:
Anonymous2011-07-01 2:54
>>182
What's sad is that this was posted in a SERIOUS blog.
Then again, you mentioned it's an objectivist blog, that explains a lot.