Hacker News new | ask | show | jobs
by antt 2664 days ago
>The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.

Writing my own sort routine? Pointless but pretty harmless.

Writing my own docx parser? Sure, that will be one mythical man century of work.

Sometimes we are using black boxes because we have created so much accidental complexity that we can't do better than "this works, we don't know why and we dare not change it". The browsers js must target are some of the biggest black boxes even though they are open(ish) source.

3 comments

> Writing my own docx parser? Sure, that will be one mythical man century of work.

I'm not sure that's actually a great example. I had a project a while ago where I needed to extract certain information from Word and Excel files, and it was less work to just write my own parser (it's just XML in a ZIP file) that got exactly the information I needed than to figure out all the complexity of using a full-blown docx/xlsx parser. It ended up being 100 lines of Haskell, and half of that was imports.

https://gist.githubusercontent.com/duairc/db3e99a7808668e84e...

Edit: The docx part of it is only 10 lines of code.

There's a slight difference between extracting a few tags from an xml file and building an manipulable ast of it.
There is, but if your problem requires just the former, it's faster and better to build it yourself than to pull in a heavy third-party dependency (of which you'll use 1% anyway).
Yes but if it requires the latter you end up with an uncontrollable mess of regular expressions which can accidentally parse the language needed to summon the great elder ones.

The media wiki parser is a perfect example of what can go wrong with simple solutions.

That's a pretty neat trick.
> sort routine? docx parser?

You immediately went for two examples that are precisely not the kind of thing the author is talking about. Consider leftpad.

There's absolutely nothing wrong with using black boxes, and I'm not arguing that it should be totally avoided. I'm arguing that a lack of understanding of how to solve your problem leads to only gluing black boxes together as you lack the understanding with which to make more nuanced decisions, and to solve any part of the problems you have yourself.

It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.