Two things spring out of this at me (inline):
On 28/02/2012, at 9:21 PM, Loup Vaillant wrote:
> - Features matter more than I think they do.
> - One may not expect the user to write his own features, even though
> it would be relatively simple.
What about when using software becomes "writing" features - see etoys. Is
clicking and dragging tiles still "writing" software? :)
> - Current systems may be not as badly written as I think they are.
> - Code reuse could be harder than I think.
It's not that they're written badly, it's just that that so many years on, no
one has really understood some of the powerful ideas of yesteryear. Even those
powerful ideas allowed a certain level of magnification... but the powerful
ideas of these days in addition to the past allow an incredibly large
possibility of magnification of thought...
A good comparison would be:
- Engineer "A" understands what a lever does, therefore with that simple
understanding can apply this knowledge to any number of concrete examples - it
takes him almost no time to work out how to implement a lever. He teaches his
apprentices this simple rule and law of physics, quite quickly, and they can
write it down in a couple of sentences on a single piece of paper and also
utilise it whenever and wherever they see fit. The Engineer "A" charges about
$40 to implement a lever.
- Engineer "B" doesn't understand what a lever does, but he does have a 1000
page book that illustrates almost every possible use of a lever, so when he
finds a need, he looks up his well indexed book, which only takes a few minutes
at the most... and then he can effectively do 90% of what Engineer "A" can do,
but not actually understanding it, his implementations aren't as good. His
apprentices get a copy of this book which only costs them $40 and which they
have to familiarise themselves with. The book weighs two pounds, and they have
to take it everywhere. The Engineer "B" charges only $50 to implement one of
his 1000 page book ideas... he also charges $10 per minute that it takes to
look it up.
> - The two orders of magnitude that seem to come from problem oriented
> languages may not come from _only_ those. It could come from the
> removal of features, as well as better engineering principles,
> meaning I'm counting some causes twice.
>
> Loup.
Julian
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc