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

21–27 of 27 posts

Re: Less is Moore

#21

Post by bandrami »

ploxiln wrote: post #10
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…

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

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

Re: Less is Moore

#22

Post by loup-vaillant »

akkartik wrote: post #7
eru wrote: post #4

Earlier quoted context omitted.

Actually, if your language is designed right, abstractions become much cheaper, especially conceptually. As an example, I find a call to `map' or `filter' much easier to understand than a (C-style) `for' loop. Part of your point still stands: the `for' loop is harder to read and write specifically because it is more general. `for' loops can do all kinds of wacky things.

Yeah. When I said 99% I wasn't just including what the language provides. That usually lies in the 1%, even for 'bad' languages. Generalization there is usually justified. No, I was thinking of the functions and interfaces we create atop the language and standard library.

Language, standard library, or custom module boundaries, it's the same problem: there are 2 kinds of generality.

The first kind is exhaustiveness. Being general by accounting for all special cases. That one is complicated, and rarely worth doing beforehand.

The second kind is genericity. Being general by ignoring all the special cases. That one is often simpler and more solid than any special case. Parametric polymorphism (or generics, or templates) are like that: ignoring the specifics of the parameters limits what you can do with them, making the generic thing simpler.

The layer at which you choose to apply exhaustiveness or genericity is irrelevant in my opinion. C++ often leans towards the exhaustiveness end of the spectrum despite being a language, for instance.

Re: Less is Moore

#23

Post by zaphar »

gwern wrote: post #6

> I came into contact with a version of this philosophy even earlier, in The Mote in God's Eye by Larry Niven and Jerry Pournelle. In the story, there are aliens called Engineers who only build special-purpose things. To them, there's no such thing as a generic chair. They would instead build a Sam-chair to my exact proportions. If those proportions changed because of a series of brownie-related incidents, they'd reb…

The corrollary to this is that sometimes a Company hits scale where having a few "Moties" customize/refine every level of the stack saves billions and suddenly it's financially worth it.

It has always been a cost/benefit analysis. The hard part is figuring out the costs and benefits when it comes time to make that decision.

Case in point. My current work is in C# with some Go sprinkled around. Go happened because the c# Console an IO api's are a hopeless mess. They are bloated with everything under the sun and special cased in the API. And to top it all of they are just about the farthest thing from composable. The creators of C#'s standard library created a monstrosity in the name of abstraction that ultimately was harder to use correctly. What is the cost of that decision? Longer development times than is necessary for projects that do IO in C#. Late refactors when you realize you should have been using a TextReader instead of a StreamReader and you have these seams running all through your app that have to change now.

Re: Less is Moore

#24

Post by akkartik »

loup-vaillant wrote: post #22
akkartik wrote: post #7

Earlier quoted context omitted.

Yeah. When I said 99% I wasn't just including what the language provides. That usually lies in the 1%, even for 'bad' languages. Generalization there is usually justified. No, I was thinking of the functions and interfaces we create atop the language and standard library.

Language, standard library, or custom module boundaries, it's the same problem: there are 2 kinds of generality. The first kind is exhaustiveness. Being general by accounting for all special cases. That one is complicated, and rarely worth doing beforehand. The second kind is genericity. Being general by ignoring all the special cases. That one is often simpler and more solid than any special case. Parametric polymor…

Interesting. My take was that language, standard library and third-party libraries are part of the same state space, just organized by the amount of use they receive. Since user-space libraries receive less hammering (many have just one user) they're usually still in the "adding exceptions" phase and haven't yet attained (and perhaps never will attain) the simplicity on the other side of complexity when the requirements stabilize.

I think that maps to your distinction, except that I don't believe in 'exhaustiveness'. The state space of a program isn't some fixed thing for most programs. It evolves and grows in response to what we want it to do, which dimensions we choose to generalize along and where we stay stable. I think it's equally reasonable to view the evolution of special cases as equally exhaustive at every point, it's the boundaries of the state space (requirements) that is growing in strange ways.

Re: Less is Moore

#25

Post by maxgee »

jonathaneunice wrote: post #16
maxgee wrote: post #13

Earlier quoted context omitted.

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

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.

Re: Less is Moore

#26

Post by aidenn0 »

lmm wrote: post #20
aidenn0 wrote: post #15

Earlier quoted context omitted.

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.

UDP vs TCP: environments with significant non-congestion related packet-loss (not to mention buffer bloat). In both cases the underlying assumption of TCP is broken, so the abstraction leaks.

Re: Less is Moore

#27

Post by hobarrera »

ploxiln wrote: post #10
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…

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

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.
Post reply on HN