elj.com · Domains · Slashdot Mirror

Eiffel by Per+Wigren · 2002-11-26 03:32 · Score: 2 · on Has Software Development Improved?

There 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 by Woko · 2001-08-11 17:39 · Score: 1 · on Programming in the Ruby Language

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. by CoreyG · 2001-06-13 05:08 · Score: 3 · on Java as a CS Introductory 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 by Lumpish+Scholar · 2001-06-13 03:04 · Score: 3 · on Java as a CS Introductory Language?

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... by DonkPunch · 2001-04-27 08:42 · Score: 3 · on Google Doubles Server Farm

Interesting slogan on those shirts.

http://www.elj.com/elj-quotes/elj-quotes-1999.html

Without DbC, what's the point? by Socializing+Agent · 2000-12-11 09:14 · Score: 3 · on Is Eiffel# Better than Eiffel?

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... ] by Derwen · 2000-09-17 17:02 · Score: 1 · on The Limits of Software

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 industry by Paul+Johnson · 2000-07-16 00:12 · Score: 5 · on What About Functional Languages?

I'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? by Kickasso · 2000-07-15 16:52 · Score: 1 · on Microsoft PDC Journal

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? by Paul+Johnson · 2000-06-24 23:29 · Score: 2 · on Who Works In Gated Communities?

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? by Anonymous Coward · 2000-02-25 03:32 · Score: 0 · on C++ Answers From Bjarne Stroustrup

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 by Dwebb · 2000-02-21 13:01 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++

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 by elj · 2000-02-21 06:35 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++

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 by elj · 2000-02-21 04:55 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++

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:

[Eiffel/C++] Eiffel outperforms C++ in independent study

BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??

Re:Another Interview by elj · 2000-02-21 04:55 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++

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:

[Eiffel/C++] Eiffel outperforms C++ in independent study

BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??

Re:Another Interview by elj · 2000-02-21 04:55 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++

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:

[Eiffel/C++] Eiffel outperforms C++ in independent study

BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??

Re:Question by elj · 2000-02-21 03:26 · Score: 1 · on Ask Bjarne Stroustrup, Inventor of C++