Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wheel Reinventor’s Principles (2024)

tobloef.com

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Wheel Reinventor’s Principles (2024)

#71

Post by sadeshmukh »

sunrunner wrote: post #64
rahkiin wrote: post #61

Earlier quoted context omitted.

We re-invented the wheel quite some times. Stone, then wood, then wood with spokes, then wood with spokes and iron trim, then we eventually added rubber, rubber tubing, then all metal spoke with rubber. For Mars rovers they made new types of air-less wheels. The saying ‘do not reinvent the wheel’ is just silly

Re-invented or re-implemented? The design was always the same just the materials have changed (and maybe there's something about motor racing and new wheels being available every year...)

Software all uses electricity, doesn't it?

Re: Wheel Reinventor’s Principles (2024)

#72

Post by renox »

glitchc wrote: post #29
didgetmaster wrote: post #20

Reinventing the wheel often means breaking things. Innovation often requires getting rid of backwards compatibility. The status quo is promoted by those who have invested in it, so disrupting it can be met with fierce resistance. When I tell people that file systems are antiquated and need to be replaced with something much better; I often get strong push back. This is a wheel that I have been reinventing for some ti…

We need content addressable FSes with bloom filters for fast lookups.

I would already happy with FS based on 'tags' not trees.

Re: Wheel Reinventor’s Principles (2024)

#73

Post by jofer »

JackFr wrote: post #44
jofer wrote: post #35

Earlier 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?"

CSV is _way_ hairier than folks think it is!!

And for anyone who's not convinced by CSV, consider parsing XML with a regex. "I don't need a full XML parser, I just need this little piece of data! Let's keep things lightweight. This can just be a regex..."

I've said it many times myself and been eventually burned by it each time. I'm not saying it's always wrong, but stop and think whether or not you can _really_ trust that "little piece of data" not to grow...

Re: Wheel Reinventor’s Principles (2024)

#74

Post by hinkley »

strongpigeon wrote: post #65

> [...] Be wary of abstractions made for fabricated use cases. Very well put and I would argue this applies to general software development. This is one of the biggest difference between my freshly-out-of-college self and me right now and something I try to teach engineer I'm trying to grow into "seniors". Too many time have I seen a lot of wasted efforts on trying to build hyper flexible components ("this can do any…

I don’t think there’s an accepted set of concrete criteria for making software that can absorb major design changes later without a great deal of effort and stress. How you write code that can accept an abstraction layer at the last responsible moment.

Some people have an intuition for it, but it’s sort of an ineffable quality, buried in Best Practices in a way that is not particularly actionable.

So people having been scarred by past attempts to refactor code reach for the abstraction in fear, just in case, because they don’t know what else to do and it’s not written down anywhere, but abstractions are.

Re: Wheel Reinventor’s Principles (2024)

#75

Post by rikroots »

I decided to reinvent SVG Filters because Safari won't let them be used with HTML canvas elements[1] ... well, at least that's the official reason.

Unofficially I just wanted a decent filter engine[2] that worked well with my canvas library, and there were things like SVG "filter chaining" which I really liked the idea of - but could they be done in a simpler way[3]? Also: proving to nobody that canvas filters can be done (fairly) efficiently without the need for WebGL shaders (because: why not?). And then I discovered I really like coding up filter functions and went a bit mad with them[4][5] and now the hole is so deep the only option left for me is to keep digging ...

[1] - Though I think that's changing this year? May already have changed - but I'm not gonna un-reinvent my filters even if the Safari folks have shipped the fix!

[2] - https://github.com/KaliedaRik/Scrawl-canvas/blob/v8/source/h...

[3] - Why do the SVG filter primitives need to be so complicated to work with?

[4] - https://scrawl-v8.rikweb.org.uk/demo/canvas-007.html

[5] - https://scrawl-v8.rikweb.org.uk/demo/filters-103.html

Re: Wheel Reinventor’s Principles (2024)

#76

Post by mjw1007 »

mikepurvis wrote: post #59
LPisGood wrote: post #50

Earlier quoted context omitted.

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 s…

Beyond the basic implementation of quoting and escaping, those are things you also have to worry about if you use someone else's csv parser.

And if you implement your own, you get to choose the answers you want.

Re: Wheel Reinventor’s Principles (2024)

#77

Post by hinkley »

add-sub-mul-div wrote: post #70
strongpigeon wrote: post #65

> [...] Be wary of abstractions made for fabricated use cases. Very well put and I would argue this applies to general software development. This is one of the biggest difference between my freshly-out-of-college self and me right now and something I try to teach engineer I'm trying to grow into "seniors". Too many time have I seen a lot of wasted efforts on trying to build hyper flexible components ("this can do any…

Another good way I've seen it put is, the difference between underengineering and overengineering is that you can fix underengineering.

Somewhere, at a tender age, I read a paean to the Chevy Straight Six engine block. One of the most heavily modified engines of all time. Later on when I read Zen and the Art of Motorcyle Maintenance it had a similar vibe and effect.

I still sometimes use it as an allegory. As it originally shipped it had very low power density. It’s an unremarkable engine. But what it has in spades is potential. You can modify it to increase cylinder diameter, you can strap a giant header on it to improve volume and compression more. You can hang blowers and custom manifolds and more carbs off it to suck out more power. IIRC at the end of its reign they had people coaxing 3, almost 4 times the first gen OEM horsepower out of these things. They had turned it into a beast for that generation of “makers”.

Re: Wheel Reinventor’s Principles (2024)

#78

Post by naitgacem »

mikepurvis wrote: post #59
LPisGood wrote: post #50

Earlier quoted context omitted.

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 s…

Even with numbers, some locales use a comma `,` as the decimal seperator, and some use the dot `.` so that can cause headaches out of the box.

Re: Wheel Reinventor’s Principles (2024)

#79

Post by lelanthran »

mikepurvis wrote: post #59
LPisGood wrote: post #50

Earlier quoted context omitted.

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 s…

What do you mean "allowed to bail"?

Regardless of the format if you're parsing something and encounter an error there are very few circumstances where the correct action is to return mangled dat.

Re: Wheel Reinventor’s Principles (2024)

#80

Post by naitgacem »

0xbadcafebee wrote: post #43

More 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…

I this this ought to be an iterative process, such as study principles so that you don't start from absolute scratch, then make a wheel that sucks, study some more and do more resarch yourself, rince and repeat until satisfied.

There is so much nuance that doesn't get captured in all the study you can do about how a certain thing is made.

Post reply on HN