Hacker News new | comments | show | ask | jobs | submit login

I'm still tickled by the fact that object oriented programming in elisp is just part of a standard library you can import.



This is why I think some Lisp (probably Scheme rather than elisp :P) is a great introductory language: very little is magical or built into the language itself. So you learn about things like OOP as patterns rather than as the one and only way to do stuff (cough Java cough).


That's the approach that SICP takes, and it works really well. Among other things, they show you how to make a basic object system.

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html


And that's great. It's not so much fun for a working programmer though. You don't want to have to implement an object system over and over again, you want to use one to write code.


scheme is great for learning, but as I am trying to make clear with this series of posts on Elisp, there's no other Lisp that's as practical as Elisp, just because of the huge amount of code there is available. It's a fantastic learning resource that people should leverage.

Scheme is still a bit stuck in the multiple-implementations-none-of-which-fully-implement-exactly-what-you-want type stage.

EmacsLisp is like Ruby, but better. One implementation (basically all the others are gone) and lots of people hacking on it and making it better.

The ways it differs from Ruby are that it's a proper Lisp (macros and homoiconicity) and that all the development and debugging tools are built in. Edebug is a fantastic tool for example.


for me it's the casual way to import prolog that does it


> object oriented programming in elisp is just part of a standard library you can import.

This is how OO is done in Common Lisp (CLOS is the standard here) and Scheme (no standard object system, but every so often someone writes one for themselves).


My (perhaps limited) understanding is that in CL everything, including integers and similar basic types, is an object - nothing has to be boxed or unboxed, nor does one necessarily need to instantiate objects in order to use them. That's not to say that there are not objects similar to those of Blub made available through CLOS, only that as is typical, Lisp muddies the waters when using terms like "object oriented." $$

$$ Reading Let Over Lambda is what done it to me.


No, I don't think so. Behind the slightly odd syntax CLOS is a very traditional OOP system. In my example in the article there's even type checking in the method:

(defmethod some-user-greeting ((user some-userc) &optional daytime) ....)

means that the argument 'user' to the method MUST be an object of class 'some-userc'.

EmacsLisp's CLOS doesn't have as much type checking as CL's but it is there.


> in CL everything, including integers and similar basic types, is an object - nothing has to be boxed or unboxed, nor does one necessarily need to instantiate objects in order to use them.

This is what CL people say, certainly; what you think of this statement (true? useful? a bad definition of 'object'?) depends entirely on what you think an 'object' is.

If you're a Smalltalker (or a Java programmer, or a C++ programmer, or a user of any language that got its object system from Smalltalk), then an object is something that can respond to messages. CLOS doesn't work like this: There are no messages, and expressions don't contain objects privileged to be the recipient of the message being used; therefore, a Smalltalker might well say that while CLOS has inheritance and polymorphism, it doesn't have objects as such.

(And, off in the corner, some C programmers are insisting that an int is a perfectly good object.)


I think that argument is nonsensical (it's covered well on the CL wiki btw - http://c2.com/cgi/wiki?HowObjectOrientedIsClos ). CLOS clearly has messages (which are implemented with methods).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: