Eiffel - still used?
deech
I am a language enthusiast who is interested in learning Eiffel. The
feature list, the elegance of sample code and its performance at the
Alioth shootout have sold me on its merits as a language.
But I don't see much software written in Eiffel (compared to say,
Haskell). And from the language development side, SmartEiffel compiler
hasn't had a release in almost 2 years. Are there a decent libraries
available for Eiffel?
Are anyone on this list comment on whether learning Eiffel was a
rewarding experience in terms of maturity of tools and the helpfulness
of the community?
Thanks for the feedback!
-deech
clemahieu
http://forums.eiffel.com or the mailing list at http://groups.eiffel.com
I very much enjoy Eiffel programming and would recommend it if you
want a native GC'ed language.
These news groups aren't frequented as much by current developers or
users, you might not get as many quality responses.
llothar
> feature list, the elegance of sample code and its performance at the
> Alioth shootout have sold me on its merits as a language.
Same here. I started picking up Eiffel in 2000 after 16 years of
programming in a handfull of other languagues (mostly C++ at these
days).
Without agents and tuples i would have left the language soon but
with them Eiffel is pretty competitable on the language side.
> But I don't see much software written in Eiffel (compared to say,
> Haskell). And from the language development side, SmartEiffel compiler
> hasn't had a release in almost 2 years.
Right there isn't. Open Source Eiffel development seems to be at its
final end. I would say SmartEiffel is officially dead - Dominique
Colnet
posted a message in the mailing list that his flame for Eiffel is
extinct.
Thats enough to put a tombstone on the SmartEiffel project - which
has such a terrible source code base that i doubt anyone will (and
should)
ever revive this compiler.
Also nobody picked up Visual Eiffel which was put under GPL years ago.
> Are there a decent libraries available for Eiffel?
Not that i'm aware of. The commercial version of EiffelStudio has a
few
bundled. Together with gobo they are good enough to cover your basic
data structures (but who needs more then arrays and dictionaries
today).
The only one which is worth to checkout is the WEL, the windows
eiffel library.
If you want to pay $5_000 bucks (per platform, so it easily sums up
to US$ 15_000) for it and a crappy buggy uncomfortable IDE - thats
your business decision.
> Are anyone on this list comment on whether learning Eiffel was a
> rewarding experience in terms of maturity of tools and the helpfulness
> of the community?
Well the community is worse, one reaseon is because i participate
here.
Otherwise there is no community anymore. Maybe a little bit in the
forums
from Eiffel Software - thats all.
The slow death of the only available free eiffel compiler took them
all with
them. There were definitely better times then where we hand an active
community.
I haven't seen any Eiffel project started in the last years (except
for
Helmut which doesn't count as this is not a library/application but a
tool chain tool) and outside of the incest development world
(Andreas Leitner e.g. with his eiffel wrapper etc.) there was nothing
new for almost ... well almost all years. I only know of my company
and
a guy who wrote a small World War 2 Strategy Game with Eiffel. Of
couse
i'm not talking about the invisible financial, military and medical
apps
that are using EiffelStudio. I'm just talking about the average Joe
the
Programmer visibility.
Will it get better:
I don't think so. While the language is still pretty good the lack of
a good free compiler (no EiffelStudio with GPL Libraries is not free
unless you suck on Richard Stallmans dick every day) is the problem.
Look at D, a language which could blow Eiffel and C++ out of the
water,
why isn't it coming up? Lack of libraries and lack of a trusted
compiler,
quality toolchain and suffering from the fact
the most important fact that most programmers don't get:
** PROGRAMMING LANGUAGES ARE NOT IMPORTANT ANYMORE.
Only Libraries and Tools are. If you get a solution with Java/C++
50% faster then it doesn't matter if it is only 20% worse. Java
Generics and PHP is a proof of this theorem. So does it matter to move
to Eiffel where you are total out of libraries and tools?
I have to say only for very very few projects.
And i have to say i don't like it but there is no way in reality to
change it.
clemahieu
trolled by people with no positive contribution to discussions.
Check out the mailing list or forums and you'll get a worth while
response. Also you can get the free GPL development environment from
http://dev.eiffel.com/Downloads
llothar
> Like I said, not many quality responses; this news group is mostly
> trolled by people with no positive contribution to discussions.
For his answer it was the most qualified and honest response.
And show me one single mistake in what i've written.
Friedrich Dominicus
> Like I said, not many quality responses; this news group is mostly
> trolled by people with no positive contribution to discussions.
What funny stuff did you smoke?
Tell anything that is not true about the SmallEiffel (SmartEiffel), and
then figure out the latest Eiffel Struggle competition. And try to get
your hands on the libraries. Fact is the diverse Eiffel offereres have
done everything they can to be incompatible to each other. You can maybe
take an old time Eiffel program written in ISE-Eiffel and have a good
chance on getting it compiled with SmallEiffel V0.x or V1.x
somewhat. Don't try that with "modern" Eiffels, and I suggest reading
the story of GOBO and how nicely they worked against it. So either you
have not the slighest clue about the Eiffel history or you are just
trolling.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Patrick Lamaizière
> Tell anything that is not true about the SmallEiffel (SmartEiffel), and
> then figure out the latest Eiffel Struggle competition. And try to get
> your hands on the libraries. Fact is the diverse Eiffel offereres have
> done everything they can to be incompatible to each other. You can maybe
> take an old time Eiffel program written in ISE-Eiffel and have a good
> chance on getting it compiled with SmallEiffel V0.x or V1.x
> somewhat. Don't try that with "modern" Eiffels, and I suggest reading
> the story of GOBO and how nicely they worked against it. So either you
> have not the slighest clue about the Eiffel history or you are just
> trolling.
I agree, plus the fact that GOBO was the de-facto standard library.
Georg Bauhaus
> Will it get better:
>
> I don't think so. While the language is still pretty good the lack of
> a good free compiler (no EiffelStudio with GPL Libraries is not free
> unless you suck on Richard Stallmans dick every day) is the problem.
Well, no free beer is flowing from anyones dick, right?
Assume there is no way to make Eiffel more convincing.
If compiler makers did not give up for personal reasons
but because they could only get a handful of demanding
buyers in the $$$ range, if the management of Windows
GUI development will prefer reducing the perceived risk
of getting fired by ordering from MS like everyone else(TM),
then, maybe, the Eiffel language cannot really convincing
without a killer feature: the plethora of .NET
libraries is as available to Eiffel as it is to C# or
to Visual Basic.
> Look at D, a language which could blow Eiffel and C++ out of the
> water,
> why isn't it coming up? Lack of libraries and lack of a trusted
> compiler,
> quality toolchain and suffering from the fact
>
> the most important fact that most programmers don't get:
>
> ** PROGRAMMING LANGUAGES ARE NOT IMPORTANT ANYMORE.
Languages are sometimes _considered_ not important anymore.
There are, however, observable reasons why the development
of languages continues to be payed for, to prove the contrary.
llothar
wrote:
> GUI development will prefer reducing the perceived risk
> of getting fired by ordering from MS like everyone else(TM),
> then, maybe, the Eiffel language cannot really convincing
> without a killer feature: the plethora of .NET
Unfortunately i think they even miss the next killer feature.
When i talked with Emmanuel Stapf about memory barriers it showed
me that they (ES) take multithreading still not seriously. There are
a lot of problems that needs to be solved here:
a) Rescue clause does not work fine with resource handling, relasing
mutexes in terms of exceptions is a pain in the ass.
b) How can you lock a command/query? You can lock the function body
but not the signature checking. Therefore you need something like
"synchronized" or completely rethink the idea of pre/post conditions.
c) How can i use interlocked variable setting if i can't pass
variables by reference? How can i specify volatile variables if i
compile to C? Is there any defined memory model for Eiffel (like
it is now for java)? How else can we add lock-free data structures
(definitely the next big thing in computer programming).
d) I mentioned the problem with command-query separation in another
post already. It just doesn't fit into the multithreaded programming
world.
Anyone who claims that multithreading is not important is a total
clown at best or an incompetent fool. The Eiffel world is full of
these
clowns because they defend there theory and methology over reality.
I love the converters and adapters and attributes in ECMA Eiffel, its
finally is now possible to write software as we could in Delphi 15
years ago.
Do you see the problem? Maybe in 15 years Eiffel will adapt to
multithreading.
> libraries is as available to Eiffel as it is to C# or
> to Visual Basic.
So why shouldn't i work with C#?
Tell me where is the unique selling point of eiffel today?
In old times it was competiting with C++, there the unique
selling point was safety. Then came java with a secure VM
and for a while the selling point was performance and no huge VM.
And now we are only left with a little better design by
contract then C# but the other languages are picking up here too.
> There are, however, observable reasons why the development
> of languages continues to be payed for, to prove the contrary.
Languages or IDE's and Tools? Even google seems to be no willing to
pay (enough) for "go" so they had to release it without generics
and exceptions. And Sun stopped all funding for "Fortress" even before
they went almost bancrupt.
Joachim
> I don't think so. While the language is still pretty good the lack of
> a good free compiler (no EiffelStudio with GPL Libraries is not free
> unless you suck on Richard Stallmans dick every day) is the problem.
checked their web-site and it says as long as you release your
software under an Open Source license, then you do not have to
purchase an EiffelStudio license.
BW,
Joachim
llothar
Thats what i call non free. Even in the FOSS world is the use of the
GPL license
for a library (Eiffel runtime) highly controversial.
Georg Bauhaus
> On 10 Dez., 18:08, Georg Bauhaus<rm.dash-bauh...@futureapps.de>
> wrote:
>
>> GUI development will prefer reducing the perceived risk
>> of getting fired by ordering from MS like everyone else(TM),
>> then, maybe, the Eiffel language cannot really convincing
>> without a killer feature: the plethora of .NET
>
> Unfortunately i think they even miss the next killer feature.
>
> When i talked with Emmanuel Stapf about memory barriers it showed
> me that they (ES) take multithreading still not seriously. There are
> a lot of problems that needs to be solved here:
I assume you did not want to employ memory barriers in Eiffel
code? Seeing "lock", "memory barriers", or similar low level
items mentioned with Eiffel, the language, makes me
think that there might not be a mismatch. Unless you have
been discussion QoI issues of "separate" or some such.
(Programming Operations at that level and not for part of
some run-time system or device driver or very specialized,
hardware dependent algorithms seems pointless exercise to me.
Yes, it might help reaping benefits that will likely be gone
next year, when some new hardware or better OS support suggests
we should be using different techniques to have objects execute
concurrently.)
Side note: MS has patents pending on some "lock free" techniques
using hardware based exclusion / atomicity to achieve some
specific kine of "lock-free".
> a) Rescue clause does not work fine with resource handling, relasing
> mutexes in terms of exceptions is a pain in the ass.
>
> b) How can you lock a command/query? You can lock the function body
> but not the signature checking. Therefore you need something like
> "synchronized" or completely rethink the idea of pre/post conditions.
No exclusion when objects are separate?
Sounds like a QoI issue to me? If "separate" is not supported
by any implementation that is a pity. But the concept seems quite
practical, at least provided I use it at the right level.
local
s1, s2 : separate SORTER;
do
create s1
create s2
merge(
s1.sorted(data, data.lower, data.middle),
s2.sorted(data, data.middle + 1, data.upper))
end
s1 and s2 have but one client, their services are immediately
available. The calls upon `sorted' divide and conquer
in parallel.
Eiffel, being what it is with catcalls and covariance does
not make me expect proofs that go beyond the "practicality"
level that it always used to have? So I'll be fairly
happy with this.
Agents might come in handy. (If I'm not mistaken then
Apple's "closures" (of Grand Central Dispatch) require similar
structure of arguments when they should be placed on a
queue for concurrent execution.)
What you have given as an example in the other thread
might be packaged with the help of an agent.
Make it a block and pass it to the supplier
for execution (on any processor) when the supplied
has computed its result. The state is then guaranteed
to be unchanged by some concurrent call.
> c) How can i use interlocked variable setting if i can't pass
> variables by reference? How can i specify volatile variables if i
> compile to C? Is there any defined memory model for Eiffel (like
> it is now for java)? How else can we add lock-free data structures
> (definitely the next big thing in computer programming).
Several tasks operating on one shared data structure in parallel,
without blocking each other and without messing things up can get
you very far with multicore CPUs; the good news is that a
traditional approach is sufficient, the gain in speed and
resource utilization can be impressive. For sure this
traditional approach does not solve all the problems that
CAS based algorithms might solve one day, but it sure makes
your programs faster and more responsive now. How many times
does a program run into a potentially critical section?
What kind of programs have several threads all of which
concurrently read and write the same shared hash table
incessantly?
> Anyone who claims that multithreading is not important is a total
> clown at best or an incompetent fool. The Eiffel world is full of
> these
> clowns because they defend there theory and methology over reality.
>
> I love the converters and adapters and attributes in ECMA Eiffel, its
> finally is now possible to write software as we could in Delphi 15
> years ago.
>
> Do you see the problem? Maybe in 15 years Eiffel will adapt to
> multithreading.
Sometimes Eiffel is simple and requires that your write
objects to do things that are achieved by built-in features
of other languages.
A factory can construct objects from other objects...
> And now we are only left with a little better design by
> contract then C# but the other languages are picking up here too.
The designers run into the same difficulties...
Do you think that buyers want tools because the language
used by the tools has technical advantages?
> Even google seems to be no willing to
> pay (enough) for "go" so they had to release it without generics
> and exceptions.
Google always releases early. What I find more worrisome is
that the fundamental type system of Go looks like that of
C... (or like that of the languages delivered with Plan 9,
not surprisingly).
> And Sun stopped all funding for "Fortress" even before
> they went almost bancrupt.
Have you seen Fortress? The silly mathematical syntax thing
aside, might they have helped continuing the tradition of
HPF or parallel APL so it need not be reinvented?
Does Eiffel even stand a chance of getting a parallel
loop construct? Perhaps not, but you can write one using
agents, I should think.
Georg Bauhaus
> Does Eiffel even stand a chance of getting a parallel
> loop construct? Perhaps not, but you can write one using
> agents, I should think.
>
Not terribly efficient, maybe.
llothar
> code? Seeing "lock", "memory barriers", or similar low level
> items mentioned with Eiffel, the language, makes me
> think that there might not be a mismatch. Unless you have
I don't want to see them and i don't want to use them in application
programming but there has to be a way to use CAS and interlocked
operations to write good container structures with multithreading
in mind. It's not really an option to mix eiffel generic hashtables
with some C++ written hashtable. You would loose too much - and
for no justifiable cost. I implemented Interlocked Integer and
Pointers in my Eiffel compiler in less then an evening. Just a
few "built_in" features which operate on lvalues (thats the magic).
And like it or not. You need low level multithreading or you are
out. There is no discussion about it: Implement or Die!
.NET and Java both realized this already. Eiffel will try to
ignore it as long as possible and finalley years later implement
it - maybe when we can buy 48core CPU's at ALDI/Wal Mart.
> Side note: MS has patents pending on some "lock free" techniques
> using hardware based exclusion / atomicity to achieve some
> specific kine of "lock-free".
Right. Lock Free is extremely difficult to write and a patent mine
field.
No arguments here.
> No exclusion when objects are separate?
Don't know. Everytime i read separate i think SCOOP and then i leave
the room. There is still no SCOOP implementation and i gave up
thinking about it 5 years ago. Tell me when there is a reasonable
implementation i can use to play with.
> Agents might come in handy. (If I'm not mistaken then
> Apple's "closures" (of Grand Central Dispatch) require similar
> structure of arguments when they should be placed on a
> queue for concurrent execution.)
Right agents are fantastic for the work pile design pattern
(thats what GCD is - just that the OS is adding/removing threads
to/from the workpile on demand). I'm doing almost all my MT
programming with agents and work piles.
> What kind of programs have several threads all of which
> concurrently read and write the same shared hash table
> incessantly?
Well for example the symbol and feature tables of my eiffel compiler.
Luckily i was able to decouple read/modify operations for the later
so that during validation and code generation there are only read
accesses. For a symbol table i wasn't able to find a way to do this.
Don't make yourself a fool by denying that there are a huge amount
of problems that are having high contention on classic locks.
But we will see more techniques coming up here. Just let the CPU
vendors develop them. http://research.sun.com/scalable/pubs/ASPLOS2009-RockHTM.pdf
is a nice read
Colin Paul Gloster
|-------------------------------------------------------------------|
|"[..] |
| |
|If you want to pay $5_000 bucks (per platform, so it easily sums up|
|to US$ 15_000) for it and a crappy buggy uncomfortable IDE - thats |
|your business decision. |
| |
|[..]" |
|-------------------------------------------------------------------|
Hello,
Is the IDE of Eiffel Studio buggy?
With kind regards,
Colin Paul Gloster
Friedrich Dominicus
Hm, you can check yourself how happy you are with it. Just download the
GPL version and run your tries.
Regards
llothar
wrote:
> Is the IDE of Eiffel Studio buggy?
It got better. But for example sometimes the autolayout of widgets
does not follow when you grow or shrink the window.
I haven't used it a lot because i don't find it comfortable enough for
text editing.
Ulrich Windl
[...]
> ** PROGRAMMING LANGUAGES ARE NOT IMPORTANT ANYMORE.
>
> Only Libraries and Tools are. If you get a solution with Java/C++
> 50% faster then it doesn't matter if it is only 20% worse. Java
> Generics and PHP is a proof of this theorem. So does it matter to move
> to Eiffel where you are total out of libraries and tools?
I'd like to disagree: For applications that do little or run
infrequently you may be right, but for applications that process a lot
of data frequently, performance (and resource consumption) is an issue.
For example: I have a simple audio player that can handle up to a few
hundred files; when I add more the software goes crazy. That device has
a very poor CPU. Recently I got a new mobile phone with much more memory
and a more powerful CPU (Symbian OS). But when I try to navigate in my
audio files (only a few hundred) I'll have to wait several seconds, just
so swicth from the title list to the album list. In practice it's so
slow that I never use it. Similarly slow is scrolling the long list of
titles.
So: Performance really matters, and good programmers are valuable still.
Software is produced faster and cheaper maybe, but definitely the
quality is getting worse steadily. Putting one framework on top of
another doesn't increase the quality of the software; instead the errors
accumulate. (MHO)
>
> I have to say only for very very few projects.
>
> And i have to say i don't like it but there is no way in reality to
> change it.
Regards,
Ulrich