I did what any sensible Lisp hacker does: I wrote my own object system(mikelevins.livejournal.com)
mikelevins.livejournal.com
I did what any sensible Lisp hacker does: I wrote my own object system
http://mikelevins.livejournal.com/3678.html
4 comments
I wouldn't mind seeing the author's code. I decided to use Clojure for a project, and while it has generally been a good experience, I do miss the ability to strategically apply CLOS in places.
I'll be ecstatic if it is well done; I'd love for Clojure to be multi-paradigm (even if the object system was a bolted-on one).
It's an article about how representation, behavior, and taxonomy are distinct concepts that can be handled separately, despite the fact that object-oriented languages tend to confuse them.
I don't think "confuse" is the right word. A class-based object system is not an affirmation that behavior and taxonomy are the same thing, just as a hammer is not an affirmation against the existence of screws.
I don't think "confuse" is the right word. A class-based object system is not an affirmation that behavior and taxonomy are the same thing, just as a hammer is not an affirmation against the existence of screws.
exactly why i don't like Lisp: every Lisp hacker makes his own object or whatever system, making it hard for other people to understand his work.
Did you actually read the article? Beyond the fact that the aforementioned line is obviously tongue-in-cheek, the author has seemingly implemented an extremely powerful new object system that isn't anything like a rehash of what was there before.
In a truly powerful language you're not straining against your bonds to get profoundly cool things to work. Sure, sometimes that means code evolves into something even a mother couldn't love. But that fact in no way establishes a basis for arguing that somehow languages should be more restrictive to protect people from bad habits.
Bad coding is a universal solvent: you can't make your language into a bottle to hold it.
In a truly powerful language you're not straining against your bonds to get profoundly cool things to work. Sure, sometimes that means code evolves into something even a mother couldn't love. But that fact in no way establishes a basis for arguing that somehow languages should be more restrictive to protect people from bad habits.
Bad coding is a universal solvent: you can't make your language into a bottle to hold it.
Writing unmaintainable crap is really the fault of the programmer, not the language, isn't it? You can write unmaintainable stuff in any language and I think Lisp is particularly good at helping the developer keeping the code clean and easily readable (despite it being very powerful so it's easy to do very stupid things, I must admit that.)
It's easy to do very stupid things, which at the time seem brilliant, and you don't realize they're stupid until they're so intertwined with the rest of the project that they're harder to fix than to just deal with.
Good point. But you can't reach the simplifying insight by any other road than your own initial stupidity. It's the way you learn Lisp. At least Lisp breaks you with grace -- quick and painful. Most other languages spare you the pain of insight.
And I'm consistently surprised by how easy it is to root out my stupidities once I've recognized them, thanks to the repl, a functional style and a small code base. Lisp teaches you to face your fears.
And I'm consistently surprised by how easy it is to root out my stupidities once I've recognized them, thanks to the repl, a functional style and a small code base. Lisp teaches you to face your fears.
What I mean, a novice programmer would do that in any language anyway (and I'm no exception) while an experienced developer would avoid these traps in any language.
Well, there are certainly 2 schools of thought; the "there should only be one way to do it" school of thought and TIMTOWDI.
I don't think you should write off lisp just because it's too flexible. If anything, that makes it much more interesting to learn - there are lots of ways to do things. Clojure currently says there should be one obvious way to do it; so maybe you should check that out.
Idiomatic Clojure wouldn't really embrace an object system anyways since it's meant to be pragmatically functional.
I don't think you should write off lisp just because it's too flexible. If anything, that makes it much more interesting to learn - there are lots of ways to do things. Clojure currently says there should be one obvious way to do it; so maybe you should check that out.
Idiomatic Clojure wouldn't really embrace an object system anyways since it's meant to be pragmatically functional.
This is, indeed, a symptom of the main problem with lisps today; there's so much power available, but a lack of incentives about not using it capriciously. Everyone writes their own implementations of relatively basic things, because the existing libraries don't do things in exactly the way they'd prefer, and it's just not painful to write a library that does just the parts you need. Clojure might get around this by tying itself to Java, as long as most Clojurists come from the Java world and are used to using those same libraries already.
it's just not painful to write a library that does just the parts you need
And this is a bad thing?
a lack of incentives about not using it capriciously
That's an argument against higher-level languages. If a language lets me do what I want, it lets me use it capriciously if I want. The only way to inhibit capriciousness is to inhibit power and flexibility.
I suspect this complaint about Lisp, which seems to get trotted out every time, is made by (and for) people who haven't worked much with Lisp. It's just too remote from reality, or at least the corner of reality that I've personally traversed.
And this is a bad thing?
a lack of incentives about not using it capriciously
That's an argument against higher-level languages. If a language lets me do what I want, it lets me use it capriciously if I want. The only way to inhibit capriciousness is to inhibit power and flexibility.
I suspect this complaint about Lisp, which seems to get trotted out every time, is made by (and for) people who haven't worked much with Lisp. It's just too remote from reality, or at least the corner of reality that I've personally traversed.
I spent a coupla years using Common Lisp as my language of choice. I like lisp (though I have specific issues with many details of actual lisps, as everyone does). However, after two years of experience with it, I was chagrined to find that it hadn't reduced the time it took to finish projects very much, if at all, over Python and PHP. There were two problems, really: lack of libraries that did what I needed to build on, and the ever-present temptation, much stronger than in most languages, to build everything myself, even where there was a 80% solution already existing.
I recognize that this stems directly from CL's greater power, and I don't want that power removed from a language; I just don't know how to get the power and develop a culture of good libraries and reuse.
I recognize that this stems directly from CL's greater power, and I don't want that power removed from a language; I just don't know how to get the power and develop a culture of good libraries and reuse.
Ok. I owe you an apology for implying you weren't speaking from experience.
The library complaint annoys me because it's become the thing that everyone repeats regardless of how applicable it is. The truth is that it depends on what kind of problem you're working on. Also, to the degree that it's easy to implement the portion of functionality that you need, the value of a library goes down; and no one seems to consider the cost of using a library, which can be nontrivial (e.g. learning curve, difficulty of modification).
The library complaint annoys me because it's become the thing that everyone repeats regardless of how applicable it is. The truth is that it depends on what kind of problem you're working on. Also, to the degree that it's easy to implement the portion of functionality that you need, the value of a library goes down; and no one seems to consider the cost of using a library, which can be nontrivial (e.g. learning curve, difficulty of modification).