61–70 of 214 posts
A significant amount of everything is done by superstition.
Still, important to be occasionally reminded of your own assumptions and corner-cutting.
I think a better title might be "A vast majority of programming is done at a level of abstraction that this author is slightly uncomfortable with". If you work in Java or Ruby or Python or C#, or even C++ all day with say, an IoC container for argument's sake, you're certainly not constantly thinking "okay this interface will be resolved to this type, which has these dependencies which will be resovled to these types…
I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".
Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped.
This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, they go with the "good enough" solution, build stuff off of it, and by the time "the right thing" comes along, all the momentum has shifted to its crappy competitor. A bunch of crappy software gets built on top of that, and as a result, we end users get the worst thing that could possibly work.
But work it does. Maybe it's worth a shift in perspective to be grateful for the stuff that works rather than worry about the stuff that doesn't quite work right.
If you work from the specifications for a library, you'll probably find that some of the documented features don't work. If they weren't used by some "framework", or mentioned in a how-to book, they probably haven't been exercised well.
Earlier quoted context omitted.
Why would you ever have a function with a name that long in the first place? Also, there are many more ways of dealing with readability: try different formatting and indentation rules, wrap lines manually where you think it makes sense and so on. As for your example, even the lowly C let's you do something like this: int (*short_name)(int) = &veeeeery_long_and_ugly_and_unnecessary_function; if(short_name(1) == 2) { p…
Explicit function naming requires slightly longer function names, but you can actually read a program and get a sense of what is happening. Give me long function names over short ones any day. In my book, 5 words is a little long, but not out of bounds.
How long identifiers are acceptable depends on a language. With languages without namespacing or modules you obviously have to use some naming convention so that there are no name conflicts and this makes your names longer. I'd say 5 words is ok in this case.
But I'm not arguing against long names of things: on the contrary, I like having names as descriptive as possible. OTOH, too long names are also bad, because they make the code less readable and harder to work with. Like almost always it's a matter of balance: you need to know when to stop adding words to a name. I think that "name is too long when it starts making other names in the same line much harder to spot" is a good heuristic for this.
Earlier quoted context omitted.
I think this is more commonly called "cargo cult programming", defined by Wikipedia[1] as: "the ritual inclusion of code or program structures that serve no real purpose". [1] https://en.wikipedia.org/wiki/Cargo_cult_programming
I think there's a significant distinction here to be made between "configuration" and "programming". Do I copy/paste swaths of code that I don't understand and put them in my programs? No, absolutely not, because each line is one I can reason about and want to understand. But do I copy/paste swaths of configuration files / init scripts / etc, without understanding the implications of every single configuration? Yes,…
Earlier quoted context omitted.
I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".
"A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors" Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped. This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, the…
Good Enough is our main design goal. Anything more than good enough means you're wasting resources.