Lisp is going to die

It's too good for its own good.
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

>>39
CLOS is The Right Thing in relation to OOP. Most Lispers just don't care about OOP or even hate it:
It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis
The purpose of OOP is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques. -- Paul Graham

>>41
There are also prototype based systems (without metaclasses), but they are just different.

>>41
I like prototypes and Smalltalk-like systems more. What about them?

Of course, I've got Prometheus and ClosureTalk, but it's a beginner's exercise to write its own message-passing OO system.

>>43
Support an existing implementation, you want to be a standard. Integrate it into some Lisp implementaion, make it look like it's default.

>>45
But I don't need them, and all the Scheme implementations out there already ship a de facto standard OOP system. Chicken has COOPS (CLOS-like), Guile has GOOPS (CLOS-like), Racket has its class system, etc. All of them have Prometheus (prototypes) in some third party library. I don't need one of them in the standard, that's not the point of Scheme. OOP is not even idiomatic Scheme, they are only nice to have in certain situations, with certain code that is handled better with OOP than FP.
The only thing I really want I saw and immediately want in the standard was foof-loop, the best general looping construct I've seen so far. It is clean, extensible, handles really well the general cases, and it's portable between R5RS-compliant implementations. And it will likely be in Big R7RS, so I have no regrets.

When you write idiomatic Lisp/Scheme code, reinventing the wheel, you probably end up with something similiar to something else, already implemented, and you just end using that instead. Meanwhile, you've learned something new by reimplementing it.

>>46
s/I really want//

>>46
But what happens when it's time to put it into play? No one can decide! Your post just listed a whole shitload of redundant projects; perfect proof of the original point. Lispers can't agree on anything.

>>46
But I don't need them
What do you need?

and all the Scheme implementations out there already ship a de facto standard OOP system. Chicken has COOPS (CLOS-like), Guile has GOOPS (CLOS-like), Racket has its class system, etc.
Try replacing them with a single unifying system. Like CFFI for CL.

>>46
certain code that is handled better with OOP than FP.
Can you provide an example, where OOP is better than FP?

>>50
Interoperability between programs.

>>48
The world is made of people with different opinions on everything. Wars happen, but we still manage to survive somehow. It's the survival of the fittest, in the end there will be one or zero predominant OOP system for Scheme (just like with CL and CLOS), depending on the needs and preferences of most of the Schemers. And, just like I said before, most implementations have their de facto standard OOP system: you can't write real world Racket code using its GUI library disregarding its class system, since it is built on top of it. But you don't have to use it everyday for everything, no one forces it down your throat, you can use whatever approach you feel will better solve your problem.

>>50
Go fuck yourself.
>>51
You too.

>>51
Use packages.

>>52
OOP system: you can't write real world Racket code using its GUI library disregarding its class system, since it is built on top of it.
You can have a GUI framework without OOP. HTML, you're viewing now, is an example of such GUI.

news flash: /prog/ lisp advocates are just as stupid as everyone else

>>55
You're either retarded or you can't comprehend English.

>>57
It would be a great accomplishment of artificial intelligence programming if it were possible to form a sentence like "You can have a GUI framework without OOP" and not know what it means.

I'll go with "Retarded" for $500, Alex.

>>58
You still can't read, I was talking of Racket's class system and Racket's GUI framework, which (Racket's GUI framework) is written with its (Racket's) class system, is my English ambiguous or something? Where did I say ``they can only be written with OOP''?

I'll go with "Retarded" for $500, Alex.
That's not my name, but I'm glad you're accepting reality.

>>59
That's not my name,
Then why did you respond to him?

>>57
Nope. The problem is in you: stop complaining and write a GUI library without OOP. Nothing stops you.

>>61
>>59

>>62

Oh, ok.

>>63
>>203

I'm not going to bother reading it. Nothing is dead as long as it's developed. Any Lisp worth its salt is being actively maintained, and as long as people care about it, something of this sort cannot die.

>>6
I guess I'll switch my major from CS to Engineering. ;_;

>>65
The article wasn't about dying, that's a trollish distortion by the OP. It was about Lisp being stuck because of the lack of cooperation. Jeez, you guys.

>>67
I read it now. I can say I mostly agree with what the author has to say, but there is a solution to this. It's called writing a standard document and implementing it. This is how you have many standard-compliant Common Lisp implementation, a lot of R5RS and quite a few R6RS compatible Schemes. From those CL implementations, most have their MOP support (which is again defined in a standard) and gray streams (which is defined in a separate standard). As long as you're willing to define a well-thought-out interface, people will implement it (however, having a refrence implementation would be very nice as well).

>>68
Absolutely—but watch this video, especially the ending: http://www.youtube.com/watch?v=pQHX-SjgQvQ

How are you going to get people together to write the standard document? How are you going to get them to agree? That's the problem!

>>69
They someone managed to do it for ANSI CL, MOP, Gray Streams, CLIM, way too many to count LispM documents, R*RS Schemes, Scheme's countless SRFIs and various others. If anything, a single person can suffice, but it's been shown that community-driven processes also work, they just take much longer.