[fonc] Modern General Purpose Programming Language (Was: Task management in a world without apps.)

[Loup Vaillant-David]

On Sun, Nov 03, 2013 at 04:11:15AM -0800, Alan Kay wrote:
> if we were to attempt an ultra high level general purpose language
> today, we wouldn't use Squeak or any other Smalltalk as a model or a
> starting place.

May I ask what would be an acceptable starting point?  Maru, maybe?

Loup.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Modern General Purpose Programming Language (Was: Task management in a world without apps.)

[Alan Kay]

Each to their own, but we have always started with 10-20 example cases that 
we'd like to be really "well fitted" and "nice", plus a few possible "powerful 
principles". I.e "expressiveness" is usually the main aim. If this seems to be 
promising then there are lots of ways to approach fast-enough implementation 
(including making new hardware or using FPGAs, etc.)

Cheers,

Alan




>
> From: Loup Vaillant-David 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Cc: karl ramberg  
>Sent: Monday, November 4, 2013 4:00 PM
>Subject: Modern General Purpose Programming Language (Was: Task management in 
>a world without apps.)
> 
>
>On Sun, Nov 03, 2013 at 04:11:15AM -0800, Alan Kay wrote:
>
>> if we were to attempt an ultra high level general purpose language
>> today, we wouldn't use Squeak or any other Smalltalk as a model or a
>> starting place.
>
>May I ask what would be an acceptable starting point?  Maru, maybe?
>
>Loup.
>
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Modern General Purpose Programming Language (Was: Task management in a world without apps.)

[Miles Fidelman]

Casey Ransberger casey.obrien.r at gmail.comwrites 



A fun, but maybe idealistic idea: an "application" of a computer 
should just be what one decides to do with it at the time.


I've been wondering how I might best switch between "tasks" (or really 
things that aren't tasks too, like toys and documentaries and 
symphonies) in a world that does away with most of the application 
level modality that we got with the first Mac.


The dominant way of doing this with apps usually looks like either the 
OS X dock or the Windows 95 taskbar. But if I wanted less shrink wrap 
and more interoperability between the virtual things I'm interacting 
with on a computer, without forcing me to "multitask" (read: do more 
than one thing at once very badly,) what's my best possible 
interaction language look like?


I would love to know if these tools came from some interesting 
research once upon a time. I'd be grateful for any references that can 
be shared. I'm also interested in hearing any wild ideas that folks 
might have, or great ideas that fell by the wayside way back when.




For a short time, there was OpenDoc - which really would have turned the 
application paradigm on its head.  Everything you interacted with was an 
object; with methods incorporated into it's "container."  E.g., if you 
were working on a "document," there was no notion of a word processor, 
just the document with embedded methods for interacting with it.


Miles Fidelman

--
In theory, there is no difference between theory and practice. In 
practice, there is.  Yogi Berra

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Modern General Purpose Programming Language (Was: Task management in a world without apps.)

[BGB]

On 11/5/2013 7:15 AM, Miles Fidelman wrote:
Casey Ransberger casey.obrien.r at gmail.comwrites 



A fun, but maybe idealistic idea: an "application" of a computer 
should just be what one decides to do with it at the time.


I've been wondering how I might best switch between "tasks" (or 
really things that aren't tasks too, like toys and documentaries and 
symphonies) in a world that does away with most of the application 
level modality that we got with the first Mac.


The dominant way of doing this with apps usually looks like either 
the OS X dock or the Windows 95 taskbar. But if I wanted less shrink 
wrap and more interoperability between the virtual things I'm 
interacting with on a computer, without forcing me to "multitask" 
(read: do more than one thing at once very badly,) what's my best 
possible interaction language look like?


I would love to know if these tools came from some interesting 
research once upon a time. I'd be grateful for any references that 
can be shared. I'm also interested in hearing any wild ideas that 
folks might have, or great ideas that fell by the wayside way back when.




For a short time, there was OpenDoc - which really would have turned 
the application paradigm on its head.  Everything you interacted with 
was an object; with methods incorporated into it's "container."  E.g., 
if you were working on a "document," there was no notion of a word 
processor, just the document with embedded methods for interacting 
with it.




a while ago, I had started, but didn't finish writing (or at least to a 
level I would want to send it) about the relationship between 
object-based and dataflow-based approaches to modular systems (where in 
both cases, the "application" could be largely dissolved in favor of 
interacting components and "generic" UIs).


but, the line gets kind of fuzzy, as what people often call "OOP" 
actually covers several distinct sets of methodologies, and people so 
much often focus on lower-level aspects (class vs not-a-class, 
inheritance trees, ...), that there is a tendency to overlook 
higher-level aspects, like whether the system is composed of objects 
interacting via passing messages using certain interfaces, or whether it 
is working with a data-stream where the objects don't really interact at 
all and rather produce and consume data in a set of shared representations.



then, there is the "bigger" issue from an architectural POV, namely, can 
"App A access anything from within App B?" short of both developers each 
having access to and the ability to hack on each-others' source code 
(or, often, get the thing rebuilt from source sometimes).


so, we have some problems:
lack of shared functionality (often short of what has explicitly been 
made into shared libraries or similar);
frequent inability to add new functionality to existing apps (or "UIs"), 
short of having access to and ability to modify their source-code to 
ones uses;

lots of software that is a PITA to get to rebuild from source (*1);
...

*1: especially in GNU land, where they pride themselves of freely 
available source, but the ever present GNU Autoconf system has a problem:

it very often has a tendency not to work;
it is often annoyingly painful to get it to work when it has decided it 
doesn't want to;
very often developers set some rather arbitrary restrictions on projects 
build-probing, like "must have exactly this version of this library to 
build", even when it will often still build and work with later (and 
earlier) versions of the library;

...

it is sad, in premise, that hard-coded Visual Studio projects, and raw 
Makefiles, are often easier to get to work when things don't go "just 
right". well, that and one time recently managing to apparently get on 
the bad side of some developers for a FOSS GPL project, by going and 
building part of it using MSVC (for plugging some functionality into the 
app), but in this case, it was the path of least effort (the other code 
I was using with it was already being built with MSVC, and I couldn't 
get the main project to rebuild from source via the "approved" routes 
anyways, ...).


weirder yet, some of the better development experiences I have had have 
been in developing extensions for closed-source commercial projects 
(without any ability to see their source-code, or for that matter, even 
worthwhile API documentation), which "should not be".



not that I don't think these problems are solvable, but maybe the 
"spaghetti string mess" that is GNU-land at present isn't really an 
ideal solution. like, there might be a need to address "general 
architectural issues" (provide solid core APIs, ...), rather than just 
daisy-chaining everything in a somewhat ad-hoc manner.



but, as an assertion:
with increasing modularity and ability to share functi