7 ms·
Just a little comment: Kay's mentioning various meta-things reminds me that I have The Art of the Metaobject Protocol (which Kay called "the best OOP book in te
by delish 11y ago
Just a little comment: Kay's mentioning various meta-things reminds me that I have The Art of the Metaobject Protocol (which Kay called "the best OOP book in ten years," and I should read it.
And another little comment as regards Kay's "complaining" that Smalltalk had become "something to be learned": I very much failed to learn computer science from high school Java, where classes, methods, encapsulation etc were treated as things-to-be-learned. I didn't know that I /could/ care about how they were put in place or why.
If I had been taught that everything in a meta-system can be changed when you structure your changes, I would have been a happier camper--motivated by autonomy and purpose.
- agumonkey 11y agoI felt the same. People differ in the way they interact with systems and logic. I certainly disliked being fed the Java way rigidly. I actually learned more about basic OOP by simulating it in ADA. Some people like to understand by building. But it's also valuable to understand an abstraction outside of any implementation. In the end it's better to have done both. And I feel strongly that to understand programming, one must write an interpreter and a compiler, so you can reason about the different abstraction levels clearly, without blind spots or dark magic.
- parasubvert 11y agoThe art of the meta object protocol was good, it basically was a well-written code commentary for how to build an advanced OO meta system (CLOS) for LISP. CLOS was a bit of a dream language, I'd say Scala is perhaps the closest practical language in terms of ideas. Interestingly, this work led Gregor Kiczales & team to create Aspect Oriented Programming - a subset of his metasystem - which became somewhat popular with Java and the Spring framework's use of AspectJ. http://en.m.wikipedia.org/wiki/Aspect-oriented_programming http://en.m.wikipedia.org/wiki/Aspect-oriented_programming As an aside, I found in college (let along high school!) that students have almost anti-philosophical learning objectives. The SICP approach of teaching computer science from the metasystem up with Scheme (and then possibly moving on to CLOS/Lisp) was near-universally hated among my peers (1996-2002) - most wanted a practical language they could "get a job" with. I believe MIT first year CS switched to Python in part to deal with this resistance.
- mbrock 11y agoWhat makes Scala more "practical" than Common Lisp, other than incidental matters of library support on the JVM?
- parasubvert 11y agoThat, and the dearth of people that know CLOS, or are able and WANT to learn CLOS. "Design by resume" surrounds us.
- DalekBaldwin 11y agoAOP also encompasses techniques you can't find in CLOS/MOP. The analogues to before/after/around methods are the easiest concepts to implement and reason about, so those are what popular language extensions tend to emphasize. But if you look at the original AOP papers describing Reverse Graphics, you'll see an AOP system used to liberally restructure the control flow of the entire base program, not just augment its behavior. It was an early version of what you can see now in something like the Halide language. > I believe MIT first year CS switched to Python in part to deal with this resistance. In part. The full story is a bit more depressing: http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python http://www.wisdomandwonder.com/link/2110/why-mit-switched-fr... Most of the other top universities that had used SICP also switched shortly after MIT.
- xenophonf 11y ago> most wanted a practical language they could "get a job" with This was me in college. Especially early on, I kept hounding my professors why they weren't teaching a particular language (e.g., C++) or toolchain (Visual Studio). It wasn't until well after I graduated that I appreciated the distinction between using tools and making tools---and that my professors taught me the latter.
- frik 11y agoJavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. http://en.wikipedia.org/wiki/Squeak http://en.wikipedia.org/wiki/Squeak One can change everything, and manipulate even the UI. Even the DevTools in all browsers nowadays are HTML5 iframes. Manipulating the objects and meta/prototype objects are features that both languages allow. Though they are different, and afaik only JS is called a prototype based programming language: http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming
- vezzy-fnord 11y agoJavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. Sure, they're "similar", but at a relatively low approximation. The capabilities of the Smalltalk environments are simply on a different plane. Manipulating the objects and meta/prototype objects are features that both languages allow. This is sort of a bare minimum for all OO languages. Even Java with its rigidity allows for complex tricks with reflection and method body replacements for hot code reloading.
- mbrock 11y agoCan you formulate more precisely (or by example) what you mean by "simply on a different plane"?
- vezzy-fnord 11y agoSee the Design Principles Behind Smalltalk article: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.... Some relevant excerpts: Here are some examples of conventional operating system components that have been naturally incorporated into the Smalltalk language: [...] Display handling -- The display is simply an instance of class Form, which is continually visible, and the graphical manipulation messages defined in that class are used to change the visible image. [...] Debugger -- The state of the Smalltalk processor is accessible as an instance of class Process that owns a chain of stack frames. The debugger is just a Smalltalk subsystem that has access to manipulate the state of a suspended process. It should be noted that nearly the only run-time error that can occur in Smalltalk is for a message not to be recognized by its receiver. Smalltalk has no "operation system" as such. The necessary primitive operations, such as reading a page from the disk, are incorporated as primitive methods in response to otherwise normal Smalltalk messages. This is from 1981, BTW.