NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/6978

Internet Message Format | 1996-08-05 | 3.9 KB

Path: pyrotek.demon.co.uk!jase
From: Jason G Doig <[e-mail]>
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Frustrated Jolyon (was Re: E - Just say NO! (was Re: Visual E - New E
Date: Sun, 07 Apr 1996 10:24:15 GMT
Message-ID: <[e-mail]>
References: <e> <[e-mail]> <[e-mail]> <4k7k0p$[e-mail]>
X-NNTP-Posting-Host: pyrotek.demon.co.uk
X-Newsreader: NewsAgent 1.4r3

[e-mail] (Chad Randall) wrote:
> Order of operations.  Yes, E is missing this.  And adding ()'s around
> everything is not only messy, but it can become confusing.  But I assume
> Wouter choose to do this to increase compiling time.  And if so, I'm all

Well, reading the manual, Wouter does tend to insist that things were
not done for compiler speed, but for 'very good reasons' (unspecified).
In any case, expression parsing is a piece of piss, and the first thing
anyone on a computing course is taught when it comes to the subject of
compilers.  To be honest, I think that a lot of the decisions /were/ made
for reasons of speed.  I can appreciate that he isn't going to change them
now, obviously that would just generate even more problems.  I just get
the impression that some of the 'design' features were done more because
he either wanted to be different, or to take the easy way out, than for
any good reason.

> for it.  I come from the school of interpreted languages, and I learned
> to write stuff in small steps, testing it every few minutes.  I know
> this is not the best way, but it is my way.

Nothing wrong with that, but to be honest for small programs (and
you do say you write modular code...), I don't notice much difference
between my C compiler, and E, except that my C compiler reports
all the errors it finds, rather than just the first one it comes
across - it also gives line numbers for unreferenced variables.  This
easily offsets the fast compile times for larger E sources.

> And I'd rather have to enclose things in ()'s than in {}'s and
> end every statement with a ';'    ;}

Actually, I quite like {}'s, as they give a nice consistent way of
showing program depth, and most editors have bracket matching,
which is damned useful.  This is much trickier in E (and of course,
Basic et-al).  I'm not going to condemn E for not having these though...

> Non-modularity???  What the hell is the "OPT MODULE" keyword for, then?
> I write modules, using small testing "main" code to debug it.  Then I
> plug it into my larger applications.  If this isn't modularity, then
> what the hell is?

Our main problem, is that all the modules are just that, E Modules.  If
they were proper linker object files, then we could link them with a
standard linker, and include other languages (there are times, despite
what Wouter would like to think, when we would like to be able to
link in say, 68020 assembly functions, or C functions).  E makes this
very difficult.  Also, E's linker tends to link entire module in, rather
than just the bits it needs.  With the current system we're stuck with
one large E program, and anything else we need to plug in getting put
into the library.

For example, for reading and image format (as Photogenics has to
do now and then), we can frequently get existing and free code
to read a format.  This is pretty much always in C.  Now if we
were to write the GIO stubs in E (I'm assuming E can actually
output libraries now, it couldn't when we started this), we would
need to convert large quantities of someone elses source to E.
Instead, we wrote the GIO template code in C and Assembler.  This
allows us to write functions in just about any language we want.
Except E...


Jase.

--
   -  - - --+-++*+*+**+*@*@@@*@*+**+*+*++-+-- - -  -
     Amiga/Mac/PC/Unix Programmer.    Amiga Owner.
  [e-mail] - NewsAgent, Photogenics.
      http://www.ucs.ed.ac.uk/~eofu31/jase.html
   -  - - --+-++*+*+**+*@*@@@*@*+**+*+*++-+-- - -  -