Lisp

The real problem with Lisp is that it was designed without any consideration of the cognitive load experienced by the programmer.  The syntax may be simple, but the semantics are extremely complex and hard to master.  This is completely at odds with needs of the programmer. 

The main cognitive load is in developing a solution to the real world problem.  The programmer is engaged in reflective cognition.  Basic UI principles dictate that, when designing tools to aid in reflective cognition, they must as intellectually shallow as possible.  The less cognition required to operate them, the more is available for completing the required task.

Lisp was unintentionally designed for experiential cognition.  It contains many artifacts, each with a very deep and rich set of semantics.  All cognition must be devoted to its operation.  It is no surprise that it only attracts programmers who are only interested in using it for its own sake.

I find it pretty easy to write Lisp, maybe you don't know it too well? It may be harder the first week when one is learning it, but it comes as natural as most other languages after that. I can't say the same about Haskell, but I don't know Haskell nearly as well.

Alright, I've officially had it with this.

First, of all what is the Big Fucking Deal with Common Lisp? I started using various Lisps in highschool. Yes, CL is a very nice language. It is not that goddamned hard to learn.  Even if >>1 is trolling, I still don't get this myth that programming in Lisp is some mythical skill only attainable to the Gods of programming. It's just a nice language that's fun to use.

And before all of the 25-year-old neckbeards come to jerk off about how great Lisp is: Lisp is not a panacea. You are a shitty coder in every language, and skimming through SICP and Practical Common Lisp does not make you more enlightened than someone who uses Java to pay the bills.

I wish everyone would close their ignorant fucking mouths about the 'philosophy' of CL. It's been around forever, there isn't a whole lot left to be said about it, and superficial understanding is not a ticket for your to shoot off your shit cannon.

>>2

In my experience, CL is expressive and fluid. Haskell feels terrible and arbitrarily complicated. It offends me when the language designers think so little of me that they have to constrain what I'm able to do because "they know what's best." Fuck that.

I gave up on both, and now I'm looking at OCaml, mainly because it's fast (Python is too fucking slow, Haskell has those fun space leaks (lazy evaluation is, in my opinion, a stupid novelty), and figuring out exactly how to optimize a CL program is like nailing jelly to a tree). It saves me from writing C all of the time, I guess.

>>1
but the semantics are extremely complex and hard to master.
In (f . a), f is a function, it is evaluated, a is a list of arguments, they are evaluated and applied to f.
(lambda arg-list . body) makes a procedure.
Everything else can be built on top of that.

Shit that was so difficult!

>>3
There's no perfection, CL has flaws, Scheme(s) has(have) flaws, OCaml does too.
The deal with Lisp is parentheses: macros, structural editing, no ``wasn't there some magic syntax to do that?''

>>3
It saves me from writing C all of the time, I guess.

orly?

Why refer to speed and the ability to output efficient machine code as a language feature? That is mostly implementation dependent and any language could be extended to include these features.

>>1
I use SLIME thread over.

>>5
Brain damage from C exposure.

>>4

There's no perfection, CL has flaws, Scheme(s) has(have) flaws, OCaml does too.

Were you trying to patronize me in a grandfatherly way, or are you so retarded that this was the only thing you could reply with? Yes, I know no language is perfect. I chose one language because it worked for me.

The deal with Lisp is parentheses: macros, structural editing, no ``wasn't there some magic syntax to do that?''

God, people are such pussies.

>>5

orly?

Yes, that is in fact what I typed. Congratulations on being able to read, cunt.

Why refer to speed and the ability to output efficient machine code as a language feature?

First of all, implementations are what you use to run code, unless you're content with tapping out code in emacs and not using it (since you probably don't write code, I can understand why this wouldn't seem like much of an issue to you). In the Real World ^(tm), the implementation can cripple the use of an otherwise-wonderful language (the fragmentation of Lisp (especially in the past) serves as a great example - dozens of implementations (because implementing a language is simple, LOL), none of which are complete, sane or even useful). Before you post a raging response saying that I didn't understand what you're saying, yes, I get the distinction between "specified language" and "implementation." I don't really fucking care, for the reasons I specified above and below.

This leads me to my next point: you are an idiot. I know we've all been raised in this bubble where kind-a sort-a language execution speed doesn't matter so just write your code in Ruby OMG MOORE'S LAW LOOOOOOOOOL, but it just isn't true. Some languages are poorly-implemented and slow, some aren't. None are perfect, but some are better than others. Sometimes, performance does fucking matter, and that's enough of a reason to pick a language with a decent implementation.

That is mostly implementation dependent and any language could be extended to include these features.

Your use of "implementation dependent" in a manner that implies triviality shows either that you have no fucking clue what you're talking about, or that you're a wizard interpreter/compiler designer. I have a comfortable guess as to which category you fall under.

Look, since you're obviously some slow kid who reads Wikipedia and masturbates himself with sterile, academic explanations of things, I'll spell it out for you: implementing a rich, well-designed language in a way that leads to fast code is a very complex engineering effort. Doing this on a whim is very likely to fail. Read more books, write some more code and pull your head out of your ass before posting again, especially if you're going to be snarky. I guess I'll stop making fun of you, because anyone who gets their rocks off pretending to know what they're talking about on a shitty 4chan board is probably a very sad, frail person.

>>7

The "performance doesn't matter" meme, while certainly true sometimes, is mostly a lame cop out used by people who use high-level languages that are slow to justify the incompetence of the person implementing the language, as well as their own incompetence.

>>10
Perfomance matters only when CPU time is more precious than your own.

It's better to spend 1 minute writing program that executes 8 hours, than spending 8 hours writing program that executes 1 minute.

>>5
>>11

better go back to your ruby.

I was gonna write something that was exactly the opposite:

programmers should be immune to "usability." "Don't make me think" is for non-programmers. Period.

with more powerful semantics you are able to improve programmer performance. Maybe not by orders of magnitude, but programmer performance is the bottleneck (economically) so I'll take what I can get.

Lisp is not intellectual masturbation. C++ design patterns are.

People use swear by Lisp because they'd rather be bound by their environment than have to come to terms with being bound by their imagination. That's why they're content to jerk off to SICP and rehash decades-old algorithms in a language that can't accommodate real-world applications or solve any modern problems while insisting that both are irrelevant. Creative hackers pick the right tool for the job and do it, and guess what: they don't do it in Lisp.

>>3
I'm looking at OCaml
static typing + OOP.
same C++, but requires PhD to master.

>>4
In (f . a), f is a function, it is evaluated, a is a list of arguments, they are evaluated and applied to f.

(print . "hello")
*** - EVAL: argument list given to PRINT is dotted: (PRINT . "hello")
The following restarts are available:
ABORT          :R1      Abort main loop

>>10
``Languages'' are not performant, fast, whatever, implementations are. Saying ``language A faster than B that is as fast as C'' is meaningless. Even if the language standard library mandates Bogosort as sorting algorithm, it doesn't make the language should. Or, would you say ``Chinese is faster than English because it's more compact and fits better in the brain's L1 cache''?
Maybe you forgot what programming languages are about: abstraction, automatization. Helping the programmer to abstract things away, to help him concentrate only on the problem at hand without having to think of memory (de|a)llocation, pointers, which instruction would be the faster, which instruction encoding would be the smaller. Helping the programmer to automatize the process of writing code such that you'll never need to write the same code twice.
Leave optimizations to the compiler, they exist to automatize and abstract the processes of optimization and translating higher-level languages to assembly. The best you can do is to choose a better algorithm.

>>16
a is a list of arguments,
(cons 'print (list "hello")) ; => (print "hello")
(cons 'f (list 1 2 3)) ; => '(f 1 2 3)

>>16
He said that a is a list. You passed a string. (print . ("hello")) would have worked, or even (print . ("hello" . ())). Either way, that's a pretty stupid way to explain a function call, given that it ignores the most basic primitive abstraction of the language, but I think the faggot who did it just wanted to show off how much he thinks he knows.

>>19
Nope, I just thought it was idiotproof and clearer than (f a ...). I was wrong.

>>18,19,20
Yeah, got it.  Didn't read closely enough.  (Still not used to thinking in Lisp terms)

>>9
You could be proud of yourself if your post didn't consist of an insult. You seem to have got the point.

No need to write a compiler there are plenty implementations to choose from for almost any language, some of which are fast.

>>17

You are a goddamned moron.

Maybe you forgot what programming languages are about: abstraction, automatization.

No I didn't, but thanks for your concern, faggot.

Leave optimizations to the compiler, they exist to automatize and abstract the processes of optimization and translating higher-level languages to assembly. The best you can do is to choose a better algorithm.


Sometimes, you have to do something that can't be optimized be a better time complexity, which is what I was talking about, which is WHY I WORRY ABOUT PERFORMANCE. Why is this so hard for you to understand, dipshit?

Anyway, I see no point in responding to anything else you posted, because it's obvious you'd just rather quote lofty generalizations to sound smart rather than understand the point being made. Please go fuck yourself.

>>15

You have no idea what you're talking about.

>>22

You could be proud of yourself if your post didn't consist of an insult. You seem to have got the point.

I think you don't understand my point. But thanks for the ethical commentary, loser.

No need to write a compiler there are plenty implementations to choose from for almost any language, some of which are fast.

Not really. Lots of languages have implementations that are only slow and shitty.

>>14
People use swear by Lisp because they'd rather be bound by their environment than have to come to terms with being bound by their imagination.

You are talking about Scheme. The opposite is true of Common Lisp.

the only unpractical thing about Lisp is that it's hard to find people who are willing to help you with it in real life (as opposed to on IRC.)

Using Lisp means you are OK with working alone, basically.

But high level languages let you skip the bullshit. Yes there are lots of times since becoming a high level programmer that I hit an imagination "writers block." But back when I wrote C++, I would have filled this time with reinventing Lisp/Smalltalk, or else by inventing something that solves an incredibly stupid C++-specific problem. (as if there's any other kind.)

Java isn't much better. When I think of intellectual masturbation, i think of this: http://harmful.cat-v.org/Blog/2009/08/05/0-java-factory/

I don't think of Lisp. The features that Lisp provides me prevent me from writing public class StubFactoryFactoryProxyImpl extends StubFactoryFactoryDynamicBase. I get right to fucking work on the real problem, instead of dicking around.

Fucking lisp fags, shitting up my board.

>>26
I don't think of Lisp. The features that Lisp provides me prevent me from writing public class StubFactoryFactoryProxyImpl extends StubFactoryFactoryDynamicBase. I get right to fucking work on the real problem, instead of dicking around.
Sure, get rid of the logical bloat and replace it with a shitload of parentheses instead. Fucking brilliant.

>>26,28
I get right to fucking work on the real problem, instead of dicking around.
What kinds of work can you actually do in LISP tho?

>>25
Instead of telling me how pathetic I am you could bring up some examples on which languages are slow period.

I'll start: Psyco

>>26
public class StubFactoryFactoryProxyImpl extends StubFactoryFactoryDynamicBase
This is why I hate the Set Theory and these Subset extends Set abstract relations.

inb4 dubzbot

^{:GJS1M 67dcbdbce4a0b67c4b48e86a6ae29205a95e4b83024a9d947213d1231800e8d9
:65 f12cf91af71327cde1a5bf2d93e57eba
:1309311965 1309380969}
>>4
<-- that's cool and all, but check 'em

>>29
Why did you quote me (>>28)?

>>31
Get the fuck out.

>>34
I don't take orders from jewish maggots.

OMG MOORE'S LAW LOOOOOOOOOL

@34 Because. #statingtheobvious

>>39
Get out.

>>38
I don't take orders from Jewish maggots.

>>29
uh, basically anything that isn't OMG ALL INSTRUCTIONS MUST BE OPTIMIZED (like a physics engine.) It's a programming language, remember?

unless what you mean is "who would hire you to write Lisp?"

that is a good question. pointy-hairs are morons though. Who needs an employer anyway?

>>40
No I mean what kinds of practical applications? Could I write an HTTP request handler or something like that?

>>30

Instead of telling me how pathetic I am you could bring up some examples on which languages are slow period.

Who cares? I could sit here and name shitty languages which, while 'theoretically' being able to have a decent implementation, in fact don't: Python (Psyco is shit, and so are all of those other useless little things you can do that make Python 'fast'; the only way to make Python fast most of the time (yes, after you've optimized your algorithms) is to drop down to C and deal with the gross kludge that is the Python API), Ruby ('fast Ruby implementation' is almost an oxymoron at this point, probably because anyone with half a brain would just use Lisp anyway, thus leaving only idiots to work on Ruby), Perl.

But really, who cares? What does it matter? What point is it proving? You all keep reminding me that a faster implementation 'could' exist, but the fact is that it doesn't, and it's years upon years of work to make one that is even remotely decent. SBCL has been around for over 10 years (longer than that if you count all the work that went into it in the form of CMUCL) and it still can be weird when trying to optimize a program.

All of this useless, unproductive pedantry is why I stopped caring about programming the first place. Fuck it.

>>41

(>>42 and all of the other ranting messages here)

In Common Lisp? Sure. Please don't mistake my rantings against CL and everyone else on this board as evidence that CL is entirely useless. To answer your question more specifically,

No I mean what kinds of practical applications? Could I write an HTTP request handler or something like that?

It'd be fairly easy, if you're familiar with basic network programming. Check out http://common-lisp.net/project/usocket/ if you're serious. It's a lot of fun to load up usocket (using something like Quicklisp) in SLIME and just play with the library.

If you were expecting something above socket level, I'm afraid I can't say for sure that there's anything you might be interested in. You could check http://www.cliki.net/networking , however, most of those libraries are probably the usual CL pieces of shit that don't work.

^{:GJS1M 67dcbdbce4a0b67c4b48e86a6ae29205a95e4b83024a9d947213d1231800e8d9
:46 96896158ba24cb43aac2b31d540d9612
:1309311965 1309389464}
>>35
<-- check 'em dubz

>>43
the reason you tend not to see a lot of libraries in CL that aren't really primitive is that making your own layers of abstraction in CL is not hard at all. It's not worth publishing.

>>45
No, it's because it's a toy language used by man-children that don't have any real work to do.

>>45
HA! YOU'VE BEEN PWONED, B[u]^IA_TC^H FEAR THE ANGER OF A EXPERT PROGRAMMER

>>45

You should totally read what I wrote again. I was bitching about all of the shitty libraries people do release and clog up CLiki with.

For the record, I am fully aware that writing complex things in CL is easy. If >>41 got really carried away, he could probably end up writing a full-featured HTTP server in Common Lisp very easily.

It really is the best language when you want to build something complex, but sadly each community is full of a bunch of religious idiots who smother it. We need an updated, cleaner version of CL (a more flexible type system, remove unnecessary cruft from the language that's still hanging around 'just because'), and leave as little flexibility in the standard as possible to encourage only one major implementation. And yes, it would be worth the years of work on a new compiler.

"If someone set off a bomb in this room, it would wipe out half of the worldwide Lisp community. That might not be a bad thing for Lisp, because it would have to be reinvented."

--John McCarthy

>>47
fail