Innovating beyond libraries and frameworks
nilsnh.no
nilsnh.no
They deserve better.
Mass mobilisation of people able to catch fish has enabled businesses to join the digital landscape.
It may be true that we've not taught people in a way that's best for their long-term prospects, but had the computer science industry taken the approach of other engineering, nursing or even accounting, with strict legislated terms and certificates, and exam boards controlling quota of people able to go into computing, then perhaps it would be an ivory tower of well built and engineered software.
But it would also have risked leaving most businesses behind and things wouldn't have accelerated nearly as fast.
What the end user ultimately wants to do is nothing that special: they either want to enter and edit data in some medium, or process existing data. What that "looks like" just depends on what layer they try to do it in.
For example, you could do your photo editing by writing code that loads the file and pushes bits. You could do similar on the command line by invoking Imagemagik. Or you could use a dedicated photo editing app. Or you could use a photo editing feature baked into a social media app.
Advancing age eventually makes one jaded about this, from two directions: "Back in my day, you edited photos in a darkroom, with toxic chemicals!" And then, more philosophically: "The point of you editing the photo is to gain clout with your buddies or sell some product, isn't it? So having the latest and greatest photo editing feature is just a fashion."
But of course, at some point in your life you're a user who wants to buy some version of this feature, but you're doing it without knowing what you want, exactly. So you ask around and end up with something.
And that doesn't really change just because you invoke a compiler or build system to access the feature. That's just the particular way in which we've professionalized software "development". At the bottom layer we have some Atlas effectively lifting the world by implementing the base algorithms, and the way in which they do so sets up the dependency structure of everything else. Atlas usually doesn't get hired to do his job: he implemented the thing 15 years ago as a research project and then moved on. Everyone depending on him is just some mercenary saying they have the best solution for your photo editing needs.
This is very well put. I've been thinking this way for some time. Unfortunately, too many people choose patterns over principles and frameworks over libraries.
Patterns applied without principles can lead to disastrous consequences.
The problem with frameworks is that there's lock-in so they're less flexible and sometimes they coerce you into making sub-optimal decisions.
This is an excellent point, but I think it's always worth considering that the tradeoff isn't between third-party security vulnerabilities and no vulnerabilities; it's between third-party security vulnerabilities and first-party security vulnerabilities.
It's up to your team to decide if you have the capabilities in-house to deal with those. If not, trusting to the wisdom of crowds may often be a better solution. (At the very least, if you're rolling your own crypto solution and not publishing it, take a strong look at why you're doing that and be very sure you aren't falling victim to smartest-kids-in-the-room syndrome).
Cryptography is something I’d leave to standard libraries. However, when it comes to authentication it might not be that hard to implement some cookie or token logic as long as the actual cryptography is handled by some well tested library.
Library vs framework vs DIY seems domain specific.
If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that. Unit testing also works well as structure you plug tests into.
If parts of your thing occur elsewhere but the overall structure doesn't, probably want libraries for the common parts. Equally use libraries for when the frameworks that fit don't look good enough.
If you can't find an adequate library, DIY time.
Write your own language seems difficult to justify economically but I really like the domain/language fit you can get out of it.
> If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that
I agree, though that often comes with some costs and tradeoffs like I tried to outline in the article.
At one point choosing java enterprise was about signalling ambition and competence. Nowadays service architectures/cloud etc serve this role of "decorative" tech choices. These types of choices factor out responsibility (of end results) from individuals while expanding their "organizational footprints" and giving their CVs a fashion make-over. Those are the incentives.
There would need to be counter-incentives.
But this is not in the interest of "architects", "system owners" or "buyers". They want programmers to be replaceable, not stakeholders.
To "architects", frameworks/libraries make programmers replaceable, and programmers need frameworks/libraries to be marketable.
>"This website has poor reputation according to Web of Trust. >www.netlife.com >Users have identified the following issues: Spam
I dont think most people here take WoT warnings that seriously but it might be good for the author to be aware of it.
I'm also curious about how simple we can make self-hosting on bare metal hardware. These days I've been looking a bit into Gnu Guix where you can define a whole server system using lisp syntax. My current explorative sideproject is to try and setup a Gitea service with Guix on a Raspberry PI.