Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Dale Schumacher
On Mon, Feb 27, 2012 at 5:23 PM, Charles Perkins wrote: > I think of the code size reduction like this: > > A book of logarithm tables may be hundreds of pages in length and yet the > equation producing the numbers can fit on one line. > > VPRI is exploring "runnable math" and is seeking key equa

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread BGB
On 2/28/2012 5:36 PM, Julian Leviston wrote: On 29/02/2012, at 10:29 AM, BGB wrote: On 2/28/2012 2:30 PM, Alan Kay wrote: Yes, this is why the STEPS proposal was careful to avoid "the current day world". For example, one of the many current day standards that was dismissed immediately is t

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Julian Leviston
On 29/02/2012, at 10:29 AM, BGB wrote: > On 2/28/2012 2:30 PM, Alan Kay wrote: >> >> Yes, this is why the STEPS proposal was careful to avoid "the current day >> world". >> >> For example, one of the many current day standards that was dismissed >> immediately is the WWW (one could hardly im

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread BGB
On 2/28/2012 2:30 PM, Alan Kay wrote: Yes, this is why the STEPS proposal was careful to avoid "the current day world". For example, one of the many current day standards that was dismissed immediately is the WWW (one could hardly imagine more of a mess). I don't think "the web" is entirel

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
Yes, this is why the STEPS proposal was careful to avoid "the current day world". For example, one of the many current day standards that was dismissed immediately is the WWW (one could hardly imagine more of a mess). But the functionality plus more can be replaced in our "ideal world" with

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread BGB
On 2/28/2012 10:33 AM, Reuben Thomas wrote: On 28 February 2012 16:41, BGB wrote: - 1 order of magnitude is gained by removing feature creep. I agree feature creep can be important. But I also believe most feature belong to a long tail, where each is needed by a minority of users.

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
As I mentioned, Smalltalk-71 was never implemented -- and rarely mentioned (but it was part of the history of Smalltalk so I put in a few words about it). If we had implemented it, we probably would have cleaned up the look of it, and also some of the conventions. You are right that part of it

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Reuben Thomas
On 28 February 2012 20:51, Niklas Larsson wrote: > > But Linux contains much more duplication than drivers only, it > supports many filesystems, many networking protocols, and many > architectures of which only a few of each are are widely used. It also > contains a lot of complicated optimization

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Jakob Praher
Dear Alan, Am 28.02.12 14:54, schrieb Alan Kay: > Hi Ryan > > Check out Smalltalk-71, which was a design to do just what you suggest > -- it was basically an attempt to combine some of my favorite > languages of the time -- Logo and Lisp, Carl Hewitt's Planner, Lisp > 70, etc. do you have a detail

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Niklas Larsson
Den 28 februari 2012 18:33 skrev Reuben Thomas : > On 28 February 2012 16:41, BGB wrote: >>> >>>  - 1 order of magnitude is gained by removing feature creep.  I agree >>>   feature creep can be important.  But I also believe most feature >>>   belong to a long tail, where each is needed by a minor

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
Hi Reuben Yep. One of the many "finesses" in the STEPS project was to point out that requiring OSs to have drivers for everything misses what being networked is all about. In a nicer distributed systems design (such as Popek's LOCUS), one would get drivers from the devices automatically, and th

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
Hi Loup Very good question -- and tell your Boss he should support you! If your boss has a math or science background, this will be an easy sell because there are many nice analogies that hold, and also some good examples in computing itself. The POL approach is generally good, but for a parti

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Reuben Thomas
On 28 February 2012 16:41, BGB wrote: >> >>  - 1 order of magnitude is gained by removing feature creep.  I agree >>   feature creep can be important.  But I also believe most feature >>   belong to a long tail, where each is needed by a minority of users. >>   It does matter, but if the rest of t

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread BGB
On 2/28/2012 3:21 AM, Loup Vaillant wrote: Originally, the VPRI claims to be able to do a system that's 10,000 smaller than our current bloatware. That's going from roughly 200 million lines to 20,000. (Or, as Alan Kay puts it, from a whole library to a single book.) That's 4 orders of magnitud

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant
Alan Kay wrote: Hi Loup As I've said and written over the years about this project, it is not possible to compare features in a direct way here. Yes, I'm aware of that. The problem rises when I do advocacy. A response I often get is "but with only 20,000 lines, they gotta leave features out!"

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant
Julian Leviston wrote: 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

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
Hi Loup As I've said and written over the years about this project, it is not possible to compare features in a direct way here. The aim is to make something that feels like "vanilla personal computing" to an end-user -- that can do "a lot" -- and limit ourselves to 20,000 lines of code. We pic

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alan Kay
Hi Ryan Check out Smalltalk-71, which was a design to do just what you suggest -- it was basically an attempt to combine some of my favorite languages of the time -- Logo and Lisp, Carl Hewitt's Planner, Lisp 70, etc. This never got implemented because of "a bet" that turned into Smalltalk-72,

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alexis Read
I've only been looking at Maru, but as I understand it Maru is supposed to be an evolution of COLA (ie Coke), and both object and lambda language. The self hosting is important in that it can be treated as a first order entity in the system, and I believe it's the smallest self hosting system avail

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Julian Leviston
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"

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Martin Baldan
Guys, there are so much lines of inquiry in this thread I'm getting lost. Here's a little summary. [message] Author: Julian Leviston http://vpri.org/mailman/private/fonc/2012/003081.html As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic,

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant
Originally, the VPRI claims to be able to do a system that's 10,000 smaller than our current bloatware. That's going from roughly 200 million lines to 20,000. (Or, as Alan Kay puts it, from a whole library to a single book.) That's 4 orders of magnitude. From the report, I made a rough break do

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Ryan Mitchley
On 27/02/2012 19:48, Tony Garnock-Jones wrote: My interest in it came out of thinking about integrating pub/sub (multi- and broadcast) messaging into the heart of a language. What would a Smalltalk look like if, instead of a strict unicast model with multi- and broadcast constructed atop (via