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

Reply via email to