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
