Domain: elj.com
Stories and comments across the archive that link to elj.com.
Comments · 31
-
EiffelThere is no silver bullet. There is no simple solution that will solve all problems. But it helps to not using overly complicated languages.. Before I tried out Eiffel I had been struggling with C++ for quite a long time.. C++ is extremly hard to learn! It's easy to learn the basics, but after a while everything just becomes a mess.. It's overfeatured and it's hard to debug.. Then I gave Eiffel a try, mostly just for fun, and everything became clear.. It just makes sense! It's simply a beautiful programminglanguage!
It's pure OO, just like smalltalk, not hybrid.
It's syntax is easy to learn, write and read.
It has assertions nicely integrated into the language, everything must meet the precontitions and postcondition you set up. It feels natural to add checks and tests pretty much everywhere instead of cluttering the code with assert()s and #ifdef DEBUG..
SmartEiffel (the GNU Eiffel compiler) compiles to ANSI-C or JVM so it's portable to every platform there is.. Some other compilers can also compile to
.NET..
You can use existing C and C++ shared libraries without wrappers/bindings. (although making bindings are preferrable to make it follow standard Eiffel-style)
It manages memory for you and has a garbage collector. You never have to think about buffer overflows and malloc()/free() again!
Its runtime speed is as fast as C/C++, and sometimes even faster because the compiler compiles to C-code that is more optimized than most human beings can code..
I could rant about it forever, but I won't.. Instead you should read one of these great tutorials!
Eiffel for beginners
Eiffel: An advanced introduction
Eiffel Object-Oriented Programming
And of course, the GNU Eiffel compiler: SmartEiffel ;-)
-
Re:Strict languages vs. hacked languages
Python lacks metaclasses, lacks a true unified object hierarchy, and supports multiple inheritance (considered a very bad idea by most experts in OO. Like the "goto" statement, multiple inheritance may seem useful at times but it leads to unmaintainable code).
I'd argue exactly the opposite. The OO purists insist on MI, while languages that get-by without it aren't truly OO.
Maintaining code is a pretty thankless job, but at least with MI the changes only have to be made in one place. Java's interface based MI either forces similar code to be included in each class that implements an interface or the inclusion of lots of little stub routines that to call the smae named routine on a different class.
This totally breaks the ISA relationship and turning it into more a sort of ISA, but I've also got a copy of the class as a private member as well.
In languages that implement MI sanely and give you explicit options on resolving name clashes (eg Eiffel) means there is no ambiguity about the class structure or which routine is called. http://www.elj.com/elj/v1/n1/gew/ provides a good evalutation of Eiffel's implemenation.
I can understand people being damaged and mentally scarred by C++'s implementation of MI, but to say its as bad as the goto statement is surely a troll. -
Re:It is a good education language.
Also, in Java, there's no way to pass variables by reference. So, in order to have a method change a value that you pass to it, you have to encapsulate it in a class. Either a custom one, or something like Vector - which is not cleaner. Also, teaching someone to rely on Garbage Collection is insane, it teaches someone to write sloppy code. Java is not a cleaner environment, and it doesn't teach people to write cleaner code.
Obviously you don't understand the language, because your "pass variables by reference" comment is completely inaccurate as shown by this response.
I've seen Java coders who STILL can't figure out how to dispose of memory, basically don't understand the difference between stack and heap, and don't understand pointers well enough to dispose of an element of a linked list.
Secondly, this is exactly the point of high(er) level languages: To eliminate details that are better solved by the machine, or previously by someone else. I've seen C/C++ coders who still can't produce binary output by hand from their source files. They're so stupid they have to use a compiler.
No, it doesn't. By virtue of using Garbage Collection, it is taking memory management out of the hands of the developer, teaching people to be lazy when it comes to object instantiation and use
Garbage Collection is completely unrelated to the concepts of Object Oriented Analysis and Design. Automatic Garbage Collection allows one to focus on solving a problem. Forcing manual garbage collection is a step backwards in any modern language. It's a detail that the machine is better able to deal with, as it should be. Automatic Garbage Collection is a concept that can be applied to many differing programming languages and it is a detriment in none of them.
So, in order to have a method change a value that you pass to it, you have to encapsulate it in a class
Or behavior more commonly known as a side-effect. And also best to be avoided when dealing with Object Oriented Programming. A common mistake of many C/C++ programmers is to get caught in the procedural traps introduced and taught by C and adapt those same concepts, wrongly, into their OO work when using C++. This is probably the reason why you think encapsulating your value in a custom class is a poor decision. Maybe you should study the term encapsulation.
And as for your comments about ease of learning. It may be easier to learn C/C++ (which is the biggest source of problems: C is a procedural language, C++ is not, but the grouping of these two together produces disastrous results), but that ease is because people learn the wrong way to write OO code. Java teaches, or forces, the correct way. After learning the proper way in Java, you'll find that you actually write better OO C++.
Java allows you to solve problems, C++ allows you to solve details. As an employer, I know which one I'd want you to deal with. -
Here's what some teachers say
Doug Lea (well known C++ programmer and writer; teaches at SUNY/Oswego)
Kevin Sullivan (U. of Virginia)
A couple of less positive articles from Australia.
An article at O'Reilly. -
Re:it's still not as 31337...
Interesting slogan on those shirts.
http://www.elj.com/elj-quotes/elj-quotes-1999.html -
Without DbC, what's the point?Sorry, but this is flat-out absurd. The main advangtage of Eiffel (as I've used it in engineering projects) is Design-by-Contract, which is unenforcable in lesser languages. Real Eiffel programmers don't want the ability to link in methods from other languages, especially since Microsoft are allowing mongrel languages to target
.NET, like Java and VB, which allow blasphemies like side-effects in functions with return values.Besides, any serious OO programmer knows that an OO language without multiple-implementation inheritance is a crippled husk of a language. Even Java has it with the addition of JAMIE and delegation.
.NET is merely a platform for VenerealBasic programmers who can't do real design, and Eiffel# is an Eiffel impostor with broken arms and legs. -
Re:myth of the "ecologica[still a little OT... ]
There is nothing in your rant with which I would disagree, Paul. However I obviously phrased my original post badly as all replies missed the point (or perhaps I shouldn't have jumped into a thread on the Amish, I know little of their supernatural beliefs - my concern is with good husbandry of the soil).My point related to technology being neither a good or bad thing in itself, merely a tool. To when technology and progress have been regarded as an end in themselves, particularly (my area of concern) when applied to the soil.
Your (good) examples all point to the results of a short-sighted greed . That is why I suggest a more far-sighted approach to land management, if we (the population of earth) are to continue to eat, shelter and clothe ourselves, nevermind the important things we all want. Here is some more locally-applicable info for you.
By the way, I followed the url above your post. I will read the essay when I have enough mental space to consider these issues again.
- Derwen -
You are in a fashion industryI've spent the last several years trying to explain to colleagues why they should start using another obscure-but-good language, Eiffel, to no avail. Here is what I have learned. Note that this is not about the pros and cons of particular languages or paradigms, its about the way the programming language industry actually works.
The language industry is dominated by network effects. There are major costs with using a minority language, and for an individual project these completely outweigh the benefits, even when the benefits are very large. Hence it is generally far better to stay with a majority language. The costs of a minority language include:
- Support. Sure, you can get a GPL compiler for most languages, but on a project you don't want to have your coders digging into the code trying to fix a bug, you want them writing code. Support is something you outsource.
- Performance. Every minority language claims to be faster than C, but often isn't in practice. Whatever the truth, C and C++ are at least known quantities. Maybe the minority language will be faster, maybe slower. If its faster, well gee so what. If its slower then you have a major problem.
- Tool support. These days even small projects start by drawing UML diagrams and then converting these automatically into class templates. CASE tool vendors don't support minority languages. Ditto for testing and documentation tools. Little things like tying your compiler to your configuration control manager might potentially be major headaches. Again, its more risk that the PM can do without.
- Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major issue. Every language is going to bring some headaches, but if you have chosen a minority language then these headaches can be turned into an excuse for project failure, and hence for hanging you out to dry.
- Trained staff in a minority language are going to be rare. This does not necessarily make them more expensive (nobody else wants them), but it does make recruitment much harder and more uncertain. Alternatively you have to train all your existing people in the new language. And for Functional Languages its not just another syntax, its a whole new way of thinking. The industry went through this with OO languages, and many PMs have vivid memories of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been sent on a one week C++ course. Getting your head around a new paradigm can take months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM reasons, but for entirely rational local reasons. But rational local decisions turn into globally arbitrary decisions, as the entire herd gallops off in a random direction chosen only because most of the herd thought that most of the herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't concentrate on making it a good language, you try to persuade the herd of programmers, PMs and tool vendors that your language is the Next Big Thing. The important point here is not how much the language will do for productivity, quality and cost, it is to create the perception that everyone else thinks that this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once. For an object lesson in how to do this, see Java. For an object lesson in how not to do it, see Eiffel. Believe me, I know all about this. I have spent a long time giving presentations extolling the technical virtues of Eiffel, only to have my audience say "y Yes, but in the Real World....". In the Real World what counts is the network effects. And you know what? My audiences were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new language is to identify a niche market and attack that. Once you have taken over your niche you can expand to nearby niches and start to build momentum. Python is doing exactly this in web serving, for example. Web serving is a good niche because lots of people do it, and productivity and quality generally count for more than raw performance. Projects also tend to be small, so experiments are not the Career Limiting Moves they are for large projects. Education can also be a useful niche if you can afford to take the long view, which is how Pascal, Basic and Unix got started.
Paul.
-
Re:Can anyone read this?Bertrand Meyer? Impartial? Gimme a break.
Bertrand Meyer claims that Eiffel could prevent Ariane 5 crash, bashes Java, and warns managers against hiring "C Hackers" (in his Object Success) -- the latter bit is nicely rebutted by Robert C. Martin here.
Oh well. For the record: I don't like Eiffel. It's your typical "one idea" language. Inheritable contracts are nice, but the rest is mediocre at best.
-
How about paying your contributors?Some time ago I wrote an essay on a related subject, basically suggesting that source be freely distributed, users be charged, and the money distributed to the authors in proportion to their contribution. It was discussed on Slashdot, my home page was slashdotted, and it was forgotten about.
So, how would this fit in with the concepts of Gated Communities? I don't actually see much problem with letting people have the source: keeping it locked up does nothing to prevent piracy. Most companies I know are fairly careful about licensing the software they use, and organisations exist to police this.
The big problem with working on non-OSS software, such as Sun stuff, is that someone else gets to keep all the profits. This sucks. But if you get either an up-front payment or a share in the profits from the software you are working on, then would that make more sense? How would it be if, say, Sun started paying $10 per accepted bugfix (where "accepted" means "integrated into their codebase"), and unless you sell your patch or whatever to the company you get to keep the rights to it? Would people here find that kind of model acceptable? Would you be attracted to projects run this way? I'm interested in opinions.
Paul.
-
Re:if C++ isn't really OOPL, then why C++ at all?
Absolutely! C++ is indeed a poor OOPL. Its backwards compatibility with C (and the CPP) make it needlessly complex. One has to be extremely careful with C++ if one intends to engineer reliable OO software systems efficiently. A better OOPL would foster good techniques without being overly restrictive.
Check out Ian Joyner's paper "C++??: A Critique of C++" and the book it spawned "Objects Unencapsulated: Java, Eiffel, and C++??" for a thought-provoking and thorough analysis of the language. You won't regret it! -
Re:C++ a heap of crap
I too am often tempted to use obscene language to describe an obscene computer language.
C++ may not be the worst computer language ever invented, but it ranks near the bottom. I cringe when I think of the harm that is being done to the computer industry by programmers who think it is a good language.
See http://www.elj.com/cppcv3/ for an in-depth critique of C++. -
Re:Question
There are a fair amount of blatent errors on that page in regards to C++. For example, "super()" is a java construct, not a C++ one.
If you can send me the list, I would appreciate it. I have had a few other contact me over the last couple of months and will do an update shortly (hopefully with your corrections).
Thanks
.. Geoff -
Re:Another Interview
Well versed in programming languages but not particularly well-versed in real world programming.
Maybe your views are based on outdated information? For a more recent view see:
BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??
-
Re:Another Interview
Well versed in programming languages but not particularly well-versed in real world programming.
Maybe your views are based on outdated information? For a more recent view see:
BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??
-
Re:Another Interview
Well versed in programming languages but not particularly well-versed in real world programming.
Maybe your views are based on outdated information? For a more recent view see:
BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Re:QuestionThe above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:
From the Eiffel/C++ perspective, the following articles are worth a look:
- Eiffel for Native Speakers of C++
- The Eiffel Contract for C++ Programmers
( the application of Design by Contract in many contexts is also available) - The Personal Software Process: Eiffel vs C++
( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )
The Eiffel to C++ terminology mapping page is also worth a look.
-
Question
What is your opinion of Eiffel (www.elj.com, or www.elj.com/eiffel/intro) as a language? Object-oriented without C-like syntax.
-
Question
What is your opinion of Eiffel (www.elj.com, or www.elj.com/eiffel/intro) as a language? Object-oriented without C-like syntax.
-
Re:Java still broken after years of hypeI am always amazed when I read articles that disparage Java as hype. I find it even more amusing when you compare development in Java to the widely accepted alternatives: C and C++. Maybe it's just me, but these languages have very serious fundamental problems that are quite a bit worse than the problems you find developing in Java today. Examples abound in Ian Joyner's criticism of C++.
Why disparage a widely available development platform (Java) that is better than any other widely available platform available to us? Perhaps we should all be working to improve Java rather than tearing it down. It may be our best hope to improve programming in this decade. Other better languages may someday replace it. But why deny yourself its improvements today?
-
Eiffel Resources and LinksEiffel is one of the top real Object Oriented languages availble today. Bertrand Meyers's breathtaking and monumental book Object Oriented Software Construction lays out a systematic rational for what the requirements are for an object oriented language. Eiffel is a language implemented to meet those requirements. Support for concepts such as ``Design by Contract'' insure that software implemented in Eiffel is correct. Garbage collection, multiple inheritance, preconditions, postconditions, class invariants are other features that contribute to robust software development under Eiffel.
GNU's implementation is called SmallEiffel and runs on Linux and many other operating systems. Bertrand Meyer's ISE Eiffel which offers the ease of Delphi development is available for Windows and Linux. It is a gem. A great resource for those interested in Eiffel is the online Eiffel Liberty Journal.
-
EiffelEiffel is one of the top real Object Oriented languages availble today. Bertrand Meyers's breathtaking and monumental book Object Oriented Software Construction lays out a systematic rational for what the requirements are for an object oriented language. Eiffel is a language implemented to meet those requirements. Support for concepts such as ``Design by Contract'' insure that software implemented in Eiffel is correct. Garbage collection, multiple inheritance, preconditions, postconditions, class invariants are other features that contribute to robust software development under Eiffel.
GNU's implementation is called SmallEiffel and runs on Linux and many other operating systems. Bertrand Meyer's ISE Eiffel which offers the ease of Delphi development is available for Windows and Linux. It is a gem. A great resource for those interested in Eiffel is the online Eiffel Liberty Journal. In my opinion there are very few languages which offer direct support for quality software engineering. Ada, Sather, and Eiffel would certainly be near the top of my list.
-
Liberal Source licensing (aka COSS)
You might want to consider Liberal Source Software as a licensing model. We haven't produced an actual license yet, but its in the works. See here for details.
Briefly, the idea is to distribute software with source code and a license that allows experimental use, modification, and the distribution of modified copies, but requires payment for any kind of "real use", for whatever value of "real" is appropriate to the software. In most cases that would be commercial use, but for example with a game it would mean actually playing the game. A key part of the scheme is that the revenue is shared amongst the developers in proportion to their contributions.
This was extensively discussed on Slashdot a while ago, under the heading "Commercial Open Source Software". Some people thought it was a good idea, others did not like it. Since then I've added some more explanations and clarifications based on the comments I received.
Paul.
-
Try Eiffel: its better than Java
Tell your boss to look at Eiffel instead. Its fully compiled, and can do lots of optimisations that Java cannot. In particular it has proper generics, which mean that you can put things in a list without having to conditionally cast them back from Object.
It also has design by contracting built in, so you can get all the advantages without having to use some crummy preprocessor hack, and all the libraries have it as well.
All the library classes are fully regular. There is no wierd stuff with String having operators that you can't define in standard Java.
See (for example) Eiffel Liberty Journal. This has links to pretty much everything else Eiffel-related on the planet.
Paul Johnson.
-
Language flame wars considered harmfulEach language is based on a certain model and shines where that model's assumptions are true.
C++ is unbeatable where the criteria are upward compatibility from C and imposing absolutely zero cost for unused features.
Java shines at exporting executables across heterogeneous networks.
Perl raises the complexity of what may be reasonably done with ad hoc, quick and dirty solutions. And although I haven't used them, it's OO capabilities look like good steps in the right direction.
The same is true of other languages. Each can be useful. Each can be misused. Attacks and flaming don't accomplish much besides temporary emotional gratification to the writer.
All that said, I recommend taking a look at Eiffel. Compared to all other languages I know, Eiffel is the only commercial language that gets static typing exactly right, implements multiple inheritance powerfully and flexibly, provides generic and constrained generic classes without multiple copies of code, supports design by contract in the language itself, and has a coherent OO approch to exception handling. Here are some links:
SmallEiffel The GNU Eiffel Compiler compiles to C and JVM.
Eiffel Forum Eiffel Archive with free software and lots of links.
Eiffel Liberty Journel Lots more links to all sorts of good OO references
Interactive Software Engineering Home page of the company that introduced Eiffel, with hundreds of pages of scholarly OO papers and EiffelBase, the open source library with 140 classes and thousands of methods