I've been having a delightful time these last couple years working with Jax (the machine learning thing), which takes the DOTADIW stance. The philosophy is to get rid of frameworks, and replace them with libraries developed with DOTADIW in mind. This leads to better separation of concerns (amongst the various libraries), fewer leaky abstractions, sane-r, better thought-out APIs, and so on. All kinds of good.
Kernighan and Pike were right: Do one thing, and do it well
11–20 of 256 posts
Re: Kernighan and Pike were right: Do one thing, and do it well
#12Its an insightful read and the final graph analogy seems very apposite. But here is the rub: if microservices is a general graph pattern, it includes all the other patterns (likear, hub and spoke etc) as these are all just particular graphs. In other words, you could implememt unix pipe like or plugin like microservices by applying certain constraints.
Is that relevant, though? An undirected cyclic graph is a superset of all other data structures[1], yet we still differentiate between them and choose the most suitable.
[1] And can be used to build all other data structures. A tree is a directed acyclic graph, a list is a tree with no more than one child per node, etc
Re: Kernighan and Pike were right: Do one thing, and do it well
#13Earlier quoted context omitted.
Not only is COM still around, it is the main delivery mechanism for Windows APIs since Vista. Agree with UNIX worship point, I also had it, I was young and naive, lacking experience in the history of computer systems.
Wow, I didn't realise. I haven't paid attention to Windows APIs for a long time. I really thought it would have died a long time ago.
That is what people outside Windows keep thinking.
After WinDev managed to botch Longhorn efforts, its .NET ideas were redone in COM for Vista, and it has been like that ever since.
WinRT/UAP/UWP, is basically COM with a new base interface IInspectable, .NET metadata instead of TLB files, and app boxing.
And it is the foundation of WinAppSDK, whose goal is to port UWP subsystem into plain Win32, although their current execution leaves a lot to be desired.
Re: Kernighan and Pike were right: Do one thing, and do it well
#14[dead]
Re: Kernighan and Pike were right: Do one thing, and do it well
#15The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusable parts. It's one of the key ideas in functional programming, and it's somewhat core to object-oriented programming. (OO is too big to be able to claim their is a consistent philosophy behind it.) But ... firstly, let's stop with the Unix worship. They didn'…
Let's just be careful what we call Unix though. In SVR4, I don't think "ls" had that many options. It didn't even have colour (not that I would know; my Wyse 60 could only have Green, Orange or White text... and the colour was set in the factory).
It's the same for many programs that started small but grew loads of knobs with age. You can't claim that this was the Unix vision, because what we call Unix today isn't even technically Unix.
I'm not saying Linux is bad or anything; I'm just pointing out that it's much more organic than Unix ever was, and that the resulting system is not necessarily carefully orchestrated.
Re: Kernighan and Pike were right: Do one thing, and do it well
#16Good article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…
To me enshittification is when the overall usefulness of a piece of software starts going down as more money is attempted to be squeezed out of its users. Agree that it's not a technical phenomenon
Re: Kernighan and Pike were right: Do one thing, and do it well
#17These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft added is because they're actually not composable everywhere that matters.
edit: typo
Re: Kernighan and Pike were right: Do one thing, and do it well
#18Earlier quoted context omitted.
Not only is COM still around, it is the main delivery mechanism for Windows APIs since Vista. Agree with UNIX worship point, I also had it, I was young and naive, lacking experience in the history of computer systems.
Wow, I didn't realise. I haven't paid attention to Windows APIs for a long time. I really thought it would have died a long time ago.
The core of COM is about allowing binary code to be used from any language through a standardized interface.
As pjmlp mentioned, this part was very successful and all new Windows APIs are based on it.
The COM which failed and which you are thinking about was related to OLE and the idea of embedding Excel sheets inside Photoshop drawings, ...
Re: Kernighan and Pike were right: Do one thing, and do it well
#19These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…
Did you read the article? The entire last half is how to apply it to UIs and what that looks like (Obsidian, Canva, etc).
Re: Kernighan and Pike were right: Do one thing, and do it well
#20Good article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…
That caught my attention too. The misuse is especially strange because the author both cites Doctorow and links to a definition in line with Doctorow's usage, before then using it in a completely different sense