Kazimir,
Thanks for that. I do not know whether that was in any way an answer to
the bit that I recently wrote to the list, but it certainly does
effectively answer
some of my points and questions about Unicon. I purchased the Unicon book,
plus the IO book, and have downloaded and played with the Unicon language
a bit, but I am much more interested in examining the class of problems
addressed by a language and it's potential for further extension. The
article to
which you pointed did a better job of examining that issue than almost
anything
that I have seen written about Unicon itself.
What the article calls "declarative", I would call intentional
programming or
programming by intent, which I believe to be a dream not fulfillable on
this planet.
What I do find amusing in that, and every other description of any language
by those who have written it, is the description of what is "natural",
especially
to the non-programmer. Having started as a IBM 360/370 Assembler language
programmer, along with COBOL, ForTran, a bit AlgoL, and oddly, a bit of
LisP back in the late 60's, I know what it is to be precisely
"imperative". I do
not believe that one can be more positively "imperative" than machine or
assembler
language, other than by physically or logically altering the machine
itself, a level
to which we only vaguely aspire at the moment(though there are many
efforts about).
Progressively, I have examined many dozens of languages, using a few
extensively,
and discarding most as hopelessly flawed. One of the most effective was the
earliest version of PanSophic's EzyTreve that had no labels and
therefore no GOTO of
any variety. It had one conditional construct...If-Then-Else, and a
variable description
scheme that was somewhere between the offsets of Assembler and the data
structures of COBOL. If one could construct the logic of the program in
one's head,
programs were amazingly small and extremely fast with almost all IO
handled and
optimized by the language. All this ran in an IBM mainframe DOS 27
environment
on 360 Model 40's and 50's. That was in the 1974 time frame. Within the
limits of the
program, I could construct reports and fixes in minutes that literally
took months
for our COBOL programmers, not that they were very good programmers. The
problem with EzyTreve was that if you could not see the whole structure
of the
program, you really could not write it at all. Modularity wasn't even a
thought.
Converge seems to be an attempt to use some of the power of Unicon in a
more
generalized structure, as the article indicates, somewhat leaning
towards intent or
declaration. Having read the article, however, gives me many ideas on
how to more
effectively and correctly use Unicon, so it serves more than one
purpose. It is to be
wondered whether Converge will ever actually mature into a
well-supported language.
It has been my experience that languages dependent on non-native
compilers, interpreters,
etc., as their base have limited lifetimes, if only because the base
usually limitis the growth
and maturation of target language. The one exception to that rule
appears to be using
C as a base, as it is sufficiently primitive and thoroughly enough
characterized to make
it a base that does not too strongly limit the product, though that
issue itself has often
intrigued me. If those who create a language must always be extreme
experts in any
other language, what does that say for their ability to follow paradigms
that strongly
differ from the base. How do we escape the implicit limits of our base.
As we gain access
to assets such as quantum processors, or dynamic embedded logic
processing, how will
we make sense of them as imperative programming constructs without
wasting most of
their power.
Everett L.(Rett) Williams
[EMAIL PROTECTED]
Majorinc, Kazimir wrote:
There was one extra blank in that link. This is better
http://tratt.net/laurie/research/publications/papers/tratt03converge.pdf
At 17:55 2. 11. 2003., Majorinc, Kazimir wrote:
Check:
tratt.net/laurie/research/publications/ papers/tratt03converge.pdf
Kazimir Majorinc, Zagreb, Croatia
Kazimir Majorinc, Zagreb, Croatia
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
