Engineering: The unified OOP paradigm

❝Resolving conflicting, divergent notions of OOP with a unified OOP paradigm❞ disclaimer I mention a few names of other people, but please understand that this is my interpretation of their work and the various concepts involved. Furthermore, I am taking quite a leap in this attempt to unify different notions. I might be wrong. I believe that we cannot master OOP programming languages until we comprehend the (design) capabilities of OOP. TL;DR Three distinct OOPs, The unified OOP paradigm, Foundation, Conclusions.


Read more ...

Engineering: The “minimal-objects” approach to OOP

❝Understanding the role of simplicity in object design (Object-Oriented Programming)❞ A few years ago, I looked into Object Oriented Programming and in particular object orientation – the paradigm – in a series of articles that look into Object Oriented Programming. These articles look primarily at the use of OOP in programming, identifying and discussing key points on how OOP works, should work, and deviations from how it is typically used. This focuses on the individual class, the way it is designed and implemented, the characteristics, and the benefits you get from doing it right vs.


Read more ...

Engineering: References

❝References on simplicity in software engineering❞ These are references that I have used over the years to build up a mental model. This is far far far from complete. These are just the ones that came to mind. In particular, there must be 10+ references missing regarding OOP programming, the do’s and don’ts, the good and bad. Topics Inter-process communication mechanisms, (enterprise) patterns, software, considerations ZeroMQ, In-memory message queues, Caches Concurrency/parallelism coroutines user-space scheduling, threading Python generators (many sources) concurrency vs parallelism, design vs execution blocking vs non-blocking channels in Go async/await, promises/futures Why OOP does/doesn’t suck Error handling: exceptions, monadic, assertions, abort/panic checked vs unchecked exceptions value of crashing/aborting/panicking sentinel return values for errors insight into errors, information the nature/place of error handling in control flow Architectural and design decisions of open source projects: prioritized features distinguishing features/aspects Function programming: monadic patterns Maybe / Option / Optional Trade-offs, mitigating trade-off-forced decisions: persistence or performance limited use of language features, memory sources, etc.


Read more ...

Engineering: Introducing simplicity to engineering

❝Introduction to the series on Simplicity in engineering❞ In this series of posts, we look at the prevalence of simplicity in engineering, in particular Computer Science and more generally in programming. This series in founded on the article that defines simplicity. In the post, I pose rather strong claims about the definition of simplicity (and its dual: complexity). I will assume the definition of simplicity is complete (i.e. the three dimensions cover all aspects of simplicity/complexity) and sound (i.


Read more ...

Object Oriented Programming: (implicit) acknowledgement of the missing access modifier

❝The missing access modifier is resolved using a static analysis and @ForOverride-annotation❞ In 2016, I noticed a curiosity about Java’s access modifiers: there is no mechanism to express that a method may only be overridden or called from within the child classes. This may be an important feature, as there are designs where you would want to allow overriding – or in particular – extending in child classes, without the risk of it being used from within the package in unexpected ways or at unexpected times.


Read more ...

Prematurely abandoning simplicity

❝Premature optimization, premature generalization, premature expansion, ... appreciating simplicity❞ This post further explores simplicity as we previously defined it. We will look at engineering concepts premature optimization and premature abstraction to see how they relate to simplicity. I was reminded, as so many times, by quotes and tweets about premature optimization and – now more and more – premature generalization. People who try to best understand how to approach programming, try to find some intuition or even some rules on dos and don’ts.


Read more ...

Concluding the definition of 'simplicity'

❝Bringing the journey of defining 'simplicity' to its natural conclusion.❞ In previous blog posts, we explored a possible definition of ‘simplicity’. We started out with a definition. We explored how broadly we might be able to apply this definition. It is general enough to apply outside of software, or computer science, or – for that matter – STEM. This will be a concise summary of the findings documented in previous blog posts. Motivation One should “simply do this”, or “just think of a simple solution”, or “keep it simple”, or you name it.


Read more ...

Evaluating 'simplicity'

❝How to answer the question: 'Can we make it any simpler?'❞ After a lot of talk about simplicity, let us make things practical. This post is intended to highlight the concerns of each of “the components of simplicity” as I previously defined them. We make things practical with questions and examples, instead of abstract descriptions. Simplifying is a two-step process that may loop around as long as the question itself can be improved based on further insights, i.e. goal is an absolutely simple answer.


Read more ...

Absolute and relative simplicity

❝Whether or not you are allowed to rephrase the question itself.❞ In post “Questioning the scope of simplicity” we pondered whether question is relevant when considering if something is “simple”. In it we pointed out that given a complicated question, e.g. a question that is overly-broad, we cannot expected to give the simplest answer possible. The answer can only be as simple as the question it is stated to answer, and if you can rephrase the question to be more specific, then your answer may become simpler.


Read more ...

Bad example demonstrates failure in complexity

❝How I failed to "fix" a simple example illustrating simplicity.❞ I decided to demonstrate the three components of simplicity, that I was writing about in posts The definition of simplicity, with an example in mathematics. It is supposed to be as trivial as possible, so as not to distract from the concept “simplicity” in itself. There was some mathematical ambiguity – which really is not relevant for illustrating the idea – but it kept bothering me. The simple example In posts The definition of simplicity and Refining ‘simplicity’, I go into we can break down the concept of simplicity in three components, concerns if you will: specialized, unoptimized, reduced.


Read more ...