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

We Who Value Simplicity Have Built Incomprehensible Machines

prog21.dadgum.com

Post reply on HN
Print view View original

61–70 of 96 posts

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#61

Post by haberman »

loup-vaillant wrote: post #46
haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

I don't disagree, but these points needs highlighting: > It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. Want real stuff? Check out VPRI's work: http://vpri.org/html/work/ifnct.htm Right now, they're working on a 20KLOC OS (including desktop publishing, messaging, and the whole compilation chain). That's about 4 orders of magnitude smaller than current systems. Here…

> Want real stuff? Check out VPRI's work

I didn't mean to make it sound like simplicity is not possible. Quite the contrary, I believe it is possible and extremely worthwhile, and it's something I have dedicated an enormous amount of time to in my own work.

All I'm saying is that the essay was not worthwhile to me, because it offered no insight that helps us get there.

> It's not much, so they say it's no big deal, and act as if it does not count.

I agree that your version is far superior, and that it is a big deal. If I saw code that constructed a class but the class didn't have any state, it would interrupt my flow while I stopped to figure out wtf is going on.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#62

Post by flogic »

talentdeficit wrote: post #9
flogic wrote: post #8

This is because that what happens in engineering. Even simple things like shovels have evolved. The blade has been shaped to into the dirt. It's got a squiggly bend so it's balanced holding dirt. Stepping up a bit further we have things like clocks. Sundials don't work in the dark so we made mechanical clocks. Those of course have bits of complexity to make them easier to read and more accurate. Now consider computer…

i think the point is that when designing clocks we didn't just attach some gears and a timing mechanism and some hands to a sundial, we threw the sundial out. computers are complex because we hardly ever remove anything, and we still bare their cost aeons after they're relevant.

Yeah but clocks generally don't interface with other technology. Trailer hitches and screw drivers do. There is a whole slew of different hitch adapters. And, most of us have or at least have seen screw drivers with a set of attachable bits.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#63

Post by haberman »

batista wrote: post #55
haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard. Simple by design might be hard, but "simplify in retrospect" is easy. It just needs you to be willing to sacrifice meaningless backwards compatibility and inflict some…

> You don't. Fuck ALL those use cases. Keep only those that are used a large percentage of the time by the large majority.

Disagree completely. Because if you do that, the moment someone comes along and needs something that you're unwilling to provide and can't be layered on top of your work, they're going to make their own "ls" that overlaps a lot but satisfies their need. If we have 15 different "ls" implementations, we're back to more overall complexity.

Basically if you want to write code that lives at the bottom of the stack, you have to think of the most crazy hard-core shit that anyone might want to do with your code and how you can accommodate that.

Two fantastic examples of software that achieve this in spades: Lua and zlib. Both let you plug in your own memory allocator instead of malloc() if you really need to. Both let you perform your own I/O if you really need to.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#64

Post by haberman »

soitgoose wrote: post #58
haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

Dude, goddamnit. This is a startup forum. People complain about shit being hard, and it's our job to make it simpler. Even if it's the temple itself.

I believe it's possible, and worth doing. Moreover, I have spent several years of my life trying to do just that in the space of network parsers and serializers!

All I was saying is that it's not easy or straightforward to achieve, and that the author's essay doesn't offer anything that helps us get there.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#65

Post by ryanmolden »

IsTom wrote: post #32
swombat wrote: post #18

I don't think the average geek values simplicity all that much. We value power, flexibility, versatility. We value openness, interoperability, upgradeability. Simplicty? It's a distant 7th or 8th on the scale. That's why computers are the way they are, and we needed a company that really did value simplicity to create a new paradigm where users don't have to deal with libpng, winsock, antiviruses and other artifacts…

I think you're confusing two kind of 'simplicity'. 'Apple' simplicity is in my eyes about cutting away what is not needed and unifying everything else. What author is talking about is simplicity that lies in roots UNIX-philosophy. It's about having many simple tools that can be composed into something more complex. Perhaps my view on the world is twisted by the kind of programmers I know (mostly CS majors), but I alm…

Another problem is simplicity is inherently subjective. Almost no one thinks their code is overly complicated, that is an attribute to be applied to other people's code. People play lip service to the idea, and will sometimes claim their code is overly complex, in an almost self-deprecating way, but not much serious effort is put forth on fixing/avoiding that. Lots of comments disparaging other's failure to "get" their design or suggestions to RTFM, or worse, in open-source, RTFC, abound however.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#66

Post by d0mine »

haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

To add to your point: physics shows that it is possible to describe complex phenomena using simple models. But discovering such models is hard.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#67

Post by d0mine »

david927 wrote: post #26
haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

The failure isn't in that we're adding too much complexity (we have to be able to create complex structures) or that we're not layering it enough (leaky abstractions build up). It's a general, and much more far-reaching, problem: our abstraction mechanisms are failing us. We need to stop complaining and put more effort into research. There are four or five projects working on this and, literally, hundreds of photo-sh…

Btw Instagram is an example of opinionated simple interface. You might be underestimating the complexity of creating such interface.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#68

Post by d0mine »

batista wrote: post #55
haberman wrote: post #20

What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…

>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard. Simple by design might be hard, but "simplify in retrospect" is easy. It just needs you to be willing to sacrifice meaningless backwards compatibility and inflict some…

People might use only 10% of features that your program provides but the problem is that different people use different 10% (it or similar was said about MS Word bloat).

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#69

Post by loup-vaillant »

haberman wrote: post #61
loup-vaillant wrote: post #46

Earlier quoted context omitted.

I don't disagree, but these points needs highlighting: > It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. Want real stuff? Check out VPRI's work: http://vpri.org/html/work/ifnct.htm Right now, they're working on a 20KLOC OS (including desktop publishing, messaging, and the whole compilation chain). That's about 4 orders of magnitude smaller than current systems. Here…

> Want real stuff? Check out VPRI's work I didn't mean to make it sound like simplicity is not possible. Quite the contrary, I believe it is possible and extremely worthwhile, and it's something I have dedicated an enormous amount of time to in my own work. All I'm saying is that the essay was not worthwhile to me, because it offered no insight that helps us get there. > It's not much, so they say it's no big deal, a…

I didn't mean to imply that you meant what you didn't mean… That was poor phrasing on my part. Actually I agree with you. Saying that something sucks is worthwhile only when few know it. When everyone does, we ought to take the next step, and propose solutions (or at least analyse the problem more deeply than it has been). I was just saying "there! There! A solution!!".

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#70

Post by jacktoole1 »

haberman wrote: post #63
batista wrote: post #55

Earlier quoted context omitted.

>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard. Simple by design might be hard, but "simplify in retrospect" is easy. It just needs you to be willing to sacrifice meaningless backwards compatibility and inflict some…

> You don't. Fuck ALL those use cases. Keep only those that are used a large percentage of the time by the large majority. Disagree completely. Because if you do that, the moment someone comes along and needs something that you're unwilling to provide and can't be layered on top of your work, they're going to make their own "ls" that overlaps a lot but satisfies their need. If we have 15 different "ls" implementation…

Heartily agree on Lua. Embedding lua was one of the best library experiences I've ever had. The implementation and language is small and simple, and I think many people undervalue that. Compiling it was as simple as dragging the source files into Xcode (not an ideal long term solution, but quick and easy to compile to any target, and at 10k lines of code, reasonable compile times). As a comparison, I spent 3 days trying to compile Spidermonkey for ARM (with eventual success attributed mostly to finding a useful patch on github).
Post reply on HN