Reddit reviews The Art of the Metaobject Protocol
We found 17 Reddit comments about The Art of the Metaobject Protocol. Here are the top ones, ranked by their Reddit score.
Reddit reviews The Art of the Metaobject ProtocolWe found 17 Reddit comments about The Art of the Metaobject Protocol. Here are the top ones, ranked by their Reddit score.
Some context, I've been living in this house for about 3 years now, my girlfriend and i moved in to take care of the owner of the house. Turns out that he was a big lisp / scheme hacker back in the 80s-90s and had developed a lot of cutting edge tech in his hay day. Anyway, these books have been hiding in his library downstairs...
It was like finding a bunch of hidden magical scrolls of lost knowledge :)
edit: I will compile a list of the books later. I'm out doing 4th of July things.
update: List of books
ISBN: 1-55558-044-0
ISBN: 1-55558-042-4
ISBN: 0-262-56038-0
ISBN: 0-393-95544-3
ISBN: 0-201-17589-4
ISBN: 0-07-000-422-6
ISBN: 0-13-370875-6
ISBN: 0-07-054666-5
ISBN: 0-262-11158-6
ISBN: 1-55860-191-0
ISBN: 1-59059-239-5
ISBN: 0-932376-41-X
ISBN: 0-07-001115-X
ISBN: 0-673-39773-4
ISBN: 0-262-07093-6
ISBN: 0-932376-87-8
ISBN: 0-13-717232-X
ISBN: 0-417-50308-8
ISBN: 0-471-60771-1
ISBN: 0-262-19288-8
ISBN: 0-262-55017-2
ISBN: 0-13-834284-9
ISBN: 1-935182-64-1
ISBN: 978-1-59327-591-4
The Art of the Metaobject Protocol is one of my favourite programming books of all time - the sudden "click" in my head that marked the transition from "What the hell is a MOP anyway?" to "That's such a simple and awesome idea, why doesn't everyone do that?" was the closest I've gotten yet to the fabled "Lisp enlightenment" :)
Largely because CL has had the benefit of several years and hundreds (thousands?) of users beating on it, while an ignorant reimplementation is likely to make all the same mistakes that Lisp did when that feature was first introduced.
For example - generic functions were first introduced in Flavors, the object system for the Lisp Machine. A bunch of issues cropped up concerning the interaction of multiple dispatch and multiple inheritance, issues that the Python community hasn't even considered. There's a whole book - The Art of the Metaobject Protocol - written about these, along with many pages in the CL HyperSpec. Even with standardization, CL made a mistake: the superclass precedence order should be monotonic. The paper A Monotonic Superclass Linearization for Dylan goes into this in more detail.
The Keene book is good.
There are also some good essays about CLOS on RPG's website.
Finally, the AMOP book shows that CLOS is simple at its core.
Lisp communities have been very accepting of object-oriented concepts, in part because Lisps are powerful enough to implement rich facilities for object-oriented programming without requiring changes to the underlying languages:
Veeery old. In case you need more, see The Art of the Metaobject Protocol. There is even a Wikipedia entry: https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol with download links of parts of the book.
The book The Art of the Metaobject Protocol has all the code in the appendix which is an example of non-trivial software well written. Link: http://www.amazon.com/The-Metaobject-Protocol-Gregor-Kiczales/dp/0262610744
Another example of good programing can be found in Operating System Design, the XINU Approach. The whole OS is given and it's well structured. Link: http://www.amazon.com/Operating-System-Design-XINU-Approach/dp/0136375391/ref=sr_1_3?s=books&ie=UTF8&qid=1426961466&sr=1-3&keywords=xinu
> What would be cool for Magpie would be a Meta-Object Protocal.
I just finished AMOP so that's definitely on my mind. My current plan is to get a solid object/multimethod system working first. Once that's in a happy place, I'll try to start moving bits of it over to Magpie itself and make them more extensible.
At the very least, I want user-defined patterns. That covers a lot of the MOP space since it would let you define your own method matching logic.
After you have read Practical Common Lisp and SICP I suggest The Art of the Metaobject Protocol then Paradigms of Artificial Intelligence Programming.
If you make it through those, you will be very well prepared for solving industrial problems with Lisp.
On Linux I recommend grabbing the latest SBCL. If you really need to stay on Windows, then CLISP is fine.
You can edit code in any text editor, so simply choose your favorite one on any platform. You will find most of the main CL nerds use emacs and SLIME as their "IDE".
As for books, there are no good books on Lisp. I'm serious, every last one of them sucks ass out loud. But here is a list, taken in order from beginner level (that's you) to CHICK MAGNET (that's me).
Good luck, it's a good job you're getting started young. But CL will ruin you for other languages FYI.
Ah, I begin to see why they consider you a troll.
> No, six.
Heheh. :) Now I know you are messing around.
> Really? Go on common-lisp.net and try proving your hypothesis.
Go to cliki.net, and try to prove yours first. In my entire experience with Lisp, I never used that older site. Even the ASDF system uses cliki.net. Oh, I knew about it, but I could not understand why anyone would want to use it when the same packages and much more are available at cliki.net.
> Macros are a shitty form of encapsulation.
This statement makes a lot of interesting assumptions. Macros are intended to be a form of encapsulation? Encapsulation is desirable in every language construct? Encapsulation is statistically linked to some form of success?
Tools can be misused in any fool's hand. Macros, when used to abstract (not their only use), can make code much easier to read or much harder to read. We can as easily cry about C pointers and Java's leaky garbage collection.
> I'm aware of that, because I have this:
Knowing names and knowing features/functions = two different things. You would not have made the ignorant statement about Java if you understood MOP. MOP is not only used in Lisp; it would help your knowledge a lot to research it. Do you have this book? -- http://www.amazon.com/The-Metaobject-Protocol-Gregor-Kiczales/dp/0262610744
> What a
bloatedelegant language.Show me your objective measures of "bloated" and "elegant". Walk the walk. Measuring number of pages is as useless as measuring lines of code.
Edit: Ah, ninja-editing. I must have struck a chord.
> Great, that's really useful to me.
I could say that about any random library I see anywhere. I tend to start with a problem and then work to solve it, grabbing what libraries are useful for it. I have noticed that rarely does armchair theorizing actually help me (or others) understand anything.
In truth, there are a great many useful packages in the Lisp ecosystem. Here is a nice list of them: http://www.cliki.net/Current%20recommended%20libraries
And better yet, you may want to consider installing QuickLisp and seeing what packages it supports. Inactive and outdated things are actively removed from its list.
The Art of the Metaobject Protocol
Real-life Lisp programming explained.
I'd add The Art of the Metaobject Protocol which in a few short pages creates an entire flexible class system and demonstrates how to extend it to do pretty much anything one needs. And it's easy and pleasant to read too.
After you've read it, you'll never again look at problems the same way; it demonstrates that for the sufficiently-clever there's always a way to make the problem solve itself.
Are you confusing dynamic typing with weak typing?
> That being the case, I find defining the available types explicitly
You do that with dynamic typing. Dynamic typing is not the absence of type... it's late binding.
> But you refer to this as imposing unnecessary clutter, which seems odd to me.
It's the explicit formalizations that are required by static typing that imposes clutter, not the typing itself.
> I hardly ever use reflection.
I use reflection all the time and it helps be reduce the amount of code by at least a factor of 2. In many cases, this factor is larger (3x to 5x) (Note: these factors apply to sections of code and not the whole application).
Here's an example from about 12 years ago. I was head developer on an application written in java (the first ever java application deployed according to Sun and IBM). We had to use AWT (which has it's own problems) and I became increasingly frustrated with their use of the observer pattern (listeners). The problem was too much formalism. I had to define listeners which could only respond to one message (actionPerformed). Then, I had to map this message to the real message... the one relevant to the problem. (For example, when an "ok" button is pressed, the action relevant to the application logic is "ok" and not "action performed". When you start building complex interfaces, the need to map between the conceptual space that is implemented by the model and the interface can add considerable needless complexity).
My solution was to use reflection. Even an implementation of reflection as poor as that in java was enough to remove huge swaths of code from the application. I created gui components that allowed the registration of listeners, but the registration component included not only the reference to the listener but also the name of the method that should be invoked against the listener. This method was invoked reflectively. Our application was about 125,000 lines of code and this change removed about 15,000 lines. (BTW... this design was not mine. I had previously worked with NeXTSTEP and Objective-C. I simply emulated the design I had seen employed there).
The change was significant. Not only did it remove a lot of code, but it significantly reduced the complexity of building GUIs. The complexity imposed by the static typing added no benefit to the application... its use served only to increase the complexity of the solution which made the application harder to code, longer to code and more difficult to change and fix.
> Perhaps our mindsets are different here, and you prefer to work more intuitively for longer, hence preferring a tool that better supports that approach?
In the example I gave above, the use of reflection significantly reduced the amount of code that was required. To me, this is a win regardless of one's analytic preferences. I see this effect whenever I employ the use of dynamic typing to a project.
The one thing to remember is that dynamic typing is a tool. It can be used well or badly, just as static typing can be used well or badly. It's necessary to take a disciplined approach when it is applied.
If you're interested, I highly recommend The Art of the Metaobject Protocol
Aside from the other excellent choices people have recommended, here are a few I liked that I haven't seen in the thread yet.
This one sounds super-obscure. It's basically the design notes for the Common Lisp Object System, which isn't exactly a manual you need to read to get your work done. However, if you look at it less a book about how to use CLOS and more a book about how an object-oriented language can be built from scratch, it's really a fantastic little read.
It's what it says on the tin -- interviews with several programming icons. What makes this one better than the other half-dozen or so similar titles is how well the author runs those interviews.
If I'm honest, I didn't find this one to be that engaging of a read, but it's worth the bit of effort to get through it just to absorb Stepanov's vision for how to express algorithms. He's got a newer book as well that I have high hopes for, but I haven't had a chance to read it yet.
Nope.
Actually C++ does this as well, it's just better hidden from the user.
This is the issue with perl5 "OO". It may have the potential to be the same as C++ or Python or whatever, but the packaging is non-existent. You must do everything yourself. Manually. I suppose that's ok if you want to learn how OO actually works (though personally I would recommend going with The Art of the Metaobject Protocol).
Python does expose the fact that the "this" argument is passed to the function which is, as you stated, a mistake. But at least everything else has pretty decent packaging.