[deleted]
We Who Value Simplicity Have Built Incomprehensible Machines
41–50 of 96 posts
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#42What 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…
Yeah sure you can keep layering till you get 47 different layers (some in parallel).... aka
"X Windows"
Layering does come at a cost. Speed and various hacks that have to reach below the layer. Partly because of X Windows Linux still has one of the slower and fragmented graphics shell.
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#43I like this essay.
In the move from '286 to '386 through '486 there were many messy kludges (addressable memory; 16 bit to 32 bit instruction set; etc etc). I felt that 'we' should just stop the relentless advance of this weird architecture and start with something more sane.
But refinement through iteration is incredibly powerful. (See Kaizen for business processes and quality control) Sometimes you get left with weird bodges; the digital equivalent of the human appendix dangling with no purpose but only occasionally poisoning the host. But mostly the benefits of forward motion outweigh the disadvantages.
There are projects where people stop and think about "how to do this right" - almost always they are over taken by people who build fast and break things. (see, I guess, various micro-kernels.)
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#44IMHO Things are already getting simpler (or I should say external API complexity is slowing down).
There are couple of reasons why I think APIs are getting simpler:
* Services, Services, Services (RESTful services)
* Greater Automated Test (Unit Testing)
* Better dependency management
* Continous Integration / Deployment
* There is a new Apple-esque simple is elegance mentality now.
In short developers are not as afraid as they used to be to make drastic API changes.
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#45It'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 do you stop and say "We need to re-write the entire code from scratch to make sure this stuff is all tightly integrated and bug-free?" or "We need to split some of this functionality off into separate by integratable softs to protect the core product and provide split pricing for power users"?
Never re-write code from scratch:- (http://www.joelonsoftware.com/articles/fog0000000069.html)
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#46What 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 is their last progress report on the STEPS project: http://www.vpri.org/pdf/tr2011004_steps11.pdf
> The most important part by far is to leave out anything you possibly can.
This is also the most overlooked part by far. I deal with something similar at my day job: I noticed that I am relatively poor at dealing with masses of complexity. My co-workers fare better. On the other hand, they don't mind small unjustified complexities. The latest bit I saw was this (in C++):
class Foo {
public:
out_t1 bar(in_t1 in);
out_t2 baz(in_t2 in);
private:
static mem data;
};
// example
Foo foo;
out = foo.bar(in);
class Foo {
public:
static out_t1 bar(in_t1 in);
static out_t2 baz(in_t2 in);
};
// example:
out = Foo::bar(in);
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#47What 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 entirely agree with you - but I think the hardest thing is SPLITTING THINGS UP into coherent units that compose the lower level API you write about. The problem is that we can divide things in many possible ways - what makes one division better then the other? This is hard, layering is the easier part (but still far from obvious: http://perlalchemy.blogspot.com/2012/04/breaking-problems-do...).
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#48I like this essay. In the move from '286 to '386 through '486 there were many messy kludges (addressable memory; 16 bit to 32 bit instruction set; etc etc). I felt that 'we' should just stop the relentless advance of this weird architecture and start with something more sane. But refinement through iteration is incredibly powerful. (See Kaizen for business processes and quality control) Sometimes you get left with we…
Let's not forget that Intel did attempt to pull an Apple with the Itanium as the 64 bit successor to x86. However, AMD stepped in with a backwards-compatible 64 bit architecture, and the rest is history. I suppose this would have happened one way or another; the beast that is the installed base does rather like to stay alive.
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#49I like this essay. In the move from '286 to '386 through '486 there were many messy kludges (addressable memory; 16 bit to 32 bit instruction set; etc etc). I felt that 'we' should just stop the relentless advance of this weird architecture and start with something more sane. But refinement through iteration is incredibly powerful. (See Kaizen for business processes and quality control) Sometimes you get left with we…
Let's not forget that Intel did attempt to pull an Apple with the Itanium as the 64 bit successor to x86. However, AMD stepped in with a backwards-compatible 64 bit architecture, and the rest is history. I suppose this would have happened one way or another; the beast that is the installed base does rather like to stay alive.
Linux kernel devs openly spoke of their dislike for Itanium. There are many recorded instances of this.
Re: We Who Value Simplicity Have Built Incomprehensible Machines
#50[deleted]