On 13/06/2011, at 7:50 PM, BGB wrote:
> On 6/13/2011 1:33 AM, Julian Leviston wrote:
>> On 12/06/2011, at 1:00 PM, BGB wrote:
>>
>>> image-based systems have their own sets of drawbacks though...
>>>
>>> dynamic reload could be a "good enough" compromise IMO, if done well...
>> I don't follow this train of thought. Everything runs in "an image". That's
>> to say, the source code directly relates to some piece of running code in
>> the system at some point. Smalltalk, Self and the like simply let you
>> interact with the running code in the same place as the artefacts that
>> create the running code. It's akin to programming in a debugger that saves
>> the contents of memory constantly as "the source".
>
> except, that traditional source-files have a "concrete" representation as so
> many files, and, beyond these files, there is nothing really of relevance (at
> least, conceptually, a person could print a program to paper, re-type it
> somewhere else, and expect the result to work).
>
> does it rebuild from source? does the rebuilt program work on the target
> systems of interest? if so, then everything is good.
>
>
> an image based system, OTOH, often means having to drag around the image
> instead, which may include a bunch of "other stuff" beyond just the raw text
> of the program, and may couple the program and the particular development
> environment used to create it.
>
[SNIP]
>
> or such...
>
This brings up an interesting point for me.
"Source" is an interesting word, isn't it? :) Source of what, exactly?
Intention, right? The "real code" is surely the electricity inside the computer
in its various configurations which represent numbers in binary. This is not
textual streams, it's binary numbers. The representation is the interesting
thing.... as are the abstractions that we derive from them.
I don't think computer programs being represented as text is very appropriate,
useful or even interesting. in fact, I'd suffice to say that it's a definite
hate/love relationship. I *love* typography, text and typing, but this has
little or naught to do with programming. Programming is simply "done" in this
way by me at the moment, begrudgingly because I have nothing better yet.
Consider what it'd be like if we didn't represent code as text... and
represented it maybe as series of ideograms or icons (TileScript nod). Syntax
errors don't really crop up any more, do they? Given a slightly nicer User
Interface than tilescript, you could still type your code, (ie use the keyboard
to fast-select tokens), but the computer won't "validate" any input that isn't
in its "dictionary" of known possible syntactically correct items given
whatever context you're in.
By the way, SmallTalk and Self are perfectly representable in textual forms...
("file out" nod) just like JVM bytecode is perfectly representable in textual
form, or assembler... but text probably isn't the most useful way to interact
with these things... just as to "edit your text" you most likely use some form
of IDE (and yes, I'd class VIM or EMACS as an IDE).
Do I need to represent here just how idiotic I think compilation is as a
process? It's a series of text stream processors that aim at building an
artefact that has little or nothing to do with a world that exists entirely in
text. TEXT!!! It's a bad way to represent the internal world of computers, in
my opinion. It'd be nice to use a system which represents things a few layers
closer to "what's actually going on", and surely the FoNC project is aimed at a
pedagogical direction intending to strip away layers of cruft between the image
inside the head of a "user" ( or programmer) that they have representing how it
works, and how it actually works...
Mind you, I think human language is fairly silly, too... we communicate using
mental "bubbles" of non-language based patterns, rendered into language, formed
into text. It's well retarded... but this might be considered a little "out
there", so I'll end here.
If I'm providing too much "noise" for the list, please anyone, let me know, and
I'll be quiet.
Julian._______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
