The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,860 other subscribers

Archive for the ‘Design Patterns’ Category

« Previous Entries

Alan Turing Wrote Object-Oriented Code In C And Ran It On BEAM – De Programmatica Ipsum

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, had collect and select methods which were the grandparents of our more common map and filter functional 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 »

Kevlin Henney on encapsulating and restricting Mutability of State to improve software quality

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 »

Every conversation about dependencies since 2020 uses the same XKCD 2347 based image, which is a problem on multiple levels

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”.

Read the rest of this entry »

Posted in Awareness, Conference Topics, Conferences, Design Patterns, Development, Event, Fun, Software Development, Systems Architecture, Technical Debt, xkcd | Leave a Comment »

The binary tree actually exists!!

Posted by jpluimers on 2024/05/02

Yup, binary trees are real:

Read the rest of this entry »

Posted in Data Structures, Design Patterns, Development, Software Development | Leave a Comment »

Avoid a software rewrite: it usually brings more trouble and puts you at a distance to competitors

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:

Read the rest of this entry »

Posted in Agile, Code Quality, Design Patterns, Development, Software Development, Systems Architecture, Technical Debt | Leave a Comment »

SignalR and Design Patterns for .NET developers

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 »

Very different views on the repository pattern

Posted by jpluimers on 2021/07/20

–jeroen

Read the rest of this entry »

Posted in .NET, Design Patterns, Development, Software Development | Leave a Comment »

How many dependencies does your development eco system have?

Posted by jpluimers on 2021/02/03

About 5 years after the disaster around npm and left-pad, I wonder

  1. how many dependencies on packages or libraries your software has,
  2. how many of them have a good or excellent test suite,
  3. how many of these you are in full control of determining the exact version used and the location it is uses from.

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:

  • Functions are not packages
  • Third party problems
  • Strive for few dependencies

and these quotes:

  • React, Babel, and a bunch of other high-profile packages on NPM broke. The reason they broke is rather astounding:A simple NPM package called left-pad that was a dependency of their code.
  • some of the things that I observed:
    • 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’s its entire 1 line of code:return toString.call(arr) == '[object Array]';
    • There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
    • A fresh install of the Babel package includes 41,000 files
    • A blank jspm/npm-based app template now starts with 28,000+ files
  • frameworks create a “core” library of basic functionality. Such a library is vetted by the creators of the language and pretty much guaranteed to be correct and bug-free.
  • if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code. Any of these would make a great code screening interview question to determine whether or not a candidate can code.
  • Take on a dependency for any complex functionality that would take a lot of time, money, and/or debugging to write yourself. Things like a database access layer (ORM) or caching client should be dependencies because they’re complicated and the risk of the dependency is well worth the savings and efficiency.
  • ask the React team how well their week has been going, and whether they wish they had written those 11 lines for left-padding a string themselves.

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 »

Mark Struberg on Twitter: “My key takaway is: “You can fix most conceptual problems of a Monolith by converting to MicroServices. And you can fix most conceptual problems of MicroServices by making a Monolith out of it”.

Posted by jpluimers on 2020/09/10

I wonder what the state of monoliths versus microservices is right now. Likely somewhere in the middle of SOA and Client/Server (:

[WayBack] Mark Struberg on Twitter: <<My key takaway is: “You can fix most conceptual problems of a Monolith by converting to MicroServices. And you can fix most conceptual problems of MicroServices by making a Monolith out of it”.… >>

–jeroen

Posted in Design Patterns, Development, Software Development, Systems Architecture | Leave a Comment »

Nick Hodges on SOLID in TypeScript using Angular

Posted by jpluimers on 2020/08/18

For my link archive: after a long history of Delphi programming, Nick Hodges did a

SOLID series with TypeScript using Angular

They explain these SOLID – Wikipedia concepts:

  1. Single responsibility principle – Wikipedia
  2. Open–closed principle – Wikipedia
  3. Liskov substitution principle – Wikipedia
  4. Interface segregation principle – Wikipedia
  5. Dependency inversion principle – Wikipedia

After that, he did a series on:

[WayBack] Angular 101 – Angles and Types

More Angular and TypeScript

Since Nick likes that combination so much:

and his TypeScript series start:

and what started as a trilogy in 5 parts of his [WayBack] Angular 101 – Angles and Types became much longer:

Related:

DIID update

Nick also updated the public repository with the changes that did make it in his Dependency injection in Delphi book earlier:

–jeroen

Read the rest of this entry »

Posted in Design Patterns, Development, Scripting, Software Development, TypeScript | Leave a Comment »

« Previous Entries