Posted by jpluimers on 2026/11/11
I used the below links to prepare for my MVVM talk a few years ago (which is linked at my blog post Delphi MVVM links).
Originally, I wrote this post in 2014 as a draft and just found out I never published it. Back then I didn’t add archived links because link rot wasn’t such a big thing. Nowadays it is (more than half the originals links died because of link rot), so I added archived links where possible. All in all just one link that was not archived at all – not a bad score!
Posted in .NET, C#, Delphi, Design Patterns, Development, Java, Java Platform, MVVM, Software Development | Leave a Comment »
Posted by jpluimers on 2025/07/16
I originally missed this as back then I was in the midst of managing trouble in my parental family, unaware I was already having rectum cancer. Then things went fast, not even including the Covid-19 years, so I was glad last year I got reminded of this mid-2019 article:
[Wayback/Archive] Alan Turing Wrote Object-Oriented Code In C And Ran It On BEAM – De Programmatica Ipsum writes a lot of interesting things on programming paradigms, starting with
In his rare 1994 book “Object-Oriented Programming In C” Axel Tobias Schreiner explains how to do inheritance, class methods, class hierarchies, and even how to raise exceptions using nothing else than pure, simple, pointer arithmetic-filled, ANSI C.
then arguing basically most of not all modern languages share the majority of programming paradigms and all these paradigms are repeats of the past:
These days, we are using the offsprings of multiple programming paradigms having unprotected sex with one another in a thoughtful orgy. PHP, C#, Perl, C++ and even Visual Basic have all closures, lambdas or anonymous functions now. F# and Scala can instantiate any class included in their corresponding vendor-provided frameworks. JavaScript implements functions as objects with a single method.call(). Haskell comonads are actually objects. Swift 1.0 implemented instance methods as curried functions.But none of this is new. Smalltalk, arguably the precursor of object orientation, hadcollectandselectmethods which were the grandparents of our more commonmapandfilterfunctional friends.
What sets modern languages apart is that they the majority covers all the paradigms you might need, just differing in how well they support the paradigm-du-jour.
It means programming language wars should have been a thing of the past for about two decades now.
Please let that sink in.
Oh: if you look for that ANSI C book, here it is: [Wayback/Archive] https://www.cs.rit.edu/~ats/books/ooc.pdf [Wayback PDF View/PDF View]
Via: [Wayback/Archive] De Programmatica Ipsum: “”In his rare 1994 book “Object…” – mas.to
--jeroen
Posted in .NET, C, C#, C++, Cloud, COBOL, Containers, Design Patterns, Development, Docker, Erlang, F#, Go (golang), Haskell, Infrastructure, Java, Java Platform, Kotlin, Kubernetes (k8n), ObjectiveC, OOP (Object Oriented Programming), Perl, Scala, Scripting, Software Development, Swift, VB.NET | Leave a Comment »
Posted by jpluimers on 2025/06/04
Important read (5 minutes or so): [Wayback/Archive] Restrict Mutability of State. When it is not necessary to change, it is necessary not to change… | by Kevlin Henney | Feb, 2025 | Medium
Via [WaybackSave/Archive] Kevlin Henney on X: “Blogged: Restrict Mutability of State “What appears at first to be a trivial observation turns out to be a subtly important one: a great many software defects arise from the (incorrect) modification of state.” “
--jeroen
Posted in Conference Topics, Conferences, Design Patterns, Development, Event, Software Development, Systems Architecture | Leave a Comment »
Posted by jpluimers on 2024/08/01
The below picture is a modification of [Wayback/Archive] 2347: Dependency – explain xkcd
Title text: Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.
It actually emphasises the problem both that [Wayback/Archive] xkcd 2347: Dependency is way too optimistic, and that everyone uses that to point out dependency issues or worse as a thought-terminating cliché .
The second problem amplifies itself by increasing the popularity of the comic, and the attracts people to use it even if they hardly know about dependencies.
In turn it diminishes the meaning of it, kind of making it more optimistic by basically amplifying the message “there is just one really fragile project our design/infrastructure depends on” (the infamous “A project some random person in Nebraska has been thanklessly maintaining since 2003”).
The sad reality is that this single fragile project is just not true. Modern development and infrastructure systems usually are underpinned by package managers installing the complex graphs of dependencies of which dozens, heck thousands are maintained for “free” by, more often than not, a single worn out maintainer per dependency.
It’s just that over the last few decades usually only one such package at a time posed a serious problem. But with dependencies on very small building blocks, the amount of blocks is rising as is their usage. Just two examples out of the Node JS world (mind you, each development and infrastructure stack lives in comparable worlds):
Mind you, these links are 2021 and 2022, so the numbers have increased.
Many think such problems are limited to programming errors, but over the last decade these have become the tip of the iceberg. The real problems now are that maintainers are fading away as they have for instance been worn out for too long, or simply are aging. So what we have seen over the last decade is the rise of supply chain attacks.
One such example was the XZ utils backdoor which was, by sheer luck because one guy tried to investigate why connecting over ssh had become much slower than before, barely detected in time. It had a CVSS score of 10.0, the highest possible score.
So be prepared that the below picture will have “your business structure” on the top, and towards the bottom a bunch of small fragile pillars with the text “many projects, each maintained by a worn out person on the verge of collapse”.
Posted in Awareness, Conference Topics, Conferences, Design Patterns, Development, Event, Fun, Software Development, Systems Architecture, Technical Debt, xkcd | Leave a Comment »
Posted by jpluimers on 2024/05/02
Posted in Data Structures, Design Patterns, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2023/11/22
[Wayback/Archive] lisacrispin on Twitter: “👇 This. If you want a new architecture, use the strangler fig pattern, and as he says in the thread, do it in prod. If you spend all your time rewriting, and your competitors spend that time adding new features for customers, your product will be in trouble.” / Twitter pointed me to the below thread.
The urge of rewrite often comes from a feeling of too much technical debt to carry. Preventing that technical debt in the first place would make this feeling go away in the first place so please strive for bringing down and limiting technical debt in the first place.
More about the above tweet further on in this blog post, but now back to the “rewrite everything” pit many fall into.
I saved the whole thread in [Wayback/Archive] Thread by @andrestaltz on Thread Reader App – Thread Reader App of which this are a few highlights:
Posted in Agile, Code Quality, Design Patterns, Development, Software Development, Systems Architecture, Technical Debt | Leave a Comment »
Posted by jpluimers on 2023/08/22
https://leanpub.com/b/signalr-and-designpatterns-for-dotnet-developers/c/Ap5p8r8xJwd9
Via
Posted in .NET, Design Patterns, Development, R (statistics/graphics), Software Development | Leave a Comment »
Posted by jpluimers on 2021/12/16
After I did conference presentations and wrote a magazine article and in 2013 about Delphi MVVM using DSharp, I saw a 3 articles in 2018, then I went through a big rollercoaster involving rectum cancer treatment.
After recovering, I found that there is one commercially project working on an MVVM framework implementation.
So here are some links on MVVM from new to old:
In my experience experimenting with MVVM and other three- and four-letter frameworks, I found a recurring concept is “convention over configuration”. This relies heavily on having matching names in the various layers.
There you see a big drawback in the Delphi compiler: it lacks a NameOf expression, which means a lot of literal strings ending in your code. Few of the MVVM frameworks have good logging explaining when literals mismatch.
The C# compiler also took a while (until C# version 6 in 2015) to get one, but now supports the [Wayback] nameof expression – C# reference | Microsoft Docs. Some more documentation about this:
Furthermore, the Delphi compiler lacks helpers on interfaces and helpers for generics (heck, I would actually want full extension methods) and generic parameters for methods on interfaces (which is different from the generic parameters on the interface declaration itself). This lack of these features often cause for convoluted syntax to workaround this. Stefan explains the first lacks more clearly in [Wayback] Delphi sorcery: Why no extension methods in Delphi?.
Requests for the nameof expression and interface helpers have been there since at least 2015:
--jeroen
Edit 20261105: more categories
Posted in .NET, C#, C# 6 (Roslyn), Delphi, Design Patterns, Development, MVVM, Software Development, Spring4D | Leave a Comment »
Posted by jpluimers on 2021/07/20
–jeroen
Posted in .NET, Design Patterns, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2021/02/03
About 5 years after the disaster around npm and left-pad, I wonder
The disaster was well phrased in [WayBack] NPM & left-pad: Have We Forgotten How To Program? – David Haney – Blogging my experiences as a developer and engineering manager. of which these topics:
and these quotes:
return toString.call(arr) == '[object Array]';Via: [WayBack] “There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here… – Elke Stangl (elkement) – Google+
Related:
–jeroen
Posted in Design Patterns, Development, Software Development, Systems Architecture | Leave a Comment »