1. About Euphoria, from a newcomer
My first language was ALGOL 60, learnt in... 1974 (time flies). The
second
was Simula 67, which I discovered three years later. Then (it must have
been around 1980) I had to learn a strange dialect of BASIC, because
that was what my first personal computer came with (a Kaypro II, with a
Z80 CPU, running CPM, a gigantic 64K of RAM, two floppy drives. No hard
disk of course). That BASIC was so full of bugs that I spent $180 on a
C compiler (BDS-C). Soon after, a American colleague gave me a copy of
Turbo Pascal, and that was so good that I bought a legit copy, and stuck
with Turbo Pascal ever since, however much I missed the features of
Simula. I could do more in an hour on my Kaypro II with Turbo Pascal
than I could in a day on the University's DEC KL-10 in Simula 67. So I
had to give up Simula, reluctantly. Forays into C++, Forth, Modula, even
Ada, did not sway me. Delphi put me right off. I was eyeing Oberon when
I discoverd Euphoria late last year (I forgot how and where).
It was the absence of the infamous Borland 64K limit and the automatic
garbage collections that had caught my eye.
I ran the benchmarks. With some, Euphoria was as fast as Borland Pascal,
with others, it was seven times as slow. But hey, I had just replaced my
aging 486DX50 with an AMD K6-200, so anything I wrote in Euphoria would
run about as fast as on my 486. Nevertheless, I held back. Old habits
die hard, and when you have been programming in Turbo Pascal for
eighteen
years... Coming from ALGOL and Simula, it had taken me a short afternoon
to start programming in Turbo Pascal, so good the old manual was. No
such luck in Euphoria. Admittedly, and I know that because I have been
into human factors for years, a good manual is the most difficult thing
to write, so I am not bitching about that.
Eventually, last week, I took the plunge. It took me two full days. I/O
was bad, but I/O is *always* the big problem. As for the rest, it was
easy, just a matter of forming the right habits. Compared with C,
Pascal, or BASIC, Euphoria *is* strange, all the more so that the
strangeness is hidden under a familiar-looking syntax.
No pointers? I don't believe it. I suspect that Euphoria is *all*
pointers. Except perhaps constants (and even so, I wonder: could they
be read-only variables?). Now for what I like.
Being warned of uninitialized variables. What a marvellous bug killer!
ALGOL and Simula intialize variables to zero on entering a block. Not
bad, but this is better. When I think that the luminaries at Borland
never thought of implement such a simple feature in their Pascal or C,
it makes me wonder.
No BEGIN ... END (or {...} for you C writers), but instead if...end if,
while...end while, for...end for, etc. First, this eschews the need for
a
special syntax for compound statements. Second, matching an "end" is so
much easier: you know what to look for, "if", "for", "while",
"procedure", "function". In Pascal and C you have to wade backwards
for the matching BEGIN or {, and woe unto you if you have made a mistake
indenting your code!
In C and Pascal statements are terminated or separated by
semicolons. In Euphoria, there is no need for such delimiters, because
it is the very syntax of the statements that tells their limits.
Brilliant.
I have often caught myself swearing at the need for those semicolons
when moving statements about. "There has to be a &^%$#! better way!".
Yes, there had to be, Euphoria has it.
The include files (*.e). Much cleaner, and require much less typing
than, say, the Turbo Pascal units.
Finally, this, about which I am in two minds.
Arguments to functions and procedures can only be passed by value. That,
to me, is the strangest feature of Euphoria. Totally unexpected, and it
took me a few minutes to recover. It is strange. The use of procedures
would thus be limited to output...? I don't mind, but it is strange.
I would expect to be able to output to a sequence as well, in place of
a file (or the screen). But then, you will rightly object, that is done
by using a function returning a sequence (e.g. append). In a picky mood,
I'll say, "all right, a file is a sequence too, so, logically:
myfile = append(myfile,someStuff)"
I know, I know, I/O is the Achilles' heel of computing. So ignore this
last
paragraph, I was only thinking aloud to myself.
More later perhaps
2. Re: About Euphoria, from a newcomer
Ralf Nieuwenhuijsen wrote:
> Euphoria does not cheat with a garbage collector [...]
Oh yes, I quite realized that!
[about learning Euphoria]
> Ai, I never had a problem with it, but then again, I learned most
> Euphoria by experience.
Same here, and I am still learning. I was only making the point that
many may be put off by the lack of an easy "entry" to Euphoria. Which
is a pity.
> Maybe using a specialized company for the documentation would help ?
Well, I had been toying with the idea of writing one myself, but I am
worried about the matter of copyright. It would be good to publish it
with the public domain version of Euphoria on a diskette (or a CD), but
where would that put me legally? BTW, I am quite good at writing, and I
did teach programming in Simula for rank beginners when I was with
the Australian National University, long ago. I still have the lecture
notes, complete with the cartoons.
> >No pointers? I don't believe it. I suspect that Euphoria is *all*
> >pointers.
> Pointers give some responsibility and power to the programmer.
> It is mostly used in languages not capable of taking the responsibility
> themselves. (C, Pascal, etc.)
Exactly! Not that they are not capable, just that they were not
implemented
properly. Simula, for instance, takes responsibility for pointers, and
it is
quite similar to Pascal, being a superset of ALGOL 60.
> >Arguments to functions and procedures can only be passed by value. That,
> >to me, is the strangest feature of Euphoria. [...]
> Ever programmed OOP ?
> It would make it sound less weird.
> Now, Euphoria has the same benefits of OOP without the need of the
> abstract OOP model.
Tsk, tsk, tsk... I started programming with objects in 1977, when I
discovered
Simula! No way eschewing objects: the whole I/O is object-oriented, and
so
is string-handling. Being a linguist, and using computers for language
handling, I *had* to jump into OOP right from the beginning.
> >I'll say, "all right, a file is a sequence too, so, logically:
> > myfile = append(myfile,someStuff)"
> Well, Robert, it is not a bad suggestion.
No, please, don't take it up yet. It would likely confuse current
users of Euphoria. Note that, if this suggestion was implemented
(or something similar), there would be no need for procedures at
all in Euphoria. Me, ignorant of computer science as I am, I just
can't imagine the implications.
> Opening a file as an object, where you can give a shape. (1D sequence,
> 2D sequence or even a whole type definition)
> I was thinking that I wanted the possibilitie of using File I/O on
> sequences (the other way around), so that I could use some routines and
> store their output in a sequence. (Or have them get their input from a
> sequence)
There is a computer language which does not distinguish between files
and
arrays: Comskee. It was designed in Germany for machine translation. I
saw
it at work in Saarbruecken University in the early 80's, where it was
used
in a machine translator translating from French into German. And a very
impressive translator it was too. Comskee is a superset of ALGOL. It ran
on
a Siemens mainframe. I still have, somewhere in my mess of books, a
Comskee
manual. I remember that it took one of their students (who knew nothing
of
computer programming) one week to learn Comskee and write a program that
parsed Latin verbs. Not bad!
> Any1 got a more detailed suggestion or idea of a better file I/O
> interface (to make up for the stupid MS-Dos like interface) ?
Well, I don't, only general ideas. The screen, for instance, is two
2-dimensional arrays: one for the characters, one for their attributes.
(A 3-dimensional array, if you prefer)
A file, as handled with conventional I/O, is a one-dimensional array.
But logically, it is n-dimensional. For instance, I wrote a dictionary
maker, with each word with its frequency (just like the demo of a
binary tree, but not using a binary tree). That is a 2-dimensional array
of course. Logically, the file should be accessible like the array:
fq=dic[n][FREQ]
But where that leads, I don't know. (I really must find that book on
Comskee)
Enough rantings. My apologies.
