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

Less is Moore

samgentle.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Less is Moore

#11

Post by SomeCallMeTim »

akkartik wrote: post #2

I'll make a stronger case to Keep it Simple: even if you have infinite computing resources and memory, implementing the simplest possible thing is far easier for other programmers to understand than the ugly generalized 'abstractions' most of us come up with 99% of the time. That 'cognitive bottleneck' will remain no matter how far back you push the resource bottleneck, and it will keep an anti-abstraction ethos comp…

The existence of poor designers isn't a good reason to never design.

In fact, the more design you do, and the more you're exposed to, the better you can get at design. And the better the design, the easier it is to understand.

An "ugly generalized abstraction" is pretty much by definition not a good abstraction. Moreover, a good abstraction is simple. It's easy to understand and it's easy to manipulate. [1]

But you need to practice to get better, so it may take a few ugly monstrosities before you can start creating masterpieces.

[1] Granted 99% of the code I've encountered in Java qualifies as ugly abstractions; Java's nature seems to encourage poor abstractions. Or attract poor developers. Or both. But even in Java it's possible to create beautiful and easy to understand abstractions.

Re: Less is Moore

#12

Post by aidenn0 »

jonathaneunice wrote: post #3

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

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.

Re: Less is Moore

#13

Post by maxgee »

jonathaneunice wrote: post #3

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

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.

Re: Less is Moore

#14

Post by akkartik »

SomeCallMeTim wrote: post #11
akkartik wrote: post #2

I'll make a stronger case to Keep it Simple: even if you have infinite computing resources and memory, implementing the simplest possible thing is far easier for other programmers to understand than the ugly generalized 'abstractions' most of us come up with 99% of the time. That 'cognitive bottleneck' will remain no matter how far back you push the resource bottleneck, and it will keep an anti-abstraction ethos comp…

The existence of poor designers isn't a good reason to never design. In fact, the more design you do, and the more you're exposed to, the better you can get at design. And the better the design, the easier it is to understand. An "ugly generalized abstraction" is pretty much by definition not a good abstraction. Moreover, a good abstraction is simple. It's easy to understand and it's easy to manipulate. [1] But you n…

Oh man, that word 'design'. You have a problem and you think, "I should design a good solution." Now you have two problems.

I was deliberately avoiding the d-word because it is vague enough that I'm not sure there's anything useful around there. The good designers are all good at designing within some domain. Jonathan Ivy, Christopher Alexander, Ralph Lauren, they all had their specialty. You wouldn't ask Ralph Lauren to design a rocket ship. Software is even wider a set of domains than meatspace. So I'm not sure you get better at design by 'practicing design'. That's just a set of vague words like 'simple', 'good', 'beautiful', 'abstraction', 'decoupled', 'coherent', 'cohesive', etc., etc. I think you get better at design by better understanding a domain. You get better at design by avoiding premature design.

Re: Less is Moore

#15

Post by aidenn0 »

SomeCallMeTim wrote: post #11
akkartik wrote: post #2

I'll make a stronger case to Keep it Simple: even if you have infinite computing resources and memory, implementing the simplest possible thing is far easier for other programmers to understand than the ugly generalized 'abstractions' most of us come up with 99% of the time. That 'cognitive bottleneck' will remain no matter how far back you push the resource bottleneck, and it will keep an anti-abstraction ethos comp…

The existence of poor designers isn't a good reason to never design. In fact, the more design you do, and the more you're exposed to, the better you can get at design. And the better the design, the easier it is to understand. An "ugly generalized abstraction" is pretty much by definition not a good abstraction. Moreover, a good abstraction is simple. It's easy to understand and it's easy to manipulate. [1] But you n…

Abstractions that never leak are extremely rare. Because of this, trying to write a general purpose abstraction is very hard. A special purpose abstraction only needs to not leak for its intended purpose which is a lot easier to get right.

Re: Less is Moore

#16

Post by jonathaneunice »

maxgee wrote: post #13
jonathaneunice wrote: post #3

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

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.

Re: Less is Moore

#17

Post by lloeki »

jonathaneunice wrote: post #3

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

> 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.

Re: Less is Moore

#18

Post by duncanawoods »

I liked this:

If you're solving problem X and realise "hang on, that's actually a special case of problem Y", it's actually the single most dangerous point in the development of your solution; you're only one step away from the logical conclusion of "I should solve Y instead". Now you're solving the wrong problem.

I think this resonates with most of us but we will still pursue the general case. I think its because problems are simpler when expressed in their general case than with all the hoary detail of a special case. Its close to a rule of nature: whenever we see complexity we can discover simple elegant rules that govern it, and as programmers who's main challenge is taming complexity, we are prepared to risk anything in our pursuit of simplicity, including more complexity...!

Re: Less is Moore

#19

Post by [deleted] »

duncanawoods wrote: post #18

I liked this: If you're solving problem X and realise "hang on, that's actually a special case of problem Y", it's actually the single most dangerous point in the development of your solution; you're only one step away from the logical conclusion of "I should solve Y instead". Now you're solving the wrong problem. I think this resonates with most of us but we will still pursue the general case. I think its because pr…

[deleted]

Re: Less is Moore

#20

Post by lmm »

aidenn0 wrote: post #15
SomeCallMeTim wrote: post #11

Earlier quoted context omitted.

The existence of poor designers isn't a good reason to never design. In fact, the more design you do, and the more you're exposed to, the better you can get at design. And the better the design, the easier it is to understand. An "ugly generalized abstraction" is pretty much by definition not a good abstraction. Moreover, a good abstraction is simple. It's easy to understand and it's easy to manipulate. [1] But you n…

Abstractions that never leak are extremely rare. Because of this, trying to write a general purpose abstraction is very hard. A special purpose abstraction only needs to not leak for its intended purpose which is a lot easier to get right.

I want more examples before I accept this Even the original "law of leaky abstractions" post did not have any good examples; using UDP rather than TCP will not save you if you pull out the network cable, and micro performance differences like the AND A = C example are rarely relevant.
Post reply on HN