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

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

Path: fwi.uva.nl!not-for-mail
From: [e-mail] (Wouter van Oortmerssen)
Newsgroups: comp.sys.amiga.programmer
Subject: Jolyon on E (was Re: Frustrated Jolyon (was Re: E - Just say NO! (was Re: Visual
Date: 9 Apr 1996 18:24:32 +0200
Organization: FWI, University of Amsterdam
Distribution: world
Message-ID: <4ke300$[e-mail]>
NNTP-Posting-Host: carol.fwi.uva.nl


Jolyon Ralph ([e-mail]) wrote:
-> I've discussed many problems (or rather things I don't like) with E in

Aha. Now tell me then, do things that are personal preference on your part
make something unfit for general serious use by anyone, regardless?

-> this thread, rather than personal abuse why don't you try and answer

Well, my apologies for passing the "flame mode" treshold so soon.  But your
comments originating from before my "flame" weren't exactly objective unbiased
reasonings either.  Notice also that of course E is also more "personal" to me
than it is to, say, you :)

-> them, saying either why you prefer the way E does it or give an
-> approximate date for fixing the problem.

Yeah right. Like I haven't done that a thousand times already.

-> I hope we can discuss the benefits/problems of your language without

I put it rather childishly, but I still feel it was not without truth, from
impressions you have given me in the past.  I could easily be wrong though.

-> resorting to personal abuse.... (I also happen to be very good with
-> hammers, as people who know me will tell you :-)

Well, good for you! :)

-> E is by no means a *bad* language. I would much rather people were
-> writing applications in E than in Amos or Blitz Basic. But from my

Oooh, now there's a scary choice.

-> personal experience (of 18 months E coding now) I can tell you that
-> maintaining large projects *is* a nightmare with the current version of
-> E. That's nothing to do with the language syntax or anything else, it's a
-> combination of factors (the way the compiler returns only one error a
-> time, the almost meaningless list of unused variables/functions, the
-> non-standard includes, etc..)

You are maintaining a large E project without utilizing E's module
system, which is not the way it was meant to be used. Not surprisingly
smaller problems start to weight heavier, and have little to do with
real large scale programming features.

I put quite a bit of thought into the E module system (and datahiding),
and as people that actually use it will be able to tell you it's
quite marvelous compared to C/C++

The one-error thing is indeed one of the bigger design errors in EC,
and like some other features too much targeted at myself as a user
(I only get errors from EC each tenth run or so).

-> And you're right, there's no reason anyone can't make professional
-> applications with it (we have, remember!), it's just I was hoping to save
-> a few people the days and days of hair-pulling we've had to suffer due to

That's because of your fixed C perspective. remember? I bet you'd be
bald by the time you tried several other languages ;)

-> the way that E works. But I was saying, in *my* opinion, anyone starting
-> programming the Amiga now would be better starting with C (a language
-> that will be of extreme use on whatever platform they end up writing for
-> in years to come) rather than E. I don't think C is any more dificult to
-> learn than E.

Geesh. I beg to differ. I think it's quite a bit easier, thanks to its
logical structure (it's there, look real hard! :).

Programming is not about C or E, and any skilled programmer will be able to
use C on another platform, E programmers will only have a superficial and
temporal disadvantage (heck, they might even have an advantage on other
accounts :).

-> Actually, the one big problem I have with E is it can't produce a
-> linkable object file. As soon as E can do that it will be much easier to
-> maintain. Any plans for that? It maybe if we can produce linkable code
-> from E that we won't need to rewrite *everything* in C.

Aaargh, the biggest FAQ ever.
On a conceptual level E doesn't work with .o/.h files because modules are
considered infinitly better.  but that's not what you wanted to hear.  On an
implementation level, E code relies on many things in it's startup code,
moreso than C (think of anything from trivial things like exception handling
to rather involved things like garbage collection).  So generating "just" a .o
file which will plug into SAS/C generated exe isn't going to work.  Infact,
have you ever tried generating an executable with .o's generated by every
amiga C/C++ compiler, for non-trivial code?  And I suppose you have been
equally succesful in integrating code from all those other languages on the
Amiga.

It can be done of course, but it involves hairy things like dragging an E
environment around.  If you insist on rewriting the main program in C and feel
like keeping some E code around, might I advice you look into EC's .library
linker?

-> Jolyon

Jason G Doig ([e-mail]) wrote:
-> Well, reading the manual, Wouter does tend to insist that things were
-> not done for compiler speed, but for 'very good reasons' (unspecified).

I think I explain that somewhere.  Basically I was irritated with the operator
priorities in languages I was using at the time (C, ProLog, and a few others),
which made me bracket everything in the end to not introduce subtle errors.  I
though having priorities that you could be sure of regardless of the operators
would be a good thing.  Mind you, that was 5 years ago.

-> 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

If only people would go by the book, eh Jase?

-> compilers.  To be honest, I think that a lot of the decisions /were/ made

Get real. Even my cat could write a precedence parser, and there would
be no speed difference whatsoever.

-> 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.7m

Taking 5 years to implement your own language hardly sounds like the easy way
out to me.  I tend to make choices for what I consider are "good reasons".

-> 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

Well, you can. For assembly this is trivial, C can be done to, if you
can make it such that it doesn't rely on C startup code. Have a look
at the o2m utility.

-> 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

Does your C compiler split .o files then?

-> 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...

You've lost me on the reasoning here. You can generate libraries
with E, infact there's an example GIO that comes with the distribution.
What is it that you can't do with E?

Wouter van Oortmerssen (still the E author :)