pgc323@[EMAIL PROTECTED]
writes:
> Hello,
>
> This morning, I've read messages from distribution lists I'm registered
> with.
> Then comp.lang.eiffel came to my mind. It's been a very long time I've
> not read posts in this newsgroup.
>
> I'm touched by what is being expressed in this thread because it's
> connected with what is very alive in people who are posting messages.
>
> I can perceive some frustration, even anger or fear, in some messages.
> Are those feelings related to some unmet need of security regarding
> Eiffel or deceived hope?
Nice to read from you after so long time.
>
> * Security?
>
> Eiffel is very promising to help people achieve best practices of OO
> Software Engineering.
> The 'Eiffel-method' in itself provides some kind of security in this
> respect.
Well DBC has it's advantages and they are large enough to convince
others to follow. See e.g D even in Jave they come to the insight that
Contracts are a really good thing (tm)
>
> Paradoxically, the Eiffel tools do not provide security. Some tools are
> dying (Ve) or have died (Hact), others (ISE, SE) implement diverging
> sublanguages. Even when you take just one tool into account, it can
> evolve in such a way that what you've done before gets broken or
> involve a lot of effort (SE, ISE). New ones (Gec) are rising but there
> is no security about compatibility.
>
> The Eiffel language by itself is evolving. The latest evolution, ECMA,
> has led to a fork in 2 sublanguages. I just can express my pain about
> this because my need for security is hungry.
Well you name it security, usually one would name it
backwards-compatibility. And with all respect too every Eiffel vendor
in this aspect most implementation really suck. I know of a lot of
other languages where this is much higher on the priority lists, in
some it's so high that it starts strangling the further development of
the language.
To some time one could write Eiffel for at least 4 compilers and had a
good chance on getting that compiled on others also, this times are
gone and they won't come back. Now this means you have to stick to one
implementation and hope for the best, well this means either accept a
really strange update pricing policy or breakage of your code for
every minor update. Your choice.....
>
> I've been an Eiffel developer for 10 years and working with Eiffel 8
> hours a day, 5 days a week, for 10 years.
Well if you can earn your living with it, you're lucky....
>
> I need Language/Tool/Vendor security because we're now about 10 people
> maintaining about 20 applications with around 6000 classes related to
> our core business. That is why I regularly interact with my Eiffel
> vendor so that my needs and their needs are met in some win-win
> interaction.
Well I bet you are using ISE-Eiffel, and they have spend some effort
on backward-compatiblity. But even there I have seen problems from
updating from 3.3.x to 3.3.y, that had annoyed me way too much to go
on with it.
>
> * Vitality
>
> People who are spending a lot of energy through their implication in a
> common base for past/current/future Eiffel give me hope (Gobo, ePosix,
> and many others). This up-to-now never ending vitality reassures me.
>
> This current support of users by users and for users is, for me, the
> sign that we have enough power to serve our own need of security.
Well a good foundation would be, getting paid for writing Eiffel
code. I can not see that happening on a large enough scale....
>
> * Criticism - enthusiasm
>
> I can read a lot of criticism about Eiffel method/tools/vendors/etc...
> And I receive them as the expression of pain by people who have been
> enthusiastic about Eiffel.
> I would like to ask what they are right-now precisely missing?
> Precisely, i.e. something doable right-now.
Well exactly what you are missing also, some kind of stability....
I just remember the things which happened not too long ago. If anyone
suggested some extensions to Eiffel they were pushed down. After a
while suddenly all things get changed, we never had any ETL II
compliant Eiffel compiler, and now we have nothing even remotly
compliant to it still and other Standards. So we have currently a
small base which now is fragmented....
>
> * Why I do not read comp.lang.eiffel frequently
>
> As I said earlier, I do not read comp.lang.eiffel that much. Just
> because I've accepted that Eiffel is a niche language, that Eiffel
> tools are what they are, and that Eiffel vendor(s) need help and
> feedback (unusual in a standard vendor/client relationship).
No that is not unusual in any way. Why do you think so?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
|
