Simula the misunderstood

by moodyharsh
simula-the-misunderstood

Simula the first async programming language ?

I think it is time to understand Simula for what it is than what Alan Kay, Bjarne Stroustrup, James Gosling tell us about it. Simula is the first event driven programming language. Simula is about events and processes. In Simula behavior was meant to be modeled by co-routines - not methods! Methods were about managing data structures.

Class -> Data
Activity / Process / Simulation -> Behavior

Yet for the past 30 years boffins are selling us bullshit that they can somehow model behavior without co-routines. You can try to fuck a giraffe to produce a goat but you can never model behavior with methods. It is impossible. Behavior is fundamentally about how events change state, with time. Because methods don’t have the notion of time you can’t model any behavior with it. Yet why is this lie repeated ? OOP as implemented by C++ and Java is an abomination. I still don't get how Bjarne Stroustrup did not steal co-routines from Simula. Zero Cost abstraction is largely a bullshit argument made up by Stroustrup to avoid new features in C++. Method calls are twice as slow and break ABI compatibility, where is the zero cost in classes ?

Objects are a lie. As a universal model objects absolutely can’t model processes like the actor model. Every OO pundit know that. And yeah, Fuck Martin Fowler too. It was perhaps easier for Alan Kay, Bjarne Stroustrup, James Gosling to fake simula than actually implement it. People fall for fakes easily. The market for fakes will always be bigger than the market for originals. I think thats the true meaning of the phrase “worse is better”. Fakes sell cheaper and can be made faster with more readily available materials. To say that inheritance is the biggest idea of Simula is wrong. Discrete event modelling is the core idea of Simula, not inheritance.

Without an event model you have nothing. Thats why you need CORBA / COM / Signals and Slots / Observer Pattern / Message Bus to do anything useful with objects. You are also never supposed to send object references anywhere. An object reference is a form of coupling. This is why you get all the dependancy injection mess. If you send an object n-levels down, you can’t add new operations since it’s already entrenched and it leads to circular references and memory leaks. You are also not supposed to read data from objects because the data can always go stale after you read it. Why not just provide hard encapsulation like process encapsulation in erlang ? Why not use C/UNIX processes instead of objects ?

Co-routines subassume CSP, Closures, Actor Model and even Melay State Machines. State machines are as fundamental to computers as motors are to engines. It of course made sense in Simula to build everything around co-routines. Yet what is the nonsense we practice today ?

Javascript, Erlang, Clojure and Golang are the true successors of Simula, not Java, C++ and Smalltalk. Maybe python too to a certain extent. The sad thing about all these languages is they fall into the trap of thinking coroutines are for concurrency and not modelling all behavior as state machines.

It is irrelevant how many Lambda Papers Guy Steele has written. First class co-routines are a more basic building block than lambdas. To simulate co-routines with closures you can do this,

https://cmichel.io/how-are-generators-transpiled-to-es5

How tedious. Why can’t they just use co-routines ? Continuations were introduced in 1998, 50 years after assembly programmers discovered and used them and now they are mainstream. In theory you can also simulate co-routines in C++ with function objects, but how many programmers are taught that this is the way to model real world behaviour ? Suspend / Resume is ugly to simulate with OO. Co-routines can implement the following patterns natively

  1. Actor
  2. Reactor
  3. Pipes / Filters
  4. State
  5. Iterator
  6. Asynchronous IO

How about diagramming ? With co-routines you can easily use state transition diagrams to design internals and data flow diagrams to describe the interaction between coroutines instead of the UML and thats all you really need. I think co-routines are the building block in SADT diagrams. Some more wonderous uses of co-routines as data transformers can be seen here in David Beazly’s tutorial.

How similar is the Simula model similair hierarchical state machines ? I have a hunch that they are closely related. State machines are the real deal in programming not functions and objects. State machines can model

  1. UI
  2. Protocols
  3. Language parasing
  4. Control Systems

with rock solid safety and stability.

Practically all engineering disciplines use state machines extensively, except software engineers and especially OO/FP programmers. State machines, actors and co-routines are central to programming and steam processing rocks. Lets build a language which supports them, oh wait we already did.

One of the biggest ironies of the programming world - despite the 70 years of structured programming propaganda to not use gotos, 50 years of OO propaganda on the use of objects for modelling and 200 years of propaganda by mathematicians on the foundational nature of functions … the most useful and more foundational construct is co-routines which is more useful and foundational than both, and was hacked together by assembly programmers using gotos for state transitions and stacks for thread memory.

In a parallel world we would all be using modular programming with co-routines, with strong contracts and actor model. Every one would be taught state machines and boolean algebra. You know, things that have actually worked. I consider the dark ages to have officially ended with the release of Golang, Clojure and Elixir. Event driven programming with state machine has always been the only real way to get things done.

There is more to programming that mindless saying everything is an object, like constraint programming which back to Sketchpad, logic programming, data flow programming and agent oriented programming. Data-Oriented Design / Entity Systems / Value types is a new paradigm based on the experience of game programmers. I find it similar to Linda and Black Board pattern and it has shown real world success.

Programming needs to be emperical. Programming languages implementors should stop wasting everyone’s time implementing OO without reading the original Sketchpad and Simula papers. Patterns that promoted sanity need to be recognized. You can’t model behavior with methods. You can’t model data either. SQL works. ER modelling works. We need to recognize that taxonomy is for organisation not modelling. Object Relational mismatch is real. By forcing the object model on everything, it makes understanding non OO models for data, which is most data … very difficult. Relational model is more generic as it supports references and is obviously more efficient. Can we have language syntax for Relational modelling ?

Further Reading

https://www.mn.uio.no/ifi/english/about/ole-johan-dahl/bibliography/the-birth-of-object-orientation-the-simula-languages.pdf
https://udidahan.com/2009/06/07/the-fallacy-of-reuse/
https://dreamsongs.com/ObjectsHaveFailedNarrative.html
https://twobithistory.org/2019/01/31/simula.html
https://dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your-software
http://harmful.cat-v.org/software/OO_programming/
http://www.softpanorama.org/SE/anti_oo.shtmlo
https://www.oocities.org/tablizer/oopbad.htm
https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
https://twobithistory.org/2019/01/31/simula.html
https://softwareengineering.stackexchange.com/questions/142327/what-did-they-call-object-oriented-programming-before-alan-kay-invented-the-term
http://stlport.org/resources/StepanovUSA.html
https://www.stroustrup.com/oopsla.pdf
https://homepages.ecs.vuw.ac.nz/~tk/publications/papers/function-object.pdf
http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf
https://www.emacswiki.org/emacs/StateMachine
https://www.state-machine.com/doc/PSiCC.pdf
https://norvig.com/design-patterns/
https://arxiv.org/vc/arxiv/papers/1008/1008.1459v8.pdf

https://www.youtube.com/watch?v=o9pEzgHorH0
https://www.youtube.com/watch?v=86xWVb4XIyE