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

71–80 of 96 posts

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#71

Post by beagle3 »

pmahoney wrote: post #57
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…

I've seen these VPRI links before. I've read through that PDF and various web pages, but I still have a poor understanding of what exactly they are doing. Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction? Is it simply that systems like Linux et. al. have been cobbled together by many hands over many years while VPRI has a single vision? Are there coding techniques I can use t…

> Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction?

I think it hangs on two principles:

1) more expressive tools at the price of performance.

2) use existing data as much as possible, but only complying with standards where really necessary.

1) is using e.e. Ometa & friends, which make it possible to (e.g.) implement a reasonable JS engine on top of any reasonable dynamic runtime with 100-200 lines or so.

2) is using e.g. the RFCs the define IP, TCP and UDP as input to a processor -- thereby, having a guaranteed-to-match-specification implementation, without having to repeat any of the struct/constants/details. The RFCs do not count among their 20K lines -- they are probably 3K lines themselves. The parser that parses RFC into data structures and some executable code IS counted in those 20K - but, last I looked, was less than 100 lines.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#72

Post by loup-vaillant »

pmahoney wrote: post #57
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…

I've seen these VPRI links before. I've read through that PDF and various web pages, but I still have a poor understanding of what exactly they are doing. Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction? Is it simply that systems like Linux et. al. have been cobbled together by many hands over many years while VPRI has a single vision? Are there coding techniques I can use t…

I count 3 "miracles". In ascending order of awesomeness, these would be:

(1) No feature creep. They provide essential functionality, little more. I say that's a good thing, because if you miss functionality, the system lets you build it relatively easily. My guess is, it explains about 1 order of magnitude (it divides code volume by 10).

(2) Factor everything. Again not very impressive, but it goes a long way. Just good engineering principles applied systematically across the system. For instance, they have one graphic stack, which draws everything in every program, including the window manager. They also have one document type. A side effect of this approach is a greatly increased integration. My guess is, it explains about 1 order of magnitude.

(Warning: the divide between (1) and (2) is somewhat arbitrary. In some ways, the STEPS system provide more functionality than current systems. I think the trick is to stop thinking in terms of features, but in terms of capabilities. For instance, UNIX don't have a feature to sort Apache log files by IP address. But it has `sort` and `awk`, and therefore it has the capability.)

(3) Build the right tools. The tools being mostly domain specific programming languages. And that is the impressive part. Their language are so expressive and simple that they can reduce code volume by two orders of magnitude without breaking a sweat. I don't know exactly how they came up with such languages, yet they did. The tree core languages that may interest you here are Ometa http://www.tinlizzie.org/ometa/, Maru http://piumarta.com/software/maru/, and Nile. Ometa is like Lex+Yacc, only much simpler and more general (it lets you transform trees, and flatten them, which makes it suitable for all compilation stages). Maru is a not-so-inefficient self-implementing language, based on 2 cores (lambdas and objects) which can implement each other.

So, 1+1+2=4. Or 1010100=10,000. I'm oversimplifying of course, but I think this gives an idea.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#73

Post by loup-vaillant »

beagle3 wrote: post #71
pmahoney wrote: post #57

Earlier quoted context omitted.

I've seen these VPRI links before. I've read through that PDF and various web pages, but I still have a poor understanding of what exactly they are doing. Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction? Is it simply that systems like Linux et. al. have been cobbled together by many hands over many years while VPRI has a single vision? Are there coding techniques I can use t…

> Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction? I think it hangs on two principles: 1) more expressive tools at the price of performance. 2) use existing data as much as possible, but only complying with standards where really necessary. 1) is using e.e. Ometa & friends, which make it possible to (e.g.) implement a reasonable JS engine on top of any reasonable dynamic run…

1) But as it turned out, the cost wasn't so high after all. (They didn't expect their graphic stack to run fast enough in a laptop, yet it does.)

2) What, they do not count the RFC they parse? I'd count that as cheating: if the RFC is part of the meaning of the system, it should be taken into account.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#74

Post by antirez »

Hey, you that are defending libpng in this thread, go write a C example to load a PNG file with varying formats and color depth using this lib.

This lib API is completely broken. I keep cut&pasting the code I wrote one day reading the doc with much pain...

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#75

Post by david927 »

raverbashing wrote: post #37
david927 wrote: post #26

Earlier quoted context omitted.

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…

"our abstraction mechanisms are failing us... There are four or five projects working on this and, literally, hundreds of photo-sharing startups." But it's the same thing! It's the same problems And IMHO in the technical places it's getting worse every day. The reason some photo sharing apps are bought by a billion dollar is the same as why lots os people use PHP even though "it sucks". User experience and ease of us…

Yes, everything is mixture of complexity. When an artist paints, she has to decide how simple or complex to make the work. But what we're talking about here is that once you pick up a PHP brush, you're screwed. That's why it sucks. You can't change brushes; you have a big fat crayon. And while that works for filling in the sky, you can't get any detail on the faces, for example. (Choose a fine brush and you have a different problem of spending all your time on the sky.)

What I'm talking about when I say "our abstraction mechanisms are failing us" is the need to use any size brush at any time.

And, as an aside, photo sharing apps are bought for billions for the same reason that tulips used to be worth a fortune. Uploading pictures of your cat is about as valuable as a 'Carnaval de Nice'.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#76

Post by nodemaker »

What you design should be very very simple to someone when she starts to play with it.But as she plays more and more she should discover gradually(exponentially) the great underlying complexity in order to achieve the simplicity on the surface.

All the great codebases,machines,mathematical equations,laws of nature,even a bacterial cell seem to have this property.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#77

Post by beagle3 »

loup-vaillant wrote: post #73
beagle3 wrote: post #71

Earlier quoted context omitted.

> Is it possible to summarize in a paragraph how they are able to achieve this LOC reduction? I think it hangs on two principles: 1) more expressive tools at the price of performance. 2) use existing data as much as possible, but only complying with standards where really necessary. 1) is using e.e. Ometa & friends, which make it possible to (e.g.) implement a reasonable JS engine on top of any reasonable dynamic run…

1) But as it turned out, the cost wasn't so high after all. (They didn't expect their graphic stack to run fast enough in a laptop, yet it does.) 2) What, they do not count the RFC they parse? I'd count that as cheating: if the RFC is part of the meaning of the system, it should be taken into account.

> What, they do not count the RFC they parse?

No, they don't.

> I'd count that as cheating: if the RFC is part of the meaning of the system, it should be taken into account.

I don't think it is cheating. The RFC text is essentially arbitrary, and "god-given" as far they are concerned -- and must only be adhered to for compliance with other systems. (If they designed their own network protocols, I would have agreed with you). By parsing it and generating code, they guarantee that the code conforms with the spec (which is more than you can say for any other network stack implementation!).

And it's all down to what they are trying to achieve: They are NOT trying to minimize LOC -- if they wanted to do that, they'd build everything in obfuscated APL or J.

They want to get to a state in which a person can understand / audit the entire software stack of a system they are running. 20k was selected as what a person can completely follow & understand in a reasonable amount of time (weeks, not years or centuries)

You cannot (average human "you") understand/audit a TCP/IP stack without reading the RFCs; therefore, they don't think they need to double-count it, and neither do I. Furthermore, if tomorrow the world switches to curveCP, they wouldn't include the related RFCs either -- only the code they had to write to make it work.

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#78

Post by batista »

d0mine wrote: post #68
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…

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

Yes, by Joel Spolsky. Only it's not 100% accurate.

Some people DO use a different 10%, but the grand majority uses the same 10% (and occasionally has a need for something outside of that).

Re: We Who Value Simplicity Have Built Incomprehensible Machines

#80

Post by leocassarani »

DanBC wrote: post #45
f45s8g2 wrote: post #12

It's because some people really do like complexity. They like writing 200 pages of documentation. And some like reading it. They want complexity. Keep adding stuff. I remember reading one of the Windows programmers' hero's writing about some massive document of several hundred pages he wrote while on the Excel team at Microsoft and being overjoyed when he learned Bill Gates had actually looked at it. I remember readi…

> I remember reading one of the Windows programmers' hero's writing about some massive document of several hundred pages he wrote while on the Excel team at Microsoft and being overjoyed when he learned Bill Gates had actually looked at it. When you have a spreadsheet programme you start with something relatively simple. You then add functionality. You add pivot tables and charting and macros and etc. At what point d…

It's ironic that you're linking to one of Joel's articles in your response, given that he's actually the "Windows programmers' hero" that the comment was referring to: http://www.joelonsoftware.com/items/2006/06/16.html.
Post reply on HN