[deleted]
Wheel Reinventor’s Principles (2024)
51–60 of 101 posts
Re: Wheel Reinventor’s Principles (2024)
#52Like every single software development principle, this phrase really needs to be explained with more context and considered with more subtlety than the usual "It's best practice" advice, for a number of reasons (some of which are stated in the article) of which I think the following two are the most important: Firstly, if you want to actually understand how the 'wheel' is invented then yes, you should re-invent it. T…
Sometimes when reinventing the wheel, you realize that pot-holes suck. Learn to appreciate the wheel and reinvent the road. Learn to appreciate the road and reinvent the rocket.
I guess I'm walking home.
Re: Wheel Reinventor’s Principles (2024)
#53> Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time.
I would like to work with this person.
Re: Wheel Reinventor’s Principles (2024)
#54More thoughts about reinventing the wheel: - Did YOU invent the last wheel, or any before it? If not, then you will make the same mistakes the last inventor made. Until you make a bunch of wheels, you'll probably suck at it. - You learn more by studying old wheels than trying to bang one out yourself. Study the principles behind the designs rather than shooting from the hip. This is why we study medicine, science and…
Good points, all of them.
Especially the last one is just a painful reality of the process. I think it's somewhat similar to the scientific method in that regard. Often your hypothesis is just false, but that does not make the attempt less valid.
Re: Wheel Reinventor’s Principles (2024)
#55Re: Wheel Reinventor’s Principles (2024)
#56Earlier quoted context omitted.
The big caveat is a big one. Choose your battles wisely! There are plenty of things that look simpler than an established library at first glance (I/O of specialized formats comes to mind quickly). However, a lot of the complexity of that established library can wind up being edge cases that you actually _do_ care about, you just don't realize it yet. It's easy to wind up blind to maintenance burden of "just a quick…
> I/O of specialized formats comes to mind quickly The classic "I'll write my own csv parser - how hard can it be?"
>
The classic "I'll write my own csv parser - how hard can it be?"
I did as part of my work. It was easy.
To be very clear: the CSV files that are used are outputs from another tool, so they are much more "well-behaved" and "well-defined" (e.g. no escaping in particular for newlines; well-known separators; well-known encoding; ...) than many CSV files that you find on the internet.
On the other hand, some columns need a little bit of "special" handling (you could also do this as a post-processing step, but it is faster to be able to attach a handler to a column to do this handling directly during the parsing).
Under these circumstances (very well-behaved CSV files, but on the other hand wishing the capability to do some processing as part of the CSV reading), likely any existing library for parsing CSV would likely either be like taking a sledgehammer to crack a nut, or would have to be modified to suit the requirements.
So, writing a (very simple) own CSV reader implementation was the right choice.
Re: Wheel Reinventor’s Principles (2024)
#57Like every single software development principle, this phrase really needs to be explained with more context and considered with more subtlety than the usual "It's best practice" advice, for a number of reasons (some of which are stated in the article) of which I think the following two are the most important: Firstly, if you want to actually understand how the 'wheel' is invented then yes, you should re-invent it. T…
The usual allegoric rebuttal is to show how many types of wheel there are, and how wheels have improved over time. The wheel as a basic concept is to mount a rotating circular shaped thing on a platform for moving. The first wheels were made of wood, at some point spokes were introduced, then other materials. Many more innovations (many of them mutually exclusive) are required to realize a formula 1 car, or a ralley car, or a bus, or a plane.
Re: Wheel Reinventor’s Principles (2024)
#58> Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time. I would like to work with this person.
> > Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time.
> I would like to work with this person.
Before you make such a bold claim, consider that this way of doing programming leads to an accumulation of knowledge that is barely transferable if you switch jobs.
I would claim that a central reason why many programmers like third-party dependencies is that being knowledgeable in these is a set of skills that is better marketable and transferable to jobs at other companies. In other words: applying these approach to programming can easily result in a career trap.
Re: Wheel Reinventor’s Principles (2024)
#59Earlier quoted context omitted.
> I/O of specialized formats comes to mind quickly The classic "I'll write my own csv parser - how hard can it be?"
What are some footguns? It does seem easy
It's easy if the fields are all numbers and you have a good handle on whether any of them will be negative, in scientific notation, etc.
Once strings are in play, it quickly gets very hairy though, with quoting and escaping that's all over the place.
Badly formed, damaged, or truncated files are another caution area— are you allowed to bail, or required to? Is it up to your parser to flag when something looks hinky so a human can check it out? Or to make a judgment call about how hinky is hinky enough that the whole process needs to abort?
Re: Wheel Reinventor’s Principles (2024)
#60> Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time. I would like to work with this person.
> > Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time. > I would like to work with this person. Before you make such a bold claim, consider that this way of doing programming leads to an accumulation of knowledge that is barely transferable if you switch jobs. I would claim that a central reason why many programmers like third-party dependencies is that being…
You're probably right. Anyway, I will be eternally grateful to the creators of H2 Database for showing that it is very much possible to create an entire database including a web interface without forcing dozens of additional dependencies onto your users.