Discussion:
[fonc] On inventing the computing microscope/telescope for the dynamic semantic web
Paul D. Fernhout
2010-10-08 15:20:08 UTC
Permalink
The PataPata project (by me) attempted to bring some ideas for Squeak and
Self to Python about five years ago. A post mortem critique on it from four
years ago:
"PataPata critique: the good, the bad, the ugly"
http://patapata.sourceforge.net/critique.html

I am wondering if there is some value in reviving the idea for JavaScript?

Firebug shows what is possible as a sort of computing microscope for
JavaScript and HTML and CSS. Sencha Ext Designer shows what is possible as
far as interactive GUI design.

Here are some comments I just posted to the list there that touch on system
design, Squeak, Self, and some FONC issues:
"Thoughts on PataPata four years later..."

http://sourceforge.net/mailarchive/message.php?msg_name=4CACF913.8030405%40kurtz-fernhout.com

http://sourceforge.net/mailarchive/message.php?msg_name=4CAF294B.8010101%40kurtz-fernhout.com

Anyway, I still think the telescope/microscope issue in designing new
computing systems is important, as I suggested here in 2007:
"[Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re:
More Pipeline News)"
http://mail.python.org/pipermail/edu-sig/2007-March/007822.html
"There is once again the common criticism leveled at Smalltalk of being too
self-contained. Compare this proposal with one that suggested making tools
that could be used like telescope or a microscope for relating to code
packages in other languages -- to use them as best possible on their own
terms (or perhaps virtualized internally). Consider how the proposal
suggests scripting all the way down -- yet how are the scripting tools built
in Squeak? Certainly not with the scripting language. And consider there are
always barriers to any system -- where you hit the OS, or CPU microcode, or
proprietary hardware specifications, or even unknowns in quantum physics,
and so on. :-) So every system has limits. But by pretending this one will
not, this project may miss out on the whole issue of interfacing to systems
beyond those limits in a coherent way."

Biology made a lot of progress by inventing the microscope -- and that was
done way before it invented genetic engineering, and even before it
understood there were bacteria around. :-)

What are our computing microscopes now? What are our computing telescopes?
Are debuggers crude computing microscopes? Are class hierarchy browsers and
package managers and IDEs and web browsers crude computing telescopes?

Maybe we need to reinvent the computing microscope and computing telescope
to help in trying to engineer better digital organisms via FONC? :-) Maybe
it is more important to do it first?

But sure, everyone is going to say, we have all the debuggers we need,
right? We have all the inspectors, browsers, and so forth we could use?

I know, inventing a "microscope" probably sounded crazy at the time too:
http://inventors.about.com/od/mstartinventions/a/microscopes.htm
"1590 – Two Dutch eye glass makers, Zaccharias Janssen and son Hans Janssen
experimented with multiple lenses placed in a tube. The Janssens observed
that viewed objects in front of the tube appeared greatly enlarged, creating
both the forerunner of the compound microscope and the telescope."

After, all, everyone in 1590 probably thought biology was already well
understood. :-) Dealing with "Evil humors" and "Bad air" and "Bad blood"
(requiring leaching) were obvious solutions to what ailed most people --
there was no need to suggest tiny itty-bitty creatures were everywhere, what
an absurd idea. Utter craziness.

BTW, the guy who proposed less patients would die if doctors washed their
hands before examining them (before much was known about bacteria)
essentially got beaten to death for his troubles, too:
http://en.wikipedia.org/wiki/Ignaz_Semmelweis

This guy (Herbert Shelton) was hounded by the police and the medical
establishment for suggesting about a century ago that sunlight, fasting, and
eating whole foods was a recipe for good health:
http://www.soilandhealth.org/02/0201hyglibcat/shelton.bio.bidwell.htm

That recipe for good health is one we are only rediscovering now, like with
the work of Dr. John Cannell and Dr. Joel Fuhrman putting the pieces
together, based on the science and scientific tools and communications
technology that Herbert Shelton did not have.
http://www.vitamindcouncil.org/treatment.shtml


Still, Herbert Shelton missed one big idea (about DHA) that probably did him in:
http://www.drfuhrman.com/library/lack_of_DHA_linked_to_Parkinsons.aspx

So, it can be hart to introduce "new ideas", between the risk of being
beaten to death by the establishment (after all, how could a gentleman
doctor's hands be "unclean"?) and the problem of only being 95% technically
right and getting 5% technically or socially very wrong.

Could the "semantic web" be the equivalent of the unknown bacteria of the
1590s? What would computing look like as a semantic web? Alan Kay said in
one talk that a baby can grow 20 times in size without being taken down for
maintenance. Is the web every "taken down" in its entirety for maintenance?

As I said at the end of my second post linked above: "It's taken a while for
me to see this, but, with JavaScript, essentially each web page can be seen
like a Smalltalk ObjectMemory (or text-based image like PataPata writes
out). While I work towards using the Pointrel System to add triples in a
declarative way, in practice, the web of calling cgi scripts at URLs is a
lot like message passing (just more like the earlier Smalltalk-72 way
without well-defined syntax). So, essentially, a web of HTML pages with
JavaScript and CGI on servers is like the Smalltalk system written large.
:-) Just in a very ad hoc and inelegant way. :-)"

Anyway, maybe that is not what FONC is about as far as actual new tools
(which focuses on being more self-contained or reinventing everything)?
http://www.viewpointsresearch.org/html/work/ifnct.htm

But, it seems like there is a need for even better microscopes and
telescopes to begin to think about all that stuff already around us
(especially tools in the hands of the next generation). And, then, with that
better knowledge of our surroundings (and history), and with other tools
those microscopes and telescopes help us build, then together we can
reinvent that emerging dynamic semantic web as needed (or at least improve
some parts of it and learn to live better with the rest of it, like we have
not wiped out bacteria, but we have learned to appreciate them more,
including the good stuff they can do for humanity). Examples:
"Winemaking"
http://en.wikipedia.org/wiki/Winemaking
"Scientists Develop Plastic-Producing Bacteria"

http://www.inhabitat.com/2008/09/22/scientists-develop-plastic-producing-bacteria/
"Teen Discovers Plastic-Decomposing Bacteria"
http://science.slashdot.org/article.pl?sid=08/05/24/0335242

And even this, about something as basic as mother's milk:
http://www.nytimes.com/2010/08/03/science/03milk.html
"A large part of human milk cannot be digested by babies and seems to have a
purpose quite different from infant nutrition — that of influencing the
composition of the bacteria in the infant’s gut."

So, through the tools of science, and not just microscopes, but also
communications tools, we have moved from thinking of health in terms of evil
spirits to seeing it as a partnership with certain bacteria and more an
issue of ecological management. :-)

Anyway, in part, this is just about following Dan Ingalls' and Alan Kay's
lead like with trying out JavaScript with the Lively Kernel.
http://www.lively-kernel.org/
But it is also about something else -- something about tools, and asking,
what are the tools that we need to survive and prosper in this emerging
JavaScript, HTML, CSS, RDF, etc. semantic web we all ready live in and are
building more-and-more of around ourselves as a global community?

Anyway, just some things for VPRI and others to think about in terms of new
projects.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Waldemar Kornewald
2010-10-08 17:51:32 UTC
Permalink
Hi,

On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout
Post by Paul D. Fernhout
The PataPata project (by me) attempted to bring some ideas for Squeak and
Self to Python about five years ago. A post mortem critique on it from four
 "PataPata critique: the good, the bad, the ugly"
 http://patapata.sourceforge.net/critique.html
In that critique you basically say that prototypes *maybe* aren't
better than classes, after all. On the other hand, it seems like most
problems with prototypes weren't related to prototypes per se, but the
(ugly?) implementation in Jython which isn't a real prototype-based
language. So, did you have a fundamental problem with prototypes or
was it more about your particular implementation?
Post by Paul D. Fernhout
I am wondering if there is some value in reviving the idea for JavaScript?
Firebug shows what is possible as a sort of computing microscope for
JavaScript and HTML and CSS. Sencha Ext Designer shows what is possible as
far as interactive GUI design.
What exactly does JavaScript give you that you don't get with Python?

If you want to have prototypes then JavaScript is probably the worst
language you can pick. You can't specify multiple delegates and you
can't change the delegates at runtime (unless your browser supports
__proto__, but even then you can only have one delegate). Also, as a
language JavaScript is just not as powerful as Python. If all you want
is a prototypes implementation that doesn't require modifications to
the interpreter then you can get that with Python, too (*without*
JavaScript's delegation limitations).

Bye,
Waldemar

--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/
John Zabroski
2010-10-08 18:28:11 UTC
Permalink
JavaScript also doesn't support true delegation, as in the Actors Model of
computation.

Also, Sencha Ext Designer is an abomination. It is a fundamental
misunderstanding of the Web and how to glue together chunks of text via
"hyperlinks". It is the same story for any number of technologies that
claim to "fix" the Web, including GWT... they are all not quite up to par,
at least by my standards.

The fundamental problem with the Web is the Browser. This is the monsterous
bug.

The fundamental problem with Sencha Ext is that the quality of the code
isn't that great (many JavaScript programmers compound the flaws of the
Browser by not understanding how to effectively program against the Browser
model), and it also misunderstands distributed computing. It encourages
writing applications as if they were still single-tier IBM computers from
the 1970s/80s costing thousands of dollars.

Why are we stuck with such poor architecture?

Cheers,
Z-Bo
Post by Paul D. Fernhout
Post by Paul D. Fernhout
I am wondering if there is some value in reviving the idea for
JavaScript?
Post by Paul D. Fernhout
Firebug shows what is possible as a sort of computing microscope for
JavaScript and HTML and CSS. Sencha Ext Designer shows what is possible
as
Post by Paul D. Fernhout
far as interactive GUI design.
What exactly does JavaScript give you that you don't get with Python?
If you want to have prototypes then JavaScript is probably the worst
language you can pick. You can't specify multiple delegates and you
can't change the delegates at runtime (unless your browser supports
__proto__, but even then you can only have one delegate). Also, as a
language JavaScript is just not as powerful as Python. If all you want
is a prototypes implementation that doesn't require modifications to
the interpreter then you can get that with Python, too (*without*
JavaScript's delegation limitations).
Bye,
Waldemar
--
http://www.allbuttonspressed.com/
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Waldemar Kornewald
2010-10-08 18:38:18 UTC
Permalink
Post by John Zabroski
Why are we stuck with such poor architecture?
A bad language attracts bad code. ;)

Bye,
Waldemar
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
John Zabroski
2010-10-08 18:48:43 UTC
Permalink
Even modern technology like Windows Phone 7 encourages, as part of their App
Store submission guidelines, that the app hardwire support for two screen
resolutions. This is bizarre considering the underlying graphics
implementation is resolution-independent.

These bad choices add up. As Gerry Weinberg wrote in Secrets of Consulting,
*Things are the way they are because they got that way ... one logical step
at a time*.

But bad choices keeps us employed in our current roles (as consultants, as
in-house IT, etc.).

Cheers,
Z-Bo
Post by Waldemar Kornewald
Post by John Zabroski
Why are we stuck with such poor architecture?
A bad language attracts bad code. ;)
Bye,
Waldemar
--
http://www.allbuttonspressed.com/blog/django
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
BGB
2010-10-08 20:52:19 UTC
Permalink
----- Original Message -----
From: "Waldemar Kornewald" <***@freenet.de>
To: "Fundamentals of New Computing" <***@vpri.org>
Sent: Friday, October 08, 2010 11:38 AM
Subject: Re: [fonc] On inventing the computing microscope/telescope for
thedynamic semantic web
Post by Waldemar Kornewald
Post by John Zabroski
Why are we stuck with such poor architecture?
A bad language attracts bad code. ;)
well, JS could be better...


for example, my custom variant (BGBScript) supports multiple delegates,
ability to handle delegation loops, ... (however, working with them requires
at present using non-standard syntax).

it also uses a different scoping model than proper JS as well:
a lexical scope is used for locals;
there is object based scoping via 'this';
there is also a toplevel scope 'top', which is also an object (most of the
toplevel is implemented in terms of objects linked together by delegation
chains).

originally, this and top were the same (there was only this, which would
need to delegate to the toplevel);
however, a split was added later, mostly because this had created problems
with using objects created outside the BS interpreter.

granted, there are many other minor variations (numeric types are
implemented and work differently than in the standard, as it has separate
integer and real types rather than a unified 'number' type, ...), so it is
not really a true JS/ES implementation, but at least most simple JS code
seems to work (apart from stuff which assumes a browser or similar).

"typeof(expr)" is also an issue, as it currently doesn't return what
ECMA-262 says it should (it currently returns the internal type names), ...


some additional non-standard features exist, but are mostly related to
interfacing with C and Java code (and their respective typesystems, but this
is mostly internal and doesn't add new syntax), and some syntax elements
adapted from ActionScript and similar.

package MyApp
{
class Bar extends Foo implements IBaz
{
function foo():void //base-types are lowercase, unlike AS
{
var x:byte[]; //syntax works, but the type is
presently ignored in this case
x=new byte[256]; //likely later, incomplete though (more
awkward syntax currently used)
x=dycNewArray("h", 256); //current syntax (uses C interface)
...
}
...
}
}


however, generally the above style is not used (nor will this example work
in the current VM), so it is more generally used similarly to JS (but with
the ability to see into C land, which is mostly how I use it).

actually, it was me adding the ability to (mostly) transparently see into
C-land which revived my interest in using/maintaining the language (this is
done with a lot of ugly hackery, involving parsing headers to mine metadata,
and auto-generating native-code thunks to glue together the interpreter and
C land, as well as a few other hacks to make C preprocesser definitions
visible, ...).

note that the C interface is largely implemented in terms of a special
object type, and hence, if this object is not part of the scope (say, using
a 'top' object which doesn't delegate to it), then C functions are not
visible (it was done this way so that the interpreter would not "inherently"
violate security by always having direct visibility of C land).


for example:
function foo()
{
printf("%f\n", M_PI); //this will actually work...
}
foo();


implemented, but largely untested, facilities also exist for the ability to
directly work with C structures, as well as the ability to shove BS
functions into C-side function pointers (this also involves generating
thunks).


or such...
Dirk Pranke
2010-10-09 01:17:56 UTC
Permalink
Post by John Zabroski
JavaScript also doesn't support true delegation, as in the Actors Model of
computation.
Also, Sencha Ext Designer is an abomination.  It is a fundamental
misunderstanding of the Web and how to glue together chunks of text via
"hyperlinks".  It is the same story for any number of technologies that
claim to "fix" the Web, including GWT... they are all not quite up to par,
at least by my standards.
The fundamental problem with the Web is the Browser.  This is the monsterous
bug.
The fundamental problem with Sencha Ext is that the quality of the code
isn't that great (many JavaScript programmers compound the flaws of the
Browser by not understanding how to effectively program against the Browser
model), and it also misunderstands distributed computing.  It encourages
writing applications as if they were still single-tier IBM computers from
the 1970s/80s costing thousands of dollars.
Why are we stuck with such poor architecture?
Apologies if you have posted this before, but have you talked anywhere
in more detail about what the "monsterous bug" is (specifically), or
how programming for the web misunderstands distributed computing?

-- Dirk
Post by John Zabroski
Cheers,
Z-Bo
Post by Waldemar Kornewald
Post by Paul D. Fernhout
I am wondering if there is some value in reviving the idea for JavaScript?
Firebug shows what is possible as a sort of computing microscope for
JavaScript and HTML and CSS. Sencha Ext Designer shows what is possible as
far as interactive GUI design.
What exactly does JavaScript give you that you don't get with Python?
If you want to have prototypes then JavaScript is probably the worst
language you can pick. You can't specify multiple delegates and you
can't change the delegates at runtime (unless your browser supports
__proto__, but even then you can only have one delegate). Also, as a
language JavaScript is just not as powerful as Python. If all you want
is a prototypes implementation that doesn't require modifications to
the interpreter then you can get that with Python, too (*without*
JavaScript's delegation limitations).
Bye,
Waldemar
--
http://www.allbuttonspressed.com/
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
John Zabroski
2010-10-10 00:44:38 UTC
Permalink
Post by John Zabroski
Post by John Zabroski
JavaScript also doesn't support true delegation, as in the Actors Model
of
Post by John Zabroski
computation.
Also, Sencha Ext Designer is an abomination. It is a fundamental
misunderstanding of the Web and how to glue together chunks of text via
"hyperlinks". It is the same story for any number of technologies that
claim to "fix" the Web, including GWT... they are all not quite up to
par,
Post by John Zabroski
at least by my standards.
The fundamental problem with the Web is the Browser. This is the
monsterous
Post by John Zabroski
bug.
The fundamental problem with Sencha Ext is that the quality of the code
isn't that great (many JavaScript programmers compound the flaws of the
Browser by not understanding how to effectively program against the
Browser
Post by John Zabroski
model), and it also misunderstands distributed computing. It encourages
writing applications as if they were still single-tier IBM computers from
the 1970s/80s costing thousands of dollars.
Why are we stuck with such poor architecture?
Apologies if you have posted this before, but have you talked anywhere
in more detail about what the "monsterous bug" is (specifically),
I have not discussed this much on the FONC list. My initial opinions were
formed from watching Alan Kay's 1997 OOPSLA speech, The Computer Revolution
Hasn't Happened Yet (available on Google Video [1]). One of Alan Kay's key
criticisms from that talk was that "You don't need a Browser." I've
mentioned this quote and its surrounding context on the FONC list in the
past. The only comment I've made on this list in the past, related to this
topic, is that the View Source feature in the modern Browser is an
abomination and completely non-object-oriented. View Source is a property
of the network, not the document. The document is just exposing a
representation. If you want to build a debugger, then it needs to be based
on the network, not tied to some Browser that has to know how to interpret
its formats. What we have right now with View Source is not a true Source.
It's some barf the Browser gives you because you don't know any better to
demand something better, richer. Sure, it's possible if View Source is a
property of the network that a subnet can always refuse your question.
That's to be expected. When that happens, you can fallback to the kludgy
View Source you have today.

99% of the people in this world to this point have been happy with it,
because they just haven't thought about what something better should do.
All they care about is if they can steal somebody else's site design and
JavaScript image rollover effect, because editing and stealing live code is
even easier than googling and finding a site with these "Goodies". And the
site they would've googled probably just used the same approach of seeing
some cool effect and using View Source. The only difference is the sites
about DHTML design decorated the rip with an article explaining how to use
it and common pitfalls the author encountered in trying to steal it.

For some context, to understand Alan's criticisms, you have to know Alan's
research and his research groups. For example, in the talk I linked above,
Alan makes an overt reference to Tim Berners-Lee's complete
non-understanding of how to build complex systems (Alan didn't call out Tim
directly, but he said the Web is what happens when physicists play with
computers). Why did Alan say such harsh things? Because he can back it
up. Some of his work at Apple on the Vivarium project was focused on
something much better than Tim's "Browser". Tim won because people didn't
understand the difference and didn't really care for it (Worse Is Better).
To be fair, Tim had the right idea with a Uri. Roy Fielding's Ph.D. thesis
explains this (and hopefully if you're working on Chromium you've read that
important thesis, since it is probably as widely read as Claude Shannon's on
communication). And both Alan and Tim understood languages needed good
resource structure. See Tim's talk at the first-ever JavaOne in 1997 [2]
and Tim's criticism of Java (where he admits never having seen the language,
or used it, just stating what he thinks the most important thing about a VM
is [3]) But that's all Tim got right at first. Tim got distracted by his
Semantic Web vision. Sometimes having too huge a vision prevents you from
working on important small problems. Compare Tim's quote in [3] to Alan's
comments about Java in [1] where Alan talks about meta-systems and
portability.
Post by John Zabroski
or
how programming for the web misunderstands distributed computing?
I've written on my blog a few criticisms, such as a somewhat incoherent
critique of what some developers called "SOFEA" architecture. For an
introduction to SOFEA, read [4]. My critique, which again was just me
rambling about its weaknesses and not meant for widespread consumption, can
be found at [5]. I also got into a lengthy debate on LtU with Google
employees about the design of GWT code splitting [6]. Eventually, one of the
architects of GWT got involved. I was not satisfied by their answer. A lot
of my other comments aren't public and focused in private e-mails with
Paul D. Fernhout
2010-10-10 14:38:22 UTC
Permalink
On 10/9/10 8:44 PM, John Zabroski wrote:
Julian Leviston
2010-10-10 14:52:29 UTC
Permalink
I'm not entirely sure why the idea of pattern expressions and meta-translators wasn't an awesome idea.

If expressing an idea cleanly in a language is possible, and expressing that language in another language clearly and cleanly is possible, why is it not possible to write a tool which will re-express that original idea in the second language, or any other target language for that matter?

I thought this development of a meta-translator was not only one of the FUNC goals, but one that had for the most part been at least completed?

Julian.
Anyway, so I do have hope that we may be able to develop platforms that let us work at a higher level of abstraction like for programming or semantic web knowledge representation, but we should still accept that (de facto social) standards like JavaScript and so on have a role to play in all that, and we need to craft our tools and abstractions with such things in mind (even if we might in some cases just use them as a VM until we have something better). That has always been the power of, say, the Lisp paradigm, even as Smalltalk's message passing paradigm has a lot going for it as a unifying and probably more scalable abstraction. What can be frustrating is when our "bosses" say "write in Fortran" instead of saying "write on top of Fortran", same as if they said, "Write in assembler" instead of "Write on top of assembler or JavaScript or whatever". I think work like VPRI through COLA is doing to think about getting the best of both worlds there is a wonderful aspiration, kind of like trying to understand the particle/wave duality mystery in physics (which it turns out is potentially explainable by a many-worlds hypothesis, btw). But it might help to have better tools to do that -- and tools that linked somehow with the semantic web and social computing and so on.
Paul D. Fernhout
2010-10-10 15:39:09 UTC
Permalink
Post by Julian Leviston
I'm not entirely sure why the idea of pattern expressions and
meta-translators wasn't an awesome idea.
Maybe we're still missing a lot of general purpose tools to work with all that?
Post by Julian Leviston
If expressing an idea cleanly in a language is possible, and expressing
that language in another language clearly and cleanly is possible, why is
it not possible to write a tool which will re-express that original idea
in the second language, or any other target language for that matter?
Well, I can wonder if it just not possible to express and idea outside of a
social community? (That's a bit philosophical though. :-)
http://en.wikipedia.org/wiki/Social_constructivism
http://en.wikipedia.org/wiki/Social_constructionism
"Although both social constructionism and social constructivism deal with
ways in which social phenomena develop, they are distinct. Social
constructionism refers to the development of phenomena relative to social
contexts while social constructivism refers to an individual's making
meaning of knowledge within a social context (Vygotsky 1978). For this
reason, social constructionism is typically described as a sociological
concept whereas social constructivism is typically described as a
psychological concept. However, while distinct, they are also complementary
aspects of a single process through which humans in society create their
worlds and, thereby, themselves."

But in practice, having written some ad hoc translators from one programming
language and library set to another, there are idiomatic and paradigm issues
that come up, ones that would really take some sort of fancy
bordering-on-AI-ish capacity to deal with. It's doable (in theory, as many
AI-ish solutions are), but it's not usually trivial in practice because of
the details involved in thinking about ways that things map to each other,
how to reason about all that, and how to involve humans in that loop.

So, say, if you are translating a GUI application that uses a drop down
combo box and the target platform does not have such a widget, what do you
do? Do you change the GUI to have a button an a popup window with a list, do
you synthesize the functionality by generating a new widget, do you put in a
stub for the programmer to fill in, or do you involve a person in realtime
to make that choice (or create a widget) and then keep a note of it
somewhere for future reference?
Post by Julian Leviston
I thought this development of a meta-translator was not only one of the
FUNC goals, but one that had for the most part been at least completed?
Software is never "done". :-) Especially because the world keeps changing
around it. :-) And especially when it is "research" and doing basic research
looking for new ideas. :-)

Although I'm still a bit confused by what OMeta does that Antlr (and
ANTLRWorks) can't do? And Antlr, while really neat as a system, is just a
platform on which to build translators with a lot of hard work.
http://tinlizzie.org/ometa/
http://www.antlr.org/

So, I would expect, likewise, that OMeta would be also a platform on which
people can put in a lot of hard work on top of? But I have not used OMeta,
so I can't speak to all the differences, even as I've seen the limits of
other parsing systems I've used, like Antlr (as well as their powers, which
can take a while to appreciate).

Anyway, if someone could clarify the differences in either goals or
implementation between OMeta and Antlr, that might be helpful in
understanding what one could (or could not) do with it, given Antlr has not
magically given us a higher level of semantic abstraction for dealing with
programming systems (even as Antlr is a great system for transforming
hierarchies encoded in some textual way). Antlr is just the beginning, like,
say, Smalltalk is just the beginning. So, I'd imagine OMeta is just a
beginning in that sense.

But I have a feeling this will bring us back to my point in the previous
section, that knowledge is in a sense social, and a translator (or language)
by itself is only part of the puzzle.

And, btw, in that sense, "personal computing" by definition can not exist,
at least, not if it involves humans dealing in "socially constructed
knowledge". :-) And thus the value in telescopes/microscopes to let
individuals look out on that social context or the artifacts it presents us
with.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Julian Leviston
2010-10-10 17:18:29 UTC
Permalink
My answer can be best expressed simply and deeply thus:

"I don't see the unix command 'ls' being rewritten every day or even every year."

Do you understand what I'm trying to get at? It's possible to use an 'ls' replacement if I so choose, but that's simply my preference. 'ls' itself hasn't been touched much in a long time. The same as the ADD assembler instruction is pretty similar across platforms. Get my drift?

Part of the role of a language meta-description is implementation of every translatable artefact. Thus if some source item requires some widget, that widget comes with it along for the ride as part of the source language (and framework) meta-description.

I'm possibly missing something, but I don't see the future as being a simple extension of the past... it should not be that we simply create "bigger worlds" as we've done in the past (think virtual machines) but rather looks for ways to adapt things from worlds to integrate with each other. Thus, I should not be looking for a better IDE, or programming environment, but rather take the things I like out of what exists... some people like to type their code, others like to drag 'n drop it. I see no reason why we can't stop trying to re-create entire universes inside the machines we use and simply split things at a component-level. We're surely smarter than reinventing the same pattern again and again.

Julian.
Software is never "done". :-) Especially because the world keeps changing around it. :-) And especially when it is "research" and doing basic research looking for new ideas. :-)
Paul D. Fernhout
2010-10-10 22:39:59 UTC
Permalink
Post by Julian Leviston
Post by Paul D. Fernhout
Software is never "done". :-) Especially because the world keeps
changing around it. :-) And especially when it is "research" and doing
basic research looking for new ideas. :-)
"I don't see the unix command 'ls' being rewritten every day or even every year."
http://git.busybox.net/busybox/log

:-)
Post by Julian Leviston
Do you understand what I'm trying to get at? It's possible to use an 'ls'
replacement if I so choose, but that's simply my preference. 'ls' itself
hasn't been touched much in a long time. The same as the ADD assembler
instruction is pretty similar across platforms. Get my drift?
http://en.wikipedia.org/wiki/Cover_Flow

:-)

And there's a lawsuit about that ongoing, by the way, with at US$250 million
dollar or so judgment being appealed.

I really dislike software patents. :-( Or being essentially forced to accede
to them as a condition of employment:
http://www.freepatentsonline.com/6513009.html

From:

http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state
"Douglas Crockford: So one of the lessons is that patents and open systems
are not compatible. I think the solution to that incompatibility is to close
the Patent Office [applause]"
Post by Julian Leviston
Part of the role of a language meta-description is implementation of
every translatable artefact. Thus if some source item requires some
widget, that widget comes with it along for the ride as part of the
source language (and framework) meta-description.
Well, licenses may get in the way, as they did for my translation of Delphi
to Java and Python. Often code we have control over or responsibility for is
only a small part of a large set of interdependent modules.

Also, you may call a service and that service may need to be reimplemented
or rethought with an entire chain of conceptual dependencies...

One issue is, what are the boundaries of the system?

Do they even include things like the documentation and culture surrounding
the artifact?

From:
http://en.wikipedia.org/wiki/Social_constructivism
"Social constructivism is a sociological theory of knowledge that applies
the general philosophical constructionism into social settings, wherein
groups construct knowledge for one another, collaboratively creating a small
culture of shared artifacts with shared meanings. When one is immersed
within a culture of this sort, one is learning all the time about how to be
a part of that culture on many levels. Its origins are largely attributed to
Lev Vygotsky. ... Social constructivism is closely related to social
constructionism in the sense that people are working together to construct
artifacts. However, there is an important difference: social constructionism
focuses on the artifacts that are created through the social interactions of
a group, while social constructivism focuses on an individual's learning
that takes place because of their interactions in a group. ... Vygotsky's
contributions reside in Mind in Society (1930, 1978) and Thought and
Language (1934, 1986). [2] Vygotsky independently came to the same
conclusions as Piaget regarding the constructive nature of development. ...
An instructional strategy grounded in social constructivism that is an area
of active research is computer-supported collaborative learning (CSCL).
This strategy gives students opportunities to practice 21st-century skills
in communication, knowledge sharing, critical thinking and use of relevant
technologies found in the workplace."

So, can a truly useful translation system function outside that social
context, including arbitrary legal constructs?

So, what are the boundaries of the translation task? They may be fuzzier
than they appear at first (or even more sharp and arbitrary, like above, due
to legal issues or social risk assessments or even limited time).
Post by Julian Leviston
I'm possibly missing something, but I don't see the future as being a
simple extension of the past... it should not be that we simply create
"bigger worlds" as we've done in the past (think virtual machines) but
rather looks for ways to adapt things from worlds to integrate with each
other. Thus, I should not be looking for a better IDE, or programming
environment, but rather take the things I like out of what exists... some
people like to type their code, others like to drag 'n drop it. I see no
reason why we can't stop trying to re-create entire universes inside the
machines we use and simply split things at a component-level. We're
surely smarter than reinventing the same pattern again and again.
Despite what I wrote above, I basically agree with your main point here. :-)

Still, Chuck Moore rewrote Forth over and over again. He liked doing it, and
it slowly improved. And as I read elsewhere, it would really upset the
people at the company he worked with that he would rewrite Forth every time
from scratch for every new processor (although relying on some microfiche
from previous versions for inspiration). One place it was said he'd even
rewrite basic routines like multiplication that came with systems saying
that he had written a multiplication routine ten times so his was more
likely to work right than one written by someone who had only ever written
one once. :-)

Chuck Moore is a bit more like a Jazz pianist in that sense than a Classical
composer. :-)

From:
http://www.advogato.org/article/1034.html
"Question to [Chuck Moore]: "Would you consider developing a new language
from scratch?" CM: "No. I develop languages all the time. Each application
requires one. But they’re all based on Forth. Forth has been called a
language tool-kit. It is the starting point for an application language,
much as the infant brain has the ability to learn any human language. ..."

But I more and more see Chuck Moore's point. I've been reimplementing the
same darn triples for almost thirty years, but I like it -- it kind of has a
Zen quality to it. I'm doing it yet again in JavaScript to learn about
JavaScript. For me, that is like being a pianist and sitting down at a new
piano in a new room and playing an old tune. :-) It is programming as
performance more than programming as bottom dollar maximal reuse. :-) But it
is not incompatible with craftsmanship. Who do you want to redo your siding
-- the carpenter who has doing it once, or the carpenter who has done it ten
times? Of course, at some point stuff gets boring and we automate it, sure.
But a lot of people still play Jazz music live even if you can get it cheap
on CD or even for free lots of places on the internet.

At the link above there is some text (not sure if Chuck Moore said it) of:
"I despair. Technology, and our very civilization, will get more and more
complex until it collapses. There is no opposing pressure to limit this
growth. No environmental group saying: Count the parts in a hybrid car to
judge its efficiency or reliability or maintainability. All I can do is
provide existence proofs: Forth is a simple language; OKAD is a simple
design tool; GreenArrays offers simple computer chips. No one is paying any
attention."

Now, is in not a good thing if lots of people have experience writing "ls"
from scratch? Isn't redundancy in human culture learning overall a good
thing? To know that there are thousands of people who could write ls in
their sleep the same way concert pianists could play Chopsticks in their sleep?

And also that one may even figure out some way to improve it (make it
faster, make it more intuitive, make it do something new, make it run on
another piece of hardware, improve the testing methodology for it, and so on)?

Can you really say you "grok" the ls program (assuming it is stand alone) if
you have not written it? Maybe you have to use someone else's "ls" for
monetary reasons or lack of interest in it, but maybe for the right person,
it would be fun to write it again? Perhaps, you can rewrite it with your own
twist on it, like putting it into BusyBox or putting some sort of
"CoverFlow" or other GUI on top of it as an extension of the file list idea?
Or maybe redesign "ls" out of existence entirely by using a semantic web of
triples to store data with not a file in sight?

What does it even mean than there is an ls "program" if it calls libraries?
Where are the boundaries of "ls"? Isn't any implementation of ls just a sort
of ripple in a larger wave pool of ideas constantly in interplay like a
lake's surface in the rain?

And even the people who maintain "ls" can get stuck in various problem
states -- seemingly absurd ones, but real ones; example:
http://www.busybox.net/FAQ.html
"The "linux" or "asm" directories of /usr/include contain Linux kernel
headers, so that the C library can talk directly to the Linux kernel. In a
perfect world, applications shouldn't include these headers directly, but we
don't live in a perfect world. ... The BusyBox developers spent two years
trying to figure out a clean way to do all this. There isn't one. The
losetup in the util-linux package from kernel.org isn't doing it cleanly
either, they just hide the ugliness by nesting #include files. Their
mount/loop.h #includes "my_dev_t.h", which #includes <linux/posix_types.h>
and <linux/version.h> just like we do. There simply is no alternative."

So, there is an example of people spending two years trying to write a
better "ls" from one particular perspective (and failing and making do with
a kludge. :-)

Anyway, so I still maintain, software is never done because the world is
continually changing around it.

Maybe in theory software like "ls" should be done. Maybe someday it will be
done. But I don't see that anytime in the next decade or two with all the
changes going on.

So, that's an interesting issue you raise with this example. How does FONC
relate to implementing and debugging something as seeming trivial and basic
as "ls" that has caused experts two years of hair pulling in the real world?

And even then, it looks like this version of ls still has "known bugs". :-)

http://busybox.sourcearchive.com/documentation/1:1.10.2-1ubuntu3/coreutils_2ls_8c-source.html
"""
/*
* To achieve a small memory footprint, this version of 'ls' doesn't do any
* file sorting, and only has the most essential command line switches
* (i.e., the ones I couldn't live without :-) All features which involve
* linking in substantial chunks of libc can be disabled.
*
* Although I don't really want to add new features to this program to
* keep it small, I *am* interested to receive bug fixes and ways to make
* it more portable.
*
* KNOWN BUGS:
* 1. ls -l of a directory doesn't give "total <blocks>" header
* 2. ls of a symlink to a directory doesn't list directory contents
* 3. hidden files can make column width too large
*
* NON-OPTIMAL BEHAVIOUR:
* 1. autowidth reads directories twice
* 2. if you do a short directory listing without filetype characters
* appended, there's no need to stat each one
* PORTABILITY:
* 1. requires lstat (BSD) - how do you do it without?
*/
"""

So, there is a todo list for an ls implementation. :-)

You picked the example, not I. :-)

And I'm glad you did, because talking about specific examples brings us back
to reality as to the history of computing and its likely future.
Julian Leviston
2010-10-10 17:21:44 UTC
Permalink
Does anyone know about a language (possibly something in smalltalk) that involves spec-driven development?

A language that stipulates a spec (in code - ie a test) must be written before any code can be written, and that can also do self-checks (sort of like a checksum) before the code is executed?

Julian.
BGB
2010-10-11 01:24:44 UTC
Permalink
----- Original Message -----
From: "Julian Leviston" <***@leviston.net>
To: "Fundamentals of New Computing" <***@vpri.org>
Sent: Sunday, October 10, 2010 10:21 AM
Subject: [fonc] Spec-Driven & Self-Testing Code

<--
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?

A language that stipulates a spec (in code - ie a test) must be written
before any code can be written, and that can also do self-checks (sort of
like a checksum) before the code is executed?

Julian.
-->

possibly relevant questions:
what would be the merit of imposing such a restriction?
how would one enforce such a restriction?
how could this be done without compromising the ability to use the language
to get much useful done?
...

IMO, any such restrictions are better left under the control of "the
development process" rather than trying to enforce them at the language
level.


this sounds sort of like:
http://en.wikipedia.org/wiki/Big_Design_Up_Front
or:
http://en.wikipedia.org/wiki/Waterfall_model


although this could also be intended:
http://en.wikipedia.org/wiki/Test-driven_development


design and testing is typically a sensible and important part of the
process, however:
usually, design, implementation, and testing are interlaced to some extent
(it is unlikely that any staged model apart from BDUF could be successfully
applied on a larger scale).

there is no good way to formally enforce these (in the toolchain), given the
widly varied nature of design, possible tests, and implementation
strategies. there are only a minority of cases where fully automated tests
can be used and produce sensible results (for many sorts of testing, some
level of human involvement is needed, such as reviewing input/output for
"sensibility", as in many non-trivial cases the behavior may be beyond what
can be both completely and accurately handled by an automated test, or
require multiple stages to become testable but in the process introduce
internal "hidden layers" which may themselves conceal various edge cases or
problems).

in effect, likely pulling off such a requirement in the general case would
likely require homunculi, and short of that, developers would likely just
end up short-circuiting the mechanism anyways for all the cases where it
would (inevitably) prove inconvinient or unworkable, and thus solving little
of value.


static provability is also another possible (and generally more workable)
strategy, however, this tends to focus on far more narrowly defined and
testable properties (such as verifying that all types are used correctly,
...).

however, "programmer has written a spec before starting implementation" is
outside the grounds of what can be achieved via a proof (nor is even
necessarily proven to always be the most desirable course of action).


or such...
Julian Leviston
2010-10-14 04:13:40 UTC
Permalink
Post by Julian Leviston
<--
Does anyone know about a language (possibly something in smalltalk) that involves spec-driven development?
A language that stipulates a spec (in code - ie a test) must be written before any code can be written, and that can also do self-checks (sort of like a checksum) before the code is executed?
Julian.
-->
what would be the merit of imposing such a restriction?
how would one enforce such a restriction?
how could this be done without compromising the ability to use the language to get much useful done?
...
IMO, any such restrictions are better left under the control of "the development process" rather than trying to enforce them at the language level.
The merit of imposing that users write specs first assumes that programmers have a plan before they start writing code, and then encourages them to become aware of their plan and requirements, explicitly laying them out in a series of test of behaviour. (See http://behaviour-driven.org/ possibly for a good explanation of where I'm coming from here).

I'm not advocating enforcement, rather encouragement. As most of us know, you cannot happily enforce things on people, let alone programmers - for example Java's nightmarish type system hinders more than helps (in my humble personal opinion, only). One *can* encourage certain things through the FORM of the language/IDE/workspace/etc., though (for example, smalltalk's class browser encourages a programmer to think in terms of classes)... unfortunately composition might be a better practice most of the time and it *may* be that having a class browser as a default tool encouraged the "over-use" of inheritance that we have seen as quite a dominant practice/idea in the OOP world.

What I *am* advocating, though, is a checksum that is written by testing suites at various levels that would mean that code wouldn't run unless it had at least the most basic testing suite run against it. I'm advocating that behaviour-tests should be a mandatory part of development (any development process - be it writing a song, programming a program or building a house). The best of us as developers in any realm do these kinds of requirement-conformance "tests" when building whatever it is we're building ANYWAY, so I see it as simply a formalisation of a hitherto unexpressed best-practice.

Code should simply be able to test itself, to perform minimal self-diagnostics in the same way that advanced photocopiers or computers can do this. If we bake this in at a micro-granular level, then the reliability and stability of systems will skyrocket. Not only this, but code essentially self-documents then. If we are as programmers, encouraged to document before *and* after we write code, we will end up with a neat description of what we were trying to do and not just the output.

As a community, I'm trying to get us to shift from being the kid in maths class who says "12" when the teacher says "What is 3 times 4"? The working out is at least as important as the answer... as we all know in later mathematics, more weight is attributed to the process than to the outcome... if there are 12 steps in a process to build an answer, and only the 12th is incorrect, then that is 11 out of 12 as a score, as averse to if there is only an incorrect answer and no working out, that is 0 out of 12 as a score... or 12 out of 12 if it is correct.

Do you see my point here?

Of course, just as it's possible to write structured code inside Smalltalk, or any Object-Oriented language, it would be possible to "get around" this encouragement of behavioural-driven-testing built into a language. But that's beside the point. I'm not trying to get to a state where things are IMPOSSIBLE to break. I'm trying to get to a state where they're encouraged to work.

If I didn't want to write tests, I could simply write tests that evaluated in true. Hands dusted and done. Mind you, the stakeholders (maybe me) would probably get frustrated as the project gets larger and more regression errors creep in with each suite of changes imposed on the system.

Respect,
Julian.
BGB
2010-10-14 06:22:12 UTC
Permalink
----- Original Message -----
From: "Julian Leviston" <***@leviston.net>
To: "Fundamentals of New Computing" <***@vpri.org>
Sent: Wednesday, October 13, 2010 9:13 PM
Subject: Re: [fonc] Spec-Driven & Self-Testing Code
Post by Julian Leviston
<--
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?
A language that stipulates a spec (in code - ie a test) must be written
before any code can be written, and that can also do self-checks (sort of
like a checksum) before the code is executed?
Julian.
-->
what would be the merit of imposing such a restriction?
how would one enforce such a restriction?
how could this be done without compromising the ability to use the
language to get much useful done?
...
IMO, any such restrictions are better left under the control of "the
development process" rather than trying to enforce them at the language
level.
<--
The merit of imposing that users write specs first assumes that programmers
have a plan before they start writing code, and then encourages them to
become aware of their plan and requirements, explicitly laying them out in a
series of test of behaviour. (See http://behaviour-driven.org/ possibly for
a good explanation of where I'm coming from here).
-->

quick skim of some of it...

ok, there seems to be a conflict here...

writing specs/plans, and testing quick/early, are very different approaches
to software design.


in a typical spec or plan-based process, a person will try to work out
everything in advance, and delay coding until after the spec is relatively
complete. this is what is usually termed "waterfall method" or "BDUF".

waterfall: first spec; then code; then test and debug; then deploy.


in a test-driven setup, usually the tests and code are written early and
written alongside each other, and planning is usually very minimal (usually
just writing out maybe basic ideas for what the thing should do).

in this later form, usually specs are written *after* the code, usually
either to document the code, or to help identify which directions they want
to go, ...

this would seem to be more the style advocated by the posted link.


it seems like there is jumping between advocating several different
methodologies.

admittedly, I tend to combine both strategies, usually writing specs for
individual components or features, but using an incremental process and
regular testing for large scale features.


<--
I'm not advocating enforcement, rather encouragement. As most of us know,
you cannot happily enforce things on people, let alone programmers - for
example Java's nightmarish type system hinders more than helps (in my humble
personal opinion, only). One *can* encourage certain things through the FORM
of the language/IDE/workspace/etc., though (for example, smalltalk's class
browser encourages a programmer to think in terms of classes)...
unfortunately composition might be a better practice most of the time and it
*may* be that having a class browser as a default tool encouraged the
"over-use" of inheritance that we have seen as quite a dominant
practice/idea in the OOP world.
-->

enforcement also usually only works when there is something well defined to
enforce, or something can be enforced in terms of taking away some specific
feature.


<--
What I *am* advocating, though, is a checksum that is written by testing
suites at various levels that would mean that code wouldn't run unless it
had at least the most basic testing suite run against it. I'm advocating
that behaviour-tests should be a mandatory part of development (any
development process - be it writing a song, programming a program or
building a house). The best of us as developers in any realm do these kinds
of requirement-conformance "tests" when building whatever it is we're
building ANYWAY, so I see it as simply a formalisation of a hitherto
unexpressed best-practice.
-->

IMO, "checksum" is also a bad choice of a terms to use in reference to unit
tests or similar.
typically, what a checksum does and what a unit test do are very different,
and it would create unneeded confusion to use one term to describe the
other.

the problem is (with the proposed idea), until both code and tests can be
written, one is almost inevitably going to write a test which always passes,
so that they can run the code, effectively so that they can in turn test and
debug the code.

traditionally, code will be run regardless of whether it is known to work,
and the main point of unit testing then is to start throwing up red-flags
that something may need to be looked at or fixed, or to track new
functionality which "should" work, but doesn't as of yet (if wanting to add
a new feature may make the test fail, which may break the build, then people
are going to delay adding the test until after the feature is generally
known to work, partly defeating some of the purpose of unit testing).


<--
Code should simply be able to test itself, to perform minimal
self-diagnostics in the same way that advanced photocopiers or computers can
do this. If we bake this in at a micro-granular level, then the reliability
and stability of systems will skyrocket. Not only this, but code essentially
self-documents then. If we are as programmers, encouraged to document before
*and* after we write code, we will end up with a neat description of what we
were trying to do and not just the output.
-->

usually I just write tests as little special-purpose frontends which test
that a piece of code works as expected.
I have tried using these for my C compiler as well, but sadly I am then left
to realize that my compiler is partly broken (some tests fail for "reasons
not yet identified", seriously, in some cases I comb through the ASM output
and still can't find the cause of the error), and I have neither the time
nor the energy to really beat all the bugs out of it (my main codegen was
written with, sadly, very little testing, and is very internally complex, so
sadly it is left on faith that a lot of this stuff actually works...).


sadly, some pieces of code, particular compilers, are somewhat difficult to
test on a fine-grain basis, and so have to be tested on a more coarse scale:
if fragments of code compile and behave as expected. this leaves a lot of
need for manual intervention in testing and debugging, such as reviewing the
output of various internal processes, trying to track down specific errors
(in possibly a large mess of other data), making debugging a relatively
labor-intensive process.

this is, sadly, an ongoing battle in my cases.



<--
As a community, I'm trying to get us to shift from being the kid in maths
class who says "12" when the teacher says "What is 3 times 4"? The working
out is at least as important as the answer... as we all know in later
mathematics, more weight is attributed to the process than to the outcome...
if there are 12 steps in a process to build an answer, and only the 12th is
incorrect, then that is 11 out of 12 as a score, as averse to if there is
only an incorrect answer and no working out, that is 0 out of 12 as a
score... or 12 out of 12 if it is correct.

Do you see my point here?
-->

hmm... not all of use are good with maths...


<--
Of course, just as it's possible to write structured code inside Smalltalk,
or any Object-Oriented language, it would be possible to "get around" this
encouragement of behavioural-driven-testing built into a language. But
that's beside the point. I'm not trying to get to a state where things are
IMPOSSIBLE to break. I'm trying to get to a state where they're encouraged
to work.

If I didn't want to write tests, I could simply write tests that evaluated
in true. Hands dusted and done. Mind you, the stakeholders (maybe me) would
probably get frustrated as the project gets larger and more regression
errors creep in with each suite of changes imposed on the system.
-->


even OO is not a requirement:
even though OO is popular, not everything needs to be OO or in an OO
language, and OO or not-OO is really a side issue to the matter of unit
tests...



sadly, if the tests prevented the project from building or running if they
failed, this would essentially leave the tests always (or almost always)
evaluating to true as the only really reasonable outcome in most cases...

granted, testing could have separate "warning" and "error" conditions, where
a warning condition is a test which fails, but the code can still be run
(only something minor has broken, or correct behavior remains as a future
goal), and an error condition is where "something has just gone horribly
wrong here", with the assumption that the test itself can be used to help
debug the problem.


often, it is still needed to run even known broken code in order to help
better isolate the problem.
now, preventing doing an official release with broken code is an altogether
different issue...


or such...
Julian Leviston
2010-10-14 06:43:29 UTC
Permalink
sadly, if the tests prevented the project from building or running if they failed, this would essentially leave the tests always (or almost always) evaluating to true as the only really reasonable outcome in most cases...
granted, testing could have separate "warning" and "error" conditions, where a warning condition is a test which fails, but the code can still be run (only something minor has broken, or correct behavior remains as a future goal), and an error condition is where "something has just gone horribly wrong here", with the assumption that the test itself can be used to help debug the problem.
often, it is still needed to run even known broken code in order to help better isolate the problem.
now, preventing doing an official release with broken code is an altogether different issue...
Unfortunately I've failed at communicating what I'm trying to say to you. I'm sorry.

Basically, I want something like Cucumber baked in at the lowest level possible. (cukes.info/)

In order to do this, I am suggesting that languages gain a checksum. This means that at a compiler-level, the code won't compile until your acceptance-tests pass. It verifies this because the testing suite builds out a checksum value and stamps it on the code to say it's okay and has worked. This checksum can be verified because it is computed at various levels of source-code (ie the method, the class, the entire source tree) and this checksum should be unique for every version of your code that exists because of the fact that the version will be different than other versions.

The assumption here is that behaviour-verification is a very good thing.

As we ALL DO IT ALL THE TIME for EVERYTHING, I'd say you cannot argue that it's not a good thing. The further assumption is that the describing and codification of this in (executable) human-natural-language (ie English most of the time, but not necessarily always English) is a good thing.

I personally think it is, or at least it should be a switchable module in every compiler / interpreter.

I'm interested if others think so, too?

Julian.
K. K. Subramaniam
2010-10-11 02:11:44 UTC
Permalink
Post by Julian Leviston
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?
Spec-driven development of what? There have been many attempts at encoding
specifications (purely descriptive code without imperatvie components) but they
are all highly domain-specific. See "Specification Language" in Wikipedia for
starters.

Smalltalk uses a prototyping approach - build as you go. It does support
"assert" statements to capture invariants. e.g.

self assert: myclass instVarNames isEmpty.

and a Test framework (See SUnit-* Packages in Squeak) for validations..

Subbu
Julian Leviston
2010-10-11 02:26:02 UTC
Permalink
Spec-driven development of code. Sorry for not specifying. (Irony? ;-))

Yes, that'd be an example of the tests / specs I'm talking about. I'm also suggesting that the programmer needs to be encouraged and made aware of their assumptions and requirements for doing something - hence baking them into the language / IDE (workspace / class browser) itself. This is essential in the documentation process, for inspection of code.

For example, if my entire operating system had been written in this theoretical spec-driven environment, I could look at it bit by bit and essentially teach myself what was encoded into the specs and learn how the operating system works at any level I'm interested in. I'm not stipulating this for restriction, only encouragement. "Checksumming" would allow the code to be quickly checked for correctness before running each time, or put a different way - code could not be compiled until the specs / tests had run through passing.

I think this is better off baked in because it would encourage programmers (users of the language) to write down what they intend to do before they do it. Something most people do whenever they're going to do something complicated anyway. It would encourage people to take care and to not code things quickly, but it would also provide regression tests.

This level of spec-driven / self-testing could not be performed as a principle and a general process as easily as if the environment / language was aware of it.

Regards,
Julian
Post by K. K. Subramaniam
Post by Julian Leviston
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?
Spec-driven development of what? There have been many attempts at encoding
specifications (purely descriptive code without imperatvie components) but they
are all highly domain-specific. See "Specification Language" in Wikipedia for
starters.
Smalltalk uses a prototyping approach - build as you go. It does support
"assert" statements to capture invariants. e.g.
self assert: myclass instVarNames isEmpty.
and a Test framework (See SUnit-* Packages in Squeak) for validations..
Subbu
Julian Leviston
2010-10-14 06:00:44 UTC
Permalink
Post by Julian Leviston
I think this is better off baked in because it would encourage programmers
(users of the language) to write down what they intend to do before they
do it. Something most people do whenever they're going to do something
complicated anyway. It would encourage people to take care and to not code
things quickly, but it would also provide regression tests.
This is why asserts were introduced. What you call a spec is nothing but the
self assert: self inv and: self p.
self dosomething.
self assert: self inv and: self q.
Where inv is the state invariant and p and q are pre- and post- conditions on
the parts of the state undergoing modifications. Researchers are interested in
inv, p and q while most practitioners depend on doSomething. assert strikes a
balance between the two.
Subbu
I'm well aware of testing frameworks. I think you may have missed what I was trying to say.

Sorry about that!

Executable documentation coupled with behavioural testing baked in is what I'm after. ie the code won't actually execute without a checksum existing first that indicates that the test suite has been run across this code.

Julian.
K. K. Subramaniam
2010-10-14 06:56:35 UTC
Permalink
Post by Julian Leviston
Executable documentation coupled with behavioural testing baked in is what
I'm after. ie the code won't actually execute without a checksum existing
first that indicates that the test suite has been run across this code.
Your requirement is recursive. You seek a verifier machine to gate execution
of code in a lower level machine. The distinction you make between 'testing'
and 'execution' involves intention - something which cannot be coded in
general. Writing executable spec is just another form of coding. How would you
test if the written spec captured the intention of the tester?

A computing machine that executes documentation is just another machine;
possibly virtual but still a machine and subject to the same frailties. Alan
Kay called an object a "recursion on the entire possibilities of the computer"
- warts and all :-).

Subbu
Julian Leviston
2010-10-14 07:07:34 UTC
Permalink
Post by K. K. Subramaniam
Post by Julian Leviston
Executable documentation coupled with behavioural testing baked in is what
I'm after. ie the code won't actually execute without a checksum existing
first that indicates that the test suite has been run across this code.
Your requirement is recursive. You seek a verifier machine to gate execution
of code in a lower level machine. The distinction you make between 'testing'
and 'execution' involves intention - something which cannot be coded in
general. Writing executable spec is just another form of coding. How would you
test if the written spec captured the intention of the tester?
A computing machine that executes documentation is just another machine;
possibly virtual but still a machine and subject to the same frailties. Alan
Kay called an object a "recursion on the entire possibilities of the computer"
- warts and all :-).
Subbu
Ah, you jest! :)

Yes, it is recursive, and like all good recursion, it has an "out". That "out" is that tests are a special case. The simple case is just that "if it breaks in any way, it's broken, otherwise it's good"). This is always the case for testing frameworks.

Humans have to check their own tests, and they have to not break. <sigh>. :P

Julian.
Anthony Durity
2010-10-18 06:43:06 UTC
Permalink
Well Ruby has RSpec:

http://en.wikipedia.org/wiki/RSpec
http://en.wikipedia.org/wiki/Behavior_driven_development
http://rspec.info/

It's not part of the Ruby language but it does have its own domain specific
language, something Ruby excels at.
Is this what you mean?

Regards,
Anthony

(de-lurking)
Post by Julian Leviston
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?
A language that stipulates a spec (in code - ie a test) must be written
before any code can be written, and that can also do self-checks (sort of
like a checksum) before the code is executed?
Julian.
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Steve Dekorte
2010-10-14 22:14:52 UTC
Permalink
I have to wonder how things might be different if someone had made a tiny, free, scriptable Smalltalk for unix before Perl appeared...

BTW, there were rumors that Sun considered using Smalltalk in browsers instead of Java but the license fees from the vendors were too high. Anyone know if that's true?
Post by John Zabroski
Why are we stuck with such poor architecture?
John Zabroski
2010-10-14 22:51:44 UTC
Permalink
I saw Paul Fernhout mention this once on /.
http://developers.slashdot.org/comments.pl?sid=1578224&cid=31429692

He linked to: http://fargoagile.com/joomla/content/view/15/26/

which references:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-December/112337.html

which states:

When I became V.P. of Development at ParcPlace-Digitalk in 1996, Bill
Lyons (then CEO) told me the same story about Sun and VW. According
to Bill, at some point in the early '90's when Adele was still CEO,
Sun approached ParcPlace for a license to use VW (probably
ObjectWorks at the time) in some set top box project they were
working on. Sun wanted to use a commercially viable OO language with
a proven track record. At the time ParcPlace was licensing Smalltalk
for >$100 a copy. Given the volume that Sun was quoting, PP gave Sun
a firm quote on the order of $100/copy. Sun was willing to pay at
most $9-10/copy for the Smalltalk licenses. Sun was not willing to go
higher and PP was unwilling to go lower, so nothing ever happened and
Sun went its own way with its own internally developed language
(Oak...Java). The initial development of Oak might well have predated
the discussions between Sun and PP, but it was PP's unwillingness to
go lower on the price of Smalltalk that gave Oak its green light
within Sun (according to Bill anyway). Bill went on to lament that
had PP played its cards right, Smalltalk would have been the language
used by Sun and the language that would have ruled the Internet.
Obviously, you can take that with a grain of salt. I don't know if
Bill's story to me was true (he certainly seemed to think it was),
but it might be confirmable by Adele. If it is true, it is merely
another sad story of what might have been and how close Smalltalk
might have come to universal acceptance.
-Eric Clayberg
That being said, I have no idea why people think Smalltalk-80 would have
been uniformly better than Java. I am not saying this to be negative. In
my view, much of the biggest mistakes with Java were requiring insane legacy
compatibility, and doing it in really bad ways. Swing should have never
have been forced to reuse AWT, for example. And AWT should never have had a
concrete component model, thus "forcing" Swing to inherit it (dropping the
rabbit ears, because I see no good explanation for why it had to inherit
AWT's component model via "implementation inheritance"). It's hard for me
to even guage if the Swing developers were good programmers or not, given
that ridiculously stupid constraint. It's not like Swing even supported
phones, it was never in J2ME. The best I can conclude is that they were not
domain experts, but who really was at the time?
I have to wonder how things might be different if someone had made a tiny,
free, scriptable Smalltalk for unix before Perl appeared...
BTW, there were rumors that Sun considered using Smalltalk in browsers
instead of Java but the license fees from the vendors were too high. Anyone
know if that's true?
Post by John Zabroski
Why are we stuck with such poor architecture?
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Duncan Mak
2010-10-14 23:53:40 UTC
Permalink
Post by John Zabroski
That being said, I have no idea why people think Smalltalk-80 would have
been uniformly better than Java. I am not saying this to be negative. In
my view, much of the biggest mistakes with Java were requiring insane legacy
compatibility, and doing it in really bad ways. Swing should have never
have been forced to reuse AWT, for example. And AWT should never have had a
concrete component model, thus "forcing" Swing to inherit it (dropping the
rabbit ears, because I see no good explanation for why it had to inherit
AWT's component model via "implementation inheritance"). It's hard for me
to even guage if the Swing developers were good programmers or not, given
that ridiculously stupid constraint. It's not like Swing even supported
phones, it was never in J2ME. The best I can conclude is that they were not
domain experts, but who really was at the time?
I started programming Swing a year ago and spent a little time learning its
history when I first started. I was able to gather a few anecdotes, and they
have fascinated me.

There were two working next-generation Java GUI toolkits at the time of
Swing's conception - Netscape's IFC and Lighthouse Design's LFC - both
toolkits were developed by ex-NeXT developers and borrowed heavily from
AppKit's design. IFC even had a design tool that mimicd Interface Builder
(which still lives on today in Cocoa).

Sun first acquired Lighthouse Design, then decided to join forces with
Netscape - with two proven(?) toolkits, the politics worked out such that
all the AWT people at Sun ended up leading the newly-joined team, and the
working code from the other parties discarded, and from this, Swing was
born.

http://talblog.info/archives/2007/01/sundown.html
http://www.noodlesoft.com/blog/2007/01/23/the-sun-also-sets/
--
Duncan.
John Zabroski
2010-10-15 02:01:06 UTC
Permalink
Wow! Thanks for that amazing nugget of Internet history.

Fun fact: Tony Duarte wrote the book Writing NeXT Programs under the
pseudonym Ann Weintz because supposedly Steve Jobs was so secretive that he
told employees not to write books about the ideas in NeXT's GUI. See:
http://www.amazon.com/Writing-Next-Programs-Introduction-Nextstep/dp/0963190105/where
Tony comments on it.
Post by Duncan Mak
Post by John Zabroski
That being said, I have no idea why people think Smalltalk-80 would have
been uniformly better than Java. I am not saying this to be negative. In
my view, much of the biggest mistakes with Java were requiring insane legacy
compatibility, and doing it in really bad ways. Swing should have never
have been forced to reuse AWT, for example. And AWT should never have had a
concrete component model, thus "forcing" Swing to inherit it (dropping the
rabbit ears, because I see no good explanation for why it had to inherit
AWT's component model via "implementation inheritance"). It's hard for me
to even guage if the Swing developers were good programmers or not, given
that ridiculously stupid constraint. It's not like Swing even supported
phones, it was never in J2ME. The best I can conclude is that they were not
domain experts, but who really was at the time?
I started programming Swing a year ago and spent a little time learning its
history when I first started. I was able to gather a few anecdotes, and they
have fascinated me.
There were two working next-generation Java GUI toolkits at the time of
Swing's conception - Netscape's IFC and Lighthouse Design's LFC - both
toolkits were developed by ex-NeXT developers and borrowed heavily from
AppKit's design. IFC even had a design tool that mimicd Interface Builder
(which still lives on today in Cocoa).
Sun first acquired Lighthouse Design, then decided to join forces with
Netscape - with two proven(?) toolkits, the politics worked out such that
all the AWT people at Sun ended up leading the newly-joined team, and the
working code from the other parties discarded, and from this, Swing was
born.
http://talblog.info/archives/2007/01/sundown.html
http://www.noodlesoft.com/blog/2007/01/23/the-sun-also-sets/
--
Duncan.
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
John Zabroski
2010-10-15 02:18:46 UTC
Permalink
By the way, at the JavaOne where Swing was announced, Sun told everyone that
backward compatibility with AWT was a must for customers. I thought I
stated that directly earlier, but apparently left it out. If you can find
the old Swing presentations from the second JavaOne, then you'll see what I
mean. The slides explicitly stated the need for backwards compatibility
with AWT, for customers. This was considered weird to many, since nobody
seemed to actually be using AWT or liked it.

AWT was also built in one month, so that Sun could demo applets on the
Internet. The perception within Sun from management at the time was that
they only had a short period of time to enter the Internet market ahead of
other competitors, and that some code was better than good code 6 months, or
a year or two later.

One of the saddest Java books ever (among many sad ones), by the way, was
Java Platform Performance [1]. It basically talks about the author's
experience tuning Swing applications. They basically said that NOBODY on
the Swing team ever performance tested code by profiling. They just kept
writing code! Then the authors job was to clean up the performance disaster
of Swing. -- Swing was notoriously slow for many years, and it wasn't until
1.6 that they finally added support for antialiased text rendering!

Interestingly, Palantir Technologies uses Java and Swing for its
"distributed intelligence" visualizations, according to a convo I had on
Facebook w/ Ari Gesher.

[1]
http://www.amazon.co.uk/Java-Platform-Performance-Strategies-Tactics/dp/0201709694/
Post by Duncan Mak
Post by John Zabroski
That being said, I have no idea why people think Smalltalk-80 would have
been uniformly better than Java. I am not saying this to be negative. In
my view, much of the biggest mistakes with Java were requiring insane legacy
compatibility, and doing it in really bad ways. Swing should have never
have been forced to reuse AWT, for example. And AWT should never have had a
concrete component model, thus "forcing" Swing to inherit it (dropping the
rabbit ears, because I see no good explanation for why it had to inherit
AWT's component model via "implementation inheritance"). It's hard for me
to even guage if the Swing developers were good programmers or not, given
that ridiculously stupid constraint. It's not like Swing even supported
phones, it was never in J2ME. The best I can conclude is that they were not
domain experts, but who really was at the time?
I started programming Swing a year ago and spent a little time learning its
history when I first started. I was able to gather a few anecdotes, and they
have fascinated me.
There were two working next-generation Java GUI toolkits at the time of
Swing's conception - Netscape's IFC and Lighthouse Design's LFC - both
toolkits were developed by ex-NeXT developers and borrowed heavily from
AppKit's design. IFC even had a design tool that mimicd Interface Builder
(which still lives on today in Cocoa).
Sun first acquired Lighthouse Design, then decided to join forces with
Netscape - with two proven(?) toolkits, the politics worked out such that
all the AWT people at Sun ended up leading the newly-joined team, and the
working code from the other parties discarded, and from this, Swing was
born.
http://talblog.info/archives/2007/01/sundown.html
http://www.noodlesoft.com/blog/2007/01/23/the-sun-also-sets/
--
Duncan.
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Paul D. Fernhout
2010-10-16 17:49:16 UTC
Permalink
Post by John Zabroski
AWT was also built in one month, so that Sun could demo applets on the
Internet. The perception within Sun from management at the time was that
they only had a short period of time to enter the Internet market ahead of
other competitors, and that some code was better than good code 6 months, or
a year or two later.
Just goes to show the biggest "bug" in computer software probably is in the
current scarcity-paradigm socio-economic system that drives how so many
programs, libraries, and standards are written, maintained, and transformed: :-)

http://knol.google.com/k/paul-d-fernhout/beyond-a-jobless-recovery#Four_long%282D%29term_heterodox_alternatives

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Pascal J. Bourguignon
2010-10-14 23:46:37 UTC
Permalink
Post by Steve Dekorte
I have to wonder how things might be different if someone had made a
tiny, free, scriptable Smalltalk for unix before Perl appeared...
There has been GNU smalltalk for a long time, AFAIR before perl, which
was quite adapted to the unix environment.

It would certainly qualify as tiny since it lacked any big GUI
framework, obviously it is free in all meanings of the words, and it
is best in writing scripts.


My point is that it hasn't changed anything and nothing else would have.
Post by Steve Dekorte
BTW, there were rumors that Sun considered using Smalltalk in
browsers instead of Java but the license fees from the vendors were
too high. Anyone know if that's true?
No idea, but since they invented Java, they could have at a much lower
cost written their own implementation of Smalltalk.
--
__Pascal Bourguignon__
http://www.informatimago.com
Jecel Assumpcao Jr.
2010-10-15 00:05:34 UTC
Permalink
Post by Pascal J. Bourguignon
No idea, but since they invented Java, they could have at a much lower
cost written their own implementation of Smalltalk.
or two (Self and Strongtalk).

Of course, Self had to be killed in favor of Java since Java ran in just
a few kilobytes while Self needed a 24MB workstation and most of Sun's
clients still had only 8MB (PC users were even worse, at 4MB and under).

-- Jecel
Paul D. Fernhout
2010-10-08 21:04:45 UTC
Permalink
Post by Waldemar Kornewald
On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout
Post by Paul D. Fernhout
The PataPata project (by me) attempted to bring some ideas for Squeak and
Self to Python about five years ago. A post mortem critique on it from four
"PataPata critique: the good, the bad, the ugly"
http://patapata.sourceforge.net/critique.html
In that critique you basically say that prototypes *maybe* aren't
better than classes, after all. On the other hand, it seems like most
problems with prototypes weren't related to prototypes per se, but the
(ugly?) implementation in Jython which isn't a real prototype-based
language. So, did you have a fundamental problem with prototypes or
was it more about your particular implementation?
Waldemar-

Thanks for the comments.

A main practical concern was the issue of managing complexity and
documenting intent in a prototype system, especially in a rough-edges
environment that mixed a couple layers (leading to confusing error messages).

Still, to some extent, saying "complexity is a problem" is kind of like
blaming disease on "bad vapors". We need to be specific about things to do,
like suggesting that you usually have to name things before you can share
them and talking about naming systems or ways of reconciling naming
conflicts, which is the equivalent of understanding that there is some
relation between many diseases and bacteria, even if that does not tell you
exactly what you should be doing about bacteria (given that people could not
survive without them).

I think, despite what I said, the success of JavaScript does show that
prototypes can do the job -- even though, as Alan Kay said, what is most
important about the magic of Smalltalk is message passing not objects (or
classes, or for that matter prototypes). I think how prototype languages
work in practice, without message passing, and with a confusion of
communicating with them through either slots of functions, is problematical;
so I'd still rather be working in Smalltalk, which ultimately I think has a
paradigm that can scale better, than either imperative or functional languages.

But, the big picture issue I wanted to raise isn't about prototypes. It as
about more general issues -- like how do we have general tools that let us
look at all sorts of computing abstractions?

In biology, while it's true there are now several different types of
microscopes (optical, electron, STM, etc.) in general, we don't have a
special microscope developed for every different type of organism we want to
look at, which is the case now with, say, debuggers and debugging processes.

So, what would the general tools look like to let us debug anything? And I'd
suggest, that would not be "gdb" as useful as that might be.

I can usefully point the same microscope at a feather, a rock, a leaf, and
pond water. So' why can't I point the same debugger at Smalltalk image, a
web page with JavaScript served by a Python CGI script, a VirtualBox
emulated Debian installation, and a semantic web trying to understand a
"jobless recovery"?

I know that may sound ludicrous, but that's my point. :-)

But when you think about it, there might be a lot of similarities at some
level in thinking about those four things in terms of displaying
information, moving between conceptual levels, maintaining to do lists,
doing experiments, recording results, communicating progress, looking at
dependencies, reasoning about complex topics, and so on. But right now, I
can't point one debugger at all those things, and even suggesting that we
could sounds absurd. Of course, most things that sound absurd really are
absurd, but still: "If at first, the idea is not absurd, then there is no
hope for it (Albert Einstein)"

In March, John Zabroski wrote: "I am going to take a break from the previous
thread of discussion. Instead, it seems like most people need a tutorial in
how to think BIG."

And that's what I'm trying to do here. There are billions of computers out
there running JavaScript, HTML, and CSS (and some other stuff, powered by
CGI stuff). How can we think big about that overall global message passing
system? Billions of computers connected closely to humans supported with
millions of customized tiny applications (each a web page) interacting as a
global dynamic semantic space are just going to be more interesting than a
few thousand computers running some fancy new kernel with some fancy new
programming language. But, should not "new computing" take in account this
reality somehow?

I've also got eight cores on my desktop, most of them idle most of the time,
and I have electric heat so most of the year it does not cost me anything to
run them. So, raw performance is not so important as it used to be. What is
important are the conceptual abstractions as well as the practical
connection with what people are willing to easily try.

Now, people made the same argument to me thirteen years ago about Java (like
Jim Spohrer), and I would not believe it. :-) I think I was right then to be
skeptical and to say VisualWorks etc. was better, even as I probably would
have been better off jumping on that bandwagon back then and helping it grow
better. I'm sort of saying, don't make the same mistake I made, but this
time about JavaScript and the dynamic semantic web.

(Of course, I also have my own twist on that -- thinking in terms of
exchanging transactions of triples, but one could just get really far with
mainstream technologies.)

For example, I think it is terrific that OMeta has a JavaScript version:
http://tinlizzie.org/ometa/
And also useable from the web:
http://www.tinlizzie.org/ometa-js/
That is a great way to make the ideas accessible to lots of people.

Again though, these issue are deeper than just JavaScript. JavaScript is
maybe an example of my point I posted to the edusig list -- that what is of
great interest now is interoperations with existing ecosystems of systems
and layers already out there, even if the system closest to you and
displaying your GUI is dynamic and very self-hosting.
Post by Waldemar Kornewald
Post by Paul D. Fernhout
I am wondering if there is some value in reviving the idea for JavaScript?
Firebug shows what is possible as a sort of computing microscope for
JavaScript and HTML and CSS. Sencha Ext Designer shows what is possible as
far as interactive GUI design.
What exactly does JavaScript give you that you don't get with Python?
If you want to have prototypes then JavaScript is probably the worst
language you can pick. You can't specify multiple delegates and you
can't change the delegates at runtime (unless your browser supports
__proto__, but even then you can only have one delegate). Also, as a
language JavaScript is just not as powerful as Python. If all you want
is a prototypes implementation that doesn't require modifications to
the interpreter then you can get that with Python, too (*without*
JavaScript's delegation limitations).
Well, both Python and JavaScript don't focus on message passing, so we could
do better than either IHMO (and have, with, say, Smalltalk decades ago). And
as I wrote four years ago about PataPata, adding a layer of machinery to do
more things to an existing language that is from a very different paradigm
is problematical. You probably end up having to build a whole new system if
you want great error message. And user communities tend to be self-selecting
both for some ideas they do like and some ideas they don't like. People
aren't generally drawn to Python in the past for doing experimental stuff
with languages the way Lisp hackers might be. And Smalltalkers can do stuff
with the language (defining new conditionals) without even thinking much
about it, just to show the power of that set of ideas. :-)

Still, culturally, JavaScript seems to be winning a certain battle for
ubiquity and mindshare (maybe unfairly, but that's the way it is right now).
And it is poised to do even more as the web momentum just grows and grows.
Even the fact that JavaScript has hardly any standard libraries is working
to its advantage in some places:
"Javascript meet Gnome, Gnome meet Javascript"
http://www.grillbar.org/wordpress/?p=307
Whereas anyone who uses Python expects the Python standard libraries that
likely as not conflict with whatever Python is embedded in.

Still, ideally, one wants tools that can work at a higher layer of
abstraction. JavaScript is being now used as the universal ubiquitous
virtual machine. It is a really stupid Virtual Machine design (compared to,
say, VisualWorks's VM, Strongtalk's, Forth's, or even now Java's JVM), but
JavaScript as a VM is free and everywhere. Go to the Google home page today
an you can see an animation about what would be John Lennon's 70th birthday,
and it is in JavaScript:
http://www.google.com/
"John Lennon Google Doodle "


It's totally stupid to use JavaScript as a VM for "world peace" since it
would be a lot better if every web page ran in its own well-designed VM and
you could create content that just compiled to the VM, and the VMs had some
sensible and secure way to talk to each other and respect each other's
security zones in an intrinsically and mutually secure way. :-)
"Stating the 'bleeding' obvious (security is cultural)"
http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00

But, short of the major browser developers and all the other web developers
out there agreeing to use a common VM, people end up using things like the
Google Web Toolkit to generate JavaScript which is a bit like Smalltalk
compiling methods to VM bytecodes (but much less efficient). And then they
build junky privacy disrespecting stuff on top of that, too. :-) And
Microsoft and Adobe are going to sabotage that (and essentially have in the
past), because economic competition is often really harmful in regards to
standards as people try to make money by locking people into their own
proprietary stuff. See my section here on competition:
http://knol.google.com/k/paul-d-fernhout/beyond-a-jobless-recovery

So, essentially I agree with your point, and even John Zabroski's point in
reply about "Why are we stuck with such poor architecture?". Yes, JavaScript
in a web browser is terrible. The problem is, everything else is worse in
many real world situations.

As someone who's first real computer was a KIM-1 with 1K of memory, I find
the entire notion of using JavaScript as a VM, on top of endless layers of
other crud, very unasthetic and wasteful. But at what point do I stop
fighting a stupid reality and work with it and transform it into at least
the best that it could be? :-) That's what Dan Ingalls did with the Lively
Kernel (even if my points here are a little different). And also I could
hope that, maybe, someday, we could throw away all the intermediate layers
at some point if they are not doing much of interest anymore so we could do
more with less (especially when we reach the point as a society that people
aren't finding there is an economic incentive to be middlemen and making it
hard to get everyone to agree so that things stay stuck in inefficient
paradigms). And it's great to have ideas like in OMeta that might support
that eventual collapse in a good way, by just shift the output target to a
different VM (although even then there are semantic issues).

Consider that even FONC-related compiler stuff written on JavaScript (or
compiled to JavaScript) will have an immediate audience, where a web browser
just manages downloading all dependencies for someone, whereas (practically)
no one is going to install a compiler and dependencis, run a desktop
application, track new versions of something, all the time running security
risks about trojan code, etc.. Now, by "practically no one", sure there may
be thousands of people (including many on this mailing list) who are
interested in that, but overall, the social momentum is the web, and now the
emerging semantic web, and JavaScript. Again, I'm not saying it is fair. I
fought against Java for years because I knew ObjectWorks was just so much
better -- but ten years later, the JVM is mostly as good as ObjectWorks was
around 1996 when I had to spend $9K or so on VisualWorks+Envy+EnvyServer,
but now the JVM is free (as in freedom) and so is (not so good as ENVY in
some ways) DVCS.

That's the beauty of OMeta in that sense or anything else that takes that
approach to have an accessible web application that can run in the browser,
and even further, stuff that may be retargetable (although you still need to
deal with a potential mismatch abstractions).

Still, one can ask -- how can that all be taken even further? OMeta working
as an Ajax application using Dojo or Google Closure or whatever for the GUI?
I'm glad to see a JavaScript together with Cola has been worked on. So, I'm
not saying things are going wrong here. I think all that stuff is great, and
very impressive, and wonderful progless. I'm learning from the examples
(like Lively Kernel). I can just wonder about the next level -- the issue of
what is this all for? And to me, that is the issue of a dynamic social
semantic web (as well as discussions about simulations). So, this is, if
anything, perhaps kind of like a plea to point FONC at the Semantic Web? :-)
"Semantic" is only mentioned in the 2009 NSF report in a programming
context, with not mention of the Semantic Web.
http://www.vpri.org/pdf/tr2009016_steps09.pdf
(I liked the "telescope" mention in there, btw, on page 14, in a diagram
about DBjr that is beginning to get at some of these points. :-) But I won't
claim to be up on all VPRI is doing. FONC may be going more in those
directions than I know.

Sure, we could argue about low level details, whether at the level of
Python/JavaScript or below. For example, if I were implementing a VM, I'd
like to, say, try implementing (in C) a protype-ish message passing system
reminiscent of Forth that had all objects where the first value at an
object's address was an index into a lookup table (where many objects might
share the same table as a sort of common "class"), and all messages with the
same selector name mapped to the same lookup index (even if there were a lot
of blank items that were mapped to "doesNotUnderstand" maybe with some
defaulting on that), which would make for a really fast system (so, no
method cache or whatever, just:
"jump (*theProtoype)[selector]"
Although, this would require a bunch of memory for lookup (since if there
were say, 10,000 selectors needed for the current VM instance, and one
hundred classes, that would be a million lookup slots or 4MB on a 32 bit
system). And for that matter, I'd get Intel or someone else to build
hardware acceleration for this, if I am dreaming about runtime efficiency,
as well as hardware for processing lists of virtual instructions (or do it
on a FPGA). But, that's not what we got, and even if I implement it,
probably nobody is going to use it, and Intel probably isn't going to
support it anyway because it would mean simpler processors could do more
(so, on the face of it, less upgrades, even if it might empower entire new
classes of applications). (Such a system might have the equivalent of class
hierarchies or even multiple-inheritance, but that would probably be managed
by tools more than infrastructure.)

In any case, whatever I or others can dream for greater code speed or
smaller memory footprint, we're left on a practical basis with JavaScript as
the ubiquitous VM (made barely acceptable speedwise by thirty years of
Moore's Law, giving us what ObjectWorks could do when I first got it around
1988). Still, it could be worse -- the VM could be the old version of BASIC
Dan Ingalls used to write an early Smalltalk implementation on in the 1970s.
:-) So, we should be thankful for our blessings. :-)

Again though, the implementation details, while important, distract from the
big picture of a common abstraction for looking at computer processes and
structured data (including the semantic web). I'm not fully sure what I mean
by that, but that's why it's research about the future of computing. :-)
Anyway, I'm just suggesting VPRI and anyone else interested in FONC could
look more into the Semantic Web as an application domain at which to point
all the great tools

Of course, I suggested the same to the Diaspora (Facebook-clone) people,
advice that will probably be ignored there: :-)
"Raising the bar to supporting a Social Semantic Desktop"

http://groups.google.com/group/diaspora-dev/browse_thread/thread/4cd369bdf16a346f

So, I'm just repeating the same thing here, perhaps. :-)

The key point being:
http://sourceforge.net/mailarchive/forum.php?thread_name=4CAF294B.8010101%40kurtz-fernhout.com&forum_name=patapata-discuss
"PataPata's powerful ideas go beyond Smalltalk's in part from adding
collective support. These include:
* The most important components in a computing system are *both* the
individual and the group of human users.
* Programming should be a natural extension of *both* thinking and
communicating.
* Programming should be a dynamic, evolutionary process consistent with the
model of human learning activity for *both* individuals and groups.
* A computing environment is both languages and productivity enhancing
interfaces of programmer/user *and* group "power tools" -- utilities to
express yourself in those languages and to organize and flexibly use both
procedural and factual knowledge created by yourself or others."

So, I'm also getting at the limits of a "Personal Computing" paradigm in
that point (which was expanded from something about an early Smalltalk
implementation to include social aspects). Dynabook as a concept saw the
local, but what is more clearer now is the social (including semantic
community) aspect of computing. We need both. Either by itself is
problematical as we get either isolated fancy computers or we get social
networks that run on the bottom common denominator. We need some hybrid --
something reminiscent of the blend of meshworks (social networks in this
case) and hierarchies (top-down tight personal control over a system in this
case), kind of like talked about by Manuel De Landa:
"Meshworks, Hierarchies, and Interfaces"
http://www.t0.or.at/delanda/meshwork.htm
"Indeed, one must resist the temptation to make hierarchies into villains
and meshworks into heroes, not only because, as I said, they are constantly
turning into one another, but because in real life we find only mixtures and
hybrids, and the properties of these cannot be established through theory
alone but demand concrete experimentation."

There is a bit of irony there in that personal computing about freedom is
really about tight control over a system, whereas giving into social
computing demands means taking part in a somewhat democratic but anarchistic
network. But that's one of the good kinds of irony in this world. :-)

So, maybe we need a "Semantic Smalltalk"? :-) And implemented on top of
FONC-type systems? On top of JavaScript and web browsers as a first cut? :-)

Not to say mixing Smalltalk and the semantic web is a new idea; here is
something related suggested by someone else from 2005:
http://morenews.blogspot.com/2005/12/smalltalk-meets-semantic-web.html
"Smalltalk:::OWL-Project "OWL has emerged from the AI/semantic community and
tends to be in the open-source community which appears to be a direction for
Smalltalk (e.g. Smalltalk Solutions at Linux World) Much of the work to date
has been implemented in Python and Ruby which, from a language perspective,
is very close to Smalltalk. However, those languages become less appealing
if you have ever worked in the IDE's supporting those languages. OWL can
provide the Smalltalk community with a "market" that is a good fit for the
features of the ST language and supporting IDE's.""

And Doug Englebart talked about this and more decades ago:
"Augmenting Society's Collective IQ"
http://www.dougengelbart.org/about/vision-highlights.html

One reason I do like JavaScript though is the notion of making systems that
are easy to change by the end user, and more and more people know some
JavaScript, and more and more people's time spent with computers is spent
with a web browser. So, it seems to me that if we are to pursue Doug
Engelbart's dream, having some way it can (at times) rest on top of web
browsers and JavaScript seems like a way to make something accessible and
changeable to the point where a lot of people could get involved with it.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
John Zabroski
2010-10-08 21:29:25 UTC
Permalink
On Fri, Oct 8, 2010 at 5:04 PM, Paul D. Fernhout <
Post by Paul D. Fernhout
But, the big picture issue I wanted to raise isn't about prototypes. It as
about more general issues -- like how do we have general tools that let us
look at all sorts of computing abstractions?
In biology, while it's true there are now several different types of
microscopes (optical, electron, STM, etc.) in general, we don't have a
special microscope developed for every different type of organism we want to
look at, which is the case now with, say, debuggers and debugging processes.
So, what would the general tools look like to let us debug anything? And
I'd suggest, that would not be "gdb" as useful as that might be.
Computer scientists stink at studying living systems. Most computer
scientists have absolutely zero experience studying and programming living
systems. When I worked at BNL, I would have lunch with a biologist who was
named after William Tecumseh Sherman, who wrote his Ph.D. at NYU about
making nano-organisms dance. That's the level of understanding and
practical experience I am talking about.

As for making things debuggable, distributed systems have a huge need for
compression of communication, and thus you can't expect humans to debug
compressed media. You need a way to formally prove that when you uncompress
the media, you can just jump right in and debug it. There have been
advances in compiler architecture geared towards this sort of thinking, such
as the logic of bunched implications viz a viz Separation Logic and even
more practical ideas towards this sort of thinking, such as Xavier LeRoy's
now famous compiler architecture for proving optimizing compiler
correctness. The sorts of transformations that an application compiler like
GWT makes are pretty fancy, and if you want to look at the same GWT
application without compression today and just study what went wrong with
it, you can't. What you need to do, in my humble opinion, is focus on
proving that mappings between representations is isomorphic and non-lossy,
even if one representation needs hidden embeddings (interpreted as no-ops by
a syntax-directed compiler) to map back to the other.

There are also other fancy techniques being developed in programming
language theory (PLT) right now. Phil Wadler and Jeremy Siek's Blame
Calculus is a good illustration of how to study a living system in a
creative way (but does not provide a complete picture, akin to not knowing
you need to stain a slide before putting it under the microscope), and so is
Carl Hewitt's ActorScript and Direct Logic. These are the only efforts I am
aware of that try to provide some information on why something happened at
runtime.
Post by Paul D. Fernhout
I can usefully point the same microscope at a feather, a rock, a leaf, and
pond water. So' why can't I point the same debugger at Smalltalk image, a
web page with JavaScript served by a Python CGI script, a VirtualBox
emulated Debian installation, and a semantic web trying to understand a
"jobless recovery"?
I know that may sound ludicrous, but that's my point. :-)
What the examples I gave above have in common is that there are certain
limitations on how general you can make this, just as Oliver Heaviside
suggested we discard the balsa wood ship models for engineering equations
derived from Maxwell.
Post by Paul D. Fernhout
But when you think about it, there might be a lot of similarities at some
level in thinking about those four things in terms of displaying
information, moving between conceptual levels, maintaining to do lists,
doing experiments, recording results, communicating progress, looking at
dependencies, reasoning about complex topics, and so on. But right now, I
can't point one debugger at all those things, and even suggesting that we
could sounds absurd. Of course, most things that sound absurd really are
absurd, but still: "If at first, the idea is not absurd, then there is no
hope for it (Albert Einstein)"
In March, John Zabroski wrote: "I am going to take a break from the
previous thread of discussion. Instead, it seems like most people need a
tutorial in how to think BIG."
And that's what I'm trying to do here.
Thanks for the kind words. I have shared my present thoughts with you here.
But a tutorial in my eyes is more about providing people with a site where
they can go to and just be engulfed in big, powerful ideas. The FONC wiki
is certainly not that. Most of the interesting details in the project are
buried and not presented in exciting ways, or if they are, they are still
buried and require somebody to dig it up. That is a huge bug. In short,
the FONC wiki is not even a wiki. It is a chalkboard with one chalk stick,
and it is locked away in some teacher's desk.
Paul D. Fernhout
2010-10-09 04:17:01 UTC
Permalink
On Fri, Oct 8, 2010 at 5:04 PM, Paul D. Fernhout<
Post by Paul D. Fernhout
But, the big picture issue I wanted to raise isn't about prototypes. It as
about more general issues -- like how do we have general tools that let us
look at all sorts of computing abstractions?
In biology, while it's true there are now several different types of
microscopes (optical, electron, STM, etc.) in general, we don't have a
special microscope developed for every different type of organism we want to
look at, which is the case now with, say, debuggers and debugging processes.
So, what would the general tools look like to let us debug anything? And
I'd suggest, that would not be "gdb" as useful as that might be.
Computer scientists stink at studying living systems. Most computer
scientists have absolutely zero experience studying and programming living
systems. When I worked at BNL, I would have lunch with a biologist who was
named after William Tecumseh Sherman, who wrote his Ph.D. at NYU about
making nano-organisms dance. That's the level of understanding and
practical experience I am talking about.
Was that a biologist or computer scientist?

I was in a PhD program in ecology and evolution for a time (as was my wife,
where we met) and I can indeed agree there is a big difference in how people
think about some things when they have an Ecology and Evolution background,
because those fields are taught so badly (or not at all) in US schools
(especially evolution). So, if you want to understand issues like
complexity, our best models connect to ecology and evolution, but since so
many CS types don't have that "soft and squishy" background, they just have
no good metaphors to use for that. But one might make similar arguments
about the value of the humanities and narrative in understanding complexity.
Math itself is valuable, but it is also limited in many ways.

See also:
"Studying Those Who Study Us: An Anthropologist in the World of
Artificial Intelligence" by Diane Forsythe
http://www.amazon.com/Studying-Those-Who-Study-Anthropologist/dp/0804742030
"[For a medical example] To build effective online health systems for
end-users one must combine the knowledge of a medical professional, the
skills of a programmer/developer, the perspective of a medical
anthropologist, and the wisdom of Solomon. And since Solomon is not
currently available, an insightful social scientist like Diana-who can help
us see our current healthcare practices from a 'man-from-mars'
perspective-can offer invaluable insights. ... Both builders and users of
[CHI] systems tend to think of them simply as technical tools or
problem-solving aids, assuming them to be value-free. However, observation
of the system-building process reveals that this is not the case: the
reasoning embedded in such systems reflects cultural values and disciplinary
assumptions, including assumptions about the everyday world of medicine."

So, one may ask, what "values" are built in to so many of the tools we use?
As for making things debuggable, distributed systems have a huge need for
compression of communication, and thus you can't expect humans to debug
compressed media. You need a way to formally prove that when you uncompress
the media, you can just jump right in and debug it.
Oh, I'm not interested in proving any thing in a CS sense. :-)

And debugging is only part of the issues. Part of it is also testing and
learning and probing (which could be done as long as you have some
consistent way of talking to the system under study -- consistent on your
end as a user, even if you might, as Michael implies, need specialized
backends for each system).

And, I'd add, all the stuff that surrounds that process, like making a
hypothesis and testing it, as people do all the time when debugging, could
be common.
There have been
advances in compiler architecture geared towards this sort of thinking, such
as the logic of bunched implications viz a viz Separation Logic and even
more practical ideas towards this sort of thinking, such as Xavier LeRoy's
now famous compiler architecture for proving optimizing compiler
correctness. The sorts of transformations that an application compiler like
GWT makes are pretty fancy, and if you want to look at the same GWT
application without compression today and just study what went wrong with
it, you can't.
I don't know about GWT, but Google's Closure claims to have a Firebug module
that lets you debug somewhat optimized code:
http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html
"You can use the compiler with Closure Inspector, a Firebug extension that
makes debugging the obfuscated code almost as easy as debugging the
human-readable source."

Squeak had a mode where, with saving only some variable names, it
essentially could decompress compiled code into fairly readable source.

In general, to make systems multilingual friendly, we need various ways to
map names onto variables as a sort of "skin" the same way people put skins
over GUI MP3 players. :-)
http://www.google.com/#hl=en&q=skinnable+app

Semantic web sorts of ideas might help there -- if you can abstract ideas to
some level, you can then present them with appropriate language terms. For
example, a "for" loop in computing might show up in whatever the
programmer's preferred language might be, including a Chinese pictograph.
So, when you looked at someone else's code, it might be translated to your
preferred language and style (maybe even the comments to some degree). That
might help programmers across the world to collaborate better and also end
some of the dominance of English, as well as end the problem of code that
becomes a mismash of keywords in one language and variable names in another.
What you need to do, in my humble opinion, is focus on
proving that mappings between representations is isomorphic and non-lossy,
even if one representation needs hidden embeddings (interpreted as no-ops by
a syntax-directed compiler) to map back to the other.
As above, it depends what you are trying to accomplish. Sure, in an ideal
world maybe. But CS is littered with decades of projects about "proving"
things and personally I have not seen that any of it has contributed one bit
to the state of the art of computing (outside maybe a very few narrow
domains like cryptography). Of course, I was never a CS major, so I can't
say I know everything there. I'm sure some people really like to do proofs
-- I enjoyed it for a time, as I always liked puzzles and things.

Most of what gets done with computers seems to me to be just people like Dan
Ingalls or Linus Torvalds forging ahead, in what Alan Kay called a motto of
"You just do it and it is done." :-) Although that motto may be a little
different in a group or at different stages of a project's evolution.

But sure, ideally, a system should be able to do what you suggest, or at
least support you well as you try to do it yourself.

Maybe "debugging" is the wrong term for what I am thinking or feeling about?
It's more like some coherent way to interact with a system where you are not
limited by what that specific system provides but can bring to bear all the
tools you have from outside.

An example of this is VirtualBox, as a virtual machine that emulates a
desktop computer. In theory, you could use any tools you have outside of
that emulator to push the mouse around, click on things, OCR the text that
it outputs, examine any running machine code and register states, monitor
network traffic it tries to put out, check what it is writing to its virtual
hard drives and so on.

You might use this capacity to debug the system. You might use it to test
that the system has certain behaviors or meets some standard. You might use
it to design or redesign or alter the system. You might use this capacity to
just learn about the system. You might use this capacity to use the system
as a module at a higher level. You might use this capacity to interact with
other people to have a discussion about the system in relation to each of
the previous things such as design or bugs (especially if you could capture
and replay what the system does).

As an analogy, a Scanning Tunneling Microsope can be used both to image a
surface of atoms and to move atoms around on that surface.
"IBM Scientists First To Measure Force Required To Move Individual Atoms"
http://www-03.ibm.com/press/us/en/pressrelease/23544.wss

About twenty-two years ago, I worked with someone at a small company who had
the idea of an executive program that would run on top of a PC to interact
with programs for you (we might call them agents now). Perhaps that idea has
just stuck in my mind. But certainly the entire realm of automated testing
tools has moved more and more in that direction.

In general, what I am proposing is breaking out of the "self hosting" model
of tools (as nice as that is) of mainstream Smalltalks, and into what
ParcPlace was trying to do with (was it?) "Van Gogh" in the mid 1990s with
firewalls between sets of objects, and what I tried to do with PataPata
where one world with its own window system could be used to inspect and
modify another world without changing its own structure significantly.

Example code for a system that has viewers defined as "worlds" of objects
that can operate on other worlds:
http://patapata.svn.sourceforge.net/viewvc/patapata/trunk/older_and_obsoleted/PataPata_0.2/
Like WorldInspector.py could operate on WorldDandelionGarden.py.
(It's not as abstract and decoupled as I would have liked -- like if data
went back an forth between them in some textual form like JSON).
There are also other fancy techniques being developed in programming
language theory (PLT) right now. Phil Wadler and Jeremy Siek's Blame
Calculus is a good illustration of how to study a living system in a
creative way (but does not provide a complete picture, akin to not knowing
you need to stain a slide before putting it under the microscope), and so is
Carl Hewitt's ActorScript and Direct Logic. These are the only efforts I am
aware of that try to provide some information on why something happened at
runtime.
Thanks for the suggestions.

When I think about them, I can see we are talking about a system at two
different levels. You are sort of talking about what we we do with the
information we are getting about a system as we try to model it with some
representation and reason about it. And that's valuable, of course. Even
essential. I'm more thinking, how do we have a paradigm where we are
collecting the data and interacting with something so we could do some kind
of science on it (where when we have that data, then we could build the
representations you are referring to or try to validate them).

So, I think what you say fits into what I say, although what you are talking
about is sort of one approach of what to do with data collected -- which is
to formalize it and formally reason about it, as opposed to what I'm
thinking about which is more to discuss the data in an ad hoc or
semi-structured way. I can see that both approaches would be valuable. I
imagine, for the right "microscope" platform, people might write a whole
variety of systems useful for analyzing the data and suggesting what to look
at next.
Post by Paul D. Fernhout
I can usefully point the same microscope at a feather, a rock, a leaf, and
pond water. So' why can't I point the same debugger at Smalltalk image, a
web page with JavaScript served by a Python CGI script, a VirtualBox
emulated Debian installation, and a semantic web trying to understand a
"jobless recovery"?
I know that may sound ludicrous, but that's my point. :-)
What the examples I gave above have in common is that there are certain
limitations on how general you can make this, just as Oliver Heaviside
suggested we discard the balsa wood ship models for engineering equations
derived from Maxwell.
Again, as above, you are thinking about building a formal model. But most
things we deal with in science don't have a complete formal model (like the
Earth's climate, or a squirrel, or even how the influenza virus interacts
with vitamin D deficiency). Scientists may have formal models about all
these (and ofter more than one), but they are generally not complete because
the whole value of a model is the simplification. So, they are not
"isomorphic" models -- they are just *useful* models. And people then have
discussion about the models. That is what goes on in science.

No one expects a microscope to tell you the exact quantum states of every
wave/particle in the field of view. That's true even though STM microscopes
begin to approach that as a recent innovation -- but they presumably have a
very small field of view, too, literally I'm guessing just hundreds of atoms
across. See:
http://en.wikipedia.org/wiki/Scanning_tunneling_microscope
But we've had almost 500 years or more of biology with microscopes or hand
lenses before getting to that stage, in any case. In that sense, gdb (the
GNU Debugger) is maybe like a roughly ground lens -- much better than
nothing in many cases, but still not a microscope of any great design, which
would require a bit more complexity (like, say, tracking your hypotheses
about bugs, or linking what you do to test cases, or allowing several people
to debug stuff together, or keeping traces of everything you tried and
letting your step backwards through all the code, etc.). Actually, I have
not used gdb in quite a while so I see they have added that last:
http://www.gnu.org/software/gdb/news/reversible.html

But can you use gdb to, say, debug medical problems? The question is absurd
right now of course (unless you medical problem is malfunctioning software
in a pacemaker), but will it still be such an absurd question in ten years,
to think that the general paradigm of debugging might be supported by more
general tools that have specialized backends, this one to talk to code, this
one to look at semantically tagged knowledge about health issues, all using
the sorts of formal processes that you imply in your suggestions?

In general, scientists (and engineers and designers) expect to be able to
use tools that give you some data about a system, and then you have to put
that data together in various ways (and more and more, the semantic web
plays a role in how communities may collectively do that).

Sure, someday people may get to the point were there is good general
agreement on rules of thumb for some design process (Maxwell's equations).
But they are still often rules of thumb in a sense that they may not reflect
what is going on in detail at the quantum level -- so they are a
simplification, as would be balsa wood models a simplification in a
different way.

Granted, some simplifications are more useful than others for specific
purposes. The equations might lead to better designs for hull shapes, but
they may not be as convincing to a potential funder of a project as a balsa
model they can play with. :-)
Post by Paul D. Fernhout
But when you think about it, there might be a lot of similarities at some
level in thinking about those four things in terms of displaying
information, moving between conceptual levels, maintaining to do lists,
doing experiments, recording results, communicating progress, looking at
dependencies, reasoning about complex topics, and so on. But right now, I
can't point one debugger at all those things, and even suggesting that we
could sounds absurd. Of course, most things that sound absurd really are
absurd, but still: "If at first, the idea is not absurd, then there is no
hope for it (Albert Einstein)"
In March, John Zabroski wrote: "I am going to take a break from the
previous thread of discussion. Instead, it seems like most people need a
tutorial in how to think BIG."
And that's what I'm trying to do here.
Thanks for the kind words. I have shared my present thoughts with you here.
You're welcome. Thanks for your comments.
But a tutorial in my eyes is more about providing people with a site where
they can go to and just be engulfed in big, powerful ideas. The FONC wiki
is certainly not that. Most of the interesting details in the project are
buried and not presented in exciting ways, or if they are, they are still
buried and require somebody to dig it up. That is a huge bug. In short,
the FONC wiki is not even a wiki. It is a chalkboard with one chalk stick,
and it is locked away in some teacher's desk.
Yes, I can see your point. Although the same is true for my own work. :-)

And that is another reason we need better tools in general. I've been
preparing a post in another context about history societies and
manufacturing where I say: "In general, history is something with a lot of
emotional value to many people (myself included) whether one wants to call
it values, sentimentality, conservativeness, art, or anything else. Humans
may have always had opposable thumbs for toolmaking, but chance are they
also have long been storytellers, and stories most often relate to
history... So, if to make is to be human, so is to think about history,
including the history of making. :-) And, I'd suggest, any *general*
infrastructure used to support that might also be useful to support cutting
edge technology development. You would think that cutting edge technology
development would support creation of cutting edge ways to organize all
that. But since so much of that cutting edge work is proprietary, and the
people doing it have already taken on so much risk in their R&D, maybe it
may be up to the people interested in history to build cutting edge systems
for looking at ecosystems of tools and processes?"

So, looking at the history of existing programming systems (like the late
Prof. Michael Mahoney at Princeton University did)
http://www.princeton.edu/~hos/Mahoney/
"Articles on the History of Computing"
http://www.princeton.edu/~hos/Mahoney/computing.html
could be one motivator to put together some of those sorts of tools (like to
provide the interfacing Michael mentioned), which then might be useful in
cutting edge endeavors that are documented as they go?

So, sure, it's a "bug". But what does that bug tell us about the
state-of-the-art in good communications? Are we still at the analogous point
in computing research where we are telling everyone to add a lot of comments
to their hand-optimized assembler code (as in, write nice stuff on the
Wiki)? Or can we conceive of some sort of semantic web about software
development where, like in Smalltalk, everything people do somehow becomes
more "self documenting" and "literate programming" with just the slightest
bit of effort and encouragement through using good tools designed to help
with that somehow?

What would such tools look like for sure, I don't know. I'm more posing the
question than saying I have the answers. However, these two tools from SRI
(which my wife helped a bit with incidentally on a joint project) give me
some examples:

"Structured Evidential Argumentation System"
http://www.ai.sri.com/~seas/
"SEAS is a software tool developed for intelligence analysts that records
analytic reasoning and methods that supports collaborative analysis across
contemporary and historical situations and analysts and has broad
applicability beyond intelligence analysis... The survival of an enterprise
often rests upon its ability to make correct and timely decisions, despite
the complexity and uncertainty of the environment. Because of the difficulty
of employing formal methods in this context, decision makers typically
resort to informal methods, sacrificing structure and rigor. We have
developed a new methodology that retains the ease-of-use, familiarity, and
(some of) the free-form nature of informal methods, while benefiting from
the rigor, structure, and potential for automation characteristic of formal
methods. Our approach aims to foster thoughtful and timely analysis through
the introduction of structure, and collaboration through access to the
corporate memory of current and past analytic results. ..."

"What is Angler"
http://www.ai.sri.com/~angler/
"Angler is a tool that helps intelligence/policy professionals Explore,
understand, and overcome cognitive biases, and Collaboratively expand their
joint cognitive vision Through use of divergent & convergent thinking
techniques (such as brainstorming and clustering). Humans tend to bias the
analysis of situations based on their previous experiences and back-ground.
Angler is a tool to help analysts explore, understand, and overcome such
biases and to collaborate in expanding their joint cognitive vision. Angler
utilizes divergent and convergent techniques, such as brainstorming and
clustering or voting, to guide a diverse set of intelligence professionals
in completing a complex knowledge task. The tool helps the group through the
process of forming consensus, while preserving and quantifying differing
ways of thinking. Angler provides a Web-based collaborative environment that
allows users distributed by both time and geography to assemble in teams,
with the help of a facilitator. ... Cognitive Expansion: In the same way
that a pair of binoculars enhances the range of things the eye can see,
Angler aims to be a mental prosthetic device that enhances our problem
solving and decision analysis processes. The cognitive horizon of a person
or a group can be loosely defined as the transitive closure of possible
deductions starting from an initial set of assumptions. This horizon can be
narrowed by competing or contradicting hypotheses. In order to overcome
cognitive bias, we must recognize that we are in a situation where we are
experiencing cognitive bias. The recognition problem is handled in one of
two possible ways. The first possibility is to ignore it. SBP assumes that
we live in a complex nontractable world, and that in most situations
requiring formal decision making this assumption is correct. On the other
hand, complexity theoreticians divide the world into ordered and unordered
situations. They have guidelines to recognize in which part of the spectrum
a problem belongs. The identification of the space to which the problem
belongs will determine the type of tools used to solve it. Overcoming
cognitive bias is a process that has to do with understanding one’s own
assumptions and the problem’s decision landscape. The decision landscape is
composed of the actors and forces that can influence the decision, the
actions that the actors (not necessarily human) can take, and the certainty
(or uncertainty) we have about the outcome of those actions. One could claim
that a thorough investigation of those assumptions will yield an answer to
the problem of cognitive bias, but the problem is often more complex. We
live in an uncertain world, and a review of the assumptions cannot often be
thorough enough to consider all possibilities. ..."

Those are proprietary, but here is a related open source tool:
http://makethecase.net/wiki/Make-the-Case_Case_Index
"Make the Case allows you to view, edit, and create cases for or against
particular propositions."

My wife also has some free software she has written that touches on some of
these themes (mostly about narrative and perspectives):
http://www.rakontu.org/

But, when you think of it, what are you doing when you "debug" a piece of
code but building up some sort of story about how it should work in some
situation, and then comparing it with a story of how it actually did work in
that situation?

So, I'm suggesting these sorts of tools might be useful when an individual
or a group of people are looking at any of:
* some bug in the Linux Kernel;
* the design of a new computer language (designs can have "bugs");
* economic policy to deal with the declining value of most human labor in an
ever-more-automated world also full of voluntary social networks and better
design (a "buggy" economic model), or
* whether to have a chocolate or vanilla wedding cake (or no cake and just
fruit salad and green smoothies) related to two programmers getting married,
where a big disagreement or just a nagging worry about doing the right thing
is a "bug" to be resolved. :-)

As I see it, those are all aspects of computing. :-) Even if they sometimes
involve the issue that: "The identification of the space to which the
problem belongs will determine the type of tools used to solve it."

Where, in software development, is there the fluid flow between these
different tools, except as something that a programmer learns by trial an
error? Where is the cognitive support? And then, from that, where is the
emerging narrative about what one is doing that can be shared and interwoven
with others? Without, as you imply, keeping some sort of Wiki up-to-date
manually when the people involved are using other tools for everything they do?

I'm not sure there is an easy answer to that, and certainly right now it
does take a lot of work to keep some good wiki site up-to-date if you want
to let people know what you are doing in a coherent way. Certainly that sort
of work is worth doing right now. I'm just asking more, are their ways that
such communications could be woven more into the tools people are using?
Maybe with some sort of "summarizing" process? Or some way of tagging what
someone is doing, or labeling parts of it, or extracting common or frequent
themes, or something like that? After all, Google does not have someone
work by hand to create a results page (or pages) for every possible search
term of interest -- there are algorithms somewhere that look at connections
and prioritize things and then present (presumably) customized results
(based perhaps on user interests or geography).

For example, why can't, say, Alan Kay make a list of ten important themes
and there might be up-to-date web pages presented as a large semantic
network evolves about FONC? Would that work (even just using Google), I
don't know. But it's sort of the beginning of an idea, anyway, just to link
it with your current interest in presenting Alan Kay's work (given as you or
someone else said the redundancy in various presentations). For a related
approach, imagine if the issue was not so much to rewrite or condense what
Alan Kay has said, as opposed to put it into some semantic web of ideas, and
then people could explore it, or one could see how often he emphasized
certain themes in presentations, and from those might flow a set of web
pages, or at least the outline of a summary that one could then tweak by
hand. I know it would be interesting to use such tools on, say, my own Sent
folder, to look for how to organize what I have written on to different
people and mailing lists, to look for common themes, URLs I frequently cite,
and so on.

Another related (new) open source project I just learned about that talks
about narrative and the semantic web btw is "Netention" (though is coming
more from the AI side of things):
http://netention.org/documentation/
"The portrayal of one’s life as an open-ended, revisable story, interwoven
with people that they know, and the people that they haven’t met (yet). ...
Netention solves, in general, all resource management and planning issues
that occur amongst communities of participants. It eliminates the
balkanization of various separate online services that presently serve
relatively narrow subsets of the more general “problem”."

Anyway, I have not used that software, but I can appreciate the aspiration.

Of course, there is always a tension between automation and better tools to
do stuff by hand. So, I don't want to come across as saying everything
should be automated. I think we need some mix of better tools and better
standards that better automation can work with, all developed within some
framework of humane values, oriented towards identifying and dealing with
major problems in our society or our individual lives and local communities
-- as a co-evolutionary process like Doug Engelbart talks about. That really
is the pressing need for future computing, IMHO. And I think a lot of the
previous work by Alan Kay, Dan Ingalls, and many others, as far as focusing
on empowerment, on learning, on fun, on sharing, on communicating ideas, on
simulation, and so on, can all support the humane side of what we need. It
is indeed easy to get lost in the bits and bytes and machine instructions
and endless abstractions and lose sight of the need for tools to
collaboratively build communities that are joyful, healthy, prosperous, and
intrinsically/mutually secure. I think in that sense the "personal"
computing aspect of future computing, while empowering on one level, is also
disempowering on another that relates to communities. We need both to
empower the individual and to empower the healthy community.

Clay Shirky is not perfect (no one is), but there are many good ideas here:
"A Group Is Its Own Worst Enemy "
http://www.shirky.com/writings/group_enemy.html
"Clay Shirky on institutions vs. collaboration"

http://www.ted.com/talks/clay_shirky_on_institutions_versus_collaboration.html

Especially for that last TED link with a video, what is the meaning to the
ideas there to FONC related to social tagging etc.? Which brings back the
semantic web (if you generalize it). But then what tools do we need to deal
with all the craziness going on in a social network, like having something
crazy like JavaScript as the universal JVM, or millions of web pages that
each are a specialized program and have information put on them in an adhoc
way without clear machine-readable licenses, or a situation where 98% of
email communications are spam but the other 2% are really essential but
where new communications efforts like Google Wave get discarded because they
are not email, and so on... These are the kind of crushing problems that the
future of computing has to deal with -- because they are crushing problems
now and people are having a tough time of them and probably will without
lots of innovation.

For reference, Douglas Crockford on JavaScript, to understand the history of
"the future of computing" relative to a decade or two ago: :-)
http://yuiblog.com/crockford/
http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-2
"Now, if you were here last time you’ll remember I went through the history
of everything that ever happened, starting with The Big Bang, going through
The Dawn of Man, and then finally there was JavaScript. The reason I did
that was because understanding the context in which this stuff happens is
really important to understanding what we have now. Without that
understanding you’re consumed by mythology which has no truth in it, that
the history of innovation has been one thing after another where the new,
good thing always displaces the old stuff. That’s not how it works,
generally. Generally the most important new innovations are received with
contempt and horror and are accepted very slowly, if ever. That’s an
important bit of knowledge to have, if the case of JavaScript."

As with JavaScript, the solutions we may see to these things in the future
may be quirky things that are in the right place at the right time. How can
FONC be that right thing in the right place real soon now? I don't know, but
I'm trying to make some suggestions based on what I see as being important
in the next decade or so. That is why I suggest that applications of FONC
link to things like the semantic web, structured arguments, multiple
perspectives, as well as being part of microscopes/telescopes to deal with
other sorts of computer systems. And that is with the acknowledgment that
those other systems, compared to FONC's spinoffs might seem stupid and
broken, like, say stupid-and-broken PHP which has none-the-less dominated
much of the server side of the web, or say, VirtualBox running Windows 95
and legacy software, an equally stupid and broken system by today's
standards, or, say, JavaScript in a web browser maybe pushing XML-ish
encoded semantic web stuff around, which is probably another stupid and
broken system, but it is what we sure have a lot of. :-)

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Michael FIG
2010-10-08 19:51:26 UTC
Permalink
Hi Paul,

Thanks for your detailed post. It's inspiring me to share a little
about my current work and understanding of VPRI's general approach
(though, again, I should remind folks that I don't represent VPRI even
though I had the pleasure of working closely with Ian in the past).

You've cited too many references for me to absorb right now, but it is
definitely convincing me that once I've bootstrapped my Perl-based
language lab (much inspired by the latest things I saw Ian working on,
as well as OMeta, but with closer links to Knuth's attribute grammars
than to PEGs proper, and much less effort because I can do portable
coroutines via Perl 5's Coro library) I should use it to bootstrap a
Javascript version. An important lesson I learned from Ian and ANTLR
was that the grammar's description should capture as much information
as possible but not specify actions, so that different clients can use
the same grammar for different purposes.

A language lab is defined by its default syntaxes, whether human or
computer-readable. I have aspirations for creating a simple, compact,
extensible syntax that people love enough to support on many computer
systems, both as a programming language and as a communication
protocol (and no, it won't be XML or sexprs). The software involved
is bootstrapping an interpreter library on each platform, and giving
it access to as many target primitives as possible. To survive as a
communication protocol, it needs to use an object-capability model of
some sort because sandboxing leads to insanity.

With first-class grammars for describing arbitrary
languages/protocols/data structures/agent network configurations, a
microscope/telescope app that dynamically utilizes such descriptions
is not far away. Each new platform we port to effectively becomes a
platform we can run on, analyze, and extend.

A generic "stage 0" interpreter/compiler lab for the default language
would be able to specialize into a "stage 1" lab for any language by
statically attaching bootstrap code to a specific grammar. Non-lab
applications could be the byproduct of asking a lab to compile other
inputs.

So, in short, I think we need exactly one level of abstraction above
the Semantic Web in order to make a true end run in the convergence
game. Legacy systems of all sorts need to be described and preserved,
not rewritten and rearchitected in a "standards-compliant" way.

BINGO! (For everybody playing Programming Language Buzzword Bingo
with my post.)

For those interested in the Perl implementation of my Ocean language
lab, it's a self-replicating single file whose embedded grammar
descriptions you can edit and run to bootstrap your own Perl-based
lab, interpret a script written in the lab's supported languages, or
play around with a REPL. I'll be posting here when I get it to the
point of being clean enough for others to use.

Thoughts?
--
Michael FIG <***@fig.org> //\
http://michael.fig.org/ \//
Paul D. Fernhout
2010-10-09 01:41:39 UTC
Permalink
Post by Michael FIG
So, in short, I think we need exactly one level of abstraction above
the Semantic Web in order to make a true end run in the convergence
game. Legacy systems of all sorts need to be described and preserved,
not rewritten and rearchitected in a "standards-compliant" way.
Sounds pretty cool. :-)

So, then what might come next would be the social context to drive people to
create all those specific descriptions you would need for interfacing with
various systems.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Rémy Mouëza
2010-10-09 13:09:56 UTC
Permalink
Hello Michael,
Post by Michael FIG
I have aspirations for creating a simple, compact,
extensible syntax that people love enough to support on many computer
systems, both as a programming language and as a communication
protocol (and no, it won't be XML or sexprs). The software involved
is bootstrapping an interpreter library on each platform, and giving
it access to as many target primitives as possible. To survive as a
communication protocol, it needs to use an object-capability model of
some sort because sandboxing leads to insanity.
[...]
Post by Michael FIG
Thoughts?
This reminds me the Rebol programming language
(http://en.wikipedia.org/wiki/Rebol & http://www.rebol.com/) which free
form syntax can be use both as a programming language and a data format.
It syntax can also be extended to create domain specific language and it
has a form of prototype base object model.

How will your Ocean language lab be different from Rebol?
--
Rémy.
Michael FIG
2010-10-10 04:13:33 UTC
Permalink
Post by Rémy Mouëza
How will your Ocean language lab be different from Rebol?
Thanks for the pointer, Remy. I was not very familiar with Rebol
before.

The difference is that the Rebol syntax can be compared with just one
component of Ocean, _Rock_, which is the default concrete syntax I
alluded to earlier.

However, the main contribution of Ocean will be first-class grammars,
encouraging people to use them as a control structure (as innovated by
the VPRI folks), and thereby assimilate other syntaxes/protocols that
don't need to have any relationship to Rock.

Ocean will share much more in common with John Shutt's Kernel language
(a cleaned up and simplified "Scheme reloaded"), which I take as an
excellent starting point for a language lab.

As an example, Ocean will be fexpr-based, as well as having
first-class environments. I believe that first-class grammars
combined with fexprs will add significant power to the language,
allowing for any construct to define syntactical transformations via a
grammar and direct eval calls, rather than indirectly as in macros.

Rebol, on the other hand, depends on simple precedence rules and
shoehorns all its DSLs into the same syntax. I can't overemphasize
the convincing case that Ian made about how simple a language
bootstrap can be when you have first-class grammars, and how much of a
useful tool they can be in everyday programming.

Ocean's next contributions will be in determining a minimal set of
basic abstractions that are needed to bootstrap the environment,
potentially differently expressed than in Kernel (which, to me,
doesn't seem too focused on bootstrapping). This needs very
convincing stories for namespaces, peer-to-peer and parent-child
messaging, protocol/syntax description, and (what may not yet be an
obvious need, and I wish I had a better way of describing it)
steganography.

Of course, that's all hot air until I get the first release together.

If there was one key idea I wanted to impart to you, dear reader, it
is that _plurality_ is the theme. I have no agenda to promote or
disparage another system, just that I want to understand them and
integrate with them to the highest degree possible. But of course,
that will only be an option once the environment is bootstrapped.

Good night,
--
Michael FIG <***@fig.org> //\
http://michael.fig.org/ \//
Dirk Pranke
2010-10-09 01:21:47 UTC
Permalink
On Fri, Oct 8, 2010 at 2:04 PM, Paul D. Fernhout
Post by Paul D. Fernhout
It's totally stupid to use JavaScript as a VM for "world peace" since it
would be a lot better if every web page ran in its own well-designed VM and
you could create content that just compiled to the VM, and the VMs had some
sensible and secure way to talk to each other and respect each other's
security zones in an intrinsically and mutually secure way. :-)
 "Stating the 'bleeding' obvious (security is cultural)"
 http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00
You are describing something that is not far from Chrome's actual
design. It appears that the other browser vendors are moving in
similar directions. Are you familiar with it? Do you care to elaborate
(off-list, if you like) on what the differences between what Chrome
does and what you'd like are (apart from the JavaScript VM being not
particularly designed for anything other than JavaScript)?

-- Dirk
Paul D. Fernhout
2010-10-09 06:09:41 UTC
Permalink
Post by Dirk Pranke
On Fri, Oct 8, 2010 at 2:04 PM, Paul D. Fernhout
Post by Paul D. Fernhout
It's totally stupid to use JavaScript as a VM for "world peace" since it
would be a lot better if every web page ran in its own well-designed VM and
you could create content that just compiled to the VM, and the VMs had some
sensible and secure way to talk to each other and respect each other's
security zones in an intrinsically and mutually secure way. :-)
"Stating the 'bleeding' obvious (security is cultural)"
http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00
You are describing something that is not far from Chrome's actual
design. It appears that the other browser vendors are moving in
similar directions. Are you familiar with it? Do you care to elaborate
(off-list, if you like) on what the differences between what Chrome
does and what you'd like are (apart from the JavaScript VM being not
particularly designed for anything other than JavaScript)?
Yes, there are similarities, you are right. I'm not familiar in detail
because I have not used Chrome or looked at the code, but to my
understanding Chrome does each tab as a separate process. And typically (not
being an expert on Chrome) that process would run a rendering engine (or
maybe not?), JavaScript (presumably?), and/or whatever downloaded plugins
are relevant to that page (certainly?).

From:
http://en.wikipedia.org/wiki/Google_Chrome
"Chrome will typically allocate each tab to fit into its own process to
"prevent malware from installing itself" and prevent what happens in one tab
from affecting what happens in another, however, the actual
process-allocation model is more complex.[49] Following the principle of
least privilege, each process is stripped of its rights and can compute, but
cannot write files or read from sensitive areas (e.g. documents,
desktop)—this is similar to the "Protected Mode" used by Internet Explorer
on Windows Vista and Windows 7. The Sandbox Team is said to have "taken this
existing process boundary and made it into a jail";[50] for example,
malicious software running in one tab is supposed to be unable to sniff
credit card numbers entered in another tab, interact with mouse inputs, or
tell Windows to "run an executable on start-up" and it will be terminated
when the tab is closed.[15] This enforces a simple computer security model
whereby there are two levels of multilevel security (user and sandbox) and
the sandbox can only respond to communication requests initiated by the
user.[51] Typically, plugins such as Adobe Flash Player are not standardized
and as such, cannot be sandboxed as tabs can be. These often need to run at,
or above, the security level of the browser itself. To reduce exposure to
attack, plugins are run in separate processes that communicate with the
renderer, itself operating at "very low privileges" in dedicated per-tab
processes. Plugins will need to be modified to operate within this software
architecture while following the principle of least privilege.[15] Chrome
supports the Netscape Plugin Application Programming Interface (NPAPI),[52]
but does not support the embedding of ActiveX controls.[52] On 30 March 2010
Google announced that the latest development version of Chrome will include
Adobe Flash as an integral part of the browser, eliminating the need to
download and install it separately. Flash will be kept up to date as part of
Chrome's own updates.[53] Java applet support is available in Chrome with
Java 6 update 12 and above[54]. Support for Java under Mac OS X was provided
by a Java Update released on May 18, 2010.[55]"

So, yes, especially from a security aspect, there is a lot of overlap.
http://www.google.com/chrome/intl/en/more/index.html
http://www.google.com/chrome/intl/en/more/security.html
"Google Chrome includes features to help protect you and your computer from
malicious websites as you browse the web. Chrome uses technologies such as
Safe Browsing, sandboxing, and auto-updates to help protect you against
phishing and malware attacks."

Of course, we use Firefox and NoScript to do some of that just with
JavaScript. I haven't installed Chrome in part just for concerns that it is
too much power for Google to have over my life. :-) But I've though about it
precisely for that feature of seperate processes. But Firefox has been
adding running plugins in separate processes, so that is a step in that
direction, too.

But, that's still not the same as having a common Virtual Machine for each
tab, where you can expect to have, say, a JVM available to run the code for
that page that meets some standards (even as you could have one installed in
many situations essentially as a plugin, but 30% coverage or whatever is not
100% coverage). And you'd need a VM optimized so there is essentially very
little cost in time or memory to create and dispose of hundreds of these VMs
(which is probably not yet the case for the JVM, although it continues to
improve -- a big advantage I've heard of, say, PHP over Java for CGI has
been that it starts fast because so much is precompiled, even if Java is
faster once it gets going). I don't know the current state of JVM startup
optimization other than that it has been getting a lot better in loading
(especially with version 6), but it still, to my understanding, can start
running as fast as, say, a Squeak VM that just maps an object memory file
using virtual memory and gets going? Also, I think the JVM still takes a
bunch of memory even just to start up? Anyway, I would expect Java will
continue to improve in that way. But, that's all future stuff.

Personally, I also think the browser itself should be written in a language
like something that runs on the JVM or something other VM, something with
garbage collection, in order to reduce the security risks of memory-related
and pointer-related programming errors in the rendering engines. The fact
that Chrome is written in C++ probably makes in fundamentally insecure. :-)
Here is a random file in C++ from the project:
http://src.chromium.org/viewvc/chrome/trunk/src/base/json/json_writer.cc?revision=54359&view=markup
Do I want to check that for memory leaks or misused pointers and so on?
Boring and tedious. So 1980s. :-) And even then you could use ObjectWorks or
Lisp. :-) So, in that sense, Chrome is obsolete. The best they could do
someday is maybe use OMeta to translate parts of it to something else. :-)
And I'm not just joking -- it is not unreasonable for me, as an end user, to
say that I would rather have software than ran half the speed but was not
going to keep having random security problems in years to come every time
someone changes it and forgets an asterisk or a bounds check somewhere. Oh,
sure there are tools, and there is testing, and so on. But then we are into
the fact that if developers are worrying about all that, they'll probably
make some other security error. And example alternative:
http://lobobrowser.org/java-browser.jsp
"Lobo is an open source web browser that is written completely in Java. "

So, in any case, whether Chrome is already obsolete for security
considerations or not, right now, you are still stuck with JavaScript as the
universal VM in Chrome, and not instead something that you could optimize
more like Java's JVM or VisualWork's VM, or Forth, or something else. Well,
it looks like Flash is getting bundled in(?), but Flash is not especially
open as a VM (even if you could use haXe or something like that with it).
You don't have a reliable alternative where you would not necessarily have
that 100X performance penalty of using JavaScript for looping or floating
point calculations (or whatever the penalty is now with optimization work
going on fast and furious). Although maybe that is changing, as with those
comments about what is going on since May -- but it still seems like a
separate install for Java?
http://www.java.com/en/download/faq/chrome.xml

And of course, not everyone is running Chrome. I'd be surprised if it had
more than 5% marketshare? Or even 1%? Well checking it, I am surprised, it
has 7% according to this:
http://marketshare.hitslink.com/
"In daily tracking, Chrome 6.0 is topping 7% of global browsing share since
being released on September 2nd. All other versions of Chrome have dropped
to near zero global share in the meantime. The almost complete migration of
users to 6.0 occurred within three weeks."

Of course, autoupdates are another potential security problem. :-) Sooner or
later, everything is going to get autoupdated to malware. :-( That's another
peril of rapid development and systems that are not designed modularly with
lots of firewalls in the first place (like if Google Chrome was just some
Jar files for a reliable and rarely changing JVM and all running in
sandboxes). Anyway, just more reality-checking issues for "the future of
computing" -- dealing with security and how people actually upgrade software
(and maybe giving people a better way to do that).

Maybe in a year or two all major OS's will have the JVM installed and so you
could ask people who visit your site to download just Chrome? But will
Windows have the JVM installed by default? I don't know and I would think
not? Still, in practice it might be installed already for something else?
But then will Chrome be configured to use it?

Anyway, the fact that it's not easy to know that is why what Chrome is doing
is not identical to what I suggested. It's compatible (like if Google got
Windows and all GNU/Linux distributions to have Java installed and
configured with Chrome), but it's not identical. And until it is, we are
left with JavaScript.

Also, it's not clear off hand how you would get different JVMs to talk to
each other in a browser like Chrome? It might be easily doable, but I'm not
sure if it has actually been done in Chrome, like to make a more complex
application or support multiple cores with VMs than were sending messages to
each other?

Anyway, just lots of unknowns for me. But a good question.

Of course, then one may ask, does it run on the Android and the iPhone?
JavaScript again is what you might expect there.

It's hard to think about how something new gets the social momentum to
overcome the hurdle of JavaScript now being entrenched everywhere people
spend most of their time at the computer -- there is even JavaScript plugins
in, say, the Thunderbird email client I use to write this. It really is
almost everywhere.

Now, there are problems of the VM approach too, even if every web browser
maker did agree to bundle in the JVM with their browser in a way that would
let everyone write to the JVM with Java, JavaScript on Rhino, Scala,
Clojure, or whatever FONC produces that can translate to the JVM. Right now,
unless people take pains to obfuscate their JavaScript, you can probably
read whatever is on a web page as an end user, and the code can even be
indexed by a search engine (in theory, though I would expect most skip it?).
But if people are writing things that are precompiled for a VM (JVM, Flash,
or whatever) then you may not get the source and also web pages may not be
accessible (unless the author makes the source available anyway or creates
related semantic content for the page that is textual that can be used in
parallel with the compiled code). So, that's actually a good side of how
JavaScript is used in practice, that the "view source" key really works. And
that's a big way people learn about JavaScript, HTML, and CSS, beyond
tutorials in the web browser itself:
http://www.w3schools.com/js/default.asp

But ultimately, I'd hope we could move to, like John says, beyond "writing
applications as if they were still single-tier IBM computers from the
1970s/80s" at least for most things. (I still think many simulations may
likely fall in that category for a long time.) And that means probably
writing much more sophisticated clouds of cooperating web pages and related
servers (or other communications infrastructure).

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Leo Richard Comerford
2010-10-09 07:01:27 UTC
Permalink
I have mentioned this before, but
http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/#comment-7893
.

Leo.
Dirk Pranke
2010-10-09 19:45:32 UTC
Permalink
On Fri, Oct 8, 2010 at 11:09 PM, Paul D. Fernhout
Post by Paul D. Fernhout
Yes, there are similarities, you are right. I'm not familiar in detail
because I have not used Chrome or looked at the code, but to my
understanding Chrome does each tab as a separate process. And typically (not
being an expert on Chrome) that process would run a rendering engine (or
maybe not?), JavaScript (presumably?), and/or whatever downloaded plugins
are relevant to that page (certainly?).
Yes, each tab is roughly a separate process (real algorithm is more
complicated, as the wikipedia article says). rendering and JS are in
the same process, but plugins run in separate sandboxed processes.

C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.

Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.

I continue to hope, but I may be unreasonable :)

-- Dirk
Dethe Elza
2010-10-09 20:18:23 UTC
Permalink
[...] it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
The Mozilla Foundation is creating the Rust language explicitly to have an alternative to C++ for building a web browser, so it may not be that unreasonable, in the medium term. Progress on Google's Go language as an alternative to C, and the addition of garbage collection to Objective-C, show there is a wide-spread need for alternatives to C/C++ among the folks who create browsers.

Rust:
http://github.com/graydon/rust/wiki/Project-FAQ

--Dethe

http://livingcode.org/
Paul D. Fernhout
2010-10-10 03:50:33 UTC
Permalink
Post by Dirk Pranke
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Yes, that seems like a good description of the problem.

How about this as a possibility towards a solution. Use OMeta (or Antlr or
whatever :-) to parse all the C++ code and output some kind of semantic
representation formatted in Lisp, RDF, Cola, OCaml, JavaScript, pure
prototype objects, or whatever. Then write AI-ish code that analyzes that
abstraction and can write out code again in C++ (or JavaScript, Smalltalk,
Assembly, Lisp, OCaml, or whatever) but having done some analysis so that it
can be proved there are no possible buffer overruns or misused pointers or
memory leaks (and if there are grey areas or halting problem issues, then
stick in range checks, etc.). And maybe optimize some other stuff while it
is at it, too. So, treat C++ like assembly language and try to write the
browser at a higher level of abstraction. :-) Ideally, the end result of
this round-trip will look *identical* to what is read it (but I'm happy if
the formatting is a little different or a while loop gets changed to a for
loop or whatever. :-)

I've written some stuff that works like this (just a tiny bit, but no real
AI) for reading our old Delphi code (using Antlr and Python) and creating an
internal representation and then outputting code either in Java or
Python/Jython. Now, libraries can be a mismatch problem (and are in that
case, though I do a bit of the heavy lifting and then the programmer has to
do a bunch of the rest), as can other semantic issues (and again, the
conversion I did had some issues, but was better than rewriting by hand).
But in theory, Delphi to Java/Jython/Swing should be doable as I outlined
above -- with a bit more sophistication in the analysis, and at worst, with
some additional tools to make whatever human input was required easier to do
at a semantic level. :-)

Ideally, all the development and debugging would be done using the higher
level abstraction, but if someone still modified the C++ code, presumably
you could read the changes back into the higher level and integrate them
back into the abstraction.

So, I guess my objection to C++ isn't so much that it is used in compiling
browsers so much as that people are coding in it and not treating it as an
intermediate language and that it is not undergoing some kind of
sophisticated automated analysis to check for problems every single time a
build is made. For example, Squeak has its VM written in Squeak Smalltalk,
but translates it to C++. Now, that's not exactly what I am talking about,
but it is closer (coding in Smalltalk is awkward in some ways, and while I
have not generated a Squeak VM in a long time, I expect there could be
potentially bugs in the Smalltalk that might lead to buffer problems in the
C -- because there is not AI-ish programming Nanny checking what is being
done). I'm proposing a more complex abstraction, one perhaps encoded in
semantic triples or some other fancy AI-ish representation, even if you
might interact with that abstraction in more than one way (editing textual
files or moving GUI items around or whatever).

So, this way all that complexity about how to parse and render quirky HTML
that is there can be preserved, but then it can be operated on by more
sophisticated analysis tools, more sophisticated collaboration tools, and
more sophisticated output tools.

Now, ideally, this is what FONC stuff should be able to support, but I don't
know how far along OMeta etc. are to the point where they could make this
easy? I get the feeling there is a whole other AI-ish layer of knowledge
representation to reason about programs that would be needed above OMeta
(perhaps like John was getting at with his points on formal analysis?).

Although, on the other hand, XHTML is coming along, and to render older
pages I guess I could just do all my web browsing in a Debian installation
in VirtualBox to sandbox potentially buggy C++ -- maybe even one VirtualBox
install per loaded page? :-) Though two gigabytes here, two gigabytes there,
and sooner or later we're talking real amounts of disk space for all those
VirtualBox installs :-) But there is probably some way to get all the
VirtualBoxes to share most of their virtual hard disks. So, anyway, there is
a a potential way to deal with legacy security holes. :-) Still, since so
much of web browsing also might interact with saving files and such, it
would help to have an intelligent assistant (microscope/telescope) that
could go into that VirtualBox (even just by OCRing the displayed GUI) and
copy downloaded files out of VirtualBox or track WebStart invocations and
create new VirtualBoxes or even run that code outside of one, or that could
do any of the other desktop integration on might want. So, virtualization
(increasing the level of abstraction) is one possible answer to the legacy
issue, as is moving to better standards that are presumably easier to render
correctly.

Maybe VirtualBox should just be integrated into Firefox or Chrome? :-)
http://www.virtualbox.org/
Though that is only a x86 solution I guess.

Anyway, I know all these suggestions are things that either would take a lot
of work and cutting edge research, or are just wildly implausible, but in
the long term, new computing is probably going to address them in some way
(with some combination of virtualization, translation, AI-ish reasoning at a
higher semantic level of abstraction, tools for programming at a higher
level of abstraction, improved standards, etc.).

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
Dirk Pranke
2010-10-10 06:25:58 UTC
Permalink
On Sat, Oct 9, 2010 at 8:50 PM, Paul D. Fernhout
Post by Paul D. Fernhout
Post by Dirk Pranke
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of  C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Yes, that seems like a good description of the problem.
How about this as a possibility towards a solution ...
I think I'd rather try to write a browser from scratch than
debug/maintain your solution ;)

Also, re: running Chrome in VirtualBox, are you aware that the page
renderers are
already run in sandboxed execution environments? It's unclear how much
more protection
each page in a separate VM would really buy you.

-- Dirk
Paul D. Fernhout
2010-10-10 12:35:15 UTC
Permalink
Post by Dirk Pranke
On Sat, Oct 9, 2010 at 8:50 PM, Paul D. Fernhout
Post by Paul D. Fernhout
Post by Dirk Pranke
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Yes, that seems like a good description of the problem.
How about this as a possibility towards a solution ...
I think I'd rather try to write a browser from scratch than
debug/maintain your solution ;)
Sure, with today's tools "debugging" a solution developed at a higher level
of abstraction would be hard. So, sure, this is why no one does what I
proposed with parting C++ into an abstraction, working with the abstraction,
and then regenerating C++ as an assembly language, and then trying to debug
the C++ and change the abstraction and have round trip problems with all
that. Still, I bet people said that about Fortran -- how can you possibly
debug a Fortran program when what you care about is the assembler instructions?

But like I implied at the start, by the (imagined) standards of, say, 2050,
we don't have any "debuggers" worth anything. :-) To steal an idea from
Marshall Brain:
http://sadtech.blogspot.com/2005/01/premise-of-sadtech.html
"Have you ever talked with a senior citizen and heard the stories? Senior
citizens love to tell about how they did things "way back when." For
example, I know people who, when they were kids, lived in shacks, pulled
their drinking water out of the well with a bucket, had an outhouse in the
back yard and plowed the fields using a mule and a hand plow. These people
are still alive and kicking -- it was not that long ago that lots of people
in the United States routinely lived that way. ... When we look at this kind
of stuff from today's perspective, it is so sad. The whole idea of spending
200 man-hours to create a single shirt is sad. The idea of typing a program
one line at a time onto punch cards is sad, and Lord help you if you ever
dropped the deck. The idea of pulling drinking water up from the well by the
bucketful or crapping in a dark outhouse on a frigid winter night is sad.
Even the thought of using the original IBM PC in 1982, with its 4.77 MHz
processor, single-sided floppy disk and 16 KB of RAM is sad when you look at
it just 20 years later. Now we can buy machines that are 1,000 times faster
and have a million times more disk space for less than $1,000. But think
about it -- the people who used these technologies at the time thought that
they were on the cutting edge. They looked upon themselves as cool, hip,
high-tech people: ..."

So, people fire up GDB on C++ (or whatever) and think they are cool and hip.
:-) Or, for a more realistic example given C++ is a couple decades old,
people fire up Firebug on their JavaScript an think they are cool and hip.
:-) And, by today's standards, they are:
http://getfirebug.com/
But by the standards of the future of new computing in 2050, Firebug, as
awesome as it is now, lacks things that one might think would be common in
2050, like:
* monitoring a simulated end user's cognitive load;
* monitoring what is going on at hundreds of network processing nodes
* integration with to do lists and workflow management;
* really useful conversational suggestions about things to think about in
regard to potential requirements, functionality, algorithmic,
implementation, networking, testing, social, paradigm, security, and
stupidity bugs as well as all the other types of possible bugs we maintain
in an entomological catalog in a semantic web (a few specimens of which are
listed here:
http://weblogs.asp.net/fbouma/archive/2003/08/01/22211.aspx );
* easy archiving of the traces of sessions and an ability to run things
backwards or in a parallelized many-worlds environment; and
* an ability to help you debug an applications multiple abstractions
(even if it is cool that it can help you debug what is going on with the
server a bit: http://getfirebug.com/wiki/index.php/Firebug_Extensions )

So, to add something to a "to do" list for a universal debugger, it should
be able to transparently deal with the interface between different levels of
abstraction. :-) As well as all those other things.

Essentially, we need a debugger who is an entomologist. Or, to take it one
step further, we need a debugger that likes bugs and cherishes them. :-) And
at that point, it's not a debugger -- it's some kind of
scientist/engineer/artist/historian/librarian/etc. of bugs.

So, it's not your Papa's debugger. :-)

And, just to not get too AI-ish, the role of the human community in that
debugging process needs to be thought through in a joyful, healthy,
prosperous, and intrinsically/mutually secure way. :-)

So, if the (semantic) network is the computer, the (semantic) network is the
debugger? :-)
Post by Dirk Pranke
Also, re: running Chrome in VirtualBox, are you aware that the page
renderers are
already run in sandboxed execution environments? It's unclear how much
more protection
each page in a separate VM would really buy you.
Ah, but my point was that the "sandbox" doesn't protect you if the sandbox
is written in C++ and has a certain class of pointer or bounds check bug or
probably some other certain bugs... So, I was just putting up a "solution"
that addressed that, regardless of how impractical it might be at the
moment. :-)

I'm not sure it was part of the VanGogh environment but at the same time
there was a related effort there to partition Smalltalk images into
firewalled subsets (so, sort of like one VM could look like multiple VMs as
a kind of hypervisor?)

But, that security issue again moves across layers of abstraction
(HTML/JavaScript vs. the browser's implementation) so again we need a better
debugger to deal with that. :-)

John pointed out that debugging on a network would be different than
debugging locally, and I'll take that now a step further and say, debugging
across multiple different abstractions would be different than debugging
just one abstraction.

And that's all C++ is in a sense, a popular abstraction -- even when just
working in C++ with a debugger, do you have support for debugging whatever
abstractions you have built yourself on top of it and the way they interact?
Maybe you have a tiny bit of support in the sense that objects and classes
might sort of relate to your abstraction (the application) and you can kind
of trace through function calls that sort of reflect that abstraction. But
the debugger is not going to help with design flaws in your abstraction --
like, say, tracking cognitive load on the end user by young GUI the way it
might, say, tell you how much computer memory is in use by your application.

Although, I could ask, if, say, Microsoft's Silverlight (mentioned by John)
is written in C# with garbage collection and range checking (I don't know
what it is written in, but it might be?) maybe it is an example of a better
VM? Or the JVM might be pretty secure in that sense (if it is written in
Java at this point, I'm not sure how much is)? But even if those are good
solutions, they don't have the ubiquity of JavaScript in most people's lives
right now.

At what point does everyone agree to use a better VM (including whatever
comes out of FONC)? Is the fact that people don't agree on some simple
useful VM for the web (other than JavaScript) a big "social bug" we have?
And does it relate to commerce and competition (at least in the past)?

For example, Richard Stallman invented the GPL license after seeing
commercialism take out the open hacker culture at the MIT AI lab. So, is the
GPL an attempt by a hacker to patch a "bug" in our economy? :-)

I saw short-sighted commercial thinking take out Smalltalk as a player in
the open systems space (the
ParcPlace-Digitalk-ObjectShare-sold-to-Cincom-for-a-song fiasco that lead to
Green/Oak/Java as well as fifteen years of people struggling with a crippled
Squeak compared to what was available out of the box with VisualWorks), as I
mention here:
"Design Principles Behind Smalltalk, Revisited" (by me)

http://forum.world.st/Design-Principles-Behind-Smalltalk-Revisited-td58519.html
Of course, people or communities can overcome their crippling limitations in
various ways, and Pharo, for example, is a Squeak fork that is getting
better every day. And fifteen years later, the JVM is not that bad and is
finally free as in freedom, and, sadly, VisualWorks Smalltalk is just a
niche product instead of being the JavaScript of today.

So is it legitimate to say a broken socio-economic paradigm based around
scarcity thinking is the biggest bug in all our software (in a world where
everything computing touches become free or really cheap)? :-)

Otherwise, maybe we'd have the ObjectWorks VM everywhere with Van Gogh and
internal firewalls (and not JavaScript and an HTML DOM and XML and whatever
other junk we have now).
John Zabroski
2010-10-10 04:21:47 UTC
Permalink
Post by Dirk Pranke
On Fri, Oct 8, 2010 at 11:09 PM, Paul D. Fernhout
Post by Paul D. Fernhout
Yes, there are similarities, you are right. I'm not familiar in detail
because I have not used Chrome or looked at the code, but to my
understanding Chrome does each tab as a separate process. And typically
(not
Post by Paul D. Fernhout
being an expert on Chrome) that process would run a rendering engine (or
maybe not?), JavaScript (presumably?), and/or whatever downloaded plugins
are relevant to that page (certainly?).
Yes, each tab is roughly a separate process (real algorithm is more
complicated, as the wikipedia article says). rendering and JS are in
the same process, but plugins run in separate sandboxed processes.
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Most major browsers are doing a much better job making sure they understand
performance, how to evaluate it and how to improve it. C, C++, Objective-C,
it doesn't matter. The key is really domain-specific knowledge and knowing
what to tune for. You need a huge benchmark suite to understand what users
are actually doing.

Big advances in browsers are being had thanks to research into parallelizing
browser rendering. But there are a host of other bottlenecks, as
Microsoft's IE team pointed out. Ultimately when you are tuning at this
scale everything looks like a compiler design issue, not a C, C++,
Objective-C issue. These all just become high level assembly languages. A
garbage JavaScript engine in C is no good. A fast JavaScript engine in C
written with extensive performance tuning and benchmarks to ensure no
performance regressions is good.

Silverlight (managed runtime) blows away pretty much even hand-tuned
JavaScript apps like the ones Google writes, by the way... unfortunately it
uses no hardware accelerated rendering that I'm aware of. Current browser
vendors have version branches w/ hardware accelerated rendering that
parallelizes perfectly. Silverlight has its own problems, of course.
Dirk Pranke
2010-10-10 06:31:09 UTC
Permalink
Post by John Zabroski
Post by Dirk Pranke
On Fri, Oct 8, 2010 at 11:09 PM, Paul D. Fernhout
Post by Paul D. Fernhout
Yes, there are similarities, you are right. I'm not familiar in detail
because I have not used Chrome or looked at the code, but to my
understanding Chrome does each tab as a separate process. And typically (not
being an expert on Chrome) that process would run a rendering engine (or
maybe not?), JavaScript (presumably?), and/or whatever downloaded plugins
are relevant to that page (certainly?).
Yes, each tab is roughly a separate process (real algorithm is more
complicated, as the wikipedia article says). rendering and JS are in
the same process, but plugins run in separate sandboxed processes.
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of  C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Most major browsers are doing a much better job making sure they understand
performance, how to evaluate it and how to improve it.  C, C++, Objective-C,
it doesn't matter.  The key is really domain-specific knowledge and knowing
what to tune for.  You need a huge benchmark suite to understand what users
are actually doing.
Big advances in browsers are being had thanks to research into parallelizing
browser rendering.  But there are a host of other bottlenecks, as
Microsoft's IE team pointed out.  Ultimately when you are tuning at this
scale everything looks like a compiler design issue, not a C, C++,
Objective-C issue.  These all just become high level assembly languages.  A
garbage JavaScript engine in C is no good.  A fast JavaScript engine in C
written with extensive performance tuning and benchmarks to ensure no
performance regressions is good.
Silverlight (managed runtime) blows away pretty much even hand-tuned
JavaScript apps like the ones Google writes, by the way... unfortunately it
uses no hardware accelerated rendering that I'm aware of.  Current browser
vendors have version branches w/ hardware accelerated rendering that
parallelizes perfectly.  Silverlight has its own problems, of course.
True. There is a video floating around [1] with Lars Bak (team lead
for the V8 engine) talking to Erik Meijer about how JavaScript VMs
compare to the JVM and the CLR and how the latter two will always be
significantly faster due to the differences in language designs and
the optimizations they enable.

But there's always NativeClient (as someone else linked to) if you
need raw speed :)

-- Dirk

[1] http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine
Leo Richard Comerford
2010-10-10 13:01:55 UTC
Permalink
Post by Dirk Pranke
But there's always NativeClient (as someone else linked to) if you
need raw speed :)
-- Dirk
Not just Native Client: a Native Client app including a GUI toolkit.
(A toolkit which will soon be talking to an OpenGL-derived interface,
or is it already?) At this point you're almost ready to rip out most
of the surface area of the runtime interface presented by the browser
to the application running in each tab. You still need things similar
to (say) a HTML renderer, but you don't need the browser vendor's
choice of monolithic HTML renderer riveted into a fixed position in
every browser tab's runtime.

(That link again:
http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/#comment-7893
)
Post by Dirk Pranke
To be fair, Tim had the right idea with a Uri.
He also had a right idea with the Principle of Least Power. Thesis,
antithesis...

Leo.
Leo Richard Comerford
2010-10-10 14:55:30 UTC
Permalink
Post by Leo Richard Comerford
You still need things similar
to (say) a HTML renderer, but you don't need the browser vendor's
choice of monolithic HTML renderer riveted into a fixed position in
every browser tab's runtime.
Let me rephrase that a bit for clarity, to "Those applications still
need things similar to HTML renderers (and scripting languages), but
they don't need the browser vendor's choice of monolithic HTML
renderer riveted into a fixed position in their runtime"
John Zabroski
2010-10-15 15:52:44 UTC
Permalink
On Sun, Oct 10, 2010 at 9:01 AM, Leo Richard Comerford <
Post by Leo Richard Comerford
Post by John Zabroski
To be fair, Tim had the right idea with a Uri.
He also had a right idea with the Principle of Least Power. Thesis,
antithesis...
You're referring to [1], Tim Berners-Lee's Axioms of Web architecture.

This is such a shallow document and mixes basic principles up in horrible
ways, and he doesn't formalize things mathematically that need to be
formalized mathematically to truly understand them. He was NOT right. If
anything, this document sounds like he is parroting somebody else without
understanding it.

For example, his section on Tolerance is parroting The Robustness Principle,
which is generally considered to be Wrong. There is also a better way to
achieve Tolerance in an object-oriented system: Request-based Mediated
Execution or Feature-Oriented Programming where clients and servers
negotiate the feature set dynamically. His example of the HTML data format
is ridiculous and stupid, and doesn't make sense to a mathematician:
Allowing implicit conversions between documents written for HTML4 Strict and
HTML4 Transitional is just one of the many stupid ideas the W3C has had.

What about his strange assertion that SQL is Turing Complete? What is Tim
even saying? He also says Java is "unashamedly procedural" despite the
fact, as I quoted earlier in this thread, he admitted at JavaOne to not
knowing much about Java. Did he suddenly learn it within the year timespan
he wrote this letter from the time he gave that talk? I suppose that's
possible.

He also writes "Computer Science in the 1960s to 80s spent a lot of effort
making languages which were as powerful as possible. Nowadays we have to
appreciate the reasons for picking not the most powerful solution but the
least powerful. Nowadays we have to appreciate the reasons for picking not
the most powerful solution but the least powerful. The reason for this is
that the less powerful the language, the more you can do with the data
stored in that language." I don't think Tim actually understands the issues
at play here, judging by his complete non-understanding of what Turing-power
is (cf. SQL having Turing-power, ANSI SQL didn't even get transitive
closures until SQL-99). There is more to data abstraction that data
interchange formats. Even SQL expert CJ Date has said so: stuff like XML
simply solves a many-to-many versioning problem among data interchange
formats by standardizing on a single format, thus allowing higher-level
issues like semantics to override syntactic issues. This is basic compiler
design: Create a uniform IR (Intermediate Representation) and map things
into that IR. Tim's verbose explanations with technical inaccuracies only
confuse the issue.

Besides, as far as the Princilpe of Least Power goes, the best example he
could give is the one that Roy Fielding provides about the design of HTTP:
Hypermedia As The Engine of Application State.

If you want great Design Principles for the Web, read (a) M.A. Padlipsky's
book The Elements of Networking Style [2] (b) Radia Perlman's book
Interconnections [3] (c) Roy Fielding's Ph.d. Thesis [4]

Mike Padlipsky actually helped build the ARPANET and supposedly Dijkstra
gave Mike permission to use GOTO if he deemed it necessary in a networking
protocol implementation, Radia Perlman is considered as having written one
of the best dissertations on distributed systems, and Roy Fielding defined
the architectural style REST.

[1] http://www.w3.org/DesignIssues/Principles.html
[2]
http://www.amazon.com/Elements-Networking-Style-Animadversions-Intercomputer/dp/0595088791/
[3]
http://www.amazon.com/Interconnections-Bridges-Switches-Internetworking-Protocols/dp/0201634481/
[4] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Paul D. Fernhout
2010-10-19 12:04:40 UTC
Permalink
Post by John Zabroski
If you want great Design Principles for the Web, read (a) M.A. Padlipsky's
book The Elements of Networking Style [2] (b) Radia Perlman's book
Interconnections [3] (c) Roy Fielding's Ph.d. Thesis [4]
While not exactly about the web, I just saw this video yesterday (video link
is the "View Webinar" button to the right):
"Less is More: Redefining the “I” of the IDE (W-JAX Keynote)"
http://live.eclipse.org/node/676
"Not long ago the notion of a tool that hides more of the program than it
shows sounded crazy. To some it probably still does. But as Mylyn continues
its rapid adoption, hundreds of thousands of developers are already part of
the next big step in the evolution of the IDE. Tasks are more important than
files, focus is more important than features, and an explicit context is the
biggest productivity boost since code completion. This talk discusses how
Java, OSGi, Eclipse, Mylyn, and a combination of open source frameworks and
commercial extensions like Tasktop have enabled this transformation. It then
reviews lessons learned for the next generation of tool innovations, and
looks ahead at how we are redefining the “I” of the IDE."

But, the funny thing about that video is that it is, essentially about how
the Eclipse and Java communities have reinvented the Smalltalk-80 work
environment without admitting it or even recognizing it. :-)

Even "tasks" were represented in Smalltalk in the 1980s and 1990s as
"projects" able to enter worlds of windows (and to a lesser extent,
workspaces as a manual collection of related evaluable commands).

I have to admit things now are "bigger" and "better" in various ways
(including security sandboxing, the spread of these ideas to cheap hardware,
and what Mylyn does at the desktop level with the TaskTop extensions), so I
don't want to take that away from recent innovations or the presenter's
ongoing work. But it is all so surreal to someone who has been using
computers for about 30 years and knows about Smalltalk. :-)

By the way, on what Tim Berners-Lee may miss about network design?
"Meshworks, Hierarchies, and Interfaces" by Manuel De Landa
http://www.t0.or.at/delanda/meshwork.htm
"Indeed, one must resist the temptation to make hierarchies into villains
and meshworks into heroes, not only because, as I said, they are constantly
turning into one another, but because in real life we find only mixtures and
hybrids, and the properties of these cannot be established through theory
alone but demand concrete experimentation."

So, that interweaves with an idea like a principle of least power. Still, I
think Tim Berners-Lee makes a lot of good points. But how design patterns
combine in practice is a complex issue. :-) Manuel De Landa's point there is
so insightful though, because it says, sometimes, yes, there is some value
to a hierarchies or a standardizations, but that value interacts with the
value of meshworks in potentially unexpected ways that require experiment to
work through.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.

spir
2010-10-08 22:23:01 UTC
Permalink
On Fri, 8 Oct 2010 19:51:32 +0200
Post by Waldemar Kornewald
Hi,
On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout
Post by Paul D. Fernhout
The PataPata project (by me) attempted to bring some ideas for Squeak and
Self to Python about five years ago. A post mortem critique on it from four
 "PataPata critique: the good, the bad, the ugly"
 http://patapata.sourceforge.net/critique.html
In that critique you basically say that prototypes *maybe* aren't
better than classes, after all. On the other hand, it seems like most
problems with prototypes weren't related to prototypes per se, but the
(ugly?) implementation in Jython which isn't a real prototype-based
language. So, did you have a fundamental problem with prototypes or
was it more about your particular implementation?
I have played with the design (& half-way) of a toy prototyped-based language and ended thinking there is some semantic flaw in this paradigm. Namely, models we need to express in programs constantly hold the notions of "kinds" of similar elements. Which often are held in collections; collections and types play together in my sense. In other words, type is a fondamental modelling concept that should be a core feature of any language.
Indeed, there are many ways to realise it concretely. In my sense, the notion of prototype (at least in the sense of self or Io) is too weak and vague. For instance, cloning does not help much in practice: programmers constantly reinvent constructors, or even separated object creation and initialisation. Having such features is conceptually helpful, practically secure, but most importantly brings it as "common wealth" of the programming community (a decisive argument for builtin features, imo).
Conversely, class-based language miss the notion, freedom to create, of individual objects. forcing the programmer to create a class for a chess board is simply stupid for me, and worse: semantically wrong. This prevents the program to mirror the model.
Post by Waldemar Kornewald
Bye,
Waldemar
Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com
K. K. Subramaniam
2010-10-09 02:15:32 UTC
Permalink
Post by spir
I have played with the design (& half-way) of a toy prototyped-based
language and ended thinking there is some semantic flaw in this paradigm.
Namely, models we need to express in programs constantly hold the notions
of "kinds" of similar elements. Which often are held in collections;
collections and types play together in my sense. In other words, type is a
fondamental modelling concept that should be a core feature of any
language.
Type is an overkill for singletons. Why do we need to separate specification
from being? When you want to express the notion of a kind of elements, are you
just positing its existence or do you really want to work with such posits? Is
it just a notion or a substance?

Subbu
Casey Ransberger
2010-10-09 02:57:23 UTC
Permalink
I think "type" is a foundationaly bad idea. What matters is that the object in question can respond intelligently to the message you're passing it. Or at least, that's what I think right now, anyway. It seems like type specification (and as such, early binding) have a very limited real use in the domain of really-actually-for-real-and-seriously mission critical systems, like those that guide missiles or passenger planes.

In the large though, it really seems like specifying type is a lot of ceremonial overhead if what you need to say is really just some arguments to some function, or pass a message to some object.

It might help if you explained what you meant by type. If you're thinking of using "class" as type, I expect you'll fail. Asking for an object's class in any case where one is not employing reflection to implement a tool for programmers reduces the power of polymorphism in your program. It can be argued easily that you shouldn't have to worry about type: you should be able to expect that your method's argument is something which sensibly implements a protocol that includes the message you're sending it. If you're talking about primitive types, e.g. a hardware integer/word, or a string as a series of bytes, then I suppose the conversation is different, right? Because if we're talking about machine primitives, we really aren't talking about objects at all, are we?
Post by spir
On Fri, 8 Oct 2010 19:51:32 +0200
Post by Waldemar Kornewald
Hi,
On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout
Post by Paul D. Fernhout
The PataPata project (by me) attempted to bring some ideas for Squeak and
Self to Python about five years ago. A post mortem critique on it from four
"PataPata critique: the good, the bad, the ugly"
http://patapata.sourceforge.net/critique.html
In that critique you basically say that prototypes *maybe* aren't
better than classes, after all. On the other hand, it seems like most
problems with prototypes weren't related to prototypes per se, but the
(ugly?) implementation in Jython which isn't a real prototype-based
language. So, did you have a fundamental problem with prototypes or
was it more about your particular implementation?
I have played with the design (& half-way) of a toy prototyped-based language and ended thinking there is some semantic flaw in this paradigm. Namely, models we need to express in programs constantly hold the notions of "kinds" of similar elements. Which often are held in collections; collections and types play together in my sense. In other words, type is a fondamental modelling concept that should be a core feature of any language.
Indeed, there are many ways to realise it concretely. In my sense, the notion of prototype (at least in the sense of self or Io) is too weak and vague. For instance, cloning does not help much in practice: programmers constantly reinvent constructors, or even separated object creation and initialisation. Having such features is conceptually helpful, practically secure, but most importantly brings it as "common wealth" of the programming community (a decisive argument for builtin features, imo).
Conversely, class-based language miss the notion, freedom to create, of individual objects. forcing the programmer to create a class for a chess board is simply stupid for me, and worse: semantically wrong. This prevents the program to mirror the model.
Post by Waldemar Kornewald
Bye,
Waldemar
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Richard Karpinski
2010-10-09 03:42:02 UTC
Permalink
But wait. I think we need more complex types than are even allowed. When we
actually compute something on the back of an envelope, we have been taught
to carry all the units along explicitly, but when we set it up for a really
stupid computer to do it automatically, we are forbidden, almost always,
from even mentioning the units. This seems quite reckless to me.

Why does it seem that no one cares that there are vast flaws in virtually
every project?

Why is no one concerned, in the most modern development techniques, with
testing, step by step, what actually works with the people who have to use
the resulting system?

Why does the whole industry accept as normal that most large projects fail,
and even those said to have succeeded are filled with cruft that never gets
used?

Aside from W. Edwards Deming, Tom Gilb, Jef Raskin, and me, I guess
everybody thinks that as long as they get paid, everything is fine.

Richard

On Fri, Oct 8, 2010 at 7:57 PM, Casey Ransberger
Post by Casey Ransberger
I think "type" is a foundationaly bad idea. What matters is that the object
in question can respond intelligently to the message you're passing it. Or
at least, that's what I think right now, anyway. It seems like type
specification (and as such, early binding) have a very limited real use in
the domain of really-actually-for-real-and-seriously mission critical
systems, like those that guide missiles or passenger planes.
In the large though, it really seems like specifying type is a lot of
ceremonial overhead if what you need to say is really just some arguments to
some function, or pass a message to some object.
It might help if you explained what you meant by type. If you're thinking
of using "class" as type, I expect you'll fail. Asking for an object's class
in any case where one is not employing reflection to implement a tool for
programmers reduces the power of polymorphism in your program. It can be
argued easily that you shouldn't have to worry about type: you should be
able to expect that your method's argument is something which sensibly
implements a protocol that includes the message you're sending it. If you're
talking about primitive types, e.g. a hardware integer/word, or a string as
a series of bytes, then I suppose the conversation is different, right?
Because if we're talking about machine primitives, we really aren't talking
about objects at all, are we?
Post by spir
On Fri, 8 Oct 2010 19:51:32 +0200
Post by Waldemar Kornewald
Hi,
On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout
Post by Paul D. Fernhout
The PataPata project (by me) attempted to bring some ideas for Squeak
and
Post by spir
Post by Waldemar Kornewald
Post by Paul D. Fernhout
Self to Python about five years ago. A post mortem critique on it from
four
Post by spir
Post by Waldemar Kornewald
Post by Paul D. Fernhout
"PataPata critique: the good, the bad, the ugly"
http://patapata.sourceforge.net/critique.html
In that critique you basically say that prototypes *maybe* aren't
better than classes, after all. On the other hand, it seems like most
problems with prototypes weren't related to prototypes per se, but the
(ugly?) implementation in Jython which isn't a real prototype-based
language. So, did you have a fundamental problem with prototypes or
was it more about your particular implementation?
I have played with the design (& half-way) of a toy prototyped-based
language and ended thinking there is some semantic flaw in this paradigm.
Namely, models we need to express in programs constantly hold the notions of
"kinds" of similar elements. Which often are held in collections;
collections and types play together in my sense. In other words, type is a
fondamental modelling concept that should be a core feature of any language.
Post by spir
Indeed, there are many ways to realise it concretely. In my sense, the
notion of prototype (at least in the sense of self or Io) is too weak and
vague. For instance, cloning does not help much in practice: programmers
constantly reinvent constructors, or even separated object creation and
initialisation. Having such features is conceptually helpful, practically
secure, but most importantly brings it as "common wealth" of the programming
community (a decisive argument for builtin features, imo).
Post by spir
Conversely, class-based language miss the notion, freedom to create, of
individual objects. forcing the programmer to create a class for a chess
board is simply stupid for me, and worse: semantically wrong. This prevents
the program to mirror the model.
Post by spir
Post by Waldemar Kornewald
Bye,
Waldemar
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
--
Richard Karpinski, Nitpicker extraordinaire
148 Sequoia Circle,
Santa Rosa, CA 95401
Home: 707-546-6760
http://nitpicker.pbwiki.com/
http://CureCancerNow.WetPaint.com/<http://curecancernow.wetpaint.com/>
Mission: to bring known cancer cures to a clinic near you, soon.
Ryan Mitchley
2010-10-11 12:42:33 UTC
Permalink
It seems that a logic programming inspired take on types might be useful:
e.g. ForAll X such that X DoThis is defined, X DoThis

or maybe, ForAll X such that X HasMethodReturning Y and Y DoThis is
defined, Y DoThis

Or, how about, pattern matching on message reception? Allow "free
variables" in the method prototype so that inexact matching is possible?
Send a message to a field of objects, and all interpret the message as
it binds to their "receptors"...
Post by Casey Ransberger
I think "type" is a foundationaly bad idea. What matters is that the object in question can respond intelligently to the message you're passing it. Or at least, that's what I think right now, anyway. It seems like type specification (and as such, early binding) have a very limited real use in the domain of really-actually-for-real-and-seriously mission critical systems, like those that guide missiles or passenger planes.
Disclaimer: http://www.peralex.com/disclaimer.html
Steve Dekorte
2010-10-14 22:17:55 UTC
Permalink
Amen.
I think "type" is a foundationaly bad idea. What matters is that the object in question can respond intelligently to the message you're passing it... Asking for an object's class.... reduces the power of polymorphism in your program.
BGB
2010-10-14 23:41:09 UTC
Permalink
another idle thought:
in many traditional OO languages, classes/objects necessarily 'contain' the
methods (in terms of both their definition syntax and conceptualization).

what about being able to define operations "over" a class if need-be (sort
of like operator overloading, but with methods)?...

there are various ways this could be done in a language (depending on
existing syntax and semantics).

in my VM framework, similar is already done fairly regularly, and similar
notions already exist within many functional languages, as well, C# allows
something vaguely similar via partial classes, ...


also notable is that in the class/instance/interface model, there are
different ways to make use of the concept of an interface:
one is the more strict and traditional Java sense, where a class implements
an interface, and can be cast to said interface (the implementation will
throw an exception if the class doesn't implement the interface);

also possible is to retroactively bind an interface to a class, effectively
using the interface as a "window" into other aspects of the object, and
possibly stuffing new fields or methods into an existing class (the usual
term for this being "interface injection" in the JVM).

both are somewhat different ways of regarding interface, yet both are
generally treated as the same concept.


in my VM / framework, the latter is actually fairly easy and cheap, since I
don't actually use vtables to associate interface methods to classes: it is
actually done with a big hash table, where the (precomputed) class-hash and
method-hash are combined and used to look up the method in this big hash
table (in fact, the core OO machinery doesn't even really care whether or
not an object implements an interface, since it will work either way,
however a language may choose to verify that a class implements an
interface).

given both experience and benchmarks, I am not really even sure one needs to
bother with vtables for virtual-method dispatch, as it would allow a simpler
implementation just to use a big-ass hash table for all method dispatch
(although it would add a little cost over vtables + frozen object layouts
with dynamically-generated-thunks, but oh well...).

I have often used similar to implement prototype objects as well (just it is
hashing object and field/method, rather than class and field/method). the
class/instance OO system also supports prototype objects, partly reusing the
same mechanism as the interface mechanism, and also uses it to fake
multiple-inheritence as well (generally unused though, and does not
implement proper C++/Ada/... semantics).

(technically, fields can also work via interfaces...).


grr... I somewhat lost track of the original point...


----- Original Message -----
From: "Steve Dekorte" <***@dekorte.com>
To: "Fundamentals of New Computing" <***@vpri.org>
Sent: Thursday, October 14, 2010 3:17 PM
Subject: Re: [fonc] On inventing the computing microscope/telescope for
thedynamic semantic web



Amen.
Post by Casey Ransberger
I think "type" is a foundationaly bad idea. What matters is that the
object in question can respond intelligently to the message you're passing
it... Asking for an object's class.... reduces the power of polymorphism
in your program.
Loading...