Hi John
I don't think I would call the Analyst visual programming. (And you are right
that to this day most people can't see what a spreadsheet really is (or is
trying to be). I think the real interest of the Analyst was that it was early
and good thinking about what easily programmable visual
I quite like what Apple's Numbers does with spreadsheets... something as simple
as naming sheets and having multiple variable-sized sheets on the one page
(they call them tables) means you can address cells by name and things become
kinda like variables...
That one simple thing makes them so
I have a question about OMeta.
Could it be used in any way to efficiently translate programs between
languages? I've been thinking about this for a number of months now... and it
strikes me that it should be possible...?
Julian.
___
fonc mailing list
Hi Alan,
I'd like to know what do you think about the spreadsheets like Spreadsheet
2000.
http://en.wikipedia.org/wiki/Spreadsheet_2000
http://www.mactech.com/articles/mactech/Vol.13/13.04/Spreadsheet2000/index.html
I much like the idea of polymorphic operators, and the way to create
(visually)
On 4/8/11, Julian Leviston jul...@leviston.net wrote:
I quite like what Apple's Numbers does with spreadsheets... something as
simple as naming sheets and having multiple variable-sized sheets on the
one page (they call them tables) means you can address cells by name and
things become kinda
Which is just what VisiOn did (the followon to spreadsheets done by Software
Arts, the original inventors).
Cheers,
Alan
From: Julian Leviston jul...@leviston.net
To: Fundamentals of New Computing fonc@vpri.org
Sent: Fri, April 8, 2011 7:14:26 AM
Subject:
So if I wanted to translate a Java application to C# (which ought to be pretty
trivial, given the similarity,) what would I do about the libraries? Or the
native interfaces?
It seems like a lot of the semantics of modern (read: industrial 60s/70s tech)
programs really live in libraries written
I like to second Alan's recommendation to explore SK8. SK8 is by far one of my
favorite authoring environments, and has served as a critical point in the
evolution of my thinking about Dynabook-like platforms. Imagine you start with
Hypercard, rebuild its foundation in Lisp (MCL) and ensure
Surely if the translation is efficient, then you can simply translate
everything (libraries, too) down to a sub-machine machine code... which
wouldn't take too much space - in fact it'd probably take less space than
existing compiled libraries AND their documentation.
... maybe we could call
Thanks for responding to my stupid question. :-)
OMeta is quite simple, which makes it very very difficult for me to think about
sometimes (often!) :)
That's pretty fricking awesome... because it obviously means you just have to
do two translations to get all the existing translations to and
But now you are adding some side conditions :)
For example, if you want comparable or even better abstractions in the target
language, then there is a lot more work that has to be done (and I don't know
of
a great system that has ever been able to do this well e.g. to go from an
This isn't our idea, but was a favorite topic in the 60s, and was championed by
Ted Steel, who proposed than an UNCOL (UNiversal Computer Oriented Language)
which could be the intermediary in all translations, especially where the end
target was machine code.
As is often the case, something
12 matches
Mail list logo
