Hacker News Reader

Comment by jonathaneunice | Hacker News Reader

The problem with this kind of YAGNI thinking is that it 1. commits everyone to understanding how to do everything and 2. requires everyone to do everything afresh, every project. The fact is, I don't know the gory details of all the Unicode encodings, XML Namespaces, multithreaded concurrency locks, database indexing strategies, or SVG rendering pipelines my code uses every day. While I can dive down to understand those things if need be, at any given moment I don't know even a fraction of those things my program directly uses. If I had to dive down on them, I wouldn't get productive work done. And as a group, we'd each be reinventing slightly different, mostly crappy single-use versions of The Wheel. Thanks, but I'm perfectly happy standing on the shoulders of giants--even if it gets a little wobbly some times.

View on HN

When it comes to really supporting non-english languages well, you kinda do have to know gory details of Unicode. (I had to.) Otherwise, stuff will mysteriously not work, and you won't know what to do. OS X / Windows filenames will surprise you. Python on OS X / Windows will surprise you. Javascript will surprise you. URLs will surprise you. There's a lot of surprises in store.

If you have some real-time large-ish-data need, you'll need to evaluate your options based on how they manage concurrency and locking. You may even have to implement a custom cache or archive layer. (I had to.)

I'll admit, I haven't dealt with SVG rendering, and it wasn't important to any company I've worked for. In cases like that, you can say "whatever, fast enough on today's computers, this one doesn't work so I'll replace it with a png." But if you really need stuff to work right, if you want it done right, you don't have to do it all yourself, but you do have to understand it all yourself, otherwise you can't correctly choose and marshall the pieces that do it.

EDIT: I feel like adding an addendum: yes, the specific views described in OP are historic relics. Still... the number of levels that exist today between do-it-yourself c programming with an alternative/minimal libc, and a ruby/rails/activerecord/auth-gems/assets-gems project, is really amazing.

the number of levels that exist today between do-it-yourself c programming with an alternative/minimal libc

Turtles all the way down. I'm working right now own an OS-less Forth system to run on a SoC, and keep thinking "man, how much easier would this be if I had a kernel and a library!"

Meanwhile, somebody else is probably working on a pure logic processor and thinking "wow, I wish I had a full SoC to work with..."

All these surprises you get with non-english characters is exactly why it needs to be abstracted and handled at another level so why don't need to know how they all that works.

YAGNI doesn't say to avoid using a general purpose framework, it says that writing one to solve the problem at hand is usually a bad idea.

You're doing a disservice to yourself and the people who have to work on (or more likely fix) your code by having this attitude. Plenty of people are capable of producing great work and still spending the time to actually understand the systems they are working on.

There aren't that many giants; there are a lot of people with a few years of experience that think/claim they're giants.

Mmmm... We'll just have to disagree on this. I can track a great number of octaves, from business strategy down to operating system scheduling and locking strategies, CPU instruction pipelines and scheduling, semiconductor fabrication techniques, and even down to the lifetime exergy of the whole equipment/software/facilities supply chain. But I can only do a little bit at a time, an as-needed basis. I can't be too concerned with instruction set design or supply chains while I'm optimizing an SQL query or building a D3.js web visualization. It's just too remote from the task at hand. If you, in contrast, can simultaneously understand and reason about every technology along the continuum from delivered apps and services down to the impedance constraints in the CPU layout process, good show! That's a surpassingly rare skill, but perhaps there are some Sherlocks among us.

I think it's obvious that I'm not advocating you have innate knowledge of everything down to semiconductor fabrication in order to be a competent javascript programmer. I would argue you want at least a basic understanding of the internals of the software you're relying on.

You're writing SQL queries and claim you don't have the time to research how the database you're using works internally without destroying your productivity? You can write SQL without knowing the database's indexing strategy or how it optimizes queries, but it's likely to be of a lesser quality than someone who has taken the time to do so.

> The problem with this kind of YAGNI thinking is that it 1. commits everyone to understanding how to do everything and 2. requires everyone to do everything afresh, every project.

IIUC is that how the Go team sets out to do stuff? I have no references but I seem to recall I read something along the lines of "writing a Min(uint, uint) function is easy enough, so there's no real need for it in the stdlib (whereas Min(float, float) is there because it relies on optimized hardware), and you can always implement it and have it published" and "container types are best implemented on a case by case basis because their traversal is best suited to each specific case, so generics aren't needed that badly".

I do undestand such arguments, yet encountering the fifteenth slice Mirror function {which is unconcerned about the type) being either non-optimal, or just wrong due to an off-by-one, or giving up on static typing, gets old fast. And I'm not even talking about tries, b*-trees or whatever other interesting data structure there is.

Reply on news.ycombinator.com