"people will clean things up so long as they are sufficiently painful, but once
this is achieved, people no longer care."
The idea I've been itching to try is to go backwards. Right now we use
programmers to assemble larger and larger pieces of software, but as time goes
on they get inconsistent and the inconsistencies propagate upwards. The result
is that each new enhancement adds something, but also degenerates the overall
stability. Eventually it all hits a ceiling.
If instead, programmers just built little pieces, and it was the computer
itself that was responsible for assembling it all together into mega-systems,
then we could reach scales that are unimaginable today. To do this of course,
the pieces would have to be tightly organized. Contributors wouldn't have the
freedom they do now, but that's a necessity to move from what is essentially a
competitive environment to a cooperative one. Some very fixed rules become
necessary.
One question that arises from this type of idea is whether or not it is even
possible for a computer to assemble a massive working system from say, a
billion little code fragments. Would it run straight into NP? In the general
case I don't think the door could be closed on this, but realistically the
assembling doesn't have to happen in real-time, most of it can be cached and
reused. Also, the final system would be composed of many major pieces, each
with their own breakdown into sub-pieces and each of those being also
decomposable. Thus getting to a super-system could take a tremendous amount of
time, but that could be distributed over a wide and mostly independent set of
work. As it is, we have 1M+ programmers right now, most of whom are essentially
writing the same things (just slightly different). With that type of man-power
directed, some pretty cool things could be created.
Paul.
>________________________________
> From: BGB <[email protected]>
>To: [email protected]
>Sent: Tuesday, October 2, 2012 5:48:14 PM
>Subject: Re: [fonc] How it is
>
>
>On 10/2/2012 12:19 PM, Paul Homer wrote:
>
>It always seems to be that each new generation of programmers goes straight
>for the low-hanging fruit, ignoring that most of it has already been solved
>many times over. Meanwhile the real problems remain. There has been progress,
>but over the couple of decades I've been working, I've always felt that it was
>'2 steps forward, 1.999999 steps back".
>>
>>
>>
>it depends probably on how one measures things, but I don't think it
is quite that bad.
>
>more like, I suspect, a lot has to do with pain-threshold:
>people will clean things up so long as they are sufficiently
painful, but once this is achieved, people no longer care.
>
>the rest is people mostly recreating the past, often poorly, usually
under the idea "this time we will do it right!", often without
looking into what the past technologies did or did not do well
engineering-wise.
>
>or, they end up trying for "something different", but usually this
turns out to be recreating something which already exists and turns
out to typically be a dead-end (IOW: where many have gone before,
and failed). often the people will think "why has no one done it
before this way?" but, usually they have, and usually it didn't turn
out well.
>
>so, a blind "rebuild starting from nothing" probably wont achieve
much.
>like, it requires taking account of history to improve on it
(classifying various options and design choices, ...).
>
>
>it is like trying to convince other language/VM
designers/implementers that expecting the end programmer to have to
write piles of boilerplate to interface with C is a problem which
should be addressed, but people just go and use terrible APIs
usually based on "registering" the C callbacks with the VM (or they
devise something like JNI or JNA and congratulate themselves, rather
than being like "this still kind of sucks").
>
>though in a way it sort of makes sense:
>many language designers end up thinking like "this language will
replace C anyways, why bother to have a half-decent FFI?...".
whereas it is probably a minority position to design a language and
VM with the attitude "C and C++ aren't going away anytime soon".
>
>
>but, at least I am aware that most of my stuff is poor imitations of
other stuff, and doesn't really do much of anything actually
original, or necessarily even all that well, but at least I can try
to improve on things (like, rip-off and refine).
>
>even, yes, as misguided and wasteful as it all may seem sometimes...
>
>
>in a way it can be distressing though when one has created something
that is lame and ugly, but at the same time is aware of the various
design tradeoffs that has caused them to design it that way (like, a
cleaner and more elegant design could have been created, but might
have suffered in another way).
>
>in a way, it is a slightly different experience I suspect...
>
>
>
>Paul.
>>
>>
>>
>>
>>>________________________________
>>> From: John Pratt <[email protected]>
>>>To: [email protected]
>>>Sent: Tuesday, October 2, 2012 11:21:59 AM
>>>Subject: [fonc] How it is
>>>
>>>Basically, Alan Kay is too polite to say what
>>>we all know to be the case, which is that things
>>>are far inferior to where they could have been
>>>if people had listened to what he was saying in the
1970's.
>>>
>>>Inefficient chip architectures, bloated frameworks,
>>>and people don't know at all.
>>>
>>>It needs a reboot from the core, all of it, it's just
that
>>>people are too afraid to admit it. New programming
languages,
>>>not aging things tied to the keyboard from the 1960's.
>>>
>>>It took me 6 months to figure out how to write a drawing
program
>>>in cocoa, but a 16-year-old figured it out in the 1970's
easily
>>>with Smalltalk.
>>>_______________________________________________
>>>fonc mailing list
>>>[email protected]
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>>
>>
>>
>>_______________________________________________
fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
>
>_______________________________________________
>fonc mailing list
>[email protected]
>http://vpri.org/mailman/listinfo/fonc
>
>
>_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
