Rich Hickey

oop and time
https://www.quora.com/Rich-Hickey-creator-of-Clojure-has-said-that-object-oriented-programming-is-unable-to-model-time-properly-What-does-modeling-time-actually-mean

http://whiley.org/2010/06/23/rich-hickey-on-clojure-se-radio/

https://www.youtube.com/watch?v=ScEPu1cs4l0 So I am going to talk about time today. In particular, how we treat time in object-oriented languages generally, and maybe how we fail to. So I am trying to provoke you today to just reconsider some fundamental things that I just think we get so entrenched with what we do every day, we fail to step back and look at what exactly are we doing. 16min "... behaviour and state, these terms are almost completely meaningless ..."

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/AreWeThereYet-mostly-text.md

ycombinator
https://news.ycombinator.com/item?id=11949692 zwieback on June 21, 2016 Voted this up out of pure nostalgia. I remember the "spirited" usenet discussions we had with topmind/tablizer on comp.object(https://groups.google.com/g/comp.object). He was a one-man army fighting proponents of OO. There were actually some decent ideas buried in his ramblings about table-oriented programming but he was so abrasive nobody could deal with him. I'd be curious what became of him...see Richard Mansfield


 * "..Sure, but the world is bigger than CRUD apps, and even in CRUD apps, object mapping is more productive than hand written SQL slinging result sets around in procedural code. In particular the ease at which OO enabled pluggable programs is invaluable in customizing in different ways for different clients or aggregating data from multiple sources. OO isn't about modeling facts about the world, it's about modelling behavior; objects aren't just structs with some data...."

Object are structs with the the functions(behaviour) embedded inside the struct taking as its first parameter(self in python) the struct itself resulting in a restricted global. Procedural are functions(behaviour) outside the struct. In both cases you only have procedural programming. Facts and the real world don't exist inside of structs, only data types, functions aren't being "modeled", the struct is being mapped to an output via functions: this is its sole ontological destiny.

gnaritas
gnaritas on June 22, 2016 wrote:

I'm going to start with a few definitions because I can see we're not using the same ones.


 * Functional programming: programming in a style where functions are the basic building blocks of the program and are passed around as data to other functions along with raw data, i.e. Lisp, Scheme, Haskell. (note, functional languages are not necessarily immutable).


 * Pure functional programming: programming in a functional style as above, with the additional insistence on not allowing mutable state at all. i.e. (no language is truly pure because side effects are a must, but Haskell comes close).


 * Object oriented Programming: programming in a style where objects are the basic building blocks of the program with 3 basic features, late binding, encapsulation, and polymorphism allowing the hiding of raw data behind a message passing interface so that the program is centered around object behavior rather than object data. (note neither classes nor inheritance are necessary features of OO systems, they are simply common features)

Mike Acton insists that data is the only thing you are supposed to be centered around and that hardware is the platform, not software.


 * "....That's a bit of a misunderstanding of both interfaces and OO. Firstly, interfaces simply define what an object looks like, it's an implementation detail and has nothing to do with OO in general. The same applies to inheritance. Inheritance is simply one means of code sharing and is not a necessary feature of an OO system, neither Self nor Javascript for example, have inheritance in their object systems. One can also build a system that is entirely object oriented without once using an inheritance hierarchy once. Code can be shared via delegation rather than inheritance....."

Interfaces are cludges to work around the fact that multiple inheritance is broken(with the exception of maybe Eiffel but your Firefox browser will take 5min to boot if written in Eiffel). An interface is a struct without data types and only functions inside of it or "behavior" as our "software engineers" likes to call procedures. The data types are added in the derived objects, spawning to the right and left of the interface.

Dmitry Kazakov
http://www.dmitry-kazakov.de/
 * "....https://groups.google.com/g/comp.object/c/zwDE5f-r7Y8/m/N9M7N3EyVikJ Right, the structure of data would be too low-level to be able to capture behavior. As in mathematics, in OO the internal structure of objects is irrelevant and when considered, then only as an implementation detail to be abstracted away. OO deals with the structures of sets of objects exposing same behavior and relations between such sets...."

Dit Kazakov think in terms of the the "behavior" or functions taking as its first parameter the struct itself? What did he assume as the fundamental ontology(Noun).

comp.object 'topmind
https://groups.google.com/g/comp.object/c/zwDE5f-r7Y8/m/N9M7N3EyVikJ topmind

https://groups.google.com/g/comp.object/c/7E2YtfvXAxA/m/31D3lK_2LjUJ I happened to discuss that very example as part of my OOSC2 critique several years ago:

https://web.archive.org/web/20090829212053/http://www.geocities.com/tablizer/lib.htm

I generally proposed a "feature table" instead of hierarchies (which wouldn't surprise those familiar with my modeling philosophy). The traditional OO solution of subtyping is not sufficient enough and not as powerful as feature sets. Just about ANY non-trivial classification system will grow to be non-tree over time. Trees are limiting (unless one duplicates leaves, which is bad modelling if done often). Some OO fans may even recommend dynamic composition (HAS-A)instead of subtyping (but then they are reinventing an ugly navigational database which are the Go To equiv of structures).

Plus, some fuss over "wasting columns" that are not used for a parrticular instance. Modern RDBMS do not used fixed column widths internally and thus unused fields take very little or no bytes, depending on the implimentation.

Your complaints are too tree-based and based on 70's database technology. Get with the times and get with Set Theory.

Excerpts:

My business software experience tells me that anything dealing with variations (subtypes) MUST be flexible. In this example, new mediums (variations) were being added as I watched: They had videos, CD's, and even training software in their library. What new media and publication types will there be in the future? What about hybrids? What about a book that also contains a CD or video? [common for tech books] The mutually exclusiveness of traditional OO types is now a poor model for our "has X and Y".

Suppose videos were added as a publication type. "Length" (duration) is proposed as one of the new fields pertaining to videos. After several months go by, someone points out that Length can pertain to other publication types. For example, almost anything with paper can have "number of pages". Software can even have it's size in "K" or "megs" as it's length. (One might also want to think about having a "Unit_of_Measure" field to make it more open ended. Unit-of-Measure could be pages, minutes, megabytes, etc. The unit-of-measure could be tied to the item type so that it does not have to be retyped for every entry.)

In the OO tree approach, first the programmer will add Length to the Video subtype. Then when it is later agreed to have Length apply to other types as well, the programmer has to come back in and move the field Length back to the root class (Publications). In the feature- list approach, the "Field Administrator" only has to open up the type control table and make a few simple mouse or keyboard clicks. It is in essence, "subtype painting by number." (The "Field Administrator" may or may not be a programmer.)

It is often not practical to expect a programmer to come tromping in every time a new variation is added or changed. That can be expensive, especially if a new (turnover) programmer has to reverse-engineer the existing code, which they will not be familiar with. The feature-list approach is much more flexible. It is often also safer because one does not have to meddle in the code to add or change variations.

(end quote)

links
Oop concedere.net