Shortcomings of Eiffel?
Andrew
advocating the use of Eiffel.
I've read OOSC2 and found it quite persuasive.
Now I'd appreciate information about what Eiffel *doesn't* do well,
doesn't do at all, or should have done differently. In what respects
is it lacking when compared to other languages? Especially other
concurrent object-oriented languages.
Andrew.
Philippe Ribet
>
> Now I'd appreciate information about what Eiffel *doesn't* do well,
> doesn't do at all, or should have done differently. In what respects
> is it lacking when compared to other languages? Especially other
> concurrent object-oriented languages.
>
The eiffel community is very small. Few enterprises use eiffel.
On the other side, C++ and Java are very common.
Java has been pushed by the very powerful marketing of Sun.
C++ offer a "smooth" transition from C (even if it has not be proved,
it's shown like that).
--
Philippe Ribet
The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!
Eirik Mangseth
"Philippe Ribet" <p.r...@worldonline.fr> wrote in message
news:3C88BB76...@worldonline.fr...
> Andrew wrote:
>
> >
> > Now I'd appreciate information about what Eiffel *doesn't* do well,
> > doesn't do at all, or should have done differently. In what respects
> > is it lacking when compared to other languages? Especially other
> > concurrent object-oriented languages.
> >
>
> The eiffel community is very small.
That is a statement about the community, not about the language. But your
answer is of course dependent on your interpretation of Andrew's question
"In what respects
is it lacking when compared to other languages?" :-)
> Few enterprises use eiffel.
So? Those who do seem to have a high degree of success with Eiffel and for
one such account please read Loryn Jenkins' statement as to why "his"
company is using Eiffel. I think the reasons given rings true for most
active Eiffelists. It certainly does for us (StockPoint Nordic, that is). As
I've said before, we've moved more and more of our code away from Java to
Eiffel. Why? Performance is one reason, there are others as well.
> On the other side, C++ and Java are very common.
And quantity does not equal quality.
> Java has been pushed by the very powerful marketing of Sun.
> C++ offer a "smooth" transition from C (even if it has not be proved,
> it's shown like that).
Have you ever talked off-hand with Java-adopters about their experience with
Java? When people are truthfull, they admit that there are more problems
with Java than hits the press. Problem is that few companies wish to admit
publicly that they've made a "bad" choice.
Andrew, it think we Eiffelists would have a hard time convincing the world
that Eiffel, as it stands today, is a good fit for hard real-time
applications.
-- eirik
"If I can't Eiffel in heaven, I won't go"
Darren New
> The eiffel community is very small. Few enterprises use eiffel.
This means, in part, that there are relatively few libraries for Eiffel
compared to (say) Perl, Tcl, Java, C++, etc. If you're building a large
system, where the capability to (say) fetch a message from a POP mailbox
and parse the headers is a small part of the problem, this might not be
a problem. If what you're building is a small tool to read a pop mailbox
and list the "from" addresses in it, you'll be much better off with a
language where POP and mail parsing are already available.
Eiffel does some of the best data structures around, but it sorely lacks
in having a wide scope of libraries for higher-order processing. I think
that makes it hard for experienced programmers to get their feet wet in
Eiffel, which leads to a further lack of libraries.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
To the user, everything works just as expected,
assuming the user's expectations are correct.
Clemens Oertel
> The eiffel community is very small. Few enterprises use eiffel. On the
if i'm not totally mistaken, eiffel lacks support for separate
declarations of exported features. this might well keep commercial
software developers from writing eiffel libraries, as they had to reveal
the source code (header files in c/c++, .class files are sufficient with
java).
furthermore, though this appears to be a matter of current open/free
eiffel implementations, incremental compilation support seems somewhat
weak (proof of contrary is always welcome).
nevertheless, compared to the more popular oo-language c++ and java,
eiffel seems to me the cleanest (just think of the terrible structure of
java base classes), most usable (good type checking system, generic
classes - compared to java) and purest oo-language (compared to c++) of
the three.
i guess, eiffel is simply playing in a totally different league than c++
or (especially) java. one would have to compare it to languages such as
ocaml, modula or ada. i take it as a language to write good, stable code,
not to produce some wicked hacks or to make fancy applets.
regards
clemens
Frank Mitchell
>
> if i'm not totally mistaken, eiffel lacks support for separate
> declarations of exported features.
There's always the flat-short form for documentation purposes. If I
recall, every current implementation but SmallEiffel allows one to
compile a library as object code plus some compiler-specific metadata.
(I'm pretty sure the old Tower system did.) Compiler-specific linking
conventions are not ideal, but GNU C++ has different conventions from
other compilers, and GCC is pretty popular. (*Is* there a C++ standard
apart from "whatever Borland and Microsoft are doing"?)
> furthermore, though this appears to be a matter of current open/free
> eiffel implementations, incremental compilation support seems somewhat
> weak (proof of contrary is always welcome).
See above. Although you generally have to buy the "enterprise edition"
...
> nevertheless, compared to the more popular oo-language c++ and java,
> eiffel seems to me the cleanest (just think of the terrible structure of
> java base classes),
Eiffel's base classes are pretty minimal, and not quite standard between
ISE and SmallEiffel at least. (Dunno about Halstenbach or
VisualEiffel.) Maybe that's better than Java's half-baked and
overzealous standards, but there's something to be said for development
environments with "batteries included" (as the Pythoners say).
> most usable (good type checking system, generic classes - compared to
> java)
I won't even try to argue for the "just static enough to be annoying"
type system of Java, or the "type checked only if you work at it" system
of C++.
> and purest oo-language (compared to c++) of the three.
As for C++'s "impurity", some (not I) consider that a strength, since
you can pick and choose your programming paradigm and favorite
idiolect. (And as long as it's just you working on a project ...)
Of course if we're including other languages, and other notions of
object-orientation besides Dr. Meyer's, Smalltalk (or Self?) could be
considered most "object-oriented".
--
Frank Mitchell (fra...@bayarea.net)
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Loryn E. Jenkins
> and list the "from" addresses in it, you'll be much better off with a
> language where POP and mail parsing are already available.
C'mon, Darren. You're *far* more intelligent than that!
You do what any self-respecting software engineer does: You get a
component that provides you the basic functionality you desire! This
tiny script was written using QuickSoft's EasyMail COM components.
indexing
description : "A simple POP3 script that downloads and prints
from_addresses."
author : "Loryn Jenkins"
date : "2002.03.09"
class
SILLY_COMMENT_REBUTTAL_SCRIPT
creation
make
feature -- Initialization
make is
-- Creation procedure
do
print_waiting_headers ("your_server", "your_account",
"your_password")
end
print_waiting_headers (a_mail_server, an_account, a_password: STRING)
is
-- Prints the FROM address of anyone who current has mail waiting
for you
-- in your POP3 account.
local
x: INTEGER
i: INTEGER
li: LINKED_LIST [STRING]
message: EMMSGMESSAGE_PROXY
do
create li.make
create pop3.make
pop3.set_license_key (License_key)
pop3.set_mail_server (a_mail_server)
pop3.set_account (an_account)
pop3.set_password (a_password)
x := pop3.connect
x := pop3.download_headers
if x = 0 then
create messages.make_from_pointer
(pop3.messages.dispatch_interface.item)
from
i := 0
until
messages.count - i = 0
loop
i := i + 1
create message.make_from_pointer (messages.item1
(i).dispatch_interface.item)
li.extend (clone (message.from_addr))
end
else
print ("There was an error retrieving your mail. Error code " +
x.out)
end
x := pop3.disconnect
from
li.start
until
li.after
loop
print (li.item)
print ("%N")
li.forth
end
end
feature {NONE} -- Constants
License_key: STRING is "your_license_key"
feature {NONE} -- Implementation
pop3: EASY_MAIL_POP3_PROXY
messages: POP3_MESSAGES_PROXY
end -- class SILLY_COMMENT_REBUTTAL_SCRIPT
Andrea Griffini
>I have come across several convincing arguments and testimonials
>advocating the use of Eiffel.
>
>I've read OOSC2 and found it quite persuasive.
I hope this is not going to start a flame war... this is not
my intention.
I'm reading OOSC2 and I like many of the ideas expressed there.
Also I'm looking around for a language alternative to C++ for
part of the software we write, as I've noticed many of the
mistakes are just about dangling pointers, memory leaks and
other things that should be handled by the language.
I was intrigued by Eiffel, too bad I installed the IDE when
unwrapping the book, and when I had enough time to start
reading the book and get to a point where I wanted to try
the language, the grace period for evaluation was already
expired!
and so I tried to look on the internet...
My impression is that Eiffel is dead !
May be never born ? Really no idea.
Now I find just broken links or pages last updated several
years ago. A global unmoderated world-wide newsgroup with a
message every few days. Even a couple of the compiler
producers seems left the business, moving to something else.
I downloaded SmallEiffel, and the trial version of
VisualEiffel and I'm not sure they're about the same
language... I'm not even sure there actually is any
real Eiffel language (not predated by a company changing
its meaning at will: that's called IMHO a "commercial product"
like MS Access or Delphi or Java, not a "language").
Why didn't Eiffel get any serious attention from the world
(excluding academic discussions and exceptions you can count
keeping your shoes on) ?
Andrea
Lothar Scholz
>Philippe Ribet wrote:
>> The eiffel community is very small. Few enterprises use eiffel.
>
>This means, in part, that there are relatively few libraries for Eiffel
Yes that is absolutely right. I say this after spending a few month
with wrapping my own GUI library.
>compared to (say) Perl, Tcl, Java, C++, etc. If you're building a large
>system, where the capability to (say) fetch a message from a POP mailbox
>and parse the headers is a small part of the problem, this might not be
>a problem. If what you're building is a small tool to read a pop mailbox
>and list the "from" addresses in it, you'll be much better off with a
>language where POP and mail parsing are already available.
But even in the C++ (and Perl !!) world i never found a library that
parsed MIME headers as described in the standards.
>Eiffel does some of the best data structures around, but it sorely lacks
>in having a wide scope of libraries for higher-order processing. I think
>that makes it hard for experienced programmers to get their feet wet in
>Eiffel, which leads to a further lack of libraries.
Yes but as a professional and with the new ETL "inline C" style it is
much easier. You can now write a wrapper for a normal library in a
few days (i needed 2 days for a wrapper around the CodeBase Database
library). Often you can do this while you read the documentation.
And how often are you writting a bridge pattern to wrap a C++ library
to fit your needs / coding conventions or to be able to switch to
another library if something wents wrong with this vendor.
For my applications i always spend most of the time in implementing
the main application logic. The important reason is simple: At the
moment the most components you can buy don't fit my needs.
Lothar Scholz
wrote:
>Why didn't Eiffel get any serious attention from the world
>(excluding academic discussions and exceptions you can count
>keeping your shoes on) ?
Why did people think for hunderts of years that earth is a disk, even
when they can see ships vanishing at the horizon ????
Why was Betamax unsuccessful when they offered quality you
now get 15 years later with SuperVHS ????
Why is my telephone bill so high - uups , thats because i particiate
to much in flamewars like this :-)
Darren New
> > and list the "from" addresses in it, you'll be much better off with a
> > language where POP and mail parsing are already available.
>
> C'mon, Darren. You're *far* more intelligent than that!
Why thank you.
> You do what any self-respecting software engineer does: You get a
> component that provides you the basic functionality you desire! This
> tiny script was written using QuickSoft's EasyMail COM components.
Um. Well. Yeah. Until it needs to work on UNIX, or whatever. And all the
other languages that can get to COM can do this just as easily. And
then, of course, you have to buy the COM component, make sure it's
installed everywhere you want to use it, etc etc. It's a rather high
barrier to entry for some things, compared to putting a blob of software
on a machine and running it.
Sure, it's possible to interface to other languages. I don't know how
easy it is, and it's certainly not touted as a strength of Eiffel, and
every compiler seems to do it differently. And doing a search on "eiffel
pop3" you don't really get anything useful, so...
> But even in the C++ (and Perl !!) world i never found a library that
> parsed MIME headers as described in the standards.
Sadly true. Tcl is the only system I know that has a header parser
that's both right and useful. Most of the C libraries for it I've seen
require huge amounts of infrastructure and such just to deal with it,
kind of dictating a lot more about the structure and purpose of your
mail client than you would expect.
> For my applications i always spend most of the time in implementing
> the main application logic. The important reason is simple: At the
> moment the most components you can buy don't fit my needs.
... Which is kind of where I was saying Eiffel can be superior. :-)
Darren New
> You do what any self-respecting software engineer does: You get a
> component that provides you the basic functionality you desire! This
> tiny script was written using QuickSoft's EasyMail COM components.
Or, to put it another way, what library is written in Eiffel that's so
powerful that people using other languages learn to link to Eiffel
rather than recreate it?
Perl has regexps. (Now ported elsewhere, of course)
Tcl has Tk. (Now ported elsewhere, of course)
C has OpenSSL, gcc, and probably more than can be counted,
which is why *everyone* knows how to link to C.
Java has (had) the browser support.
Ada probably has all kinds of stuff for it they'd have to kill
you if you found out about. ;-)
My personal opinion is that without something like that, using Eiffel
will always be an engineering tradeoff rather than a requirement. The
boss will always be saying "Shall we use Eiffel or something else?"
Rather than "Shall we use Eiffel or just skip this part?" I don't see
that Eiffel gives you a whole lot more functionality than Java or
Smalltalk (for example) does. It's not really a high-level language
(like SQL, Mathematica, APL, etc), and it's not really a language that
lets you easily do a lot of low-level things (like hooking interrupts,
running as NT services, driving hardware, doing real-time stuff, etc).
It's just kind of in the middle, so there's apparently no one thing it
excels at that makes it better than everything else (C, Fortran, Pascal,
Java, Smalltalk, etc) out there.
I'd be happy to be proven wrong, of course.
Philippe Ribet
> My impression is that Eiffel is dead !
> May be never born ? Really no idea.
>
> Now I find just broken links or pages last updated several
> years ago. A global unmoderated world-wide newsgroup with a
> message every few days. Even a couple of the compiler
> producers seems left the business, moving to something else.
>
> I downloaded SmallEiffel, and the trial version of
Dead ? And you downloaded SmallEiffel -0.74beta20 ? Have a look :
SmallEiffel started in 1994, so it's 7-8 years developpment. -0.74 will
come out in few days, the 27th stable version. Between the last stable
release (about 8 month), 20 intermediate (beta) release came out. And
you say it's dead ?
Have a look to projects like elj or gobo and I'll see it's not dead !
Geoff Eldridge
> "Loryn E. Jenkins" wrote:
> > You do what any self-respecting software engineer does: You get a
> > component that provides you the basic functionality you desire! This
> > tiny script was written using QuickSoft's EasyMail COM components.
>
> Or, to put it another way, what library is written in Eiffel that's so
> powerful that people using other languages learn to link to Eiffel
> rather than recreate it?
For pop3 and other email classes, see the nenie library ..
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nenie/net/library/email/
-- maybe Franck could give some details .. I am also aware of another
-- SmallEiffel implementation that might be released in the near future.
--
-- BTW, nenie is pretty well kept secret like most things Eiffel ..
-- http://www.nenie.org/eiffel/
> Perl has regexps. (Now ported elsewhere, of course)
Including Eiffel now ..
http://elj.sourceforge.net/projects/other/reg_exp/
This library has been gobonised (http://www.elj.com/elj.cgi?article=20011203c)
recently and now should work without change on all Eiffel compilers ..
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/library/regexp/
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/example/regexp/
> Tcl has Tk. (Now ported elsewhere, of course)
A lot of communities are moving to wxWindows (see http://www.wxpython.org/) ..
An Eiffel interface is currenly being developed ..
http://elj.sourceforge.net/projects/gui/ewxw/
http://elj.sourceforge.net/phpwiki/index.php/EwxwLibrary
> C has OpenSSL, gcc, and probably more than can be counted,
> which is why *everyone* knows how to link to C.
What we have learnt with the elj project, is that it is often better
to interface these specialised libraries at the interface and then
develop higher level libraries in Eiffel .. this is going to be a lot
easier now that we have SmallEiffel and ISE Eiffel both using the new
ETL external syntax clauses (a great divide has finally been bridged
and the community will be able to work together to build library
interfaces).
> Java has (had) the browser support.
> Ada probably has all kinds of stuff for it they'd have to kill
> you if you found out about. ;-)
[..]
Don't forget the great work happening in the GOBO project:
http://sourceforge.net/projects/gobo-eiffel/
http://elj.sourceforge.net/projects/other/gobo/
There are developing much needed tools (eg, getest, gelint, geant, etc)
and libraries (xml, data structs, etc) ..
eposix has a lot functionality, which nobody seems to know about ..
http://www.pobox.com/~berend/eposix/
Eiffel may appear to be very quiet and in this newsgroup in particular,
but those who have kept this group active over the years are now
involved in developing the libraries other communities have taken for
granted for years.
Maybe, now is the time for you to join one of these projects and start
contributing ..
Geoff
Lothar Scholz
>lets you easily do a lot of low-level things (like hooking interrupts,
>running as NT services, driving hardware, doing real-time stuff, etc).
>It's just kind of in the middle, so there's apparently no one thing it
>excels at that makes it better than everything else (C, Fortran, Pascal,
>Java, Smalltalk, etc) out there.
>
>I'd be happy to be proven wrong, of course.
You are wrong when you think its complicated to run a smalleiffel
program as a NT service. I do this here and its easy.
Loryn E. Jenkins
> other languages that can get to COM can do this just as easily. And
> then, of course, you have to buy the COM component, make sure it's
> installed everywhere you want to use it, etc etc. It's a rather high
> barrier to entry for some things, compared to putting a blob of software
> on a machine and running it.
This response is actually a good example of what is unsatisfying in
these newsgroup discussions: shifting goals posts. This discussion is
about, "What is bad about Eiffel," not, "What is great about Eiffel".
You gave an example where you consider Eiffel poor. I simply
demonstrated ... with real working code ... that this criticism is
invalid, on Win32 at least. Now you shift the goal posts of this
discussion:
* A small quick project does not usually entail portability
requirements. Small and quick projects are *just that*. Short sharp
quick projects aiming to get the job done. Once you introduce the goal
of portability, of course you approach the task differently. Software
engineering is *all about* making appropriate trade-offs. Now, Eiffel
allows you to write portable code easily. But it does from time to
time require more work than platform specific code. (Especially on
Win32, where component-oriented development is so prevalent.)
* Software distribution. Once again, getting a quick job done for
myself *is* a little different from creating code intended for
distribution. However, component-oriented development is pretty
mainstream these days! It isn't that big a problem!
* Finally, you shifted the goal-posts of the rhetoric here, from "what
is bad about eiffel" to "what does it need to be a world-beater".
> Sure, it's possible to interface to other languages. I don't know how
> easy it is, and it's certainly not touted as a strength of Eiffel, and
> every compiler seems to do it differently. And doing a search on "eiffel
> pop3" you don't really get anything useful, so...
So? Are you going to diss on VB because a lot of VB apps rely on code
that *might* be written in third-party languages within COM wrappers?
There *are* a lot of reasons to diss on VB. But surely this isn't one
of them!
In reality, I often find that well-constructed COM interfaces are
easier to code to than Eiffel class libraries. But that's because the
Eiffel class library writers provide the mechanisms of the cluster,
but forget to provide a simple "user-oriented" interface to their
code.
<snip>
> > For my applications i always spend most of the time in implementing
> > the main application logic. The important reason is simple: At the
> > moment the most components you can buy don't fit my needs.
>
> ... Which is kind of where I was saying Eiffel can be superior. :-)
I wholeheartedly agree! Standard Transactions' new system is currently
around 300 classes (excluding library code), with approximately 100 of
them being persistent. Eiffel is *very* effective in this situation.
We use ISE Eiffel 5.1, EiffelCOM, EiffelMatisse and Fresher's Matisse
OODBMS. This combination of tools and facilities is quite effective.
Loryn Jenkins, CTO
Standard Transactions
http://standardtransactions.com
Loryn E. Jenkins
Thanks for the pointers. As usual, very useful. Long time no see. Been
quietly coding recently, eh?
Patrick Doyle
>
>My impression is that Eiffel is dead !
>May be never born ? Really no idea.
>
>Now I find just broken links or pages last updated several years ago.
Can't blame you there.
>A global unmoderated world-wide newsgroup with a message every few days.
You must have looked during a particularly quiet period.
>Even a couple of the compiler producers seems left the business, moving to
>something else.
There is Tower. Who is the other compiler producer you're referring to?
>I downloaded SmallEiffel, and the trial version of
>VisualEiffel and I'm not sure they're about the same
>language... I'm not even sure there actually is any
>real Eiffel language (not predated by a company changing
>its meaning at will: that's called IMHO a "commercial product"
>like MS Access or Delphi or Java, not a "language").
Well, if you use the Gobo library, your code becomes quite portable.
--
--
Patrick Doyle
doy...@eecg.toronto.edu
Darren New
>
> > Um. Well. Yeah. Until it needs to work on UNIX, or whatever. And all the
> > other languages that can get to COM can do this just as easily. And
> > then, of course, you have to buy the COM component, make sure it's
> > installed everywhere you want to use it, etc etc. It's a rather high
> > barrier to entry for some things, compared to putting a blob of software
> > on a machine and running it.
>
> This response is actually a good example of what is unsatisfying in
> these newsgroup discussions: shifting goals posts. This discussion is
> about, "What is bad about Eiffel," not, "What is great about Eiffel".
> You gave an example where you consider Eiffel poor. I simply
> demonstrated ... with real working code ... that this criticism is
> invalid, on Win32 at least. Now you shift the goal posts of this
> discussion:
No. You first made the assumption that I'm on Win32. Then you made the
assumption that I've already licensed and installed your COM object.
You're imagining that because I said it was a quick project it didn't
require portability, that it's only for one person, etc.
I said "a small tool for reading a pop mailbox and getting the list of
names". Nothing about who would run it, why it's being run, where it's
being run, whether the developer is on the same platform as deployment,
etc. Indeed, I often do all this stuff as part of a larger server suite.
I gave an example of the kind of libraries that I don't see available
for Eiffel. You said "Well, it's not written in Eiffel, but you can buy
a library that Eiffel can interface to on Windows." That's shifting the
goalposts as well.
> * A small quick project does not usually entail portability
> requirements.
I think you're mistaken here. I develop quite frequently (usually, even)
on Windows for software I deploy on Unix. I spend maybe 2% of my time
considering the portability issues. This includes GUI software doing
sound and animation, multi-threaded servers, event-driven network
protocols, and so on. (And no, it isn't Java I'm using, but Tcl.)
> * Software distribution. Once again, getting a quick job done for
> myself *is* a little different from creating code intended for
> distribution. However, component-oriented development is pretty
> mainstream these days! It isn't that big a problem!
Well, again, if I have the choice of using a free tool that already has
POP support and MIME support available in free libraries, or trying to
find a tool out there that already interfaces to Eiffel via COM and then
pay for it, get a license, see if it works, etc, then I'll go with the
former.
> * Finally, you shifted the goal-posts of the rhetoric here, from "what
> is bad about eiffel" to "what does it need to be a world-beater".
No, I simply expanded on my thoughts. You know, like a conversation
rather than an argument.
> > Sure, it's possible to interface to other languages. I don't know how
> > easy it is, and it's certainly not touted as a strength of Eiffel, and
> > every compiler seems to do it differently. And doing a search on "eiffel
> > pop3" you don't really get anything useful, so...
>
> So? Are you going to diss on VB because a lot of VB apps rely on code
> that *might* be written in third-party languages within COM wrappers?
> There *are* a lot of reasons to diss on VB. But surely this isn't one
> of them!
VB? Now who is shifting the goalposts?
But to answer, no, because VB isn't a language that's specifically
designed to be powerful and easy to write big libraries in. Nor is it a
language designed to be independent of the platform it's on and vender
independent.
> In reality, I often find that well-constructed COM interfaces are
> easier to code to than Eiffel class libraries. But that's because the
> Eiffel class library writers provide the mechanisms of the cluster,
> but forget to provide a simple "user-oriented" interface to their
> code.
Agreed. Java has much the same problem, where to (for example) read an
email, you have to go thru 3 or 4 different layers of abstraction just
to get to an actual internet email message, where in reality I think the
likelyhood of anyone wanting a piece of code that'll work with both VMS
mail and RFC822 is pretty low, compared to the number of people who want
to get the job done.
Darren New
> Eiffel may appear to be very quiet and in this newsgroup in particular,
> but those who have kept this group active over the years are now
> involved in developing the libraries other communities have taken for
> granted for years.
Yeah. As I said when SmallEiffel first hit the scene, I figured that
would be the boost that's needed to start getting libraries going. It'll
be interesting to watch ISE trying to catch up with SmallEiffel features
in a couple years. ;-)
> Maybe, now is the time for you to join one of these projects and start
> contributing ..
Eiffel sadly still lacks some of the basic language-level infrastructure
that I would want to do the libraries I'd be thinking of doing. (Dynamic
code loading, events and/or decent threading, etc.) In addition, as I
said in another post, Eiffel really doesn't give me much that I can't
get out of the other languages I already know, and it's not (at least
yet) name-brand enough to be useful to me in business. I've tried
pushing it at various places when starting new projects, and the
response has always been quite negative. I like the concept of Eiffel,
but the devil is in the details.
Franck Arnaud
> -- BTW, nenie is pretty well kept secret like most things Eiffel ..
it's not so much secret as unfinished. at least in
the sense of not being feature complete and documented.
probably an issue with eiffelists is that we are
often perfectionists and don't publicise where others
would have for something half as finished and not
working :)
at least with open CVS repositories development
stuff is available.
Andrew
(1) The available libraries are good, but Eiffel needs to provide more
(standard?) libraries, in the way that Java does (only less messily).
That is, Eiffel should support a broader, more sophisticated set of
features, such as... (insert suggestions here)
(2) Eiffel needs a larger developer community
(3) "Eiffel sadly still lacks some of the basic language-level
infrastructure
that I would want to do the libraries I'd be thinking of doing.
(Dynamic
code loading, events and/or decent threading, etc.)"
(4) Something that can't be done easily in other languages.
What about the arcane stuff, like memory models? Does Eiffel strongly
specify expression evaluation and memory consistency rules, or is it
silent on that? (I wonder if "Eiffel: The Language" talks about
this?). Is the exception-handling mechanism a pleasure to use? Would
a standardised intermediate bytecode language (or reliance on a
standard, strict interpretation of C) be a good idea for Eiffel
program portability?
I would argue that (1) and (3) are library concerns, not language
concerns (depending on what is meant by "decent threading" -- what is
wrong with 'separate'? Threads are one of the huge *problems* of Java,
despite their usefulness). (2) might be fixed by fixing (1), (3) or
(4). (4) could be a language issue (but then it could be anything).
It seems, then, that so far no-one experienced with Eiffel is aware of
shortcomings in the actual language itself(?)
Lothar Scholz
>Yeah. As I said when SmallEiffel first hit the scene, I figured that
>would be the boost that's needed to start getting libraries going. It'll
>be interesting to watch ISE trying to catch up with SmallEiffel features
>in a couple years. ;-)
Hope that this is true. At the moment Dominique is very conservative
with development. Thats why you can find 2 SmallEiffel children on
SourceForge.
>Eiffel sadly still lacks some of the basic language-level infrastructure
>that I would want to do the libraries I'd be thinking of doing. (Dynamic
>code loading, events and/or decent threading, etc.) In addition, as I
Dynamic loading is really a problem for Smalleiffel (but not for the
other versions).
When writing client applications i never found multi threading
very important. As a TCL/TK programmer i believe you can agree with
this point of view. It simply raises to much problems i real world
software processes (add hock programming under high time pressures).
But on the server side i real miss this feature. It seems that the
server belongs to JAVA :-(
>said in another post, Eiffel really doesn't give me much that I can't
>get out of the other languages I already know, and it's not (at least
Hmmm... 2,5 years ago i did an intensive evaluation of the languages
out there and find nothing that satisfied me. Java was to slow for
a GUI client application and has seom well known problems.
What other languages are performance optimized to use it with
basic algorithms on larger data sets - this eliminates all script
languages, which are here 20x slower. I also coded in TCL before
but what are you doing when you must write a TK canvas app with
a more intelligent line routing algorithms.
I just found 6 languages that are useable:
C++ (sorry to bad to be used in time constrainted larger projects)
Java (all competitiors use this but not me)
Eiffel ( that the winner)
Common Lisp (only one company and very very expensive and
the syntax needs a lot of training)
Smalltalk (also some performace problems - but my language number 2)
Gnu ADA (don't like the department of world wide murder language)
This are the only non freak languages - others like ML, Dylan, OPAL
etc... are really dead.
I must say that the biggest mistake i made was to use Smalleiffel
instead of investing 4000$ for a WIN32 / LINUX combination of ISE's
eiffel (the second was depending on some open source libraries that
developed much slower then expected).
> I like the concept of Eiffel, but the devil is in the details.
Thats always the problem but it is more a side effect.
Thomas Beale
Andrew wrote:
>So... so far, the points we've got are:
>
>(1) The available libraries are good, but Eiffel needs to provide more
>(standard?) libraries, in the way that Java does (only less messily).
>That is, Eiffel should support a broader, more sophisticated set of
>features, such as... (insert suggestions here)
>
#1 requirement: an available Corba-based framework for building
distributed enterprise level applications. Java programmers have J2EE,
C++ programmers have all kinds of Corba products. ISE now has .NET but
it is not portable (not yet anyway) and AFAIK, does not support
prioritised, multi-threaded server application building the way the C++
Corba and (presumably) Java products do.
>(2) Eiffel needs a larger developer community
>
>(3) "Eiffel sadly still lacks some of the basic language-level
>infrastructure that I would want to do the libraries I'd be thinking of doing.
>(Dynamic code loading, events and/or decent threading, etc.)"
>
I don't find this so interesting.
>
>It seems, then, that so far no-one experienced with Eiffel is aware of
>shortcomings in the actual language itself(?)
>
there are some small ones, such as the problem of non-conformance of
expanded types to reference types like ANY, but they can be worked
around. According to some people, genericity could be better done, but
let's face it, it's much clearer than the other languages.
The main library lack in my opinion is that the class TYPE is not yet
implemented, which prevents you from writinng any easy reflection code,
needed for writinng database bindings, XML converters and intelligent GUIs.
On the plus side, agents are a powerful feature not in all other languages.
- thomas beale
>
Pascal Obry
Lothar Scholz <llo...@mailandnews.de> writes:
> C++ (sorry to bad to be used in time constrainted larger projects)
> Java (all competitiors use this but not me)
> Eiffel ( that the winner)
> Common Lisp (only one company and very very expensive and
> the syntax needs a lot of training)
> Smalltalk (also some performace problems - but my language number 2)
> Gnu ADA (don't like the department of world wide murder language)
Maybe you do not know that Ada is a French language (from Bull). And of course
Ada is used in many non defense industry. Note that anyway I think the DOD use
certainly all languages so... are you going to trash all of them ?
The good news is that you can revisit the Ada language with a different point
of view now :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"
Darren New
> Dynamic loading is really a problem for Smalleiffel (but not for the
> other versions).
I think it's a problem conceptually, because of system validity rules
and such.
> When writing client applications i never found multi threading
> very important.
I guess you haven't written any game clients. :-) Personally, I don't
use multithreading much in Tcl, but rather events, and I do event-based
programming in Tcl for both clients and servers all the time. I'd have
to use threads if the event-handling system wasn't so good, such as in
Java.
> What other languages are performance optimized to use it with
> basic algorithms on larger data sets - this eliminates all script
> languages, which are here 20x slower.
Err, well, not anymore, no. And of course depending on what you're
doing.
> I also coded in TCL before
> but what are you doing when you must write a TK canvas app with
> a more intelligent line routing algorithms.
Not sure I understand that sentence.
> I just found 6 languages that are useable:
>
> C++ (sorry to bad to be used in time constrainted larger projects)
> Java (all competitiors use this but not me)
> Eiffel ( that the winner)
> Common Lisp (only one company and very very expensive and
> the syntax needs a lot of training)
> Smalltalk (also some performace problems - but my language number 2)
> Gnu ADA (don't like the department of world wide murder language)
Department of world wide murder? You mean the USA's DoD? You mean you
don't like the language? Or you won't use the language because the DoD
paid for its development? The latter is just ... weird. :-)
Anyway, I've done rather large and powerful servers and clients both in
Tcl, and it works fine for me (and many other big names) when doing
internet-type stuff. I probably wouldn't try to do work in mathematical
graph theory with it, tho.
Mingjui Liao
> Geoff Eldridge wrote:
> > Eiffel may appear to be very quiet and in this newsgroup in particular,
> > but those who have kept this group active over the years are now
> > involved in developing the libraries other communities have taken for
> > granted for years.
>
> Yeah. As I said when SmallEiffel first hit the scene, I figured that
> would be the boost that's needed to start getting libraries going. It'll
> be interesting to watch ISE trying to catch up with SmallEiffel features
> in a couple years. ;-)
>
> > Maybe, now is the time for you to join one of these projects and start
> > contributing ..
>
> Eiffel sadly still lacks some of the basic language-level infrastructure
> that I would want to do the libraries I'd be thinking of doing. (Dynamic
> code loading, events and/or decent threading, etc.) In addition, as I
> said in another post, Eiffel really doesn't give me much that I can't
> get out of the other languages I already know, and it's not (at least
> yet) name-brand enough to be useful to me in business. I've tried
> pushing it at various places when starting new projects, and the
> response has always been quite negative. I like the concept of Eiffel,
> but the devil is in the details.
I am trying to understand how SmallEiffel's compiler works, so I can
add the dynamic loading to it. Maybe you can help?
Also, there is a patch out there that adds the multi-thread
capability.
If you wish to use it in the workplace, you should look at ISE's
compiler since they support your wishlist quite well.
Loryn E. Jenkins
> "Loryn E. Jenkins" wrote:
> >
> > > Um. Well. Yeah. Until it needs to work on UNIX, or whatever. And all the
> > > other languages that can get to COM can do this just as easily. And
> > > then, of course, you have to buy the COM component, make sure it's
> > > installed everywhere you want to use it, etc etc. It's a rather high
> > > barrier to entry for some things, compared to putting a blob of software
> > > on a machine and running it.
> >
> > This response is actually a good example of what is unsatisfying in
> > about, "What is bad about Eiffel," not, "What is great about Eiffel".
> > You gave an example where you consider Eiffel poor. I simply
> > demonstrated ... with real working code ... that this criticism is
> > invalid, on Win32 at least. Now you shift the goal posts of this
> > discussion:
>
> No. You first made the assumption that I'm on Win32. Then you made the
> assumption that I've already licensed and installed your COM object.
Well, actually, (grin), I didn't even spend a second thinking about
what *you* were on. I was simply demonstrating how *I* construct
systems in Eiffel.
> You're imagining that because I said it was a quick project it didn't
> require portability, that it's only for one person, etc.
Imagining? Assumption. Hey: It's cool you can do it in TCL.
> I said "a small tool for reading a pop mailbox and getting the list of
> names". Nothing about who would run it, why it's being run, where it's
> being run, whether the developer is on the same platform as deployment,
> etc. Indeed, I often do all this stuff as part of a larger server suite.
I develop stuff for Win32. Portability is pretty low on my priorities.
Wherever I have a choice, of course, I choose the portable solution.
Anything else, I have no compunction whatsoever about exploiting
system-specific capabilities.
> I gave an example of the kind of libraries that I don't see available
> for Eiffel. You said "Well, it's not written in Eiffel, but you can buy
> a library that Eiffel can interface to on Windows." That's shifting the
> goalposts as well.
I don't know. "Available for Eiffel", in my book, means "available for
Eiffel developers". "Available", for me, means I can use it within my
Eiffel universe. (For example, stepping out to manually wrap C code is
not what *I* consider "available"; but I can see how it is for many
Eiffel developers.) But, for me, COM *is* available. I downloaded the
component, ran the EiffelCOM Wizard. And immediately had POP3, IMAP,
SMTP, etc. classes available to me.
> > * A small quick project does not usually entail portability
> > requirements.
>
> I think you're mistaken here.
OK, granted, it can be done in environments whose wrappers provide
portability across operating systems. I was merely referring to the
fact that it has historically been a trade-off.
> I develop quite frequently (usually, even)
> on Windows for software I deploy on Unix. I spend maybe 2% of my time
> considering the portability issues. This includes GUI software doing
> sound and animation, multi-threaded servers, event-driven network
> protocols, and so on. (And no, it isn't Java I'm using, but Tcl.)
Hey! Sounds cool. More power to you.
> > * Software distribution. Once again, getting a quick job done for
> > myself *is* a little different from creating code intended for
> > distribution. However, component-oriented development is pretty
> > mainstream these days! It isn't that big a problem!
>
> Well, again, if I have the choice of using a free tool that already has
> POP support and MIME support available in free libraries, or trying to
> find a tool out there that already interfaces to Eiffel via COM and then
> pay for it, get a license, see if it works, etc, then I'll go with the
> former.
Well, I probably would too.
> > * Finally, you shifted the goal-posts of the rhetoric here, from "what
> > is bad about eiffel" to "what does it need to be a world-beater".
>
> No, I simply expanded on my thoughts. You know, like a conversation
> rather than an argument.
Hey. Sorry for insulting you. I've just seen so many "OO design
discussions" here on this forum where the requirements are always
shifted, shifted, shifted. I approached this discussion in good faith,
from my world view; obviously you did the same from yours. For me, the
solution I would implement is perfectly satisfying to me. I consider
anything wrapped in COM to be "available" to me as an Eiffel
developer.
> > > Sure, it's possible to interface to other languages. I don't know how
> > > easy it is, and it's certainly not touted as a strength of Eiffel, and
> > > every compiler seems to do it differently. And doing a search on "eiffel
> > > pop3" you don't really get anything useful, so...
> >
> > So? Are you going to diss on VB because a lot of VB apps rely on code
> > that *might* be written in third-party languages within COM wrappers?
> > There *are* a lot of reasons to diss on VB. But surely this isn't one
> > of them!
>
> VB? Now who is shifting the goalposts?
Not. As I described above, my world-view says that anything
"available" to me is available for me. Same in Eiffel as it is in VB.
That's how a lot of functionality is delivered on the Win32 platform.
Components. Not source code.
I do generally prefer native Eiffel solutions. For example, just now
I'm switching out the ISS string matching cluster for the PCRE
library. I do prefer the all-Eiffel solution. But I'm primarily
switching over because the PCRE cluster is more powerful.
> But to answer, no, because VB isn't a language that's specifically
> designed to be powerful and easy to write big libraries in. Nor is it a
> language designed to be independent of the platform it's on and vender
> independent.
And Eiffel has the power to be as portable or platform-specific as the
developer wishes for it to be.
> > In reality, I often find that well-constructed COM interfaces are
> > easier to code to than Eiffel class libraries. But that's because the
> > Eiffel class library writers provide the mechanisms of the cluster,
> > but forget to provide a simple "user-oriented" interface to their
> > code.
>
> Agreed. Java has much the same problem, where to (for example) read an
> email, you have to go thru 3 or 4 different layers of abstraction just
> to get to an actual internet email message, where in reality I think the
> likelyhood of anyone wanting a piece of code that'll work with both VMS
> mail and RFC822 is pretty low, compared to the number of people who want
> to get the job done.
Hey. Once again. Sorry if you felt insulted. I had no intention of
that.
A few years ago, I used to level the same accusation you just made
against Eiffel. Then came along the EiffelCOM library and all the
power of all those COM components on the Win32 platform became mine!
It provided a radical expansion of the possibilities for implementing
systems in Eiffel. Now there's .NET which will take this to yet
another level of underlying functionality. I'm getting increasingly
excited about the future of engineering high-quality systems in
Eiffel. I really enjoy programming in it.
AND, with care, it will be possible to write portable systems across
UNIX, Win32 and .NET runtimes. With care. That mightn't be good enough
for you. It more than allows me to get my job done.
Darren New
> Eiffel developers.) But, for me, COM *is* available. I downloaded the
> component, ran the EiffelCOM Wizard. And immediately had POP3, IMAP,
> SMTP, etc. classes available to me.
Very cool. If Eiffel's level of COM interface is that easy, then that's
definitely a plus.
> Hey. Sorry for insulting you. I've just seen so many "OO design
> discussions" here on this forum where the requirements are always
> shifted, shifted, shifted. I approached this discussion in good faith,
> from my world view; obviously you did the same from yours. For me, the
> solution I would implement is perfectly satisfying to me. I consider
> anything wrapped in COM to be "available" to me as an Eiffel
> developer.
Yah, that's cool. I'm behind on Eiffel technology. :-)
> That's how a lot of functionality is delivered on the Win32 platform.
> Components. Not source code.
It's definitely a way of working "reusable" components that's superior
in a lot of ways. Personally, I've been trying to figure out the most
"reusable" mechanisms for software, and OO ain't it. :-)
> > But to answer, no, because VB isn't a language that's specifically
> > designed to be powerful and easy to write big libraries in. Nor is it a
> > language designed to be independent of the platform it's on and vender
> > independent.
>
> And Eiffel has the power to be as portable or platform-specific as the
> developer wishes for it to be.
Um, actually, I would disagree with that. Some of the stuff (like
numerics, for example) isn't well defined enough for my taste to be
portable to those who need that sort of stuff to be portable. At least,
last I looked.
> Hey. Once again. Sorry if you felt insulted. I had no intention of
> that.
No problem. I hadn't assumed you did. I was just trying to keep
everything civil and have a conversation, rather than having everyone
changing the definitions of stuff to try to prove they were right. :-)
> A few years ago, I used to level the same accusation you just made
> against Eiffel. Then came along the EiffelCOM library and all the
> power of all those COM components on the Win32 platform became mine!
> It provided a radical expansion of the possibilities for implementing
> systems in Eiffel. Now there's .NET which will take this to yet
> another level of underlying functionality. I'm getting increasingly
> excited about the future of engineering high-quality systems in
> Eiffel. I really enjoy programming in it.
>
> AND, with care, it will be possible to write portable systems across
> UNIX, Win32 and .NET runtimes. With care. That mightn't be good enough
> for you. It more than allows me to get my job done.
Indeed. Eiffel has definitely improved since last I really looked
closely at it, which was the ISE 4.2 to 4.5 timeframe.
Friedrich Dominicus
> Lothar Scholz <llo...@mailandnews.de> writes:
>
> > C++ (sorry to bad to be used in time constrainted larger projects)
> > Java (all competitiors use this but not me)
> > Eiffel ( that the winner)
> > Common Lisp (only one company and very very expensive and
> > the syntax needs a lot of training)
Well what company are you talking about? There are at least 3 probably
more.
LispWorks : www.xanalys.com (definitly not very expensive visit their homepage)
Franz Lisp : www.franz.com
MCL : www.digitool.com (not expensive
Corman Lisp ...
than there are
Clisp
and
CMUCL as "free speech" alternatives.
Syntax needs a lot of training? Hardly more than Eiffel
Friedrich
Paul Cohen
"Loryn E. Jenkins" wrote:
>
> A few years ago, I used to level the same accusation you just made
> against Eiffel. Then came along the EiffelCOM library and all the
> power of all those COM components on the Win32 platform became mine!
> It provided a radical expansion of the possibilities for implementing
> systems in Eiffel. Now there's .NET which will take this to yet
> another level of underlying functionality. I'm getting increasingly
> excited about the future of engineering high-quality systems in
> Eiffel. I really enjoy programming in it.
>
And with Mono gaining momentum, who knows where we could end up? :-)
I agree fully with you Loryn, I really enjoy programming in Eiffel.
/Paul
--
Paul Cohen Tel: +46 8 50 714 366
Software consultant Vx: +46 8 50 714 000
Enea Business Software AB Fax: +46 8 65 857 90
Hornsgatan 166
117 28 Stockholm www.enea.se
Paul G Crismer
> #1 requirement: an available Corba-based framework for building
> distributed enterprise level applications. Java programmers have J2EE,
> C++ programmers have all kinds of Corba products. ISE now has .NET but
> it is not portable (not yet anyway) and AFAIK, does not support
> prioritised, multi-threaded server application building the way the C++
> Corba and (presumably) Java products do.
I second this #1 requirement. I would rephrase it like this : Eiffel
must have
effective and powerful bridges to todays popular software solutions.
Eiffel cannot stay on its island waiting for people using it.
The best way to contaminate the world is to be present at the world.
> The main library lack in my opinion is that the class TYPE is not yet
> implemented, which prevents you from writinng any easy reflection code,
> needed for writinng database bindings, XML converters and intelligent GUIs.
Agree.
Eiffel marketing should focus on the "Eiffel advantage".
Let me illustrate this : while evaluating .NET technology, I've
"ported" VB.NET applications to Eiffel for NET. Amazing : it works
and it looks good.
But what's the value/advantage if the only difference regarding VB or
C# is with syntactic sugar?
The Eiffel advantage :
1* "Executable" specification elements through software contracts;
consequence : documentation always in sync. with current state of
development.
2* Genericity
3* Elegant multiple inheritance mechanism
4* Strong type system + Global system analysis
(1,4) are about trusted and robust software components
(2,3) are more about language expressiveness
(1) favors precise software interfaces and thus favor good
communication and social skills between software teams (less bugs due
to false hypothesis or excess of imagination).
Software is closer to literature than to science, while scientific
methods help.
The expressiveness of Eiffel coupled to its pragmatic approach to
accuracy help developers write software literature : precise,
readable, documented and -still- efficent and executable applications.
It just needs effective bridges to asocial and illiterate software
pieces that as so common and so hype today (while they bring very
interesting solutions).
Best regards,
Paul G. Crismer
NN
Paul G Crismer skrev i meldingen ...
>Thomas Beale <tho...@deepthought.com.au> wrote in message
>
>> #1 requirement: an available Corba-based framework for building
>> distributed enterprise level applications. Java programmers have J2EE,
>> C++ programmers have all kinds of Corba products. ISE now has .NET but
>> it is not portable (not yet anyway) and AFAIK, does not support
>> prioritised, multi-threaded server application building the way the C++
>> Corba and (presumably) Java products do.
>
>I second this #1 requirement.
Two point to be made here:
a) There are two CORBA bindings available for Eiffel. One is commercial and
sold and maintained by 2AB, Inc. The other is Open Source and is developed
and maintained by the mico/e team at the Univ. of Goettingen in Germany.
b) A framework like J2EE is not something a single Eiffel vendor should
provide. CORBA frameworks are defined by the Object Management Group (OMG)
and AFAIK the OMG will release (have released) the specification for the
CORBA Component Model (CCM) which is I believe a superset of the
functionality found in J2EE's EJB/container implementation.
I would venture that Eiffel implementations of the various OMG specs are
driven by demand and probably some financing commitment up-front (in the
commercial case).
>I would rephrase it like this : Eiffel
>must have
>effective and powerful bridges to todays popular software solutions.
IMHO when it comes to CORBA it does. At StockPoint Nordic we've successfully
utilized ISE Eiffel and 2AB's orb2 (formerly known as DAIS) and as I've said
in this news group many times before, so has the Chicago Board of Trade in
cooperation with OM Technology.
It is easy to say that "Eiffel must have ......", but where is the demand?
There is only so much a vendor can risk doing without some commercial
commitment from its customers. I believe this goes for 2AB as well as ISE
(and probably the other vendors as well). They've got limited resources and
can't provide every feature between heaven and earth just because it would
be nice to have without being sure that they get some ROI.
So we're back to the chicken and egg situation once again. Sigh.
-- eirik
"If I can't Eiffel in heaven, I won't go"
[snip]
Greg C
[...]
> My impression is that Eiffel is dead !
> May be never born ? Really no idea.
>
> Now I find just broken links or pages last updated several
> message every few days. Even a couple of the compiler
> producers seems left the business, moving to something else.
Traffic may not be much in comp.lang.eiffel, but if you go to
http://groups.yahoo.com
and search for eiffel you'll find lots of discusssion groups. Some
quite dead, others very active. The ones I subscribe to (SmallEiffel,
ELJ and Gobo) create a lot of traffic.
> I downloaded SmallEiffel, and the trial version of
> VisualEiffel and I'm not sure they're about the same
> language... I'm not even sure there actually is any
> real Eiffel language (not predated by a company changing
> its meaning at will: that's called IMHO a "commercial product"
> like MS Access or Delphi or Java, not a "language").
Did you find Cetus Links?
http://www.cetus-links.org/oo_eiffel_libraries.html
about one hundred and fifty libraries and utilities listed. Some are
cruft, but this doesn't even include a few of the more active and
interesting library projects, like ELJ's database and Windows
bindings.
http://elj.sourceforge.net/
Yes, cross compiler compatibility has been a big bugaboo of the
language, but that's improving. With -0.74, SmallEiffel has made great
strides in embracing new Eiffel standards as outlined in ETL3 (which
is available in PDF drafts via eiffel.com) and NICE has been slowly
hacking away at the problem as well.
> Why didn't Eiffel get any serious attention from the world
> (excluding academic discussions and exceptions you can count
> keeping your shoes on) ?
>
> Andrea
Bertrand Meyer once said something along the lines that Eiffel sits at
the cusp of the academic and commercial worlds, hence it satisfies
neither :-)
Seriously though, there seems to be momentum growing behind the GNU
compiler and the portable Gobo libraries. The language itself
continues to evolve (though at a much more measured pace than other
languages), and compiler vendors seem to be more cooperative in
building in compatibility.
Greg
Andrea Griffini
>quite dead, others very active. The ones I subscribe to (SmallEiffel,
>ELJ and Gobo) create a lot of traffic.
Thanx... I'll try to read those too. I would have said
that comp.lang.eiffel was the best place for talking
about the eiffel language ...
I've checked this NG for a few weeks and I would have
said that eiffel was really dead. Probably the signal/noise
ratio here is better than in comp.lang.c++ ... but even
all those ones asking for help with their homework looks
like... hmmm... liveness :)
Now my impression is that eiffel isn't dead but things
goes on really quietly. Also all that old stuff on the
net doesn't look good... when I find the home page of
www.eiffel-forum.org in which the most recent news
are dated jan-14-2000 you should agree with me that
the impression can't be of a lively language.
Also the dates of the last few news looks scary...
(there's just *one* line dated 1999).
>Did you find Cetus Links?
>http://www.cetus-links.org/oo_eiffel_libraries.html
Yes I did... that's where I found most pointers
>Yes, cross compiler compatibility has been a big bugaboo of the
>language, but that's improving. With -0.74, SmallEiffel has made great
>strides in embracing new Eiffel standards as outlined in ETL3 (which
>is available in PDF drafts via eiffel.com) and NICE has been slowly
>hacking away at the problem as well.
That is something that surprised me. I don't know the
evolution of eiffel (I'm just finishing OOSC2, the only
book I've read where eiffel is described with some
detail level) but I thought that wouldn't have been
as painful as the one of "C++".
Finding incompatibilities in the "base" library and
finding READMEs talking about differences in the core
language about compilers is something that really
I didn't expect.
I've read about Gobo and Pylon... but my impression
that this is the right direction, but that Eiffel is
just starting the path to become a viable language.
I was looking for a language in which start to build...
How can I expect to be building something if the core
language and the base libraries are unstable ?
Many of "C++" horrors are an unfortunate heritage from
its evolution... that's at the same time good and bad.
The "C++" language is now quite dirty and asymmetric
(and damn complex), but it's powerful and you can still
compile most of the code that has been written decades ago.
I stumbled in a description of the approved substitution
of the double-exclamative syntax for object creation
with a new keyword "create"... what really made my eyes
looking like ping-pong balls for a few seconds was
the (absent) justification.
To cite OOSC2, may be eiffel is like 'make' and that
there are just a dozen or two users in the whole world ?
I was looking for an alternative to C++ for start writing
tons of middle-high level code ... how can I even remotely
propose a language in which changes are made for the
fun of it ?
>Seriously though, there seems to be momentum growing behind the GNU
>compiler and the portable Gobo libraries. The language itself
>continues to evolve (though at a much more measured pace than other
>languages), and compiler vendors seem to be more cooperative in
>building in compatibility.
Actually while I've read somewhere a nice line reciting
that the biologist' term for "stability" is "death", I
think that in a language stability (at least as backward
compatibility at the 'core' level) is a must.
What for example I don't like about Java (Java2 ? Java3 ?
Java 2000 ? Java XP ? where are them now ?) is that in
many things they changed their mind.
I didn't like at all the original approach to security
for example (imho just philosophically wrong), but seeing
them changing it later just transformed a language with
errors in a total error. If i wanna write something on
which I can rely for the next decade... can I use Java ?
Java wasn't around 10 years ago, and won't be around in
10 year -- at least in any compatible form.
But java is a strange marketing case of something
getting really famous before anyone was actually using it;
so may be in the java community no one can even think
to a piece of software that runs (and is maintained) for
more than 10 years (may be because java is targeted to
companies that last only for a few quarters ? :-) )
Is this going to be the same for eiffel ? I hope not.
So I won't consider that "at a much more measured pace"
as a negative point.
C++ not so long ago was imho unusable (too many differences
between compilers) but now things are much better if you
avoid the dark corners. This means that if I write a C++
program now then I can think it will last as long as *I*
decide it to last... not as long as ISE or Sun or someone
other that's not interested in the implications for *my*
businness thinks that would be funnier to twiddle it a bit.
ISE for example shown me that you can be somewhat successful
programming in a language you design yourself (and *not*
kidding this is one of the options I'm thinking to).
But can someone succeed using Eiffel (and not bending the
definition of what Eiffel is at will) ?
Definitely I need more reading and thinking ...
Thank you for your time
Andrea
Chris Saunders
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3c8e72a4...@news.tin.it...
snipped a bunch
> I stumbled in a description of the approved substitution
> of the double-exclamative syntax for object creation
> with a new keyword "create"... what really made my eyes
> looking like ping-pong balls for a few seconds was
> the (absent) justification.
>
> To cite OOSC2, may be eiffel is like 'make' and that
> there are just a dozen or two users in the whole world ?
>
> I was looking for an alternative to C++ for start writing
> tons of middle-high level code ... how can I even remotely
> propose a language in which changes are made for the
> fun of it ?
>
snipped a bunch more
Lets say you are an experienced programmer but not particularly
familiar with Eiffel. If you were reading some Eiffel code which
would you be more likely to understand.
!! whatever
or
create whatever
I think that an important part of the Eiffel philosophy is to be
as easy as possible to learn and apply. Readability of code
is an important facet of this.
Regards
Chris Saunders
chris.s...@sympatico.ca
Lothar Scholz
<fr...@q-software-solutions.com> wrote:
>Pascal Obry <p.o...@wanadoo.fr> writes:
>
>> Lothar Scholz <llo...@mailandnews.de> writes:
>>
>> > C++ (sorry to bad to be used in time constrainted larger projects)
>> > Java (all competitiors use this but not me)
>> > Eiffel ( that the winner)
>> > Common Lisp (only one company and very very expensive and
>> > the syntax needs a lot of training)
>Well what company are you talking about? There are at least 3 probably
>more.
>
>LispWorks : www.xanalys.com (definitly not very expensive visit their homepage)
>Franz Lisp : www.franz.com
>MCL : www.digitool.com (not expensive
>Corman Lisp ...
I'm talking about Franz Lisp where you can spend 15.000$ for one
plattform easily.
>than there are
>Clisp
>and
>CMUCL as "free speech" alternatives.
Yes but CLISP has a real performace problems and it is a very simple
command line tool without any IDE help.
>Syntax needs a lot of training? Hardly more than Eiffel
Okay, i don't mean the syntax - i mean training your facility to read
the lisp code (macros for example are very hard to understand) and yes
there is a problem with the parenthesis - this can break your brain.
Lothar Scholz
wrote:
>I was looking for a language in which start to build...
>How can I expect to be building something if the core
>language and the base libraries are unstable ?
>Many of "C++" horrors are an unfortunate heritage from
>its evolution... that's at the same time good and bad.
>The "C++" language is now quite dirty and asymmetric
>(and damn complex), but it's powerful and you can still
>compile most of the code that has been written decades ago.
But things are changing. The C++ commitee just introduced
the keywords "and" , "or" and "not" for && || ~
This breaks lots of code. Try the newest GCC and
you will see what i mean.
Friedrich Dominicus
> >
> >LispWorks : www.xanalys.com (definitly not very expensive visit their homepage)
> >Franz Lisp : www.franz.com
> >MCL : www.digitool.com (not expensive
> >Corman Lisp ...
>
> I'm talking about Franz Lisp where you can spend 15.000$ for one
> plattform easily.
Well than why don't you write there is just one company?
LispWorks is a wonderful Lisp implementation and cost less than
ISE-Eiffel
>
> >than there are
> >Clisp
> >and
> >CMUCL as "free speech" alternatives.
>
> Yes but CLISP has a real performace problems and it is a very simple
> command line tool without any IDE help.
What have you done with CLisp that you write such things. It's easy to
find bottlnecsk in Eiffel to if I look for them.
>
> >Syntax needs a lot of training? Hardly more than Eiffel
>
> Okay, i don't mean the syntax - i mean training your facility to read
> the lisp code (macros for example are very hard to understand) and yes
> there is a problem with the parenthesis - this can break your brain.
Well Lisp Macros are sophisticated. But I can't see that Macros are
always hard to understand, but the offer unique features which Eiffel
simple does not have. You can easiyl write you own languages just by
extending Lisp you can do that that way in Eiffel.
But while we are at it. The Subject is Eiffel shortcomings.
Eiffel does not offer by default
- bignums, rationals
- Eiffel has no Macro System
- Eiffel lacks elements for functional development
- Eiffel is less flexible than Common Lisp
- the exception handling is less elaborated in Eiffel
- Common Lisp is standardized ( besides the Kernel libraries
there's is nothing standard in Eiffel)
usually you have to go always through objects to get things done (this
has changed with agents but they are not "Standard" and not every
Eiffel Compiler supports it.
Everyone who has written some Eiffel will probably know this schema
class ACTION
feature
action is do end;
end class
class ACTION1
inherit ACTION
redefine action
end;
feature ..
..
class ACTION2 is ....
Well with HOFS I do not have do to that.
I probably can find some other shortcomings but I think it's enough
for the moment...
Regards
Friedrich
Pascal Obry
Pascal Obry <p.o...@wanadoo.fr> writes:
> Maybe you do not know that Ada is a French language (from Bull).
BTW, both Eiffel and Ada have French roots.
Lothar Scholz
>
>Pascal Obry <p.o...@wanadoo.fr> writes:
>
>> Maybe you do not know that Ada is a French language (from Bull).
>
>BTW, both Eiffel and Ada have French roots.
Yes but Bull is IMHO a cowboy company - i mean a US company
with a headquarter in texas.
Greg C
[...]
> That is something that surprised me. I don't know the
> evolution of eiffel (I'm just finishing OOSC2, the only
> book I've read where eiffel is described with some
> detail level) but I thought that wouldn't have been
> as painful as the one of "C++".
> Finding incompatibilities in the "base" library and
> finding READMEs talking about differences in the core
> language about compilers is something that really
> I didn't expect.
Part of this disparity arose from a small number of compiler vendors
working on their own corners of the market. Until recently those
markets didn't really overlap and there wasn't much impetus to iron
out the wrinkles. That's changed recently, and from watching NICE's
efforts it looks like there's more cooperation these days.
[...]
> I was looking for a language in which start to build...
> How can I expect to be building something if the core
> language and the base libraries are unstable ?
> Many of "C++" horrors are an unfortunate heritage from
> its evolution... that's at the same time good and bad.
> The "C++" language is now quite dirty and asymmetric
> (and damn complex), but it's powerful and you can still
> compile most of the code that has been written decades ago.
"Decades ago"? You have C++ code dating from 1982? That compiles? Can
I see it? ;-)
If by dark corners of the language you mean anything involving
templates, pointer arithmetic, macros, and expressions with ambiguous
orders of evaluation, then I might agree. In my experience one can
only write truly stable, portable C++ with great care and attention to
details, and even then you may have to reproduce significant chunks of
the standard library yourself. My company recently had to write a
proprietary version of quick sort because its an unstable sort and
different compilers provided us with different results when given the
same inputs. We've also had to implement our own I/O layers because of
problems/limitations in that area, as well as our own extensions for
memory management, etc.
[...]
> I stumbled in a description of the approved substitution
> of the double-exclamative syntax for object creation
> with a new keyword "create"... what really made my eyes
> looking like ping-pong balls for a few seconds was
> the (absent) justification.
The whole discussion over "create" took place three or four years ago,
and as I recall it happened at Talkitover.com, not in c.l.e (sigh) The
impetus was to improve readability, though there was a lot of concern
expressed about introducing a new reserved word and possibly breaking
code that declared variables or features named 'create'. Most of the
Eiffel community now considers that discussion water under the bridge
as it were; I haven't checked the c.l.e FAQ recently. Is this issue
covered there?
> To cite OOSC2, may be eiffel is like 'make' and that
> there are just a dozen or two users in the whole world ?
Well over a hundred people are members of NICE alone. The Eiffel
community is a bit bigger than a couple dozen :-)
http://www.eiffel-nice.org/members.html
[...]
> But can someone succeed using Eiffel (and not bending the
> definition of what Eiffel is at will) ?
From my POV there are several successful Eiffel projects around,
changes to the languages are usually in the form of extensions (tuples
and agents, for example) that don't destabilize the code, and changes
that obsolesce old code are considered carefully (though you have to
be on your toes to find the discussion!)
I personally use SmallEiffel and to a lesser extent ISE Eiffel where
others might use Perl to manipulate large text files. SE with PCRE
handles pattern searches through 1 and 2 G files far better than Perl!
Greg
Darren New
> But while we are at it. The Subject is Eiffel shortcomings.
> Eiffel does not offer by default
> - bignums, rationals
I'm always amused at the folks who leave out decimal math here too. (You
know, packed BCD. Whatever you want to call it.) That nasty bit of math
that lets you write financial systems the perform correctly.
Eiffel also doesn't tell you the size of integers or floats, does it? Or
is that something that's actually standardized in General or Platform or
something now?
Pascal Obry
Lothar Scholz <llo...@mailandnews.de> writes:
I don't think it was the case back in 1983 (First Ada Standard). The work on
Ada started on 1977. Anyway both language's team leader were french :)
Patrick Doyle
Mingjui Liao <snow...@sinamail.com> wrote:
>
>I am trying to understand how SmallEiffel's compiler works, so I can
>add the dynamic loading to it. Maybe you can help?
Have you seen this?
http://www.eiffel-forum.org/archive/doyle/sedl.htm
It doesn't add dynamic loading to the compiler, but instead does a bunch of
things manually which *should* be added to the compiler. Regardless, the
result is dynamic class loading from a DLL. (Actually, it's Linux, so it's a
".so" file, though the platform-specific parts are isolated.)
Patrick Doyle
Andrew <bod...@hotmail.com> wrote:
>
>What about the arcane stuff, like memory models? Does Eiffel strongly
>specify expression evaluation and memory consistency rules, or is it
>silent on that?
Eiffel has no particular memory model, since it was not designed to be
multithreaded. (It plays havoc with contracts.) There is SCOOP, which is more
than just a memory model; and then there are various attempts to do more
straightforward multithreading in Eiffel, presumably using whatever memory
model is provided by the underlying hardware.
It would be nice if memory models were not necessary. They only affect
unsynchronized shared data access, and that shouldn't happen anyway.
>Is the exception-handling mechanism a pleasure to use?
I don't think it is. I have ranted on this topic in the past, so I won't bore
everyone by repeating myself here, but I think the three major problems are:
1. Eiffel's exceptions are considered to break contracts. DbC says that
correct programs never break contracts. The only logical conclusion is that
correct Eiffel programs must never use exceptions. Needless to say, this
reduces their usefulness.
2. Eiffel's exceptions are integers, instead of objects. Aside from the
academic argument that this makes Eiffel's claim to "pure OO" questionable,
there is also the difficulty that exceptions cannot be arranged into
hierarchies, cannot store any data, cannot exhibit polymorphic behaviour,
etc.
3. Exception handling is not enforced at compile time, as it is in Java.
It is simple to allow an exception accidentally to propagate to the top level
and cause the program to terminate. This is consistent with Eiffel's
treatment of exceptions as contract breaches (which are also caught at
runtime), but it is unfortunate since safer alternatives exist.
Peter Gummer
> the keywords "and" , "or" and "not" for && || ~
Wow that'll be a major advance in C++'s legibility. Let's hope Java &&
C# follow suit!
By the way, && and || are Boolean operators but ~ is a bitwise logical
operator. Surely the keyword "not" would be Boolean too (i.e. "!")?
Peter Gummer
Peter Horan
> > I stumbled in a description of the approved substitution
> > of the double-exclamative syntax for object creation
> > with a new keyword "create"... what really made my eyes
> > looking like ping-pong balls for a few seconds was
> > the (absent) justification.
>
> The whole discussion over "create" took place three or four years ago,
> and as I recall it happened at Talkitover.com, not in c.l.e (sigh) The
> impetus was to improve readability, though there was a lot of concern
> expressed about introducing a new reserved word and possibly breaking
> code that declared variables or features named 'create'. Most of the
> Eiffel community now considers that discussion water under the bridge
> as it were; I haven't checked the c.l.e FAQ recently. Is this issue
> covered there?
"create" was adopted as a standard by NICE in January. The first formal
proposal was submitted in March 2000, the final November 2001.
--
Peter Horan School of Computing and Mathematics
pe...@deakin.edu.au Deakin University
+61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter
-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)
Thomas Beale
NN wrote:
>b) A framework like J2EE is not something a single Eiffel vendor should
>provide. CORBA frameworks are defined by the Object Management Group (OMG)
>and AFAIK the OMG will release (have released) the specification for the
>CORBA Component Model (CCM) which is I believe a superset of the
>functionality found in J2EE's EJB/container implementation.
>
I should have mentioned that I don't think it is up to compiler vendors
to provide this kind of thing. Companies like 2AB are more the kind of
vendor for Corba products.
>IMHO when it comes to CORBA it does. At StockPoint Nordic we've successfully
>utilized ISE Eiffel and 2AB's orb2 (formerly known as DAIS) and as I've said
>in this news group many times before, so has the Chicago Board of Trade in
>cooperation with OM Technology.
>
>It is easy to say that "Eiffel must have ......", but where is the demand?
>There is only so much a vendor can risk doing without some commercial
>commitment from its customers. I believe this goes for 2AB as well as ISE
>(and probably the other vendors as well). They've got limited resources and
>can't provide every feature between heaven and earth just because it would
>be nice to have without being sure that they get some ROI.
>
I guess it just needs a Sun to champion Eiffel!
- thomas beale
Peter Gummer
> 2. Eiffel's exceptions are integers, instead of objects.
Interesting, though-provoking post, as always Patrick, but... in
Eiffel integers *are* objects.
Peter Gummer
Friedrich Dominicus
> Friedrich Dominicus wrote:
> > But while we are at it. The Subject is Eiffel shortcomings.
> > Eiffel does not offer by default
> > - bignums, rationals
>
> I'm always amused at the folks who leave out decimal math here too. (You
> know, packed BCD. Whatever you want to call it.) That nasty bit of math
> that lets you write financial systems the perform correctly.
Well probably it's left out because some implementation offer some
libraries for it. But as you know we are in c.l.e...
>
> Eiffel also doesn't tell you the size of integers or floats, does it? Or
> is that something that's actually standardized in General or Platform or
> something now?
Well there are probably some things availalbe for it. But they are not
Standard. You expressed it better than me. The whole numerical stuff
in Eiffel is relativly weak.
- Integers just flow over
- Large Numbers are not available
- while interfacing with C you will have problems for unsigned types.
- ...
Regards
Friedrich
Friedrich Dominicus
>
> 1. Eiffel's exceptions are considered to break contracts. DbC says that
> correct programs never break contracts. The only logical conclusion is that
> correct Eiffel programs must never use exceptions. Needless to say, this
> reduces their usefulness.
Well another thing which was never used at least in ISE-Eiffel were
the ITERATOR classes which brings us back to the fact that NO Eiffel
compiler up till now works as pointed out in ETL, Chapter 11. Which
simply means MI is somewhat broken (since ages!)
>
> 2. Eiffel's exceptions are integers, instead of objects. Aside from the
> academic argument that this makes Eiffel's claim to "pure OO" questionable,
> there is also the difficulty that exceptions cannot be arranged into
> hierarchies, cannot store any data, cannot exhibit polymorphic behaviour,
> etc.
For an example how things could be see the Condition system from
Common Lisp...
very well put. May I add another story.
DBC just works iff Programmers follow the CQS! Even with the new
keyword pure things have changed. It is not checked by the compiler!
So the language offers features for "safer" programming, but does not
support them fully.
Enough ranting...
Regards
Friedrich
Christopher Barber
Greg C
Ah, but you can't inherit off of an integer (at least not with any
compiler I know of) so you're stuck with passing around nothing more
than integers. I think assertion handling is extended somewhat in
ETL3. (You also get strings!)
But then, considering the incredible abuse applied to C++ exceptions
(have you ever tried to debug a memory allocation error in a
dynamically created class that has the single purpose of serving
exceptions?) perhaps its better that Eiffel errs on the side of
minimalism in this one.
Greg
Greg C
> Friedrich Dominicus wrote:
> > But while we are at it. The Subject is Eiffel shortcomings.
> > Eiffel does not offer by default
> > - bignums, rationals
>
> I'm always amused at the folks who leave out decimal math here too. (You
> know, packed BCD. Whatever you want to call it.) That nasty bit of math
> that lets you write financial systems the perform correctly.
>
> Eiffel also doesn't tell you the size of integers or floats, does it? Or
> is that something that's actually standardized in General or Platform or
> something now?
There are features for getting the size of these things in bits or
bytes or somesuch. I'm too lazy (buzy?) to get the short version of
ANY up for all my compilers right now.
Greg
Peter Gummer
> Andrew <bod...@hotmail.com> wrote:
> >Is the exception-handling mechanism a pleasure to use?
>
> I don't think it is. I have ranted on this topic in the past, so I won't bore
> everyone by repeating myself here, but I think the three major problems are:
In addition to the problems Patrick mentions, I would like to add a
fourth:
4. Eiffel has no equivalent of the "finally" keyword in
Ada(?)/Java/C#/Delphi. Its closest equivalent is the "rescue" clause.
This becomes a problem when a routine acquires a resource (e.g. opens
a file) and must release the resource (i.e. close the file) before
returning. Ada(?)/Java/C#/Delphi can release the resource in the
"finally" block, which is always executed even if an exception occurs.
Eiffel -- correct me if I'm wrong -- must duplicate the code to
release the resource: once in the routine body, and again in the
"rescue" clause.
Peter Gummer
Eirik Mangseth
>
>
> NN wrote:
>
> >b) A framework like J2EE is not something a single Eiffel vendor should
> >provide. CORBA frameworks are defined by the Object Management Group
(OMG)
> >and AFAIK the OMG will release (have released) the specification for the
> >CORBA Component Model (CCM) which is I believe a superset of the
> >functionality found in J2EE's EJB/container implementation.
> >
> I should have mentioned that I don't think it is up to compiler vendors
> to provide this kind of thing. Companies like 2AB are more the kind of
> vendor for Corba products.
Yes, but they would like to see some upfront financial commitment if the
market isn't clearly there.
>
> >IMHO when it comes to CORBA it does. At StockPoint Nordic we've
successfully
> >utilized ISE Eiffel and 2AB's orb2 (formerly known as DAIS) and as I've
said
> >in this news group many times before, so has the Chicago Board of Trade
in
> >cooperation with OM Technology.
> >
> >It is easy to say that "Eiffel must have ......", but where is the
demand?
> >There is only so much a vendor can risk doing without some commercial
> >commitment from its customers. I believe this goes for 2AB as well as ISE
> >(and probably the other vendors as well). They've got limited resources
and
> >can't provide every feature between heaven and earth just because it
would
> >be nice to have without being sure that they get some ROI.
> >
> I guess it just needs a Sun to champion Eiffel!
I'm not to worried about that. Eiffel is 16 years old and still going strong
despite the many rumours of its demise. I think the best thing to do is to
write good software in Eiffel and then tell people about it afterwards. To
paraphrase Kent Beck: "The proof is in the software".
>
> - thomas beale
Eirik Mangseth
"Peter Horan" <pe...@deakin.edu.au> wrote in message
news:3C8FF38A...@deakin.edu.au...
> Greg C wrote:
>
> > > I stumbled in a description of the approved substitution
> > > of the double-exclamative syntax for object creation
> > > with a new keyword "create"... what really made my eyes
> > > looking like ping-pong balls for a few seconds was
> > > the (absent) justification.
> >
> > The whole discussion over "create" took place three or four years ago,
> > and as I recall it happened at Talkitover.com, not in c.l.e (sigh) The
> > impetus was to improve readability, though there was a lot of concern
> > expressed about introducing a new reserved word and possibly breaking
> > code that declared variables or features named 'create'. Most of the
> > Eiffel community now considers that discussion water under the bridge
> > as it were; I haven't checked the c.l.e FAQ recently. Is this issue
> > covered there?
>
> "create" was adopted as a standard by NICE in January. The first formal
> proposal was submitted in March 2000, the final November 2001.
"create" existed in early versions of Eiffel. Read OOSC1 or look at code
from ISE Eiffel 2.2
> --
> Peter Horan School of Computing and Mathematics
> pe...@deakin.edu.au Deakin University
> +61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
> +61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter
>
> -- The Eiffel guarantee: From specification to implementation
> -- (http://www.cetus-links.org/oo_eiffel.html)
-- eirik
Doug Pardee
> ... Exception handling is not enforced at compile time, as it is
> in Java. It is simple to allow an exception accidentally to
> propagate to the top level and cause the program to terminate.
> This is consistent with Eiffel's treatment of exceptions as
> contract breaches (which are also caught at runtime), but it
> is unfortunate since safer alternatives exist.
I am not at all sure that the Java community would, in the main, agree
that compiler-enforced exception handling is a good idea. It *sounds*
like a good idea, but it turns out not to be so wonderful in practice.
Bruce Eckel has written a paper on this topic, "Does Java need Checked
Exceptions?" (online at
http://www.mindview.net/Etc/Discussions/CheckedExceptions).
A few quotes:
"Checked exceptions seem like a really good idea at first."
"the only language I know of where they exist is in Java, and I'll
bet it was because people saw unchecked exception specifications in
C++ and thought that was a mistake (I know I did, for the longest
time)."
"At this point, I feel like checked exceptions are (1) an untried
experiment when they were put into Java ... (2) a failure because so
many people end up swallowing the exceptions in their code."
The article also contains a link to a discussion by Eric Gunnerson as
to why they chose not to implement checked exceptions in C# (online at
http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820).
A telling quote from that discussion:
"Examination of small programs leads to the conclusion that
requiring exception specifications could both enhance developer
productivity and enhance code quality, but experience with large
software projects suggests a different result -- decreased
productivity and little or no increase in code quality."
In both papers, the primary issue raised is that if a programmer is
forced to explicitly handle every possible exception on every possible
call, he quickly starts short-cutting the process by simply making the
exceptions disappear.
You could argue that there is no need to actually *catch* each listed
exception, just add it to the "throws" clause and let it percolate up.
This is even worse, as Dejan Jelovic notes (at
http://www.jelovic.com/articles/java_good_bad.htm):
"Checked exceptions are evil because they put implementation details
(which exceptions are thrown) into interfaces. So instead of letting
me propagate the exceptions until the place where the transaction
started, Java is forcing me to handle them locally because large
portions of the standard library use checked exceptions. I get around
this by catching them, wrapping them into an exception derived from
RuntimeException and re-throwing, but that is both painful and leads
to information about the exception being lost."
So, if you don't want your public interface to depend upon which
exceptions just happen to occur in the current implementation, you
*must* catch each such exception and process it.
In "Exceptional Java"
(http://www.octopull.demon.co.uk/java/ExceptionalJava.html), Alan
Griffiths discusses three major failings of checked exceptions:
1. Breaking encapsulation
2. Loss of information
3. Information overload
IMHO, if you read just one of the papers referenced here, this is the
one to read.
The issue of broken encapsulation can seriously complicate the three
GoF design patterns which use "blind calls": Command, Visitor, and
Observer. The "throws" clause of the blindly called method as defined
in the interface must list all checked exceptions which might be
thrown or passed through by all current implementations of the method,
and all future implementations are bound by that list of checked
exceptions.
In most cases Command and Observer will merely be defined to not throw
any exceptions. The implementations of the "execute" or "notify"
methods will have to deal with all exceptions which arise, and make
them go away (as discussed above).
The Visitor pattern can have real problems with the broken
encapsulation, though, as discussed in this quote (from
http://www.owlnet.rice.edu/~comp212/lecture-notes/sec1.7.3.html):
"When implementing a Visitor class, it'll often become necessary to
throw various exceptions in the visitor's methods. But then the
abstract methods in the visitor's superclass must declare that they
throw all these exceptions. Then each time we want to add a new
visitor class, we may have to revise every other visitor class.
Consequently, any code that uses these visitors would now have to deal
with handling these added exceptions. This can quickly cause code
management costs to spiral out of control."
-- Doug Pardee, Enterprise Machines dpa...@enterprisemachines.com
Andrea Griffini
<chris.s...@sympatico.ca> wrote:
>Lets say you are an experienced programmer but not particularly
>familiar with Eiffel. If you were reading some Eiffel code which
>would you be more likely to understand.
>
>!! whatever
>or
>create whatever
I've to admit that the double exclamation mark was
quite strange and kind of different from the rest
of the language.
>I think that an important part of the Eiffel philosophy is to be
>as easy as possible to learn and apply. Readability of code
>is an important facet of this.
Yeah. But if backward compatibility isn't considered a serious
issue then it's hard to have developers adopting the language.
Actually after thinking to it a while I came to the conclusion
that being current diffusion of Eiffel quite limited probably
fixing things now is still a viable option. And the sooner the
better...
I've read that 'create' was in OOSC1 and this confuses me a bit
because I've seen the double-exclamation creation in OOSC2.
Also saying "create p.make" is still confusing, as the current
value of p isn't used and the syntax is all but clear on this.
I think that something like p := POINT.create would be clearer
(just thought to this in this moment... no idea if other parts
of the language are uncompatible with this view).
Andrea
Andrea Griffini
<llo...@mailandnews.de> wrote:
>But things are changing. The C++ commitee just introduced
>the keywords "and" , "or" and "not" for && || ~
>This breaks lots of code. Try the newest GCC and
>you will see what i mean.
Digraphs and alternative keywords are in my opinion
one of those somewhat surprising stupid results you
can get from meetings of a group of individually quite
intelligent people. I think it's something that has
to do with the meeting concept itself :DD
Apart from kidding I seriously think that digraphs
and trigraphs and alternative keywords don't add
anything to the language and just break things
and create problems.
Note that I'm in a country in which the local keyboard
requires three keys to get "{" and in which you've
no way at all to type "`" or "~" (excluding entering
the numeric code for the character)... but still I think
that this problem is a keyboard problem, not a language
problem and one should fix the keyboard (like I and many
like me do... using US keyboards) and not the language.
Also I don't think that introducing alternative keywords
for &&, || and the like was such a great idea... like
it wouldn't be a great idea to replace the big sigma symbol
used in math for summation with "add_all".
A convention is a convention... and terseness doesn't
necessarely mean less clear (even if may require some
training first).
Andrea
Andrea Griffini
wrote:
>By the way, && and || are Boolean operators but ~ is a bitwise logical
>operator. Surely the keyword "not" would be Boolean too (i.e. "!")?
In C++ the alternative keyword for binary negation ("~") is "compl"
Andrea
Yngve Zackrisson
One thing i miss in the langue Eiffel is the possibility to comment out
blocks of code.
Like with
/*
...
*/
in C.
(AFAIK it is not possible).
Yngve.
Andrew <bod...@hotmail.com> wrote in message
news:14c850e7.02030...@posting.google.com...
> I have come across several convincing arguments and testimonials
> advocating the use of Eiffel.
>
> I've read OOSC2 and found it quite persuasive.
>
> Now I'd appreciate information about what Eiffel *doesn't* do well,
> doesn't do at all, or should have done differently. In what respects
> is it lacking when compared to other languages? Especially other
> concurrent object-oriented languages.
>
> Andrew.
Friedrich Dominicus
> One thing i miss in the langue Eiffel is the possibility to comment out
> blocks of code.
> Like with
> /*
> ...
> */
> in C.
> (AFAIK it is not possible).
Well this is a bad examples. You just have to add -- before each
line. It's very easy at least in Emacs you just say comment-region
And it's even better than in C you can not have other comments
enclosed in C comment you have to use the #if 0 trick for that.
Regards
Friedrich
Pascal Obry
"Yngve Zackrisson" <yngve.z...@telia.com> writes:
> One thing i miss in the langue Eiffel is the possibility to comment out
> blocks of code.
> Like with
> /*
> ...
> */
> in C.
> (AFAIK it is not possible).
And this has been proved to be a really bad idea becaude embedded block
comments. In some softwares the rule is to use "#if 0"~/#endif. For example in
Ada it is a design choice (as for Eiffel) to not implement block comment.
And as already pointed out a decend editor (I use Emacs too) have a comment
and uncomment region commands that will do the job for you.
Peter Gummer
> Also I don't think that introducing alternative keywords
> for &&, || and the like was such a great idea... like
> it wouldn't be a great idea to replace the big sigma symbol
> used in math for summation with "add_all".
> A convention is a convention... and terseness doesn't
> necessarely mean less clear (even if may require some
> training first).
As a native speaker of English, Andrea, I cannot agree. I think I can
speak for all whose first language is English when I say that "and" is
much clearer than "&&".
Your opinion is interesting, however. Si parla Italiano? I first
encountered a similar opinion to yours from a Korean, which taught me
not to assume that C-style languages look illegible to everybody!
Andrea Griffini
wrote:
>As a native speaker of English, Andrea, I cannot agree. I think I can
>speak for all whose first language is English when I say that "and" is
>much clearer than "&&".
I was saying that's not a big issue. One should consider that COBOL
syntax for computation was probably the most similar to english, but
I don't think that anyone would adopt that path for a modern language.
After a while (not much indeed) I think you "metabolize" the symbols
and just skim over them reading the concept behind them and it
doesn't really matter if it's written "and" or "&&".
Completely different is the situation for C syntax for declaration
in which our minds (at lest mine :D) aren't able to "metabolize" the
complexity and you have to stop and think hard to get what is the
expression saying... No surprise that most C books suggestion is
to use the typedef facility extensively...
"and" may be better for who doesn't know the language... but honestly
I think that's may be the smallest of the problems s/he will have in
understanding what is the program doing. There are many more
"details" and the syntax is only the very very beginning.
Sure i think that while may be questionable that !! -> create
is a good change for Eiffel (not widely known and without
a big code base) it's quite hardly defendible the choice to
introduce several new keywords (including ones like "compl"
that are everything but clear) to a basically "C" syntax where
"C" is probably one of the most diffused languages and with
the biggest code base in the world breaking running programs
for just such a small achievement.
Not to mention that the digraph introduced also another lexer
problem with <: and templates instantiation on names of the
global namespace --> std::vector<::myclass>.
>Your opinion is interesting, however. Si parla Italiano? I first
>encountered a similar opinion to yours from a Korean, which taught me
>not to assume that C-style languages look illegible to everybody!
May be for a korean three strange and different symbols like "and"
are harder to distinguish than two equally strange but at least
equal ones like "&&" ;)
Andrea
Franck Arnaud
> Ah, but you can't inherit off of an integer (at least not with any
> compiler I know of)
Doesn't it work in Smalleiffel at least?
It's probably not very useful, because descendants do not conform,
but that's a property of all expanded types and does not detract
from the fact they are objects.
Yngve Zackrisson
It is always astonishing to me how easily the subject in this discussion
group diverge.
The subject for this thread was 'Shortcomings of Eiffel?'
An for my little contribution it was 'things i miss in the langue Eiffel'.
It was not 'Tips and tricks for what I can do with my favorite editor
(Emacs)'.
IMHO a programming language should not get hardwired towards any particular
editor.
Preferences for editors may be different, as well as how easily available
they are.
In some cases, it may even be restrictions of what editor to use.
To mix programming language design and editor capablities is IMHO not an
example
'separation of concerne'.
Hence, I want to be able to easily comment out / uncomment out blocks of
code easily,
independent of whatever editor I may have to use.
Futher.
In C, for example, one can still use // in the beginning of the rows to
comment out blocks of code.
The difference is that in C it is up to the programmer what approach to use.
That is the reason why i miss the possibility to comment out blocks of code
in the programming langue Eiffel.
As for the problem with embedded block comments I know of that problem.
My experience is that it is less time consuming and less error prone than to
manually
comment out code line by line.
Last.
If I have not delimit myself to 'the programming langue Eiffel' the list
have been much longer.
What comes to my mind is my problems/frustration with previous Eiffel tools,
tools setup,
inadequate tutorials and documentation, non-compilable example programs etc.
Regards
// Yngve
Pascal Obry <p.o...@wanadoo.fr> wrote in message
news:ulmcsa...@wanadoo.fr...
Friedrich Dominicus
> It is always astonishing to me how easily the subject in this discussion
> group diverge.
>
> The subject for this thread was 'Shortcomings of Eiffel?'
> An for my little contribution it was 'things i miss in the langue Eiffel'.
>
> It was not 'Tips and tricks for what I can do with my favorite editor
> (Emacs)'.
>
> IMHO a programming language should not get hardwired towards any particular
> editor.
> Preferences for editors may be different, as well as how easily available
> they are.
> In some cases, it may even be restrictions of what editor to use.
> To mix programming language design and editor capablities is IMHO not an
> example
> 'separation of concerne'.
> Hence, I want to be able to easily comment out / uncomment out blocks of
> code easily,
> independent of whatever editor I may have to use.
type a -- in front of each line . That can be done in any editor. And
you even do not have to care if a line just consists of a comment...
>
> Futher.
> In C, for example, one can still use // in the beginning of the rows to
> comment out blocks of code.
Well how do you do that. You put a // in each line well you can do the
same for Eiffel
>
> The difference is that in C it is up to the programmer what approach to use.
>
> That is the reason why i miss the possibility to comment out blocks of code
> in the programming langue Eiffel.
This is ridicolous you come up with // instead of -- and tell me
somthing about block comments. This is uterly nonsense.
>
> As for the problem with embedded block comments I know of that problem.
> My experience is that it is less time consuming and less error prone than to
> manually
> comment out code line by line.
Well please do so. If you do think this is the way to go do it by
hand.
>
> Last.
> If I have not delimit myself to 'the programming langue Eiffel' the list
> have been much longer.
> What comes to my mind is my problems/frustration with previous Eiffel tools,
> tools setup,
> inadequate tutorials and documentation, non-compilable example
> programs etc.
Well how about reading a decent book about Eiffel? How about choosing
Halstenbach Eiffel which comes with more documentation than any other
languages. You tell us that we should not mix up tools and langauge
but you are doing the same here.
Friedrich
Victor B. Putz
> This is ridicolous you come up with // instead of -- and tell me
> somthing about block comments. This is uterly nonsense.
(chuckle)--actually, the point I think he was trying to make is that in
C++ (and maybe ansi C) you have a *choice* about which style of
commenting to use, EITHER by commenting out individual lines with // OR
by commenting out blocks of code with /* ... */
It's a stylistic/taste thing to an extent. I personally do feel that
"commenting out blocks of code" is an action that's orthogonal to a
language and is indeed a feature that should be delegated to the editor
or other tools. And I also like the individual line comments because a)
there are no nesting issues, and b) I actually prefer "There's Only One
Way To Do It"--as long as it's a reasonable and simple way.
But I can see it as being perceived as a usability issue, so while I
disagree with the poster, I wouldn't just dismiss it as "utterly
nonsense" (grin).
> You tell us that we should not mix up tools and langauge
> but you are doing the same here.
Here I can somewhat agree with Friedrich. I regard comments as a
feature of the language in that every language ought to provide a
mechanism to document code in the code itself. The ability to remove a
section of code from compilation might also be part of the language, but
I'd delegate it to tools (preprocessor or editor), although the
mechanism of that might be through "commenting out sections of code".
But the two ideas (commenting code vs conditional compilation of code)
aren't related that much, and I think conditional compilation should be
supported by tools.
Now it's fair to say that Eiffel has no real tools for conditional
compilation! I am *glad* that Eiffel doesn't have a preprocessor, mind
you, because it makes some things much simpler, but there have been times
when I would have liked the ability to remove code from compilation to
eg try other algorithms, disable a section of code to test something,
etc. And so while I'd like to remove the somewhat conflative term
"commenting out sections of code" and instead talk about "selective" or
"conditional" compilation of code, I think that's a valid criticism of
Eiffel.
On shortcomings of Eiffel: the agent mechanism is a HUGE step forward,
but I will say that, having played with OCaml, I really really like the
"let...in..." mechanism for decomposing a complex feature into many
small functions that work together. Meyer's objection, if I remember
OOSC2 correctly, is that allowing nested function declarations like this
prevents reuse of code, so every function should be individually
declared--but I feel this clutters the "namespace" of a class too much.
I'd really like to see, if you will, anonymous (and named) on-the-spot
declarations for agents.
-->VPutz
Pascal Obry
"Yngve Zackrisson" <yngve.z...@telia.com> writes:
> It is always astonishing to me how easily the subject in this discussion
> group diverge.
>
> The subject for this thread was 'Shortcomings of Eiffel?'
> An for my little contribution it was 'things i miss in the langue Eiffel'.
>
> It was not 'Tips and tricks for what I can do with my favorite editor
> (Emacs)'.
The point is, /* and */ (block comment) has proved to be unsafe, so it seems
to me that it is better not be part of a safe language. My point was that it
is not so "painful" since most editors (not just Emacs) handle block comments
for you.
>
> IMHO a programming language should not get hardwired towards any particular
> editor.
> Preferences for editors may be different, as well as how easily available
> they are.
> In some cases, it may even be restrictions of what editor to use.
> To mix programming language design and editor capablities is IMHO not an
> example
> 'separation of concerne'.
> Hence, I want to be able to easily comment out / uncomment out blocks of
> code easily,
> independent of whatever editor I may have to use.
>
> Futher.
> In C, for example, one can still use // in the beginning of the rows to
> comment out blocks of code.
Not in C but in C++, and this is not for a "block of code" but a single line
of code.
> The difference is that in C it is up to the programmer what approach to use.
In C++.
> That is the reason why i miss the possibility to comment out blocks of code
> in the programming langue Eiffel.
>
> As for the problem with embedded block comments I know of that problem.
> My experience is that it is less time consuming and less error prone than to
> manually
> comment out code line by line.
:)
Your time is certainly nothing compare to a code failure and the time it takes
to track down a bug in a big software.
Robert Vogler
----- Original Message -----
From: "Pascal Obry" <p.o...@wanadoo.fr>
Newsgroups: comp.lang.eiffel
Sent: Tuesday, March 19, 2002 10:04 AM
Subject: Re: Shortcomings of Eiffel?
> The point is, /* and */ (block comment) has proved to be unsafe, so it
seems
> to me that it is better not be part of a safe language. My point was that
it
> is not so "painful" since most editors (not just Emacs) handle block
comments
> for you.
I don't understand the "safety" issue in block commenting. Could you
please explain the issues. I'm assuming we're talking about block
commenting that supports nesting, such as the following.
/* begin external comment block -- comment
starts here
/* begin internal comment block A
*/ end internal comment block A -- comment
doesn't end here with nesting comments
/* begin internal comment block B
*/ end internal comment block B
*/ end external comment block -- comment ends
here
Darren New
> I don't understand the "safety" issue in block commenting.
You will, the first time you spend 3 hours trying to fix a bug in code
that's been commented out and you don't know your changes aren't
actually having any effect on the executable.
Of course, syntax-colored editting helps with such.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
Remember, drive defensively if you drink.
Pascal Obry
"Robert Vogler" <lowl...@cs.byu.edu> writes:
> I don't understand the "safety" issue in block commenting. Could you
> please explain the issues. I'm assuming we're talking about block
> commenting that supports nesting, such as the following.
>
> /* begin external comment block -- comment
> starts here
>
> /* begin internal comment block A
> */ end internal comment block A -- comment
Not at all, here the external comment is terminated. This is the whole
problem. There is no nested comment and the first */ close the outer /*.
This is a single comment:
/* /* /* /* kkkkk */
> doesn't end here with nesting comments
>
> /* begin internal comment block B
> */ end internal comment block B
>
> */ end external comment block -- comment ends
> here
>
>
Here is one example:
int
main (void)
{
int a, b=1, c=2, d=3, e=4;
a = 2
/* sdqfqdsf qds dqsfqs fsdqf qsdf dsq dsqfqdsfds
fqsdfqdsf qsdqdsfqdsf fqsdfdqdsfqsdfqsfd
qsdfqsdfqsdfqsd dsqf dsqf dsq qsfd
+ b + c
/* qdsfqsdf qsdfqsdfqsdf qsdfqsdf qsdfqsdf qsdfqsdf
qsdfqsdf qsdf qdsfqsdf qsdfqsdf qsdfqsdfqsfd */
+ d + e;
}
Note that it is not that hard here it is just to show the problem. It happens
that a block comment could be really big, so it is hard to see what is or what
is not commented out.
Or, first you write:
a = 2
/* code below is completly wrong... bla bla bla
bla bla blabla bla blabla bla blabla bla blabla bla blabla bla blabla
bla blabla bla blabla bla blabla bla bla */
/*
+ b
+ c
+ d
+ e
*/
+ 32;
Then a guy see that and think that "+ c" is not right.
a = 2
/* code below is bla bla blabla bla blabla bla blabla bla blabla bla bla
bla bla blabla bla blabla bla blabla bla blabla bla blabla bla blabla
bla blabla bla blabla bla blabla bla bla */
/*
+ b
/* + c */
+ d
+ e
*/
+ 32;
:)
Here it seems very improbable, but in real software with large piece of code
complex and lot of comments... I can tell you that this is not so rare! And
tracking down this kind of bug is very painful !
Robert Vogler
>
> This is a single comment:
>
> /* /* /* /* kkkkk */
>
I know C / C++ style block comments are dumb and error-prone. But aren't we
talking about the notion of adding *good* block comments to Eiffel --
comments that actually adhere to nesting rules?
>
> int
> main (void)
> {
> int a, b=1, c=2, d=3, e=4;
>
> a = 2
> /* sdqfqdsf qds dqsfqs fsdqf qsdf dsq dsqfqdsfds
> fqsdfqdsf qsdqdsfqdsf fqsdfdqdsfqsdfqsfd
> qsdfqsdfqsdfqsd dsqf dsqf dsq qsfd
> + b + c
> /* qdsfqsdf qsdfqsdfqsdf qsdfqsdf qsdfqsdf qsdfqsdf
> qsdfqsdf qsdf qdsfqsdf qsdfqsdf qsdfqsdfqsfd */
> + d + e;
> }
>
Syntax error -- unbalanced nesting of comments -- easily detectable and
resolvable.
Works perfectly with real nested comments.
Yngve Zackrisson
Friedrich Dominicus <fr...@q-software-solutions.com> wrote in message
news:87d6y1g...@fbigm.here...
> "Yngve Zackrisson" <yngve.z...@telia.com> writes:
(snip ... )
You dont seem to have understood my point.
That I *easily*, with whatever editor, want to be able
to comment out / uncomment a blocks of code
during my programming and compilation cycles.
> >
> > Last.
> > If I have not delimit myself to 'the programming langue Eiffel' the list
> > have been much longer.
> > What comes to my mind is my problems/frustration with previous Eiffel
tools,
> > tools setup,
> > inadequate tutorials and documentation, non-compilable example
> > programs etc.
> Well how about reading a decent book about Eiffel? How about choosing
> Halstenbach Eiffel which comes with more documentation than any other
> languages. You tell us that we should not mix up tools and langauge
> but you are doing the same here.
> Friedrich
Ok. Got your point. I should have spare this to another sub-thread.
As for my reading of decent Eiffel books. I have read OOSC2.
It was decent.
// Yngve.
Terry Sullivan
debug ("tag_name")
...
insert code here
...
end
to "comment out" code that we don't want in our production code.
Just turn it on and off in the Ace file.
TS
Loryn E. Jenkins
(From memory) When I last tried, circa 1997, the issue was covariant
redefinitions of one and zero not playing well with post-conditions
that assumed 0 and 1 (ie manifest INTEGERs) are of the current type.
Something like that prevented inheriting from INTEGER or INTEGER_REF.
Loryn Jenkins, CTO
Standard Transactions
http://standardtransactions.com
Patrick Doyle
>
>It is always astonishing to me how easily the subject in this discussion
>group diverge.
Welcome to Usenet.
--
--
Patrick Doyle
doy...@eecg.toronto.edu
Friedrich Dominicus
> >
> > This is a single comment:
> >
> > /* /* /* /* kkkkk */
> >
>
> I know C / C++ style block comments are dumb and error-prone. But aren't we
> talking about the notion of adding *good* block comments to Eiffel --
> comments that actually adhere to nesting rules?
What is the problem you can nest Eiffel comments as deep as you like.
Friedrich
Friedrich Dominicus
>
> > The difference is that in C it is up to the programmer what approach to use.
>
> In C++.
In C too if it adheres to the most up-to-date standard.
Regards
Friedrich
Greg C
> > int
> > main (void)
> > {
> > int a, b=1, c=2, d=3, e=4;
> >
> > a = 2
> > /* sdqfqdsf qds dqsfqs fsdqf qsdf dsq dsqfqdsfds
> > fqsdfqdsf qsdqdsfqdsf fqsdfdqdsfqsdfqsfd
> > qsdfqsdfqsdfqsd dsqf dsqf dsq qsfd
> > + b + c
> > /* qdsfqsdf qsdfqsdfqsdf qsdfqsdf qsdfqsdf qsdfqsdf
> > qsdfqsdf qsdf qdsfqsdf qsdfqsdf qsdfqsdfqsfd */
> > + d + e;
> > }
> >
>
> Syntax error -- unbalanced nesting of comments -- easily detectable and
> resolvable.
Try before you buy. I ran the code through three compilers, VC++ 6.0,
lcc-win32 and gcc and *none* of them reported a syntax error.
Keep in mind that comments are generally stripped out by the C/C++
preprocessor. Ancient versions of token pasting still lurk out there
with tricks like
a/**/b // becomes ab
Rather than complaining about the lack of a block comment syntax, I
suggest that the people who want it come up with a solid proposal for
a safe, easily implemented syntax for review, and if you're really
feeling adventurous, create a version of the SE compiler that
implements the proposal.
Greg
Robert Vogler
"Greg C" <gmc...@yahoo.com> wrote in message
news:62340e2a.0203...@posting.google.com...
> "Robert Vogler" <lowl...@cs.byu.edu> wrote in message
news:<a78887$eck$1...@acs2.byu.edu>...
>
> > > int
> > > main (void)
> > > {
> > > int a, b=1, c=2, d=3, e=4;
> > >
> > > a = 2
> > > /* sdqfqdsf qds dqsfqs fsdqf qsdf dsq dsqfqdsfds
> > > fqsdfqdsf qsdqdsfqdsf fqsdfdqdsfqsdfqsfd
> > > qsdfqsdfqsdfqsd dsqf dsqf dsq qsfd
> > > + b + c
> > > /* qdsfqsdf qsdfqsdfqsdf qsdfqsdf qsdfqsdf qsdfqsdf
> > > qsdfqsdf qsdf qdsfqsdf qsdfqsdf qsdfqsdfqsfd */
> > > + d + e;
> > > }
> > >
> >
> > Syntax error -- unbalanced nesting of comments -- easily detectable and
> > resolvable.
>
> Try before you buy. I ran the code through three compilers, VC++ 6.0,
> lcc-win32 and gcc and *none* of them reported a syntax error.
>
Of course there was no syntax error. C++ does not support nested comments.
C++ would have seen only a single block of comments rather than startA
startB endB (missing endA). The whole point is that Eiffel doesn't have to
be so brain dead.
> Keep in mind that comments are generally stripped out by the C/C++
> preprocessor. Ancient versions of token pasting still lurk out there
> with tricks like
> a/**/b // becomes ab
>
> Rather than complaining about the lack of a block comment syntax, I
> suggest that the people who want it come up with a solid proposal for
> a safe, easily implemented syntax for review, and if you're really
> feeling adventurous, create a version of the SE compiler that
> implements the proposal.
>
my proposal:
use standard /* */ delimiters. (the look of the delimiter characters
isn't really the issue)
adhere to nesting rules (just like matched parens)
keep // (C/C++) and -- (Eiffel) for single line comments (terminated by
eol)
Trust me this isn't that hard. I'm just a college student. I'm writing
a compiler for a language based on pascal. Nested comments are not that big
of a deal. Push down atomata (stacks) are well understood concepts.
Yes, the preprocessor or parser will be slightly (only barely) more
complicated, due to the nesting facility.
And trying to do it on C++ would break code. But it's only simple
syntax errors in most cases. Not too difficult. The hardest part would be
determining the programmers intended use of commenting.
It ought to be just fine for Eiffel. I don't know of any conflicting
syntax off the top of my head.
> Greg
Pascal Obry
"Robert Vogler" <lowl...@cs.byu.edu> writes:
> Trust me this isn't that hard. I'm just a college student. I'm writing
> a compiler for a language based on pascal. Nested comments are not that big
> of a deal. Push down atomata (stacks) are well understood concepts.
We all know that it is not that hard. But what is the point to deal
with them ?
Why should this be allowed ?
/* a comment
on multiple line
/* with an embeeded comment */
what is it for ?
*/
A piece of code comment-out ? Well if the code is not needed it could be
removed. The way to deal with temporary code, code to use at some point or
whatever is not a language issue but a configuration/revision system
issue. Use CVS or whatever to deal with that.
Greg C
> "Greg C" <gmc...@yahoo.com> wrote in message
> news:62340e2a.0203...@posting.google.com...
> > "Robert Vogler" <lowl...@cs.byu.edu> wrote in message
> news:<a78887$eck$1...@acs2.byu.edu>...
> >
>
> my proposal:
> use standard /* */ delimiters. (the look of the delimiter characters
> isn't really the issue)
> adhere to nesting rules (just like matched parens)
> keep // (C/C++) and -- (Eiffel) for single line comments (terminated by
> eol)
>
> Trust me this isn't that hard. I'm just a college student. I'm writing
> a compiler for a language based on pascal. Nested comments are not that big
> of a deal. Push down atomata (stacks) are well understood concepts.
>
> Yes, the preprocessor or parser will be slightly (only barely) more
> complicated, due to the nesting facility.
> And trying to do it on C++ would break code. But it's only simple
> syntax errors in most cases. Not too difficult. The hardest part would be
> determining the programmers intended use of commenting.
> It ought to be just fine for Eiffel. I don't know of any conflicting
> syntax off the top of my head.
Nested comments per se aren't that bad, but what happens when you
combine
them with the current commenting standard? Say we take the existing
"--"
delimiter and toss in "/* */". Now how do you interpret the following?
/* -- /* One deep or two deep?
-- /* Zero deep or one deep?
I'm just scratching the surface here. One can toss in all kinds of
permutations, levels of depth and programming text to come up with fun
variations.
The problem I see with nested comments is that when reading the
source, the human brain doesn't parse the text using a push-down
stack. At least not naturally. This makes them difficult to read, easy
to introduce by accident, and difficult to debug.
IMO layering on a second set of commenting rules is taking Eiffel in
the direction of C++ and adding complexity that is not absolutely
necessary. Better to do without and rely on other tools (editors,
revision control systems, or even the Gobo preprocessor.)
BTW the suggestion someone had to use revision control is hard to
beat. Delete the code and if everything still works, you never have to
look back :-) Goes hand in hand with the concepts of refactoring.
Greg
Peter Gummer
> BTW the suggestion someone had to use revision control is hard to
> beat. Delete the code and if everything still works, you never have to
> look back :-) Goes hand in hand with the concepts of refactoring.
Indeed! The practice of commenting out large chunks of code, although
sometimes convenient in the short term, can be a royal pain when
someone leaves the code in that state. Have you ever had to work on
code that contained large commented-out blocks, with no explanation as
to why they were left there? I worked a few years ago with someone who
did this often. I always had to figure out if it was old obsolete code
(that he forgot to delete), or new experimental code (containing the
germ of an idea that he hadn't completed).
Block commenting just encourages such sloppiness.
----
Peter Gummer
Pascal Obry
peter_...@hotmail.com (Peter Gummer) writes:
> gmc...@yahoo.com (Greg C) wrote in message news:<62340e2a.02032...@posting.google.com>...
> > BTW the suggestion someone had to use revision control is hard to
I'm the one :)
> > beat. Delete the code and if everything still works, you never have to
> > look back :-) Goes hand in hand with the concepts of refactoring.
>
> Indeed! The practice of commenting out large chunks of code, although
> sometimes convenient in the short term, can be a royal pain when
> someone leaves the code in that state. Have you ever had to work on
> code that contained large commented-out blocks, with no explanation as
> to why they were left there?
It is also a big pain for a single instruction. I have already seen that. You
have a big piece of code which does lot of math computation and in the middle
you have a single commented out instruction. No comment of course ! And here
you are wondering why was it commented out ? Was it for working around a bug
in the compiler, a bug in the computation, a slight variant of the same
algorithm... ???
> Block commenting just encourages such sloppiness.
I fully agree.
Ken Carpenter
message
>
> I'd really like to see, if you will, anonymous (and named) on-the-spot
> declarations for agents.
The ETL3 draft on Agents discusses "inline" agents that are created
without names right where they are used:
Example:
-- Pass the inline agent to my_feature for later use
x := my_feature( (i: INTEGER): BOOLEAN do Result := is_positive (i) end );
Is this what you meant?
Ken Carpenter
http://www.helikon.com/cosm/
Cosm: Massively Multiplayer Space Strategy