211–220 of 407 posts
p.s. The hype predates even HN. I remember reading these stuffs on magazines. Holy crap, I'm old.
Just FYI, when this was written, "framework" was a buzzword. Everyone tried to write a framework for something, and tried to sell it over well-working libraries. The hype died down because it became obvious that frameworks are overly complicated and don't compose well. p.s. The hype predates even HN. I remember reading these stuffs on magazines. Holy crap, I'm old.
Earlier quoted context omitted.
That's the reason why CS classes and degrees exist. Or at least it should be. No company will pay you for several years just to learn complexity theory, write sorting algorithms, study schedulers, rewrite UNIX tools, understand hardware architectures, etc... They want you to be productive right away, and the shortest path is just to follow recipes with the latest framework. That's the point of education, universities…
This misses the mark. CS classes and degrees are akin to reading books about swinging hammers rather than just swinging the hammer.
Computer Science is akin to learning how to forge a hammer, what materials to use in said hammer, and then determining what size and shape is applicable for a given task.
Sometimes the specified hammer is made. Most times it is not.
"Swinging hammers" is rarely, if ever, considered.
Earlier quoted context omitted.
Its resonance may sustain because theres always people entering the field who are trying to build something, and either get caught up on a frameworks hypetrain or have fond enough memories using a given framework to build something quickly, and then getting burned trying to build something ambitious with a given framework because its opinionation proves to be too rigid one way or another, and a perpetual new influx o…
Which is precisely why a framework is necessary, but knowing how to write what you want without the framework is even more necessary. If you only know how to code within the constraints of the framework, you're gonna fail for anything non-trivial. If you try to ditch frameworks entirely, same deal.
Actually knowing how to code is important, but so is knowing how to take a problem and implement it without ever doing anything the framework authors didn't think of.
You might need a nasty hack like exporting a bitmap to a ramdisk and then importing it again to read a pixel value, to avoid messing with some nasty AI, or you might have a case where performance matters and you do want to mess with the buggy undocumented crap API.
It's almost like the idea that language shapes how you think. Frameworks are kind of like subsets or dialects of programming languages. If you actually know the framework well, you can often do stuff that seems like it would need low level control, in an idiomatic way that doesn't fight the framework.
I was thinking of building a Bluetooth device you can leave somewhere that alerts your phone should it be disturbed, as a portable security system. However the PineTime, an open source smartwatch, has all the features needed for $25, cheaper than almost any small quantity prototype.
Not sure if I'll ever get around to that project, but if I do, I probably won't be building any single function hardware just for it, especially not without being sure the whole idea is worth it.
Earlier quoted context omitted.
One of the very first times I was paid to professionally develop software for someone else I totally fucked it up by trying to build some kind of “modular” “reusable” contraption, that in reality was a vague collection of ill-defined ideas for what I wanted to make. I have since come to believe that this is a trap that many people fall into. Even a colleague of mine at my current job might be sort of in this track hi…
Overengineering confessions. He that is without sin among you, let him cast the first stone at her. There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously. We don’t really have g…
Earlier quoted context omitted.
What with Google and now GPT, it's critical that your framework is well talked about on the internet. Otherwise searching "show me some code to do XYZ using the frankenframework" will come up empty and then it's game over for your framework. That makes building your own framework even less of a good idea than it used to be.
OTOH, if you build a framework/library, you might be able to use AI to generate thousands of examples of using your framework/library, then publish those examples. If it's too difficult for the AI to generate correct examples, then that may be a sign of what parts would also be difficult for humans. We may in fact see an explosion of new frameworks and libraries that use this strategy.
Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking framewo…
Earlier quoted context omitted.
Overengineering confessions. He that is without sin among you, let him cast the first stone at her. There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously. We don’t really have g…
Good abstraction is the foundation for most of what we do. Bad abstraction is worse than no abstraction. Not everything needs to be abstracted. Ontology is bad abstraction (is a has a stuff). Some people are bad at abstraction and some people are bad at writing business code; Both can be good coders.
Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?
Earlier quoted context omitted.
And interestingly, your argument also falls apart in the same way as the framework argument. It might make the average developer more productive on an average project. But most projects are not average, and neither are most developers. Everyone has some unique combination of strengths, just like every project has special cases that don’t fit within the box of a framework. A framework is great if you don’t know much a…
> But most projects are not average I call bullshit. Most projects are average by definition. Otherwise that wouldn’t be the average.
Earlier quoted context omitted.
This misses the mark. CS classes and degrees are akin to reading books about swinging hammers rather than just swinging the hammer.
Life pro tip...don't enroll in a university where your CS degree is akin to reading books about swinging hammers rather than actual hammering.