Result of I need your experience - classification and comparison of languages
Yvan Radenac
This is the results of the questions i asked few months ago as the
post
"I need your experience - classification and comparison"
The subject of the report is "oriented object languages and their free
implementation".
First, thank you for your answers.
You can find, in french, the report at
http://www.cnamoo.net/uv/b5/ftp/mini/radenac.pdf
But, if you are interesting in, i can post the sheets in english.
Regards,
Yvan
Fernando Pérez
> Hi,
> This is the results of the questions i asked few months ago as the
> post
> "I need your experience - classification and comparison"
> The subject of the report is "oriented object languages and their free
> implementation".
>
> First, thank you for your answers.
>
> You can find, in french, the report at
> http://www.cnamoo.net/uv/b5/ftp/mini/radenac.pdf
Hi,
I'd love to take a look at it, but you need to rebuild that pdf with
non-bitmapped fonts. Sorry but it just looks awful and it will give anyone a
headache in 5 minutes. It's not your fault, it's an annoying problem with
fonts when making pdf from latex.
Here's a piece of the man page for lyxport
(http://www-hep.colorado.edu/~fperez/lyxport/lyxport.html#fonts) on this
issue. If you used raw latex instead of lyx the same applies.
Fonts
Normally PDF documents made on Unix-type systems from LaTeX sources produce
horrible looking fonts when viewed with Adobe's own Acrobat Reader. I don't
know the many intricacies of the problem (you can search for the details on
your own). I'll simply list here the trick that has helped me solve the
font problem. Try it, your mileage may vary.
In your home directory, make (or modify it if it already exists) a file named
.dvipsrc which must contain the lines:
p+ psfonts.cmz
p+ psfonts.amz
Make sure that the LaTeX preamble of your LyX file (or the part before
\begin{document} if you are using straight LaTeX files) contains:
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl}
This will guarantee that T1 encoded fonts come out looking good in the final
PDF.
note
Paul Hewlett <pa...@cape.issi.co.za> tells me that: ``Selecting the 'pslatex'
fonts in Layout->Document->Fonts make the fonts in the resultant pdf document
eminently readable.'' Thanks for the tip.
Cheers,
f.
Jakub Travnik
[snip]
> You can find, in french, the report at
> http://www.cnamoo.net/uv/b5/ftp/mini/radenac.pdf
>
> But, if you are interesting in, i can post the sheets in english.
>
> Regards,
> Yvan
Hello,
I have looked at it even not speaking frances.
Why is Andy Hunt written in Ruby item on page
12(physical)/11(logical)?
I think Yukihiro Matsumoto aka Matz should be there.
Or is there a reason for Andy being there?
Jakub Travnik
jabber://jt...@jabber.com
Alwyn
yvan.r...@equant.com (Yvan Radenac) wrote:
> Hi,
> This is the results of the questions i asked few months ago as the
> post
> "I need your experience - classification and comparison"
> The subject of the report is "oriented object languages and their free
> implementation".
>
> First, thank you for your answers.
>
> You can find, in french, the report at
> http://www.cnamoo.net/uv/b5/ftp/mini/radenac.pdf
Many errors and lacunae in the section 'Historique', I'm afraid. For
instance, you say that Ada was invented by the American DoD. It comes in
fact from a team under the direction of Jean Ichbiah, working for the
French firm, CII Honeywell-Bull. And I thought Ruby was devised by a
certain Yukihiro Matsumoto. :-)
Alwyn
Yvan Radenac
Hi,
I'm right with you, but as i use a paper on the NET, i respect the copyright,
so the writer of this said that it's Andy Hunt...
But, if you read at page 37, you can find Yukihiro Matsumoto for the language Ruby.
I will write both of them for the historic.
Thank you for your attentive reading
Regards, Yvan
Yvan Radenac
Hi,
For the "Historique",
i used a paper on the NET which said that it was Andy Hunt. As i
respect the copyright, i let it as it. But i will add Yukihiro
Matsumoto as you can read page 37.
For Ada, it's not so simple. The DoD asked for a new language.
Bull+Honeywell won. But DoD chose this language, with it's own
criterias to select it.
On my own, it's not false, and not really right too. I will complete
this.
Thank you for your attentive reading.
Regards,
Yvan
Alwyn
> Alwyn <al...@alwyn.demon.co.uk> wrote in message news:<alwyn-014BC5.
>> In article <b9660815.02050...@posting.google.com>,
>> yvan.r...@equant.com (Yvan Radenac) wrote:
>>
>> > Hi,
>> > This is the results of the questions i asked few months ago as the
>> > post
>> > "I need your experience - classification and comparison"
>> > The subject of the report is "oriented object languages and their
>> > free implementation". First, thank you for your answers. You can
>> > find, in french, the report at http://www.cnamoo.net/uv/b5/ftp/mini/
>> > radenac.pdf
>>
>> Many errors and lacunae in the section 'Historique', I'm afraid. For
>> instance, you say that Ada was invented by the American DoD. It comes
>> in fact from a team under the direction of Jean Ichbiah, working for
>> the French firm, CII Honeywell-Bull. And I thought Ruby was devised
>> by a certain Yukihiro Matsumoto. :-) Alwyn
>
>
> Hi,
> For the "Historique",
> i used a paper on the NET which said that it was Andy Hunt. As i
> respect the copyright, i let it as it. But i will add Yukihiro
> Matsumoto as you can read page 37.
M. Sureau has no entry for Ruby in his 'Histoire'. He has only this to
say:
'Il existe cependant une tendance à la modernisation avec des langages
de script comme Python , Ruby. NetRexx. Seul Python avec plusieurs
centaines de milliers d'utilisateurs, à [sic] une diffusion notable.'
http://www.scriptol.org/fr/index.php
Overall, I do not find this a reliable source of information on the
history of programming languages, and it is remarkable that this French
source pays so little attention to developments at INRIA (<http://www.
irnia.fr/>) and by the Frenchman, Bertrand Meyer (<http://www.eiffel.
com>). I think you need to do some more research of your own in this
area rather than rely on a sigle source.
Alwyn
Ian Parker
Radenac <yvan.r...@equant.com> writes
It looks interesting (and even the fonts look OK). I'd enjoy reading it
in English.
Regards
--
Ian Parker
Yvan Radenac
You can find an updated report, with your corrections, at
http://perso.wanadoo.fr/yvan.radenac/informatique/cnam/genie-log/projetb5.pdf
The another URL will be updated.
Thank you for your reading.
Regards,
Yvan
Gabriel Moreau
use covariance (not safe) and Sather contravariance (safe).
One really nice features in Sather is Iterator you don't find in any
other languages. You can find iterator in Ruby but they are not as nice
as in Sather. Iterator are a very safe features because loop are clean
and many bug comes from loop.
gaby
Alex Martelli
> I don't understand why Effeil is more safe than Sather because Effeil
> use covariance (not safe) and Sather contravariance (safe).
Sather is indeed safer, although covariance (admittedly unsafe!) is
sometimes quite handy indeed.
> One really nice features in Sather is Iterator you don't find in any
> other languages. You can find iterator in Ruby but they are not as nice
> as in Sather. Iterator are a very safe features because loop are clean
> and many bug comes from loop.
Sather iterators are indeed awesome and I highly recommend everybody
to study them, see:
http://www.icsi.berkeley.edu/~sather/Publications/toplas.html
Ruby's iterators are Smalltalk-like and thus "inside-out" with
respect to Sather's. The paper you can download from the above
URL presents a fair comparison (since Ruby's iterators are basically
what the paper calls closures/blocks) and, I think, shows the
superiority of Sather's approach. Traversing more than one
structure at a time is easy for Sather, not for Ruby.
Python's iterators are far closer to Sather's -- some minor details,
such as the fact that to get the next item from a Python iterator
you call .next() on it (or use it in the headclause of a for
statement), while a Sather iterator gives its next value whenever
you use it within a loop statement, are little more than syntax
sugar (Sather's sugar is nicer, Python's way simpler to retrofit
into an existing language;-).
Sather's iterators are _way_ more powerful than Python's because
Sather's can accept both "hot" arguments (evaluated anew each time
the iterator is called) and "once" ones (evaluated only at the first
call on the iterator). The flip side of this is a sentence in
Sather's paper that's a fair assessment: [Sather] "iterators are a
powerful construct and it is possible to write obscure and hard to
understand code using them". Python's are less powerful, but they
don't really present any mystery nor are they particularly prone to
producing obscure and hard to understand code.
All in all, if a totally new language was being designed I think
I'd go for something closer to Sather's iterators rather than
Python's, but its a delicate judgment -- the tradeoff between
maximal power and potential elegance vs potential obscurity and
lack of clarity is a crucial and difficult one. GvR, Python's
architect, has a great track record in getting most such tradeoffs
"just about right" (even though in the case of iterators and
generators he was of course constrained by backwards compatibility,
since they were being retrofitted into an existing language!).
Alex
Terry Reedy
only go to c.l.p and not c.l.r or c.l.s. Please let me know if
otherwise.)
"Alex Martelli" <al...@aleax.it> wrote in message
news:lOKD8.34859$CN3.1...@news2.tin.it...
> Sather iterators are indeed awesome and I highly recommend everybody
> to study them, see:
> http://www.icsi.berkeley.edu/~sather/Publications/toplas.html
I found this interesting and useful for better understanding iteration
both in Python and elsewhere. But I am slightly less impressed with
the Sather alternative. As a result of having 'loop...end' as the
only loop construct, Sather generalizes 'iterator' to 'something that
controls looping' from 'something that sequentially accesses
collection items -- which may
control looping as a side-effect'. Sather combine two ideas that I
think are better kept somewhat separate: loop control and sequential
presentation of implicit or explicit set/container contents. A Sather
iterator yields nothing (not even None) for pure loop control (to go
on), something for at least implicit sequencing, or quits (equivalent
to raise StopIteration in Python). Hence, every class inherits the
control iterators while!(), until!(), and break! even though they have
nothing in particular to do with the class and its values. I find
this to be as much confusing as elegant.
However, Sather's generalization does suggest a *possible* proprosal
for Python: make an otherwise uncaught StopIteration consistently do
what it says within for and while loop bodies as as well as in
for-loop headers. IE, implicitly wrap loop bodies with
try: <body>
except StopIteration: break
In particular,
item = iterator.next()
would (if not otherwise wrapped with try) act like
try: item = iterator.next()
except StopIteration: break
as it implicitly does now in for headers. This would also allow (for
better or worse)
def until(val):
if val: raise StopIteration
while 1:
<do stuff>
until(condition)
<do more stuff>
which should mostly end requests for a do-while or until statement.
Counterargument: does not add functionality; explicit better than
implicit except in bounded context such as for loop head.
> Traversing more than one structure at a time is easy for Sather,
not for Ruby.
Python, of course, has map and zip and proposals (accepted yet?) for
lazy, iterator/generator oriented versions.
> Python's iterators are far closer to Sather's -- some minor details,
> such as the fact that to get the next item from a Python iterator
> you call .next() on it (or use it in the headclause of a for
> statement), while a Sather iterator gives its next value whenever
> you use it within a loop statement, are little more than syntax
> sugar (Sather's sugar is nicer, Python's way simpler to retrofit
> into an existing language;-).
Some editors could convert '!' to '.next()'. One would just have to
be careful in comments and strings ;<), unless the editor was also
code/comment/string-literal aware.
> Sather's iterators are _way_ more powerful than Python's because
> Sather's can accept both "hot" arguments (evaluated anew each time
> the iterator is called) and "once" ones (evaluated only at the first
> call on the iterator).
Python generators can be called with mutable arguments, can they not?
This is somewhat analogous to using mutable defaults and even 'hotter'
(more bug and confusion prone) since arg mutations are not confined to
the body of the function or even calls thereto.
Without discipline, this is a poor way to write a consumer iterator.
Reduce() is Python's generic consumer iterator. Python's slice
setting generalizes Sather's set!() and it therefore arguably better
even though a special syntax is needed. Any class can be given
whatever iterator-like consumer methods one wants to write.
I see four main differences between a consumer function and a (Sather)
consumer iterator:
1. The iterator is called n times instead of once (bad) but the
function may make n calls if it gets an producer iterator rather than
an explicit sequence (then even).
2. The iterator returns n results (n-1 partial) instead of just the
final one (bad unless they are actually wanted, in which case the
function can return a list).
3. The iterator can yield and resume anywhere in the body text, though
the example given yields as the bottom. However, a function can just
as easily grab the next item via indexing or .next() call anywhere it
pleases, as needed. Seems pretty even to me.
4. The iterator maintains state in local variables between calls while
a function written to act as an iterator has to either use global
variables (slower and subject to clashes with other processes), use
instance variables (slower but probably the default best choice,
though still subject to clash with other methods of the same
instance), or stash and retrieve local variables in instance variables
(slower and cumbersome, so should be limited to variables used
repeatedly in internal loops; but such may not be needed in functions
meant to be called repeatedly with one item at a time). This is a win
for Sather's generalization of yield.
>All in all, if a totally new language was being designed I think
>I'd go for something closer to Sather's iterators rather than
>Python's, but its a delicate judgment ...
Each fit into their language. Sather mostly lies between S-expression
Lisp and Python in terms of syntactic uniformity/diversity. Both
uniformity and variety have advantages as others have discussed. If a
language has non-function statement syntax like 'loop ... end' and 'if
... then ...', then I prefer that control items like while, until, and
break be part of that statement syntax. I (and others) see while as a
multiple-execution version of if. On the other hand, resumable
consumers are in general as sensible as resumable producers. It is
Python's for-loops which make the latter more special for Python.
Terry J. Reedy
Alex Martelli
...
>> Traversing more than one structure at a time is easy for Sather,
> not for Ruby.
>
> Python, of course, has map and zip and proposals (accepted yet?) for
> lazy, iterator/generator oriented versions.
Not accepted yet, but explicit calls to .next() will allow multiple
traversals more flexibly, anyway:-).
>> Sather's iterators are _way_ more powerful than Python's because
>> Sather's can accept both "hot" arguments (evaluated anew each time
>> the iterator is called) and "once" ones (evaluated only at the first
>> call on the iterator).
>
> Python generators can be called with mutable arguments, can they not?
This has little to do with the power of "hot arguments" to Sather
iterators, which are simply general expressions evaluated afresh each
time the iterator is called, while a "once argument" is evaluated at
the first call to the iterator within a given loop statement.
> uniformity and variety have advantages as others have discussed. If a
> language has non-function statement syntax like 'loop ... end' and 'if
> ... then ...', then I prefer that control items like while, until, and
> break be part of that statement syntax. I (and others) see while as a
> multiple-execution version of if. On the other hand, resumable
This is our most substantial disagreement -- I consider the unification
of ALL loop control structures into one overarching concept to be the
main contribution of Sather to innovation in programming languages. No
reason to have all sort of different syntax when ONE syntax and one
Big Idea does it all (and more) even better. Sure, you COULD express
"loop if!(condition) ... end" (although the semantics of this very
hypothetical "if!" iterator would have to be 'bundled'). But the
parallel between while and if is quite imperfect in most languages,
anyway. Python does have while/else, but it stretches things a bit
to consider its semantics "a multiple-execution version" of those of
if/else -- and no while/elwhile/elwhile/else parallel to if/elif/elif/else
is on offer anyway. Should it? I don't think so. Sather's loop/end
and iterators is a just much nicer way to generalize loops, and I don't
think it makes sense to reject it based on a hypothetical parallelism
between while and if that doesn't hold anyway!
Alex
Terry Reedy
> Terry Reedy wrote:
> > Python generators can be called with mutable arguments, can they
not?
>
> This has little to do with the power of "hot arguments" to Sather
> iterators, which are simply general expressions evaluated afresh
each
> time the iterator is called, while a "once argument" is evaluated at
> the first call to the iterator within a given loop statement.
The point I was making is that one *could* pass fresh values to a
generator at every iteration via a list or dict and have the same
effect as the Sather method. I don't recommend this, but I also think
it is at least a bit wierd to have function calls that don't do what
they look like they are doing and which might do something different
after the first call. If I understand correctly, in the Sather
version of the following:
from somewhere import it
a = b = 1
while 1:
f(it(a,b))
a = a+1
b = b+2
one cannot tell from looking at the above whether either of the last
two lines has any affect. Depending of the parameter-list definition
in the it() source, it(a,b) could mean any of it(1,1), it(1,b),
it(a,1), or it(a,b).
...
>This is our most substantial disagreement
Yes
> -- I consider the unification
>of ALL loop control structures into one overarching concept to be the
>main contribution of Sather to innovation in programming languages.
It is a matter of where you draw the line between what to unify and
what to treat differently. In this case, the question is whether
'iterative flow-control' should be unified with 'alternative
flow-control' or 'iterative collection-access'.
> No reason to have all sort of different syntax when ONE syntax and
one
>Big Idea does it all (and more) even better
Which is why some people like Lisp. On the other hand, some people
prefer mixing operator expressions, function calls, and statements,
even if they do understand the unifying Big Idea of function
composition.
> But the parallel between while and if is quite imperfect in most
languages,
...
> I don't think it makes sense to reject it based on a hypothetical
parallelism
> between while and if that doesn't hold anyway!
'while condition: block' is syntactic sugar for ':label: if condition:
block; goto label'.
My view was partly formed by Dijkstra's guarded command notation as
used, for instance, in The Science of Programming by David Gries. He
used two flow control commands: one for alternation and one for
iteration. With '[] condition->block' changed to its Pythonic form,
they are:
if
condition1: block1
condition2: block2
...
conditionn: blockn
fi
do
condition1: block1
condition2: block2
...
conditionn: blockn
od
The difference for 'do' is the addition of an implicit 'goto enclosing
do' at the end of each block.
Terry J. Reedy