1. It sounds like you have an encountered the concept of the complexity pyramid before. Or if you have, what do you think it is? 2. I prefer to frame other people‘s thoughts as different rather than wrong. Influenced by both rational and emotional considerations, as well as experience. Sometimes it benefits me to adopt those ways of thinking. And sometimes I try to offer a different way, as I have done in this discussion, I hope. 3. Do I understand you correctly that an extension is a completely different thing than the definition? 4. I think I have already stated my case against linearization elsewhere. 5. Legos are a great example of a system based on fundamentals: every piece has the same sort of bumps and hollows so that they all fit together easily and in unforeseen ways. Chemistry is another example of such an a system. When I design a language, or an environment for programming, I strive for an abstraction level that contains only a few basic concepts that can be mixed and matched. In my experience, such a system fosters creativity and in my work, I seek to do that very thing.

Who was that undergraduate? Why do you mention that he was unpaid? Where I come from, undergraduates are rarely paid. Significance They pay the university in return for the education.

What a pleasure to see that echo of Doc Brown!

"Flavors was a genius discovery that revolutionized OO by an unpaid undergrad over a few weeks." Were you that undergrad? Why do you think it was genius and revolutionary? What was the novel insight? What was the revolutionary idea? I don't understand. Why are you so laudatory? Did it solve a huge problem for you? Did you have a transformative experience with it? You refer to your book, and LtUO. Where can I find them? Your second paragraph seems to assert that the quotient of features divided by lines-of-code is equivalent to simplicity. I prefer to think of simplicity in terms of how much new stuff a user has to learn, taking into account what the user already knows. Am I misunderstanding your argument? When I encountered Flavors, back in the 80's I think, it just seemed like an overly complicated attempt to layer an object-oriented system onto Lisp. Smalltalk seemed much more elegant, and later Self was more powerful with fewer concepts still than Smalltalk. When I program in any language, I try to make the best use of what it provides, but I would never claim that my success is an endorsement of the fundamental language design. You seem to be saying that, because you used Flavor constructs to build something useful the choice to design the language that was good. What am I missing here? I say Korz allows for far more modularity than its (dynamic) predecessors, because it allows for subjective modularity. The whole purpose of modularity is to centralize invariants, easing the finding the code that either depends upon or enforces some invariant. The need for subjectivity arises because there is no one containing hierarchy that cleanly centralizes the invariants. Your "invariants that no one owns" reflects a limited understanding of the power of subjectivity. For any invariant, one can add a dimension that owns it, and thus a projection of the space that does centralize the invariant. I sympathize, because the cognitive shift from a linear, objective world-view to a multidimensional, contextual world-view is profound. IDEs matter; they cannot be separated from the language. And building a good one for a contextual, multidimensional system will be interesting. The conflicts that can emerge when writing Korz code are the same ones that Flavors merely papers over by linearizing inheritance. If I want to resolve a conflict in Korz I can do it with either extra dimensions, or more specificity in the coordinate inheritance hierarchies. To me, the inheritance linearization in Flavors was just a way to ease the implementation at the cost of a more baroque mental model for the programmer. But hey! Korz is mainly just an idea, and I could be wrong. I've made plenty of mistakes before. And please don't interpret what I write and any attempt to change your mind or even challenge the way you see things. As my mother would say, "That's what makes horse-racing." Each person lives in his or her own subjective reality and you are entitled to yours. You pays your money and you takes your chances. Best of luck!

"predefined" Rubs me the wrong way. Why those and not others? Defined how? Macros?? If so, it's a symptom of what I consider to be a disease, sorry. OTOH, a system built on uniform true partial evaluation or adaptive optimization is fine by me. "Streamlines"? Were they predefined for the sake of performance? If so, I think there's a better way. In Self, the standard library is just stuff you import. It's as visible and as malleable as anything you write yourself. And what you write yourself runs as fast as "library" code, while both your own and library code is fully debuggable. Were there Lisp or Flavors systems that worked the same way? When? Later, AFAIK.

Thanks for this clip! That portrayal!!!

Your own work on ownership is a very productive way to frame things in the right contexts. I suspect that the Korz language is powerful enough to express it dynamically.

The underlying problem here is unidimensionality and ignoring subjectivity. Ubiquitous multiple dispatch of implicit as well as explicit arguments is like peanut butter and chocolate. Suddenly, the module structure varies with your viewpoint and the problem you’re trying to solve at that moment. There is a cost to adding the complexity to your model of reality, but it provides an elegant and unified solution to the problems. For example, it eliminates the speed bump when you have to factor your code to accommodate the visitor pattern. Need to add pretty printing to your expression evaluator? Just add a dimension and constraints to a few slots, only the ones that do the actual evaluation. The expression tree walkers remain untouched because they don’t care about the new dimension. The key is the multidimensional subjectivity of useful modularity.

Time travel and a heavy object falling a large distance. Plus flying cars and flying steam locomotives! A mad scientist!

Since the Korz papers don’t always include that word in the title, they can be hard to find. So here is a list: Core Papers on the Korz Model • Korz: Simple, Symmetric, Subjective, Context-Oriented Programming
David Ungar, Harold Ossher, Doug Kimelman.
Onward! 2014 (ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software). DOI: 10.1145/2661136.2661147.
Free PDF: worrydream.com mirror.
Main paper: sea-of-slots model, implicit named arguments + multiple dispatch, subjective objects, prototype (Self-based), examples. • Subjective, multidimensional modularity with Korz
Harold Ossher, David M. Ungar, Doug Kimelman.
Companion Proceedings of MODULARITY 2015. DOI: 10.1145/2735386.2735923.
Focuses on modularity, symmetry/subjectivity, and IDE views of the slot space. • Korz: Envisioning a Paradigm for Dynamic Multidimensional Contextual Variation (Extended Abstract)
David M. Ungar, Harold Ossher, Doug Kimelman.
SNAPL 2015. • A Simple, Symmetric, Subjective Foundation for Object-, Aspect- and Context-Oriented Programming
Harold Ossher, David Ungar, Doug Kimelman.
FOOL 2014 (Foundations of Object-Oriented Languages, co-located with SPLASH 2014).
Position paper arguing Korz as a unifying foundation; discusses open issues. Available via workshop archives / university pages. Related / Precursor Papers (same themes: simple/symmetric/subjective/context) • Enterprise context: a rich source of requirements for context-oriented programming
(Ossher, Ungar, Kimelman et al.).
COP ’13 (5th ACM International Workshop on Context-Oriented Programming), 2013. DOI: 10.1145/2489793.2489796.
Requirements from enterprise-scale context (scale, integration, temporality, policy, etc.) that motivated the work. • A Simple and Unifying Approach to Subjective Objects
Randall B. Smith and David M. Ungar.
Theory and Practice of Object Systems, 1996.
Earlier work on perspective-receiver symmetry for subjective behavior (influences the subjective aspect of Korz). • Subject-oriented programming: a critique of pure objects
William H. Harrison and Harold Ossher.
OOPSLA 1993.
Foundational paper on subjective views / subjects (Ossher’s long-running line of work that feeds into Korz). Patent • US9898310B2 – Symmetrical dimensions in context-oriented programming to optimize software object execution
Inventors: Harold L. Ossher, David M. Ungar (IBM).
Detailed formal description of the Korz model, examples, and IDE concepts.
Google Patents. Videos / Talks • Dancing with Symmetry to Harness the Power of Complexity: Subjective Programming in Context
David Ungar and Harold Ossher.
Recorded ~Feb 2014 (SPLASH/Onward! era). ~59 minutes.
Explicitly introduces the multi-dimensional context paradigm, context-based dispatch, and early prototype.
Available on InfoQ with MP3 audio + slides: infoq.com/presentations/oop-….
This is the clearest non-“Korz”-titled video/talk matching the keywords you mentioned.

It’s a question of level. I both agree and disagree with Cook and Gilad. You must’ve heard of the complexity pyramid. It’s an inverted pyramid. At the top, you have a bunch of features, but as you go down the pyramid, you have fewer more powerful features that are the building blocks, and it might even be an hourglass whereas you go down below the fundamentals things get more varied again. But the key is to let the punishment fit the crime. Each level must be designed to fit the way the person who will be using that level thinks. There is an appropriate level for modular extension. With Korz, you extend the code by adding a new dimension that may influence the dispatch of each operation. Please put in the time to inform yourself before you continue the discussion. It might to your understanding of modular extension. There is also an appropriate level for a few fundamental principles upon which everything else can be readily understood. When a system is built, that way people find novel and productive ways to combine things as opposed to building a system as a set of special cases.

Here’s what I mean, way too many things for this level in the system: Built-in Flavors method combination types: • :daemon (default) • :daemon-with-or • :daemon-with-and • :daemon-with-override • :progn • :or • :and • :list • :append • :nconc • :max • :min

There is a problem with symmetric, multiple dispatch, when it’s uni-dimensional and context-free. It’s always easier to see the surface manifestations of a problem then to puzzle out the underlying missing concepts. And that’s what Flavors did by introducing so many different options for inheritance. It’s the trap of adding a new feature for every problematic example. But maybe what you think Flavors was is different than how I remember it. My ask of you is to: first, give me a concrete example, and second, please go read up on Korz. Extra can always be added to break unwanted symmetries. I call myself senderPath here in order to highlight one of the biggest technical mistakes in my career. Why? Because I can always be wrong, and maybe others can, too. Is there a chance there’s some trade-off involved with Flavors that you’re overlooking?

Thank you for bringing me so much joy and laughter.

My favorite movie/trilogy of all time!

PS: “PL” == “programming language”

Context! We all sin (esp. me) when we fail to ground assertions about PLs to context. A Mars Rover is not the same as a student research desktop. Each PL design is a multidimensional tradeoff. TANSTAAFL.

My latest best thinking on inheritance was explained in the Korz papers & talks with Ossher, Kimelman, Adams. Symmetric multiple dispatch with implicit arguments. Flavors always felt too baroque. Korz did not tackle static guarantees. I like the Scandinavian esthetic here (Beta).

Already purchased one of each, and I like the happy colors, but I have to wait till next year?! Argh.

Hand is up