Hi,
Can we change the topic to "languages and systems" ?
:-) I consider language based POV not comparable
to systems based POV[*], it is better to think as
complementary abordages and not contrary...
[*] it is like comparing Smalltalk with Object
"Oriented" languages; imo it reveals not
deep understanding of Smalltalk.
For people that understand "sustainability" as the ability to
continue evolving, other tools are available and better
than languages.
The language is not as important as the actions made on
the system itself.
So I hear you talking about systems versus languages,
and that systems are more interesting because they
are unconstrained.
Systems point of view (POV) is complementary to
closed world POV defined by rules.
Systems includes the consideration of change in time
preserving identity (the very first attribute of anObject).
Working on systems make it possible to use reflexion (our
reflexion) on what we are DOING and our acts are
governed by seen what we all have done and
not only with our idea(ls) of future, or a reduction
to a simple and universal law to be instantiated "correctly"
by anUnknown entity of the future.
That seems compatible with what I understand Ian is
working on (building a basis for a system where every
limit can be changed at runtime). The work that I'm
trying to do is to allow multiple systems
to reside in the same CPU and address space.
Yes.
The main diference is related with the inclusion of
humans in the formulation (human as a been capable
to open the system, and a part that can perform true
reflexion without a model).
The languages come secondary, they each are just
a means to communicate with the system. But they are
necessary, for those of us who want a TTY interface
to the system (the 70s-era people like myself). Those
who want a graphical interface will want to wait for
(or help work on) something like the IDE that I saw
Takashi working on while I visited VPRI in June.
Those with a telephony interface will want....
Yes! each one must have a way to work.
Also people that not need written words to
consider that something exist.
Most people today are constrained/seduced to
think that the preexistence of a -written- model
is a must for a system.
I do not want to minimize the value of normal abordages
for new computing paradigms, I want to point that
systems abordages today are not related with computing
but with informatics, and it includes working in a
non-declarative way (e.g. also outside OO limitations)
The point is you are looking at the bootstrap, and though
you may find it repulsive, the ideal is not to make the
bootstrap prettier, it is to get to the point where you
too can contribute (i.e. there's a working "Smalltalk-80" application).
I have not said that it is repulsive for me.
I am only saying that booting (the big-bang) is not
related with sustainability of a system; and it is more
important IMO the activity that is realized to effectivelly
change a system and how we learn doing changes
while the system is "active".
On:
too can contribute (i.e. there's a working "Smalltalk-80" application).
There is no Smalltalk now, because it do nothing (do not run).
As I know there is only code...
The ADN of a system is not the system, it is simply
ONE way of writing a design of an idealized/reduced
system.
I think it is important to publish binary versions to let
people start from top and go to bottom if he/she needs
really to do (lower level?) changes.
I also think it is important to preserve history (e.g. do not
promote the idea that something new is been written
that can be written +40years ago, in a high-level-assembly
or low-level-basic, or aLanguage).
If we accept the fact that a Smaltalk can be changed
at any place, all the results possible with Smalltalk
will became a new... Smalltalk. The important point
here is the preservation of identity, and not the internal
composition (nor code). Smalltalk is not its contents.
We can try to define a language for all persons and
a law for all systems; or... we can try to work to modify
a systems that has booted +30years ago.
The tools for each work can´t be the same, because
the objetives and the methods are not the same.
The main difference I see with Smalltalk is that it (or
Squeak at least) uses a virtual machine, which is implemented
in C, and cannot be modified from the Smalltalk
portion of the code.
Yes (you are not talking about Smalltalk here).
The VM never was part of the Smalltalk.
If we put more objects inside the system,
we are not creating a new platform... the
identity of the system is preserved (the system
is sustainable and let us perform sostenible development).
But.. if you say that you boot a new system from scratch
with a law that was not written yet; you are promoting
that there is a creative process involved...
(not a bad POV if it do not hide that there are
other ways of thinking about it)
It is reasonable to consider taking a Squeak image,
running it on a COLA-implemented VM
that gives bytecode access to the COLA compiler,
and gradually evolving that image to something
that can take full advantage of COLA.
Yes! we need a binary release to start
(changing it while running).
If we did that, and still had a TTY interface to
the underlying COLA-based VM, would you still
say that the tools "can't be the same"?
Yes! history is on my side.
Never the tools was the same for all people.
Diversity is reflected on tools, and granted by people/minds;
puting people outside of the formula (it is only text
or only designed as objects) ensure exclusion and
promote one-way/"univesal" thinking (e.g. no inter-cultural
work can be realized this way).
Thanks for reading my email and for talking about
systems outside language limitations.
all the best for you too,
Ale.
----- Original Message -----
From: "Michael FIG" <[EMAIL PROTECTED]>
To: "Fundamentals of New Computing" <[email protected]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 25, 2008 8:33 PM
Subject: [fonc] languages vs. systems [was: Coding Standards]
Hi,
"Alejandro F. Reimondo" <[EMAIL PROTECTED]> writes:
For people that understand "sustainability" as the ability to
continue evolving, other tools are available and better
than languages.
The language is not as important as the actions made on
the system itself.
So I hear you talking about systems versus languages, and that systems
are more interesting because they are unconstrained.
That seems compatible with what I understand Ian is working on
(building a basis for a system where every limit can be changed at
runtime). The work that I'm trying to do is to allow multiple systems
to reside in the same CPU and address space.
The languages come secondary, they each are just a means to
communicate with the system. But they are necessary, for those of us
who want a TTY interface to the system (the 70s-era people like
myself). Those who want a graphical interface will want to wait for
(or help work on) something like the IDE that I saw Takashi working on
while I visited VPRI in June. Those with a telephony interface will
want....
The point is you are looking at the bootstrap, and though you may find
it repulsive, the ideal is not to make the bootstrap prettier, it is
to get to the point where you too can contribute (i.e. there's a
working "Smalltalk-80" application).
We can try to define a language for all persons and
a law for all systems; or... we can try to work to modify
a systems that has booted +30years ago.
The tools for each work can´t be the same, because
the objetives and the methods are not the same.
The main difference I see with Smalltalk is that it (or Squeak at
least) uses a virtual machine, which is implemented in C, and cannot
be modified from the Smalltalk portion of the code. It is reasonable
to consider taking a Squeak image, running it on a COLA-implemented VM
that gives bytecode access to the COLA compiler, and gradually
evolving that image to something that can take full advantage of COLA.
If we did that, and still had a TTY interface to the underlying
COLA-based VM, would you still say that the tools "can't be the same"?
All the best,
--
Michael FIG <[EMAIL PROTECTED]> //\
http://michael.fig.org/ \//
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
