It is a really long post and heavily references Godel, Escher, Bach but this section I think explains the difference really well:
Hofstadter offers several supporting examples for this thesis, but I'll paraphrase one of my all-time favorites. It goes more or less as follows.
Imagine you're listening to announcers commenting on an NFL (American football) game. They're talking about a new rookie player that you don't know anything about. At this point, the rookie – let's say his name is L.T. – is just an instance of the class "football player" with no differentiation.
The announcers mention that L.T. is a running back: a bit like Emmitt Smith in that he has great speed and balance, and he's great at finding holes in the defense.
At this point, L.T. is basically an "instance" of (or a clone of) Emmitt Smith: he just inherited all of Emmitt's properties, at least the ones that you're familiar with.
Then the announcers add that L.T. is also great at catching the ball, so he's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs like Walter Payton. And so on.
As the announcers add distinguishing attributes, L.T. the Rookie gradually takes shape as a particular entity that relies less and less on the parent class of "football player". He's become a very, very specific football player.
But here's the rub: even though he's a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player.
This is called prototype-based modeling: Emmitt Smith was a prototype for L.T., and L.T. became a prototype for Joe, who in turn can serve as the prototype for someone else.
These are really different facets of the same rookie and have to do with the role he can play in various relations -- each facet can come from a different prototype (or class...) if necessary. So "viewed as a" or "in the role of" a Catcher, we "see" certain attributes, and "as a runner" we see others. Certain knowledge representation schemes (frame systems, description logics, default reasoning and truth-maintenance schemes, etc.) can deal with this context-sensitivity well -- programming languages tend to have some weakened notion of these things, such as Inferfaces or Traits.
Hah that's a good question. I haven't really thought about that or explored type systems that would interact with this pattern. Would be really interested in reading about it though!
It's not just about static type systems, though. nerdponx was asking about type systems in general. It's a tricky question even for dynamic type systems. Javascript keeps reference to the constructor and the prototype, so you can determine the "type" that way, but that's not the only way a prototype-based OOP language can work. A language can work without keeping such references and instead simply copying each property on cloning. How do you determine the type of an object then? Is the type based on the presence of certain properties? Does it include the equality of the values of such properties or does just their presence suffice? Does having additional properties change the type? There seem to be many questions with arbitrary answers in making such a dynamic type system.
I think I had static type systems in mind when I asked the question, but that was helpful all the same. It seems in the case of Self it does in fact keep the reference around.
I suppose the whole point of a static type system is moot with a fully prototype-based language. Instead maybe you can enforce compile-time checks (contracts?) on the messages an object is expected to receive.
> I suppose the whole point of a static type system is moot with a fully prototype-based language. Instead maybe you can enforce compile-time checks (contracts?) on the messages an object is expected to receive.
I think if you can do the latter, you can probably do the former. By that I mean you can probably do neither.
If cloning is something you do in runtime, how can you enforce compile-time checks on the messages they're supposed to receive? Such messages are defined at runtime.
Shot in the dark here, but I vaguely remember a blog post that used birds in an explanation for monads and I can't seem to find it again. It had hand-drawn birds, and I think it started out with the identity monad, with the bird representing it only able to speak their own name.
Does anyone remember that post? I'd love to find it again, I got really excited when I saw the title, thinking that it had finally come around again.
AI Algorithms, Data Structures, and Idioms in Prolog, Lisp, and Java, by George Luger, free from the author's personal page on Florida State uni, here:
This is an excellent resource also for LISP (and Java!) and AI algorithms, particularly various search strategies.
I'd also recommend the standard Prolog textbtook, Prolog Programming for AI, by Ivan Bratko. You can most likely find an edition in most university libraries.
I've learned a lot from Adventure in Prolog, a Prolog tutorial on the Amzi! Prolog website (though I used a different Prolog to do the exercises, which is a very good sign of nice, basic and portable examples):
Those are practical resources. On a more theoretical side, another commenter recommended Perreira & Shreiber, which I can't recommend enough. Also, for a more formal text on logic programming, with proofs and all, the classic reference is J. W. Lloyd, Foundations of Logic Programming. Again, you can probably find a copy in your friendly neighbourhood university library (or, er, google it for a very bad copy of dubious legitimacy, like).
The exposure most people have to prolog in school is about a chapter in the "programming languages" course.
Yes, pick any book and work through it from page 1 to the end. Preferable 3!
Read and pour through the manuals for whatever interpreter & compiler you use.
Be warned, Prolog will ruin you, you shall be able to slay dragons and at the same time you most likely will not enjoy programming in "modern languages" anymore.
(Intro/Novice)
Learn Prolog Now (free on the web)
Adventure in Prolog(free on the web)
Logic Programming with Prolog
(Intermediate)
The Practice of Prolog
Prolog Programming for Artificial Intelligence
Prolog Programming In Depth
Prolog Experiments in Discrete Mathematics, Logic, and Computability
(Advanced)
The Art of Prolog
The Craft of Prolog
Clause and Effect
Simply Logical
Prolog and Natural Language Analysis
Meta Programming Logic
Intelligent Image Processing in Prolog
Expert Systems in Prolog
Functional Grammar in Prolog
(Papers)
Warren Abstract Machine
Negation and Control in Prolog
For a really nice explanation of the Warren Abstract Machine, see "Warren's Abstract Machine: A Tutorial Reconstruction" by Hassan Aït-Kaci: http://wambook.sourceforge.net
Clocksin & Mellish has the benefit of being a slim volume, which makes it approachable.
Sterling & Shapiro (Art of Prolog) has much more depth. Not sure I'd recommend to a beginner. (It has a beautiful cover, though and is almost worth getting just for that.)
My favorite Prolog book is Pereira & Sheiber's "Prolog and Natural-Language Analysis". It's slanted toward NLP but the coverage of Prolog itself is top notch.
I just googled that and don't know if it's a legitimate source, but I've previously downloaded a copy from the site of one of the authors, so it's probably all right.
Peter Flach's "Simply Logical: Intelligent Reasoning by Example" also deserves to be mentioned as a wonderful introduction to Prolog and computational logic in general. It's available as a PDF from the author (http://people.cs.bris.ac.uk/~flach/SimplyLogical.html) and also in an interactive version where the examples can be run in-browser, using SWISH: https://book.simply-logical.space/
People have already recommended it, but "Programming in Prolog" by Clocksin and Mellish was the text book for the Prolog course that SWI-Prolog offered back in June.
I've been thinking about this idea for a while and love the reimplementation idea. I really want to start live-streaming myself coding (or pair programming) and have been trying to come up with some ideas that would end up being interesting to watch.
One idea was taking a popular open source tool with a good test suite and trying to get the tests to pass, but I think checking code out at a point before a new feature is implemented and reimplementing it could end up being really interesting. Could even make it more interactive by sharing the checkout point so viewers can do an implementation themselves and doing a stream walking through different interesting implementations.
I had a class in high school that mostly covered the basics, though I wouldn't say I "learned" it. It wasn't until around 15+ years later and after I started working as a programmer and decided to work through a Programming A Chess Engine In C [1] youtube series that it finally really clicked.
I have one app that connects to my Pinboard account and emails me 10 random bookmarks every morning. I've been using Pinboard for years and it is full of stuff that I marked "to read" or read a long time ago that I forgot to go back to. It is surprising how often some old blog post shows back up and is relevant to a discussion I was having in the last few days.
I have another app that emails me the tweets, blog posts, and HN comments of my favorite bloggers every morning. With the rise of tweetstorms, I felt like I was missing a lot of great stuff, but now I don't have to obsessively check twitter/hn/my favorite blogs all day every day. (I really miss RSS)
I made the transition from engineer to managing a team of around 12 at Groupon. So I made the transition with a smaller team than you are - forgive me if some of this isn't as useful for your situation.
What worked for me:
- One on Ones. Nothing I've done has had as much of an impact as weekly one-on-one meetings with everybody on my team. I tend to follow the format outlined on Rands In Repose: http://randsinrepose.com/archives/the-update-the-vent-and-th... (This is an incredible blog for engineering management. I would highly recommend reading everything he has written.)
- Read everything you can find on the topic and about leadership in general and start figuring out how you can incorporate the lessons from those books into your situation and context. This is a brand new skill set that you need to approach with the same effort that you had been approaching engineering.
- Finally, one piece of advice I got when I first transitioned into management was that "first-time managers usually fall into the trap of becoming the manager they wish they had. What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager." Easier said than done, obviously, but I've always found it useful to return to it whenever I am struggling.
>"Finally, one piece of advice I got when I first transitioned into management was that "first-time managers usually fall into the trap of becoming the manager they wish they had. What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager."
That is a very salient point. Managing a team of multiple people of different backgrounds, experience levels, quirks, communication styles, pet peeves, etc. is an exercise in adaptation.
As a Director, there are certain things you need your team to adapt to in order to keep your team on track with your strategy and process. How you go about getting them to do that is all about you adapting to them to get them excited, help them overcome hurdles, break down communication barriers, and build your relationship so they know you have their backs and you know you can rely on them.
It sounds easy in principle, but it is incredibly difficult in reality, particularly for those who may be stronger on the technical side than the communication side.
And P.S., you won't always be successful, so start planning for when (not if) you will fail in that regard. That means making sure your team knows that you are always open to their candid feedback so you can do a better job of supporting them.
On a final note, I'm quite partial to this illustration that nicely sums up your role in relation to your team [1]. In another sense, some see an org chart with them at the top and their team beneath them. I see it as an inverse pyramid with the leader at the bottom supporting each and every one of their team members because your success is wholly dependent on their success at that level.
One trick that worked for me (pack+ a day smoker for 5+ years) was not exactly calling it "quitting". I had tried quitting a bunch of times, but every time I had a lapse in will power and had a cigarette, the justification to start again basically went "oh well, guess I failed quitting, time to go out and buy a pack."
When I changed my mindset to more of a "I just don't really smoke anymore." it was ok to have one every once in a while when I was out with friends and not feel like I failed. Now I'm basically down to only one cigarette a year or two when I'm with old friends, and I usually feel bad enough in the morning after it that I don't really have any desire to smoke again for a long time.
It's really different for everyone. So I'll put this out as a word of caution: my response to that one accidental cigarette has been (twice) that cravings increase over the next couple of weeks, then I was having one random shitty night, and feeling all "fuck everything", bought a pack at the night store, and was back at square zero.
