Re: [fonc] How it is
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.99 steps back. Paul. From: John Pratt jpra...@gmail.com To: fonc@vpri.org 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 fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] How it is
On 2 October 2012 16:21, John Pratt jpra...@gmail.com wrote: 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. He's also not very good at dissemination, or doesn't work at it enough. It's all very well saying I told you so when, at least in the internet age, he's done the equivalent of writing I told you so on a disposable napkin which he then locked in the bottom drawer of a filing cabinet in a basement room of a condemned building on a locked site with a sign outside saying BEWARE OF THE LEOPARD, when he could've easily put it on an enormous poster on a main street. I've said enough about that on this list in the past, but I am excited that it's nearly the end of October and hence we should get the final VPRI report and (according to past assertions from the crew) a code drop shortly. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
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.99 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 jpra...@gmail.com *To:* fonc@vpri.org *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 fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] How it is
Reuben Thomas r...@sc3d.org writes:
On 2 October 2012 16:21, John Pratt jpra...@gmail.com wrote:
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.
He's also not very good at dissemination, or doesn't work at it
enough. It's all very well saying I told you so when, at least in
the internet age, he's done the equivalent of writing I told you so
on a disposable napkin which he then locked in the bottom drawer of a
filing cabinet in a basement room of a condemned building on a locked
site with a sign outside saying BEWARE OF THE LEOPARD, when he
could've easily put it on an enormous poster on a main street.
I don't think you can say that. He has worked at Apple, where he has
done all the evangelizing he could. The iPad is basically the hardware
outcome. Hypercard, Dylan, etc as software outcome.
There are a lot of developments around Smalltalk and Squeak too.
Alice http://www.alice.org/
Scratch http://scratch.mit.edu/
Croquet http://opencroquet.org/
etc.
The problem is not the sources of the message. It's the receiptors.
Before 2000, one could give them the excuse that hardware was slow,
dynamic programming languages were not good enough to do fancy things.
But not since. And indeed, there's more and more dynamic programming
languages available (Ruby, Python, etc).
Of course those new languages and systems are not refinements, they're just
yet another try at the same target, so they don't reach it or even aim
any better. Again, the problem is more with the receiptors, who just
prefer to reinvent new stuff rather than learn history, read old
papers and use old programming languages and old systems and refine
them.
Well, at least, in 2012, C and C++ have closures… Perhaps in 35 years,
they'll be sexp-based too!
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] How it is
On 10/2/2012 5:48 PM, Pascal J. Bourguignon wrote: BGB cr88...@gmail.com writes: 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.99 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. One excuse for this however, is that sources for old research projects are not available generally, the more so for failed projects. At most, there's a paper describing the project and some results, but no source, much less machine readable sources. (The fact is that those sources were on punch cards or other unreadable media). a lot of things are for things which are much more recent as 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, ...). Sometimes while not making great scientific or technological advances, it still improves things. Linus wanted to learn unix and wrote Linux and Richard wanted to have the sources and wrote GNU, and we get GNU/Linux which is better than the other unices. well, except, in both of these cases, they were taking account of things which happened before: both of them knew about, and were basing their design efforts off of, Unix. the bigger problem is not with people being like I am going to write my own version of X, but, rather, a person running into the problem without really taking into account that X ever existed, or without putting any effort into understanding how it worked. 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... I would say that for one thing the development of new ideas would have to be done in autarcy: we don't want and can't support old OSes and old languages, since the fundamental principles will be different. But then I'd observe the fate of those different systems, even with a corporation such as IBM backing them, such as OS/400, or BeOS. Even if some of them could find a niche, they remain quite confidential. yeah. the problem is, a new thing is hard. it is one thing to sell, for example, an x86 chip with a few more features hacked on, and quite another to try to sell something like an Itanium. people really like their old stuff to keep on working, and for better or worse, it makes sense to keep the new thing as a backwards-compatible extension. On the other hand, more or less relatively recently, companies have been able to develop and sell new languages/systems: Sun did Java/JVM and it's now developed by Google in Android systems; Apple promoted
