ISE makes me cross
oliver austin
cross.
We'll I'm posting because I have to tell someone that ISE 4.4 is a load of
bug ridden rubbish.
My very first post to here I called it an appalling editor, some people
scoffed and pointed at my inexperience
Well I've used it solidly for ages and yes...I can now say its appalling,
but not just the editor.
It hangs at compile time (which is painfully slow) and crashes with
segmentation faults etc at least hourly.
Hmmm..well I feel better now..thank you Oliver :o)
Patrick Schoenbach
Oliver,
I am very sorry to hear about your bad experience with your product, and
yes, I also can understand that such experiences can be very
frustrating. Instead of relieving your anger here in a public rant, it
definately would be better to let us know *exactly* what problems you
have and what ideas you have to improve our product. Your ideas are
definately welcome. Please let me know what your problems and wishes
are in detail.
It is always easy to let out anger and post a general destructive rant,
but it does not help anyone; it only stirs up emotions. Whereas, telling
us about your problems and ideas in detail helps us to improve our
product and this again helps the whole Eiffel community and also the
raise of Eiffel itself.
Thank you for your understanding.
--
Best regards,
Patrick
--
----------------------------------------
Patrick Schoenbach
Interactive Software Engineering, Inc.
email: Patrick.S...@eiffel.com
URL: http://www.eiffel.com
Patrick Schoenbach
oliver austin <oliver...@btinternet.com> wrote:
>I'm cross today, and you know when you have to tell someone when you're
>cross.
>We'll I'm posting because I have to tell someone that ISE 4.4 is a load of
>bug ridden rubbish.
>My very first post to here I called it an appalling editor, some people
>scoffed and pointed at my inexperience
>Well I've used it solidly for ages and yes...I can now say its appalling,
>but not just the editor.
>It hangs at compile time (which is painfully slow) and crashes with
>segmentation faults etc at least hourly.
>
>Hmmm..well I feel better now..thank you Oliver :o)
Oliver,
I am very sorry to hear about your bad experience with our product, and
oliver austin
Here are a few things though they are largely repetition of what I have said
before. More crop up as I work but I as I can't get it to compile my memory
isn't being jogged by having them reoccur, similarly I would be able to add
more detail.
ISE 4.4 (Windows Ver.)
Software Quality Issues
-- Crashes when load ACE file when we press System icon to load it first of
all.
-- Regular segmentation faults at compile time.
-- System hangs at freeze time (makes it a very apt name :o)
-- Having to delete Eifgen directory and/or restart the software to overcome
errant compiler errors
-- Tabs have very strange behaviour, they definitely don't do what it says
on the tin.
-- Have to click twice on an editor window to position cursor.
Functionality Issues
-- No proper undo, in the MS Word sense of multiple un-do and a maybe nice
list telling you what they were etc
-- No greying of items in the list of editor windows that are not saved.
-- Debugger does not step into/over features/classes
-- No syntax highlighting
-- Unhelpful syntax error messages (although admittedly they're often quick
to spot)
-- No comment out areas of code functionality or block comments in the
language.
Those who use ISE may be able to add more to this list.
Oliver
Roger Browne
> Admittedly ranting does little good, nor does poor quality software....!
> ...Software Quality Issues...
You just have to give the software a while to bed itself in.
Don't laugh - this explanation was really given to me; not by ISE but by
an IT manager - and there's a grain of truth in it...
ACT ONE, SCENE ONE
------------------
It's 1988. Back then, I ran a business that dealt in Microsoft products
as a sideline (before Microsoft was so big). We sold a copy of Excel 1.0
(running under Windows 2.0) to a customer who had previously been using
Lotus 1-2-3.
The customer found a few bugs in Excel, and I took them up with
Microsoft New Zealand, who were very helpful. The customer reported more
and more bugs, but his IT Manager put a stop to this.
"I know it sounds crazy", he said, "but software has to be bedded in.
Use it for a month, then report any bugs that are troubling you."
A month later, the customer was completely happy with his copy of Excel,
and had no bugs to report. "I know it can't be", he said, "but it's as
if the software has somehow bedded itself down and become bug-free as
I've been using it."
Of course, without realizing it, the user had simply been using the
parts of the software that worked well, and had not further explored the
parts with which he was not making progress.
ACT ONE, SCENE TWO
------------------
It's around 1994 or 1995, at Software Development Conference in London.
ISE has booked a stand for two days, and as (then) UK reseller for ISE
products, I came down to help Bertrand Meyer and Darcy Harrison run the
stand.
ISE had recently released "ISE Personal Eiffel for Windows with
Graphics". I knew (from feedback from my customers, and from personal
experience) that this was a very buggy compiler. By comparison, it would
make today's Eiffel products look like paragons of stability. I wondered
what lay ahead as we attempted to demo this software.
ISE had hired a PC. Much to my amazement, Bertrand inserted the CD,
installed ISE Eiffel, and proceeded to demonstrate it for two whole days
without a single crash or even the slightest blip. I didn't dare touch
the demo machine. The software might have bedded in for Bertrand, but it
certainly hadn't for me.
ACT TWO
-------
At various times, I have reported bugs to ISE. The response is usually
"We are aware of that problem, and have fixed it in the next release".
And indeed, when the next release arrives, the problem has usually been
fixed.
However, occasionally (though not recently) I have reported a problem
and received a reply such as "This cannot be so. We use it every day
ourselves, and it works perfectly". Clearly, the software had "bedded
down" for someone at ISE.
INTERMISSION
------------
I don't for one minute condone buggy software. Indeed, I have written
newspaper articles disputing the oft-heard claim that "modern software
is so complex that it is necessarily buggy".
When my business was an ISE dealer, I saw many people try the product,
of whom the vast majority don't use it for long, but a minority used it
and loved it and became extremely devoted users.
ACT THREE
---------
Over the years, many people try ISE Eiffel. Most of them don't stick
with it, and other technologies are "stealing the thunder".
But now it's the year 2000, and we find that over the years lots of
people _have_ used ISE Eiffel very successfully for important projects.
Sure, they delete EIFGEN and *.epr every now and then, but for the most
part the compiler has successfully "bedded down" on their system.
ACT FOUR, SCENE ONE
-------------------
It's 1948, and British-made motorcycles dominate the market. Sure, they
break down a lot. Sure, you have to prime them before they will even
start. But that won't put off a true motorcycle enthusiast.
ACT FOUR, SCENE TWO
-------------------
It's 1984, and Japanese-made motorcycles dominate the market. They "just
work!". Of course, there's still a dedicated band of enthusiasts who
stick with British-made motorcycles.
FINALE
------
It's 2003. One of the existing vendors (or is it a new entrant?) comes
along with an Eiffel system that "just works", and sweeps the
marketplace. Eiffel takes its rightful place amongst popular and
successful languages.
=== THE END ===
By the way, none of this is really specific to ISE. Object Tools and
Halstenbach have had similar problems (and their users also get used to
deleting the project directory when things get scrambled). ISE Eiffel
and Visual Eiffel did both eventually "bed down" for me, and I used them
very happily and successfully for important projects. Although
Halstenbach Eiffel did not "bed down" enough before my time-limited
license ran out, it probably would have if I hadused it for as long as I
had used ISE Eiffel and Visual Eiffel.
So what's the purpose of this rambling post? Not a lot, except to
introduce the concept of "bedding down" which I've not seen mentioned in
the Journal of Software Parapsychology.
Now I'll try to give some encouragement to Oliver. (An Eiffel user needs
a lot of encouragement when they can't get their compilation to finish
for days on end. I know, I've been there done that and got the T-shirt.)
Oliver wrote:
> -- Crashes when load ACE file when we press System icon to load it first of
> all.
I've had this too, and I don't know what causes it. I just delete
EIFGEN, *.epr, and the ACE file, then start again. Yeah, it's a pain
having to rebuild the ACE file, but it doesn't happen too often. Once I
think it was caused by a stray control-S in the ACE file (sometimes
eiffelbench doesn't interpret control-S as "save", but passes it to the
editing window).
> -- Regular segmentation faults at compile time.
I've had this too. It seems to be caused by some construct that the
compiler cannot cope with. I usually go back to a recent backup from a
time before it stopped compiling, then redo the work since then. Yeah,
it's a pain having to do the same work twice, but it doesn't happen too
often. Once I think it was caused by an expanded class; regular ISE
Eiffel users soon learn that non-trivial expanded classes can be
troublesome.
> -- Having to delete Eifgen directory and/or restart the software to overcome
> errant compiler errors
I always delete the *.epr file whenever I delete EIFGEN. It's almost
worth setting up a batch file to do this.
> -- Unhelpful syntax error messages (although admittedly they're often quick
> to spot)
Perhaps the messages seem unhelpful to a beginner, but to an experienced
user they are _really_ good, when combined with their clickability. For
example, if you get an error that a called feature didn't have
appropriate export status, within two clicks you can get to the line of
the feature call OR the line of the export clause OR a number of other
relevant pieces of code.
> Those who use ISE may be able to add more to this list.
Sure, but what's the point?
Instead, let me say that as you use the product more and more, you will
discover more things that you love than things that you hate.
Regards,
Roger
--
Roger Browne - ro...@eiffel.tm - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
Christophe Thibaut
I particularly like the anticipation scene in 2003. Although I can't help
thinking that before getting to such a situation one of those two events should
happen to Eiffel :
1) Eiffel is at last considered by a big company like something that could be the
next generation emblematic language and is at last "embedded" in a
suite-studio-builder (gaining the hallmark effect + the robustness of those EDIs
resulting of a 15+ years savoir-faire, not mentioning the uncomparable
development-resource power)
2) some Eiffel open source EDI becomes a quality standard à la Linux (but Eiffel
is not referring to a well known paradigm like unix for linux) and is
evangelized via some incredible -- and free -- products.
Agreed, while hoping for one (or both) of those 2 events to come, we IMO should
pass on what could still somewhat seem like amateurship and bring always more
software.
Regards
Christophe.
not.fo...@not.for.spam
wrote:
>I've had this too, and I don't know what causes it. I just delete
>EIFGEN, *.epr, and the ACE file, then start again. Yeah, it's a pain
ISE should consider using "Design by Contract" to improve the
reliability of their software.
Eric Langjahr
choice for a quality standard. Many human factors problems. And very
variable code quality
And I have noticed that my TIVO seems to HANG about as much as my
Windows NT box crashes. Now that is not neccessarily the fault of
LINUX. OTOH many have pointed to things like TIVO as proof of LINUX
potential.
Note: If anyone doesn't know about it, TIVO is basically a digital VCR
with numerous usability enhancements that is built on a Linux base.
It is marketed by Phillips.
Eric Langjahr
is (for someone used to Windows / mac tools) a bit strange.
Just the idea, for example that one fixes 'certain situations' by
deleting the project (.epr) file is very strange if one is used to
Borland or Microsoft tools. In these environment the project file is
like a make file. So project is NOT a good choice of terminology.
ACE should have been elevated and treated like a project (make) file.
I think that ISE just doesn't recognize all the semantic issues like
that and HOW important they are to customer acceptance. And the list
of strange oddities could go on and on.
I really think they should consider hiring a Human Factors expert.
Of course those who stick with the program eventually get the software
'bedded down' but by then are often not able to articulate what was so
VERY strange initially. I think that ISE needs to do MORE usability
testing with programmers who have NEVER seen their product and take
CAREFUL notes.
Often the first look is the only look and for too many that first look
leads to much confusion.
Now I don't what to just bash ISE. I still don't see a release of a
version of Visual Eiffel what works under Windows 2000. Mine is more
or less completely DOA on Win2k
On Tue, 21 Mar 2000 19:29:31 +0000, Roger Browne
<ro...@eiffel.demon.co.uk> wrote:
Jason Stokes
not.fo...@not.for.spam wrote in message ...
>>EIFGEN, *.epr, and the ACE file, then start again. Yeah, it's a pain
>
>reliability of their software.
There's this problem of Bertrand Meyer making Design by Contract sound like
a panacea instead of just a useful technique.
I'm sure if Eiffel had backers with the same resources available to them as
Microsoft and Sun, such as Java enjoys, we'd see some seriously spiffy
Eiffel stuff quick smart.
Ian Joyner
> oliver austin wrote:
>
> > Admittedly ranting does little good, nor does poor quality software....!
> > ...Software Quality Issues...
>
> You just have to give the software a while to bed itself in.
>
> Don't laugh - this explanation was really given to me; not by ISE but by
> an IT manager - and there's a grain of truth in it...
Interesting stories about "bedding in" software. In some cases, it seems true
because first time users seem to find all manner of things just from using the
software in a stupid fashion, so when they use it more the way it was intended,
it seems to work. That's why I am very concerned to get feedback from first-time
customers.
I can't say that when I started with ISE's Eiffel three years ago, that I had
such problems, apart from quickly finding out a few things I shouldn't do, like
change the name of a class. I think this is fixed now. When used to EiffelBench,
it is great because you can browse around directly from the source, and you don't
need to rely on so many finds to find things. However, it would be nice if they
integrated the editor with browsing better by writing their own editor. But there
is only so much one Eiffel vendor can do.
OTOH, I am always a bit suspicious of such flaming posts because it is a tactic
by some unscrupulous companies to rubbish others products.
> FINALE
> ------
>
> It's 2003. One of the existing vendors (or is it a new entrant?) comes
> along with an Eiffel system that "just works", and sweeps the
> marketplace. Eiffel takes its rightful place amongst popular and
> successful languages.
Ah now that would be Object Tools Eiffel for Mac ;-)
--
Ian Joyner
i.jo...@acm.org http://homepages.tig.com.au/~ijoyner/
Eiffel for Macintosh
http://www.object-tools.com/products/eiffel-s/index.html
Objects Unencapsulated -- The book
http://www.prenhall.com/allbooks/ptr_0130142697.html
http://www.elj.com/oue1/ (review)
Eirik Mangseth
ISE's case is 4.5. Yes, the upgrade
is a bit pricey, but IMHO worth it (and I pay for the upgrades myself).
4.5 is, although not bug free, a vast improvement on 4.4 and that message
have been reiterated in c.l.e. ever since 4.5 was released.
Having said that, I agree that there are especially UI issues to be dealt
with in the product, but I know that ISE is aware of those isssues and
hopefully they will address them soon.
Secondly, EiffelBench is based on EiffelVision1 which is a fairly complex
library causing quite a few bugs to creep in and that may have cost ISE more
users than they would like. I'm lucky enough to have been able to have a go
at EiffelVision2 and it is a *very* good product. So, perhaps we'll see a
stable version of EiffelBench based on EV2 sometimes in the future. At least
we can hope that much.
Best regards
Eirik Mangseth
Stockpoint Nordic AS, Lysaker, Norway
"If I can't Eiffel in heaven, I won't go"
"oliver austin" <oliver...@btinternet.com> wrote in message
news:8b86vj$kur$1...@neptunium.btinternet.com...
> Admittedly ranting does little good, nor does poor quality software....!
> Here are a few things though they are largely repetition of what I have
said
> before. More crop up as I work but I as I can't get it to compile my
memory
> isn't being jogged by having them reoccur, similarly I would be able to
add
> more detail.
>
> ISE 4.4 (Windows Ver.)
> Software Quality Issues
> -- Crashes when load ACE file when we press System icon to load it first
of
> all.
> -- Regular segmentation faults at compile time.
> -- System hangs at freeze time (makes it a very apt name :o)
> -- Having to delete Eifgen directory and/or restart the software to
overcome
> errant compiler errors
> -- Tabs have very strange behaviour, they definitely don't do what it says
> on the tin.
> -- Have to click twice on an editor window to position cursor.
>
> Functionality Issues
> -- No proper undo, in the MS Word sense of multiple un-do and a maybe nice
> list telling you what they were etc
> -- No greying of items in the list of editor windows that are not saved.
> -- Debugger does not step into/over features/classes
> -- No syntax highlighting
> -- Unhelpful syntax error messages (although admittedly they're often
quick
> to spot)
> -- No comment out areas of code functionality or block comments in the
> language.
>
> Those who use ISE may be able to add more to this list.
>
> Oliver
>
>
>
Ulrich Windl
> -- Have to click twice on an editor window to position cursor.
Especially frustrating to me: You can mark text only after an
additional click.
>
> Functionality Issues
> -- No proper undo, in the MS Word sense of multiple un-do and a maybe nice
> list telling you what they were etc
I can only guess the author of the software hasn't read OOSC2: In my
last course I had students write an editio with undo, and they
actually succeeded doing so.
> -- No greying of items in the list of editor windows that are not saved.
> -- Debugger does not step into/over features/classes
In Halstenbach's ISS you can't se a breakpoint in the middle of a
routine unless already at a breakpoint. Nasty: set breakpoint, run,
set another breakpoint, clear first breakpoint, continue.
> -- No syntax highlighting
No autoindent.
> -- Unhelpful syntax error messages (although admittedly they're often quick
> to spot)
In many cases you can't even position to that spot. Mr Meyer said:
Real users don't make syntax errors. I feel quite virtual these days
;-)
> -- No comment out areas of code functionality or block comments in the
> language.
That is intentional (See OOSC2 on style). GNU Emacs can! (BTW: Why I
am using GNU EMacs in windows wile ISS BASE is up and running? It's
much easier to edit with GNU Emacs!)
>
> Those who use ISE may be able to add more to this list.
ISS BASE is similar. When the IDE crashes, it writes a backtrace, but
usually you can't read it befor the window closes ;-)
Regards,
Ulrich
Ulrich Windl
> oliver austin wrote:
>
> > Admittedly ranting does little good, nor does poor quality software....!
> > ...Software Quality Issues...
>
> You just have to give the software a while to bed itself in.
[...]
I was quite surprised when my program stopped working after being
frozen. Repeated incremental melts worked however. Of course I had no
external routines and nasty things like that. I was surprised that
nobody had the error before me (1999).
Recently I had a problem with a redefined "is_equal" that is used
polymorphically in a generic class. The program finds invalid types at
runtime and gets segmentation faults. If I remove my "is_equal",
everything works fine. Still no external stuff or low-level
programming involved.
I mean: If Eiffel can't prove by it's own environments that it is a
better language to write good software, it proves the opposite to be
true.
Regards,
Ulrich
Ian Joyner
> I mean: If Eiffel can't prove by it's own environments that it is a
> better language to write good software, it proves the opposite to be
> true.
No, it doesn't prove that. The two factors that discount this as a proof are
that Eiffel as both a language and ISE environment are very ambitious and make
no compromises. In fact, I think it is difficult to build anything on top of
windows to be stable.
The second factor is that all Eiffel vendors have very few developers working
on their stuff, not the hundreds that larger corporations have. I don't agree
that you need 100s, in fact this is the bulldozer approach to software
development that I particularly dislike. However, ISE and other vendors have
done very well to produce the software they have considering the restricted
resources they have and the number of directions the industry is pulling them
in, ie., Java, COM, CORBA, etc.
Having said that, I agree that all Eiffel vendors could do better, but they
could also do with more market share, therefore more income and being able to
pay more developers and support staff.
Graham Perkins
> ...
> But now it's the year 2000, and we find that over the years lots of
> people _have_ used ISE Eiffel very successfully for important projects.
> Sure, they delete EIFGEN and *.epr every now and then, but for the most
> part the compiler has successfully "bedded down" on their system.
>
I just wanted to add that these features are not unique to ISE.
The same thing is happening to me with JBuilder. It has a lot
of trouble with developers renaming, moving, or deleting source
code files. You can do some of that from within the environment,
but it doesn't keep compiled code in synch. Other file
management you have to do from the operating system.
Often you just have to shut down, go into windows explorer,
move/delete/rename your files and alter their package declarations
by hand, delete the project file and all the compiled code, restart
JBuilder with a new project, and add all the files back in.
Berend de Boer
oliver austin wrote:
> -- Having to delete Eifgen directory and/or restart the software to overcome
> errant compiler errors
To make this comparison fair, a tool as Delphi also has a Build option.
It helps. And I'm quite sure Visual C++ users also use their complete
build future when things have screwed up.
It would already help a lot of ISE would add a Clean Melt option or so
which would do exactly this (delete .epr and EIFGEN). Lots more
userfriendly, and no more people complaining about having to delete
stuff (well that's just what happens, but nobody knows it anymore :-) ).
Groetjes,
Berend. (-:
Berend de Boer
Ulrich Windl wrote:
> That is intentional (See OOSC2 on style). GNU Emacs can! (BTW: Why I
> am using GNU EMacs in windows wile ISS BASE is up and running? It's
> much easier to edit with GNU Emacs!)
Welcome, this guy is doing the same. And this works quite well is ISE
seems to pickup changes on disk quite well (at ISE they probably all use
a different editor than the builtin so this feature works quite well :-)
).
Groetjes,
Berend. (-:
Yngve Zackrisson
Eric Langjahr <lang...@itsdata.com> wrote in message
news:742gds0ia95quinlj...@4ax.com...
>
> I think that ISE just doesn't recognize all the semantic issues like
> that and HOW important they are to customer acceptance. And the list
> of strange oddities could go on and on.
>
> I really think they should consider hiring a Human Factors expert.
>
I have also had these thoughts.
User Interface Design expertise, On-Line Documentation writers, etc ...
seems lacking. Maybe also Testers.
> Of course those who stick with the program eventually get the software
> 'bedded down' but by then are often not able to articulate what was so
> VERY strange initially. I think that ISE needs to do MORE usability
> testing with programmers who have NEVER seen their product and take
> CAREFUL notes.
Has the ISE Developement environment ever been in a usability lab ?
>
> Often the first look is the only look and for too many that first look
> leads to much confusion.
True, at least for me (I am an hobyist in Eiffel).
When I try new software I want to *reuse* as much as possibel of my previous
experience.
In Windows this means that the software should conform to normal Windows
standards.
It should also be easy to install and create the first simple (GUI)
application with.
Regards
Yngve Zackrisson.
Eric Langjahr
want this to become an ISE bashing session but just one other point.
ISE makes it very difficult for developers to keep their product
current or go back and get upgrades as the costs are HIGH.
From 4.3 to 4.x is about $1000 to upgrade the enterprise version. And
basically these .x releases are bug fix releases. Yes there may be a
language enhancement occasionally but they basically amount to bug fix
releases.
For Eiffel or any tool to succeed it generally has to be brought in
via the back door to many corporations. This generally means that
developers need to be the early adopters, and in most cases, the early
funders of this research.
So basically, if I can use myself as an example, my purchasing of
Eiffel products still amounts to R&D. I try and look at the product
and evalute how I can fit it into my business structure and if it is
ready for prime time. I have tended to purchase an upgrade around
every year. Happily I have to say that ISE is making progress. I can
see a time in the not too distant future when I might be able to take
some of the development that is now done in Delphi or C++ and start
doing it in Eiffel.
Obviously there are many issues, beyond the tools and language, that
come into play.
But I think with cost of upgrades being so high, often the first look
is the last.
And I realize that there are other versions besides the Enterprise
version with lower costs but most professional programmers will not
neccessarily settle for good, or better, but want BEST.
I realize this is a catch-22. I certainly don't suggest that ISE
should not want to make a profit. And I certainly realize the need
for a revenue stream so that Eiffel can continue to be marketed. So I
am not sure what the solution is. But I do know that there is a basic
problem with the pricing structure that seems to be used by ISE.
Bottom line for me, and many others I suspect, is that I am already
SOLD on the language. There are no questions about its elegance or
superiority to any other OO statically typed language in the
marketplace. But the tools and libraries surrounding the language
are what will make or break it.
Right now I think most people realize that Eiffel is a great language
with some unique advantages. Unfortunately that alone will not be
enough.
On Wed, 22 Mar 2000 23:13:51 +1100, Ian Joyner <i.jo...@acm.org>
wrote:
Thomas Beale
Berend de Boer wrote:
> It would already help a lot of ISE would add a Clean Melt option or so
> which would do exactly this (delete .epr and EIFGEN). Lots more
That's actually a very good idea - maybe a right button click on the melt button,
so as not to waste another button. Why don't you forward this suggestion to ISE -
I'm sure they would consider it.
- thomas beale
Ian Joyner
> Berend de Boer wrote:
>
> > It would already help a lot of ISE would add a Clean Melt option or so
> > which would do exactly this (delete .epr and EIFGEN). Lots more
>
> That's actually a very good idea - maybe a right button click on the melt button,
> so as not to waste another button.
Good idea, but right clicking is not a good user interface. The problem with a lot
of MS and MS influenced software, is they have these invisible little tricks that
encourages people to write books like xx Secrets Revealed. There should be an
explicit way to do anything in a user interface and optionally a not so obvious but
still fairly explicit short cut (like command key equivalents on menu items).
> Why don't you forward this suggestion to ISE -
> I'm sure they would consider it.
>
> - thomas beale
--
Thomas Beale
> I think everyone has made some good points. And I certainly don't
> want this to become an ISE bashing session but just one other point.
>
> ISE makes it very difficult for developers to keep their product
> current or go back and get upgrades as the costs are HIGH.
They are, somewhat, but not compared to the kinds of tools routinely purchased by
corporations, e.g. C++ development platforms, CM software, databases and so on. I
think that the real problem is a general one: in today's IT world there are vastly
more very small companies or single developers, often working on contract. People
in this position (I am now one) are very far from being able to just go and buy 5 x
$1000 licences of a tool and not think about it, in the way a corporation can.
For this reason, some of Eric Raymond's arguments about service-model (i.e. rental
model) charging for software tools are germane. An alternative model for Eiffel
vendors might be to just pay say "$100/year forever". With this kind of pricing
strategy available, vendors might be able to have a lot more customers on board,
and still earn the same or more income; more to the point, the income stream
matches more closely the ongoing expenditure by the vendor: enhancements, suppport,
bug fixing and so on.
> From 4.3 to 4.x is about $1000 to upgrade the enterprise version. And
> basically these .x releases are bug fix releases. Yes there may be a
> language enhancement occasionally but they basically amount to bug fix releases.
Hm. I wouldn't call agents a bug fix, for example, but I can see what you mean - if
there is a new feature you don't use, then you will see the release as a bug fix
release.
> For Eiffel or any tool to succeed it generally has to be brought in
> via the back door to many corporations. This generally means that
> developers need to be the early adopters, and in most cases, the early
> funders of this research.
I have brought Eiffel into 2 corporations and one institution (a research
hospital). In none of these cases was price a problem - not even remotely. Nor were
concerns about some annoying dialogue box bug in the IDE. They were all the other
arguments about "it's not Java", "will it stay around", "where to get engineers who
know this", "does it really do anything for quality" and so on.
I think price is a problem only for the single developer or very small company.
> ...
>
> But I think with cost of upgrades being so high, often the first look
> is the last.
So perhaps both corporate and single developer charging models need to exist. Or
maybe a per-seat rental model should just be used for everyone - maybe you have to
sign on for 5 years at a time, to help the vendor a little bit.
> And I realize that there are other versions besides the Enterprise
> version with lower costs but most professional programmers will not
> neccessarily settle for good, or better, but want BEST.
Yes, anyone doing real work will want "the lot".
> I realize this is a catch-22. I certainly don't suggest that ISE
> should not want to make a profit. And I certainly realize the need
> for a revenue stream so that Eiffel can continue to be marketed. So I
> am not sure what the solution is. But I do know that there is a basic
> problem with the pricing structure that seems to be used by ISE.
Well I don't think they're any different from any other vendor. Each new VC++ costs
far too much (and look what you get - a broken language and 50,000 pages of
detailed help to make you feel better about it! Plus an instant donation of 400Mb
of your drivespace...). As I say, I think that the real problem is the changing
developer demographic.
- thomas beale
Charles Hixson
buying the Professional version, and being disappointed, more than once. That I've
just bought it again is more of a testament to my disappointment with the
alternatives that a vote of confidence for ISE (actually, I feel quite ripped off,
even if this time I didn't purchase the full package...of course that means that
I'm likely to be unable to do something because the needed tool isn't available,
but I can't afford to keep on shelling out cash so freely).
ISE isn't the only vendor to adopt this approach, either. I frequently end up
feeling that the vendor is doomed, so I might as well not bother. But I
drastically need a portable GUI builder that produces code that can be statically
linked into my programs. (I may end up having to go with Python/tkInter, which is
cheap and comes with a decent Windows installer. I truly want to avoid the immense
hassle that not having a statically linked GUI package would cause me, but there
may be no way around it.)
Charles Hixson
> Eric Langjahr wrote:
-- everything snipped
I don't think that the price is a problem for corporations or reasonably large
companies. For individual developers it's a bit different. For individual developers
who aren't really sure what language they will end up using......... I find it .. very
unpleasant.
And then I end up on a mailing list as if I could afford $2000 for a jaunt off to some
fancy location. Nothing in the way of training available at any affordable price, of
course. (Well, I didn't really expect that, but did they need to rub my nose in it
with that mailing list ad!)
Jim Cochrane
Eric Langjahr <lang...@itsdata.com> wrote:
>I think everyone has made some good points. And I certainly don't
>want this to become an ISE bashing session but just one other point.
>
>ISE makes it very difficult for developers to keep their product
>current or go back and get upgrades as the costs are HIGH.
>
>basically these .x releases are bug fix releases. Yes there may be a
>language enhancement occasionally but they basically amount to bug fix
>releases.
>
>
>Obviously there are many issues, beyond the tools and language, that
>come into play.
>
>is the last.
I think ISE's costs are quite reasonable for most companies. But I think
it would be a wise move for ISE to re-evaluate their pricing for individual
developers.
--
Jim Cochrane
j...@dimensional.com
Friedrich Dominicus
> ISE isn't the only vendor to adopt this approach, either. I frequently end up
> feeling that the vendor is doomed, so I might as well not bother. But I
> drastically need a portable GUI builder that produces code that can be statically
> linked into my programs. (I may end up having to go with Python/tkInter, which is
> cheap and comes with a decent Windows installer. I truly want to avoid the immense
> hassle that not having a statically linked GUI package would cause me, but there
> may be no way around it.)
You might have a look at VEGTK. IMO the update prices are too higth for
ISE and no discount while long-term customer or for finding bugs (even
show-stoppers do not count ;-), but you don't get a fix either. Anyway
if you have a look e.g on FRANZ Common Lips than you'll be suprises how
muchthey charge. My comment were answered with. "But you are x-times
more productive")
If I compare cheaper C and C++ environements with Eiffel than Eiffel is
in a good position. So Eiffel may enable one to be more than 5 times or
so more productive. Now than IMO it can cost 5 times more.
But if I compare Eiffel to Common Lisp, I would think that Common Lisp
would win. So in fact you can get Xanalys (ex Harleqin) Professional
Version for $795 or so. This includes CLIM (which should be portable
across platforms) and so I would think this price is very competitive in
comparison to Eiffel.
And if you look tought the Libraries and Tools which are part of this
package Eiffel looses hands-down. So you might check simular offers and
decide yourself.
Regards
Friedrich
Charles Hixson
times as good. I've been more successful at getting screen drawing done with free tools
in Python than with fairly expensive tools in Eiffel. What Eiffel may offer that I need
is the ability to produce stand-alone statically linked programs. But I don't even know
yet that I can do this in a way that is relatively easy to port from OS to OS and to a
machine that I never touch, except over a voice phone link ("OK, the first step is you
put the floppy into the drive. The shiny metal part goes in first and the round metal
part should be on the bottom." -- This isn't an exaggeration, merely an extreme case.)
The problem that I have with Python is that it's hard to get it working as a stand-alone
system. Not only my program needs to be installed, but also the Python interpreter and
whatever graphics library I end up using (tkInter [tcl/Tk], wxWindows, ???). This is
difficult to do without any support at the user site.
The problem with Eiffel is that (OK, I need to look into VEGTK) it's difficult to design
complex data entry screens to collect all the various information that I need.
Currently I'm using MSAccess for this, and it was working before they brought out Access
2000. Now folk have a mixture of different incompatible versions of access, and some who
have installed the new version installed it in such a way that it can't read databases
that include Visual Basic programs. (And, of course, from my perspective Basic is a
really vile language.) But Access can do the job. It can design screens. It can print
reports. It's a terrible language. It's expensive (but since it's a part of MSOffice, I
can convince anyone to buy it -- or justify not supporting them). But it comes in several
incompatible versions, and I can't control what the users install on their machine. So I
want something that's statically linked. But if it isn't a part of MSAccess (or MS
Developers Studio) then I, personally, have to shell out the cash. So I get a bit irate
over folk who say "Buy this and be 10 times as productive!". I'm paid the same no matter
what. Only MS programs will be paid for (and not always them, but I can find out in
advance). Being 10 or 20 times as productive (if it were really true) would be
professionally satisfying, but it wouldn't bring me in one extra dime.
(Perhaps this should really have been a part of the other thread: "Why didn't people
stick with Eiffel", but since I just bought a new ISE Eiffel compiler, that doesn't seem
quite apropos. But the documentation is poor. The cost is ... high. And I'm still not
sure that I can actually use it to get the job done. So this thread really seems more
appropriate.)
OTOH, since I did just buy a new Eiffel compiler, I'm not anxious to purchase another new
experiment. Three years ago Harlequin Lisp couldn't do what I need to do (or at least, I
couldn't make it do what I need to do). But then three years ago what I bought didn't
include CLIM and it wasn't cross-platform. I never got as far as trying to generate
statically linked programs, so I have no idea as to whether or not that would have been
practical. In the time since then Harlequin has sold off part of their software arm, so
I feel unsure of the support committed to what's left. Still, I did, in the past decade,
look at both Franz and Harlequin Lisp. Purchases are not followed up by reasonable
upgrade offers. The basic packages didn't work sufficiently well to be useable in a
timely manner. (But at that time I was developing on Win95 and Allegro for Windows was, I
believe, a new product. Possibly if I were to spring for another copy in a new
environment [at a full price, I've checked!] it would do what I need. But I haven't been
able to prove that, and I prefer to only gamble with what I can afford to lose.)
Friedrich Dominicus
>
> But to me Eiffel doesn't look 5 times better than Python. Perhaps twice as good, or 2.5
> times as good. I've been more successful at getting screen drawing done with free tools
> in Python than with fairly expensive tools in Eiffel. What Eiffel may offer that I need
> is the ability to produce stand-alone statically linked programs.
Now you requirements are clear so you just have to check if Eiffel can
provide the facilities you like. If they claim they can than it has to
work if not I would return my copy and claim a refund.
>But I don't even know
> yet that I can do this in a way that is relatively easy to port from OS to OS and to a
> machine that I never touch, except over a voice phone link ("OK, the first step is you
> put the floppy into the drive.
How should that work, you can't easily port a statical library from one
OS to another. So I guess you mean from OS to OS. Now statically linked
means that everything is included for to run on one specifig Operating
System and Eiffel can do that.
> The shiny metal part goes in first and the round metal
> part should be on the bottom." -- This isn't an exaggeration, merely an extreme case.)
>
> The problem that I have with Python is that it's hard to get it working as a stand-alone
> system. Not only my program needs to be installed, but also the Python interpreter and
> whatever graphics library I end up using (tkInter [tcl/Tk], wxWindows, ???). This is
> difficult to do without any support at the user site.
Now it is not terrible difficult to install Python on any machine and
the space it needs seem to be reasonable.
>
> The problem with Eiffel is that (OK, I need to look into VEGTK) it's difficult to design
> complex data entry screens to collect all the various information that I need.
Now it seems to me that you need some good interface to an Database. So
I would look for software which
>
> Currently I'm using MSAccess for this, and it was working before they brought out Access
> 2000. Now folk have a mixture of different incompatible versions of access, and some who
> have installed the new version installed it in such a way that it can't read databases
> that include Visual Basic programs. (And, of course, from my perspective Basic is a
> really vile language.) But Access can do the job. It can design screens. It can print
> reports. It's a terrible language.
e.g to Access. This seems to mean you should look of ODBC access from
Eiffel and or Inteface Eiffel whatever Database you like to use.
> It's expensive (but since it's a part of MSOffice, I
> can convince anyone to buy it -- or justify not supporting them). But it comes in several
> incompatible versions, and I can't control what the users install on their machine. So I
> want something that's statically linked. But if it isn't a part of MSAccess (or MS
> Developers Studio) then I, personally, have to shell out the cash. So I get a bit irate
> over folk who say "Buy this and be 10 times as productive!". I'm paid the same no matter
> what.
Oh this is clear just the Vendors say we're so expensive because you can
deliver faster (and then it may be cheaper for you). So maybe statically
linked applications is what you need. It would be a suprise for me if
you can't use Eiffel for that.
Only MS programs will be paid for (and not always them, but I can find
out in
> advance). Being 10 or 20 times as productive (if it were really true) would be
> professionally satisfying, but it wouldn't bring me in one extra dime.
This is simple not true. You can do more in the same time. Or you need
less time to get the work done. So it brings you a lot of extra-dims.
>
> (Perhaps this should really have been a part of the other thread: "Why didn't people
> stick with Eiffel", but since I just bought a new ISE Eiffel compiler, that doesn't seem
> quite apropos. But the documentation is poor. The cost is ... high.
This are weak points I've to admit, just it's you who can check before
using or buying a product and you may get a cheaper personal licence
> And I'm still not
> sure that I can actually use it to get the job done. So this thread really seems more
> appropriate.)
I think I can follow but you do not have said what you're exact job is.
>
> OTOH, since I did just buy a new Eiffel compiler, I'm not anxious to purchase another new
> experiment. Three years ago Harlequin Lisp couldn't do what I need to do (or at least, I
> couldn't make it do what I need to do). But then three years ago what I bought didn't
> include CLIM and it wasn't cross-platform. I never got as far as trying to generate
> statically linked programs, so I have no idea as to whether or not that would have been
> practical. In the time since then Harlequin has sold off part of their software arm, so
> I feel unsure of the support committed to what's left. Still, I did, in the past decade,
> look at both Franz and Harlequin Lisp. Purchases are not followed up by reasonable
> upgrade offers. The basic packages didn't work sufficiently well to be useable in a
> timely manner. (But at that time I was developing on Win95 and Allegro for Windows was, I
> believe, a new product. Possibly if I were to spring for another copy in a new
> environment [at a full price, I've checked!] it would do what I need. But I haven't been
> able to prove that, and I prefer to only gamble with what I can afford to lose.)
There are some points in the last paragraph just I guess this is
off-topic here. I just can tell that there are three Eiffel-vendors and
a free alternative. It seems that you mainly work on Windows. Now Visual
Eiffel is Windows centric as is Halstenbach-Eiffel. Halstenbach Eiffel
comes on Windows with Tune. And this might be what you're looking for.
So why not don't you try to make a small example with ISE-Eiffel and see
how it worked out. If it does not work but ISE claims it should then
they have to help you IMO. You can check other alternatives with your
small example and you might see what suits you. It may be that you have
to buy another product but that is a risk you have to bear regardless of
the product you use.
But IMO it's up to you to look for what you really need. Nobody else can
do that, so it's unfair to claim that e.g ISE makes you cross while you
don't have checked with you requirements.
Regards
Friedrich
ric...@netlabs.net
Charles Hixson <charle...@earthlink.net> wrote:
[...]
>...But I
> drastically need a portable GUI builder that produces code that can be
statically
> linked into my programs. (I may end up having to go with
Python/tkInter, which is
> cheap and comes with a decent Windows installer. I truly want to avoid
the immense
> hassle that not having a statically linked GUI package would cause me,
but there
> may be no way around it.)
>
Perhaps you should consider eGTK
(http://www.netlabs.net/~richieb/gtk_eiffel.html) and the Glade/eglade
UI builder. All open source and free.
...richie
http://www.netlabs.net/~richieb
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Michael P. Soulier
<oliver...@btinternet.com> wrote:
>I'm cross today, and you know when you have to tell someone when you're
>cross.
>We'll I'm posting because I have to tell someone that ISE 4.4 is a load of
>bug ridden rubbish.
>My very first post to here I called it an appalling editor, some people
>scoffed and pointed at my inexperience
>Well I've used it solidly for ages and yes...I can now say its appalling,
>but not just the editor.
>It hangs at compile time (which is painfully slow) and crashes with
>segmentation faults etc at least hourly.
>
>Hmmm..well I feel better now..thank you Oliver :o)
Wow, is it written in Eiffel? I thought you couldn't write bug-ridden
software in Eiffel? ;-) Sorry, just had to take a poke at propaganda.
Personally, I've been using SmallEiffel and Vim. I tried the ISE Eiffel, but
the editor doesn't seem any more advanced than a windoze notepad. The only way I
could get syntax shading was in clickable mode, which doesn't allow editing, so
that seems kind of strange. I also found inconsistencies where sometimes the GUI
wouldn't allow me to go into clickable mode. Maybe that was just their Linux
implementation, but they claim bug-free software, and they don't seem to be able
to deliver in their own tools. The help doesn't even work. At all.
Ah well. I'm sure it will improve with time and sweat.
Mike
--
Michael P. Soulier <msou...@storm.ca>
--------------------------------------
"To listen to the words of the learned, and to instill into others the
lessons of science, is better than religious exercises."
-- Prophet Muhammad (pbuh)
Ian Joyner
> On Tue, 21 Mar 2000 11:59:33 -0000, oliver austin
> <oliver...@btinternet.com> wrote:
> >I'm cross today, and you know when you have to tell someone when you're
> >cross.
> >We'll I'm posting because I have to tell someone that ISE 4.4 is a load of
> >bug ridden rubbish.
> >My very first post to here I called it an appalling editor, some people
> >scoffed and pointed at my inexperience
> >Well I've used it solidly for ages and yes...I can now say its appalling,
> >but not just the editor.
> >It hangs at compile time (which is painfully slow) and crashes with
> >segmentation faults etc at least hourly.
> >
> >Hmmm..well I feel better now..thank you Oliver :o)
>
> Wow, is it written in Eiffel? I thought you couldn't write bug-ridden
> software in Eiffel? ;-) Sorry, just had to take a poke at propaganda.
What propaganda is that? I don't think such propaganda exists. The techniques in Eiffel
help write better quality software, no one would claim that you couldn't write
bug-ridden software in Eiffel. After all it is easier to do than write software with
few bugs.
Friedrich Dominicus
>
> Wow, is it written in Eiffel? I thought you couldn't write bug-ridden
> software in Eiffel? ;-) Sorry, just had to take a poke at propaganda.
One can write bug-ridden software in any language, just Eiffel makes it
a bit harder ;-)
Now the question was is it written in Eiffel. AFAIK it's a mixture out
of C and Eiffel. So to what extend they use Eiffel is beyond my
knowledge, but they use e.g for their classes ARRAY and STRING C.
>
> Personally, I've been using SmallEiffel and Vim. I tried the ISE Eiffel, but
> the editor doesn't seem any more advanced than a windoze notepad.
You're right it one of the poorest pieces of nearly any Eiffel IDE. I do
not know how well Visual Eiffel does.
>
> Ah well. I'm sure it will improve with time and sweat.
Or the next release ...
Regards
Friedrich
Michael P. Soulier
>
>What propaganda is that? I don't think such propaganda exists. The techniques in Eiffel
>help write better quality software, no one would claim that you couldn't write
>bug-ridden software in Eiffel. After all it is easier to do than write software with
>few bugs.
My experience has been that everywhere I look for Eiffel information, I get
told that it's much easier to write bug-free software using it. The eiffel
homepage, posts on in this newsgroup, Meyer's book, etc.
"To preserve your investment by giving you robust software that can be
reused in many different developments."
I realize that this is the salesman attitude that you defended previously,
and granted, companies must do a certain amount of this. However, I always refer
to such things as propaganda, even in my own company. My first thought has
always been, "ok, prove it...".
There's just no silver bullet in software, IMHO. I use the right tool for
the right job, which is why I'm open to evaluating any language. Well, except
maybe Visual Basic. ;-)
Mike
Michael P. Soulier
<Friedrich...@inka.de> wrote:
>
>One can write bug-ridden software in any language, just Eiffel makes it
>a bit harder ;-)
I am personally capable of snatching defeat from the jaws of victory in any
language. ;-)
>Now the question was is it written in Eiffel. AFAIK it's a mixture out
>of C and Eiffel. So to what extend they use Eiffel is beyond my
>knowledge, but they use e.g for their classes ARRAY and STRING C.
Ah. Before my benchmarks I would have thought this would be slow, but it
seems within a few percent of C++ when the assertions are disabled, so...
>You're right it one of the poorest pieces of nearly any Eiffel IDE. I do
>not know how well Visual Eiffel does.
Well, I complain about most editors really, because they take perfectly good
Unix editors that would make you productive, and throw them out and give you
notepad. The only 3rd party tool I've seen to not follow this is Visual
SlickEdit, which has extremely good Emacs and Vi keybindings.
Put me in Vi, or better yet Vim, and I'm very productive. Anything else is a
waste of time. Too much reaching for the mouse and the arrow keys.
>> Ah well. I'm sure it will improve with time and sweat.
>
>Or the next release ...
Yup, that's how it goes...
Mike
Friedrich Dominicus
> waste of time. Too much reaching for the mouse and the arrow keys.
not with Emacs. But don't get into that here;-)
I guess you find out, but you can use your preferred editor with ISE
and/or Halstenbach it worked quite fine. Put the command for you editor
behind the Shell-hole and you can just drop the source on it and you
Editor is fired up.
> >
> >Or the next release ...
>
> Yup, that's how it goes...
Unfortunatly, even that did not help sometimes ...
Regard
Friedrich
Jim Cochrane
Friedrich Dominicus <Friedrich...@inka.de> wrote:
>> Put me in Vi, or better yet Vim, and I'm very productive. Anything else is a
>> waste of time. Too much reaching for the mouse and the arrow keys.
>
>not with Emacs. But don't get into that here;-)
>
>I guess you find out, but you can use your preferred editor with ISE
>and/or Halstenbach it worked quite fine. Put the command for you editor
>behind the Shell-hole and you can just drop the source on it and you
>Editor is fired up.
Yes - I find ISE Eiffel on Linux configured with Vim as the editor,
combined with a bash terminal when I need more power, to be a very nice,
powerful development environment.
>
>
>
>> >
>> >Or the next release ...
>>
>> Yup, that's how it goes...
>
>Unfortunatly, even that did not help sometimes ...
>
>Regard
>Friedrich
--
Jim Cochrane
j...@dimensional.com
Joachim Durchholz
> "Michael P. Soulier" wrote:
>
> > Wow, is it written in Eiffel? I thought you couldn't
> > write bug-ridden software in Eiffel? ;-) Sorry, just had to
> > take a poke at propaganda.
>
http://www.eiffel.com/services/training/contract/page.html
It says "Built-in reliability for mission-critical applications". I
don't see any meaningful interpretation of that statement other than
what Michael reported.
Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.
Joachim Durchholz
Newsbeitrag: 38DB96E2...@inka.de...
>
> Now Visual
> Eiffel is Windows centric as is Halstenbach-Eiffel.
Just to set the record straight: This is true for graphics stuff, but
the other libraries (networking, file access, etc.) work well on various
flavours of Unix for Halstenbach iss-base. And the situation may be
changing for portable graphics anyway :)
> Halstenbach Eiffel comes on Windows with Tune.
TUNE is an Eiffel library for configuring objects from a textual
description. The really interesting thing is iss-vision, which has
wrapper classes for the majority of Windows controls (and shields the
programmers from the worst, er, intricacies of Windoze; it also offers
a Grid control that does the layout stuff and is quite powerful - since
I started working with iss-vision-based software, I'm getting more and
more annoyed that most Windows dialogs aren't resizable...).
iss-base comes with a GUI designer (the "Builder"). Halstenbach thinks
it's the best GUI builder in the Eiffel market, but I'm pretty sure that
the competitors have a different opinion :) .
Installing Eiffel software means copying the application and maybe a few
dlls. Just put the dlls in the same directory as the main executable.
I'm not sure whether this policy is viable for Access, but it surely
works for MFC applications (been there, done that).
Joachim Durchholz
38D92863...@pobox.com...
>
> To make this comparison fair, a tool as Delphi also has a Build
> option.
> It helps. And I'm quite sure Visual C++ users also use their complete
> build future when things have screwed up.
Yup - it's called Build All.
Though there's a qualitative difference: VC may fail to recompile a
file, or the compiler may report an Internal Errror; both cases are
quite rare (maybe once in a month). The crashes that have been reported
here are both more serious (the entire IDE goes down) and I assume more
often as well.
> It would already help a lot of ISE would add a Clean Melt option or so
> which would do exactly this (delete .epr and EIFGEN). Lots more
> userfriendly, and no more people complaining about having to delete
> stuff (well that's just what happens, but nobody knows it anymore
> :-) ).
This would be a Very Good Thing. If the bloody compiler tells me that
the epr and/or eifgen is unusable and should be deleted - why doesn't
it delete them on its own? Or ask me whether it should do this?
Joachim Durchholz
38D8B8FF...@acm.org...
>
> No, it doesn't prove that. The two factors that discount this as a
> proof are that Eiffel as both a language and ISE environment are
> very ambitious and make no compromises. In fact, I think it is
> difficult to build anything on top of windows to be stable.
If you mean Windows: No, that's unrelated. Ulrich was listing compiler
bugs, such as the inability to have a working polymorphic is_equal.
Besides, it *is* possible to write software that's much more reliable
than what we see in the Eiffel world today. The problems with Microsoft
software could equally well be discounted as "it's buggy because it's
ambitious": the facilities of Word are *very* ambitious.
[Agreeing to the rest you said]
Joachim Durchholz
>
> ISS BASE is similar. When the IDE crashes, it writes a backtrace, but
> usually you can't read it befor the window closes ;-)
If you want to see the trace, run it from a command line like
D:\WINNT40\system32\CMD.EXE /k
%ISS_BASE%\spec\%PLATFORM%\bin\ibcomp.exe -bench
(type it on a single line).
I've got a shortcut with this command line on my desktop, and it proved
to be of invaluable help for submitting bug reports.
Berend de Boer
Friedrich Dominicus wrote:
> I guess you find out, but you can use your preferred editor with ISE
> and/or Halstenbach it worked quite fine. Put the command for you editor
> behind the Shell-hole and you can just drop the source on it and you
> Editor is fired up.
Does that work in Windows? I just tried it on NT but although I could
specify an editor I couldn't get it to show up.
Groetjes,
Berend. (-:
Raphael Simon
- The path to the currently selected editor is absolute or is in the PATH
variable (environment variable for NT, set in "autoexec.bat" for 9x).
- The path to the project does not have spaces in its name. If it does then
the command line should be modified from:
"gvim" +$line $target
to
"gvim" +$line "$target"
(not the added double quotes around "$target").
This example assume that GVim is installed on the machine and that the path
to "gvim.exe" is in the PATH variable. You can modify the command line by
right-clicking on the shell hole or in the preferences tool.
Hope this helps,
Raphael.
--
Raphael Simon
Interactive Software Engineering, Inc.
"Berend de Boer" <ber...@pobox.com> wrote in message
news:38DF9DEF...@pobox.com...
Michael P. Soulier
<Friedrich...@inka.de> wrote:
>
>I guess you find out, but you can use your preferred editor with ISE
>and/or Halstenbach it worked quite fine. Put the command for you editor
>behind the Shell-hole and you can just drop the source on it and you
>Editor is fired up.
>
Oh cool. I'll have to try that. Modular and customizable is always good.
Michael P. Soulier
>
>Yes - I find ISE Eiffel on Linux configured with Vim as the editor,
>combined with a bash terminal when I need more power, to be a very nice,
>powerful development environment.
Yeah, I was pleasantly surprised to find Vim syntax support for Eiffel
already. I love this tool, I use it on every platform I code on.
Mike
Friedrich Dominicus
>
> Friedrich Dominicus wrote:
>
> > I guess you find out, but you can use your preferred editor with ISE
> > and/or Halstenbach it worked quite fine. Put the command for you editor
> > behind the Shell-hole and you can just drop the source on it and you
> > Editor is fired up.
>
> specify an editor I couldn't get it to show up.
Oh I forgot poor Windows people. Now I think it should work anyway. what
is the command-line you tried maybe you have to use s.th like
cmd /c vi +g +f
or the like.
Regards
Friedrich
Thomas Beale
"Michael P. Soulier" wrote:
> On Mon, 27 Mar 2000 15:42:45 +0200, Friedrich Dominicus
> <Friedrich...@inka.de> wrote:
> >
> >I guess you find out, but you can use your preferred editor with ISE
> >and/or Halstenbach it worked quite fine. Put the command for you editor
> >behind the Shell-hole and you can just drop the source on it and you
> >Editor is fired up.
> >
>
> Oh cool. I'll have to try that. Modular and customizable is always good.
>
Someone probably said so already, but on NT, a line like
d:\opt\lemmy\lemmy32.exe +$line
(no, you don't have to follow my unix-hangover directory naming!)
entered into the dialogue box available from a right-button click on the shell-hole
(between the two magenta class holes) on a class tool will make the lemmy (vi)
editor come up. Same deal for vim AFAIK. Just remember to use double quotes around
command lines with the (world's most stupidly named) directory "Program files" or
similar in it.
I find Roger Browne's comments of a while back about "bedding in" an environment
true: the ISE editor is horrible (I have an idea it's a 3rd party component they got
stuck with and can't rewrite for some reason), but I don't care anymore. I can use
it nearly as fast as vi. I use vi for searching, and anything "hard".
- thomas beale
Jim Cochrane
Yes, vim is a very nice editor. I just discovered that I can add the
lines:
set smartindent
set cinwords=is,local,do,if,else,elseif,from,until,loop,export,rescue,require,ensure,check,invariant,once,redefine,rename,select,undefine,inspect,when
to the eiffel.vim file to have it do auto-indenting on the next line after
you type one of these keywords.
--
Jim Cochrane
j...@dimensional.com
Ian Joyner
> Well, I complain about most editors really, because they take perfectly good
> Unix editors that would make you productive, and throw them out and give you
> notepad. The only 3rd party tool I've seen to not follow this is Visual
> SlickEdit, which has extremely good Emacs and Vi keybindings.
> Put me in Vi, or better yet Vim, and I'm very productive. Anything else is a
> waste of time. Too much reaching for the mouse and the arrow keys.
No, vi people only look productive as they hammer away at the keyboard. That actually
is not productive at all. vi is the most completely backwards piece of software
imaginable. So you use hjkl instead of arrows or the mouse. I can't see criticising any
editor because it is not vi is a valid criticism.
Ian Joyner
> Ian Joyner <i.jo...@acm.org> wrote:
> > "Michael P. Soulier" wrote:
> >
> > > Wow, is it written in Eiffel? I thought you couldn't
> > > write bug-ridden software in Eiffel? ;-) Sorry, just had to
> > > take a poke at propaganda.
> >
> > What propaganda is that? I don't think such propaganda exists.
>
> http://www.eiffel.com/services/training/contract/page.html
>
> It says "Built-in reliability for mission-critical applications". I
> don't see any meaningful interpretation of that statement other than
> what Michael reported.
You take things out of context, which of course makes the phrase lose
its meaning. It is:
"Design by Contract: Built-in reliability for mission-critical
applications"
I think that makes it interpretable and I would not count this as
propaganda. Marketing, yes, because this page is selling a course.
If you want propaganda, how about the term "Zero friction computing". I
don't know of any CS text that defines friction in computing, but this
phrase is being applied to a new virtual machine. Hmmm....
Bruce Hoult
> No, vi people only look productive as they hammer away at the keyboard.
That actually
> is not productive at all. vi is the most completely backwards piece of
software
> imaginable. So you use hjkl instead of arrows or the mouse. I can't see
criticising any
> editor because it is not vi is a valid criticism.
amen.
emacs is better, but not *that* much. If I'm on a contract and I need to
get some serious editing done, I plug my G3 PowerBook into the network and
edit files in BBEdit using "open via ftp". It's just *so* much slicker
and faster for most common things that it's not funny. And I know emacs
at least as well as most people who swear it's the bee's knees -- its
RCS/CVS integration is fantastic, and it's perfectly good at looking at
files and making the occasional small change, but anything involving
wholesale code rearrangement and it sucks badly.
-- Bruce
Ian Joyner
I agree. I used vi in the early 80s. Even in those days, it had its
afficionados who swore anything else was inferior because vi was completely
"orthogonal". A strange use of this term. I actually think vi has some very
powerful editing capabilities, but it is the modality of positioning vs.
typing that shows its age. I thought when Mac came along, that the vi style
of editing would disappear, along with the RSI that seemed to plague vi
users.
No one is going to defend the editor ISE uses, but as an environment,
EiffelBench offers so much more as a system editor rather than just a text
editor. It really doesn't matter to me how fast I can hit keys to move the
cursor around the screen, that just is not productive work. A programmer must
concentrate on the semantics of the system as a whole, not just being one who
pushes characters around a screen. Seems to me, Unix and C have always been
at that level and that is the big difference with something like Eiffel (and
Macintosh).
Eirik Mangseth
"Ian Joyner" <i.jo...@acm.org> wrote in message
news:38E307CC...@acm.org...
amen
Eirik Mangseth
Stockpoint Nordic AS, Lysaker, Norway
"If I can't Eiffel in heaven, I won't go"
Jim Cochrane
>Bruce Hoult wrote:
>
>> In article <38E1BE77...@acm.org>, i.jo...@acm.org wrote:
>>
>> > No, vi people only look productive as they hammer away at the keyboard.
>> That actually
>
>I agree. I used vi in the early 80s. Even in those days, it had its
>afficionados who swore anything else was inferior because vi was completely
>"orthogonal". A strange use of this term. I actually think vi has some very
>powerful editing capabilities, but it is the modality of positioning vs.
>typing that shows its age. I thought when Mac came along, that the vi style
>of editing would disappear, along with the RSI that seemed to plague vi
>users.
>
>No one is going to defend the editor ISE uses, but as an environment,
>EiffelBench offers so much more as a system editor rather than just a text
>editor. It really doesn't matter to me how fast I can hit keys to move the
>cursor around the screen, that just is not productive work. A programmer must
>concentrate on the semantics of the system as a whole, not just being one who
>pushes characters around a screen. Seems to me, Unix and C have always been
>at that level and that is the big difference with something like Eiffel (and
>Macintosh).
Actually, I like the combination of UNIX (Linux), vi, and ebench. ebench
has some flaws, but it is a very good, powerful OO IDE (using something
like Visual C++ after using ebench I find quite painful). Combine this
with the power and flexibility of UNIX and vi (actually, Vim, which is
more powerful than vi), and you have a nice, powerful, productive
development environment - at least for UNIX geeks like me who are used
to the UNIX style of writing simple programs at the command line to
accomplish rather complex tasks (such as
gvim $(find . -name '*.e' -exec grep -il x_function {} ';')
:-) ). And I really find vi's touch-typing facilities combined with its
power superior, for me, to GUI-based editors. I guess it truly is
different strokes, etc...
>
>--
>Ian Joyner
>i.jo...@acm.org http://homepages.tig.com.au/~ijoyner/
>
>Eiffel for Macintosh
>http://www.object-tools.com/products/eiffel-s/index.html
>
>Objects Unencapsulated -- The book
>http://www.prenhall.com/allbooks/ptr_0130142697.html
>http://www.elj.com/oue1/ (review)
>
>
--
Jim Cochrane
j...@dimensional.com
Michael P. Soulier
>"Michael P. Soulier" wrote:
>
>No, vi people only look productive as they hammer away at the keyboard.
>That actually
>imaginable. So you use hjkl instead of arrows or the mouse. I can't see criticising any
>editor because it is not vi is a valid criticism.
*laugh* Sir, I did not say, "if it's not vi it's crap". In fact, I believe
that I suggested Emacs as well. If you had properly read my post instead of
getting enflamed the second you saw the word "vi", you might have noticed that.
Let me restate, and read it carefully this time. It is my opinion that any
editor that does not provide productive editing features, merely providing plain
editing, no macro support, no abbreviations, no regular expression support, no
room for customization, is inadequate.
Also sir, note that this is my opinion. You're welcome to have your own, and
obviously do. However, I would appreciate it if you did not state your opinion
as fact. No one has that much credibility in my book.
Cheers,
Mike
Michael P. Soulier
>emacs is better, but not *that* much. If I'm on a contract and I need to
May I point out that I mentioned Emacs in my posting? I was dissing editors
with the functionality of notepad (read: none at all).
>get some serious editing done, I plug my G3 PowerBook into the network and
>edit files in BBEdit using "open via ftp". It's just *so* much slicker
>and faster for most common things that it's not funny. And I know emacs
>at least as well as most people who swear it's the bee's knees -- its
>RCS/CVS integration is fantastic, and it's perfectly good at looking at
>files and making the occasional small change, but anything involving
>wholesale code rearrangement and it sucks badly.
Emacs has ang-ftp, in case you didn't know. I used to use it on systems at
work where we don't have the same NFS mounts. I only stopped using it whe I
found that the Perl mode was broken, and the keybindings are, IMHO, arthritic.
Anyway, my original point was that most built-in editors in IDE don't have
enough editing features, ISE Eiffel included. But then, that's my opinion.
Mike
Michael P. Soulier
>You take things out of context, which of course makes the phrase lose
>its meaning. It is:
>
>"Design by Contract: Built-in reliability for mission-critical
>applications"
>
>I think that makes it interpretable and I would not count this as
>propaganda. Marketing, yes, because this page is selling a course.
>
>If you want propaganda, how about the term "Zero friction computing". I
>don't know of any CS text that defines friction in computing, but this
>phrase is being applied to a new virtual machine. Hmmm....
Actually, I believe that would properly be referred to as a "buzz-word". In
any case, I don't see why anyone would get offended by the truth that every
company uses propaganda. I was just suggesting that _every_ source must be taken
with a grain of salt.
When I began posting on this newsgroup looking for Eiffel opinions, several
people told me not to bother because no one would be objective. While I have run
into the occasional person that believes that their opinion is God's word, my
experience has actually been quite positive. I have however found it necessary
to cut through some of the hype and get at what's real. I've found a good
language underneath.
It pays to be objective people. Criticism about one's believes should be
welcome. It makes us question what we believe we know. Last time I checked, that
was still a good thing.
Cheers,
Mike
Michael P. Soulier
>
>No one is going to defend the editor ISE uses, but as an environment,
>EiffelBench offers so much more as a system editor rather than just a text
>editor. It really doesn't matter to me how fast I can hit keys to move the
>cursor around the screen, that just is not productive work. A programmer must
>concentrate on the semantics of the system as a whole, not just being one who
>pushes characters around a screen. Seems to me, Unix and C have always been
>at that level and that is the big difference with something like Eiffel (and
>Macintosh).
UNIX has typically been about building larger tools from existing tools, the
command-line being the prime method for this. So, instead of limiting the user
to the tools that the tool developer thought to provide, the user can quickly
build their own to suit their specific needs. This is certainly not
"integrated", as in IDE, but it is highly flexible. Instead of clicking on a
class name to see its implementation, I use ctags in Eiffel mode within the
editor to automatically jump to the implementation.
Also, since I work in various languages, I prefer to learn tools that will
be workable in all of those languages. So far I've been able to do that, and I
believe that it makes me very productive. I also believe that it allows me to
"concentrate on the semantics of the system as a whole", like you
suggest above.
Perhaps I missed some documentation, but does the editor in ISE Eiffel allow
for syntax shading and editing at the same time? The first thing that I noticed
was that I could only get syntax shading in "clickable" mode, which doesn't
allow editing. The main reason I don't use it was because I prefer to have
syntax shading while I code, the second being the fact that I can only use the
environment for Eiffel (obviously).
Perhaps I missed something?
Cheers,
Mike
Michael P. Soulier
>
>Actually, I like the combination of UNIX (Linux), vi, and ebench. ebench
>has some flaws, but it is a very good, powerful OO IDE (using something
>like Visual C++ after using ebench I find quite painful). Combine this
>with the power and flexibility of UNIX and vi (actually, Vim, which is
>more powerful than vi), and you have a nice, powerful, productive
>development environment - at least for UNIX geeks like me who are used
>to the UNIX style of writing simple programs at the command line to
>accomplish rather complex tasks (such as
>gvim $(find . -name '*.e' -exec grep -il x_function {} ';')
>:-) ). And I really find vi's touch-typing facilities combined with its
>power superior, for me, to GUI-based editors. I guess it truly is
>different strokes, etc...
Amen. Choice is important, and I was impressed when I found out that ISE
Eiffel permits the user to configure a different editor. Everyone here is an
individual, and works in different ways. Leaving room for that is, IMHO,
important.
Cheers,
Mike
Babak Makkinejad
My experience using UNIX and UNIX tools (such as emacs) has been a rather
painful one. I never felt very productive on UNIX. I began programming on
VAX/VMS, using FORTRAN, DCL, and EVE editors. Everytime I worked on the VAX
I felt I was bothering the machine. Later on, I had to use UNIX and EMACS.
Everytime I used UNIX I felt that the machine was bothering me. I much
rather I be bothering the machine than the machine be bothering me.
Recently, after years of working on DOS & various flavors of WINDOWS I had
the chance to see what SUN had to offer on SOLARIS. In my opinion, their
tools and others for HP, SCO, or LINUX belonged to the dark ages. As a
programmer, I was never interested in trying to build my own tools. I have
more important things to do than to loose my efficiency on things that ought
not be a problem; I have programs to write and customers to keep happy.
The first IDE that I saw was Borland's (R.I.P.) TurboC. Here we are,
fifteen years later and we still don't have anything like that available on
the UNIX platform. I am not unsympathetic to the UNIX command line, I just
don't think it is as efficient as an IDE.
I am now trying to learn ISE Eiffel because I think it is a superior O-O
language to C++ even though I have been programming in C++ for 8 years. The
chief advantage of Eiffel is that, in my opinion, it forces O-O paradigm on
programmers and maintains it. (I don't think very highly of Java; I think
it is brain-damaged form of C++.) Chief problem with C++ programs is that
the developers don't write O-O code since the language actually supports
procedural, package-like, and O-O paradigms. (I have seen a lot of C++
programs with global variables, un-structured returns, etc.)
So far I have used ISE Eiffel and Visual Eiffel. Visual Eiffel is a decent
tool but it is not comaparable to VC++ 6.0 in terms of its features. ISE
Eiffel requires a paradigm shift in ergonomics. I am not complaining about
its editor, one can always use another; I do find it strange thought. It is
difficult for someone like myself (although not impossible) to try to argue
for Eiffel when C++, Java, VB, PowerBuilder, Delphi, and SmallTalk all vie
for the developer mindset. I am trying but the state of Eiffel tools on PC
platform leaves something to be desired.
Best regards,
Babak Makkinejad
Michael P. Soulier <msou...@storm.ca> wrote in message
news:slrn8ecvs4....@localhost.localdomain...
Ian Joyner
> Also, since I work in various languages, I prefer to learn tools that will
> be workable in all of those languages. So far I've been able to do that, and I
> believe that it makes me very productive. I also believe that it allows me to
> "concentrate on the semantics of the system as a whole", like you
> suggest above.
I appreciate that, and Object Tools is working with CodeWarrior for those who use that
environment for exactly these reasons. However, and I can say this myself, it is not as
easy to integrate everything you would like into such an environment, so we don't have
clickable short and flat, which is very useful.
> Perhaps I missed some documentation, but does the editor in ISE Eiffel allow
> for syntax shading and editing at the same time? The first thing that I noticed
> was that I could only get syntax shading in "clickable" mode, which doesn't
> allow editing. The main reason I don't use it was because I prefer to have
> syntax shading while I code, the second being the fact that I can only use the
> environment for Eiffel (obviously).
I completely agree here, I think the editing environment should be smart enough to
present pretty formatting and highlighting, and it would be nice to see ISE integrate
these two modes.
Michael P. Soulier
>
>I appreciate that, and Object Tools is working with CodeWarrior for those who use that
>environment for exactly these reasons. However, and I can say this myself, it is not as
>easy to integrate everything you would like into such an environment, so we don't have
>clickable short and flat, which is very useful.
Ooooh. I like CodeWarrior. Like I was arguing previously, tools that I can
use across languages make me more productive, and I've always liked how
CodeWarrior doesn't hide details from me, and is workable with several
languages. I look forward to seeing the outcome of this.
>I completely agree here, I think the editing environment should be smart enough to
>present pretty formatting and highlighting, and it would be nice to see ISE integrate
>these two modes.
Very. However, it certainly was good of ISE to permit pluggable editors.
Choice is a good thing.
Cheers,
Mike
Michael P. Soulier
>Hello Gentlemen:
Greetings.
[snip!]
>Recently, after years of working on DOS & various flavors of WINDOWS I had
>the chance to see what SUN had to offer on SOLARIS. In my opinion, their
>tools and others for HP, SCO, or LINUX belonged to the dark ages. As a
>programmer, I was never interested in trying to build my own tools. I have
>more important things to do than to loose my efficiency on things that ought
>not be a problem; I have programs to write and customers to keep happy.
Strange. This is nearly my exact argument when someone asks me why I don't
like using Windows.
I really have better things to do than spend my day hitting the reset
button, or looking for functionality that I could write with one line in a bash
shell.
>The first IDE that I saw was Borland's (R.I.P.) TurboC. Here we are,
>fifteen years later and we still don't have anything like that available on
>the UNIX platform. I am not unsympathetic to the UNIX command line, I just
>don't think it is as efficient as an IDE.
Incorrect. CodeWarrior, Code Fusion, Visual SlickEdit and a few others have
been available for some time. Now that Borland/Inprise and Corel have joined
forces, the list continues. I just downloaded Jbuilder for Linux. Also, how can
you argue that nothing like Turbo C is available for UNIX when I have a copy of
ISE Eiffel for Linux right here?
As for efficiency as an IDE, that's questionable. I just spent 8 months
coding my thesis in VC++, while doing a lot of UNIX work on the side. VC++ has
some nice features, but I found nothing to put it above my usual combination of
gcc, make, Vim, and ctags. It has a few strikes against it for flexibility as
well, to say nothing of the horrible code that it generates if you elect to use
those features. Plus, my knowledge of it is now only good on windows, in C++
using the MFC. My knowledge elsewhere is much more portable, across platforms
and languages.
>I am now trying to learn ISE Eiffel because I think it is a superior O-O
>language to C++ even though I have been programming in C++ for 8 years. The
>chief advantage of Eiffel is that, in my opinion, it forces O-O paradigm on
>programmers and maintains it. (I don't think very highly of Java; I think
>it is brain-damaged form of C++.) Chief problem with C++ programs is that
>the developers don't write O-O code since the language actually supports
>procedural, package-like, and O-O paradigms. (I have seen a lot of C++
>programs with global variables, un-structured returns, etc.)
Saying that the developers don't write something assumes omniscience. I've
seen plenty of C++ code without any procedural code to be found. The design
intent was to be flexible, as OO is not necessarily the holy grail of
programming. If you want OO, fine, if not, fine. I see no reason to force a
programmer to do anything, frankly. Use the right tool for the right job.
>So far I have used ISE Eiffel and Visual Eiffel. Visual Eiffel is a decent
>tool but it is not comaparable to VC++ 6.0 in terms of its features. ISE
>Eiffel requires a paradigm shift in ergonomics. I am not complaining about
>its editor, one can always use another; I do find it strange thought. It is
>difficult for someone like myself (although not impossible) to try to argue
>for Eiffel when C++, Java, VB, PowerBuilder, Delphi, and SmallTalk all vie
>for the developer mindset. I am trying but the state of Eiffel tools on PC
>platform leaves something to be desired.
I was surprised myself at the environment. I honestly found VC++ and Delphi
to have superior environments overall. There are some good ideas certainly, but
I think it has a way to go.
As for your UNIX experiences, we can certainly discuss it in more detail
off the newsgroup if you like. You glossed over your specific complaints above,
rightly so, since this isn't the aim of this newsgroup, but I am curious. I'll
be the first to advocate a, "to each their own" attitude. As far as computer
science, you might call me "pro choice". Hence my leaning towards Linux, where I
actually am given one, to say nothing of the stability of my development
platform, which is quite important to me.
In any case, while I personally find UNIX to be a work of art, one man's art
is another man's trash. For what I do at work though, I honestly can't imagine
another environment. Without it, I'd never get out of there on time.
Cheers,
Mike
David Broadfoot
> On Wed, 29 Mar 2000 18:27:34 +1000, Ian Joyner <i.jo...@acm.org> wrote:
> >"Michael P. Soulier" wrote:
[snip]
> *laugh* Sir, I did not say, "if it's not vi it's crap".
Actually, you said "Anything else is a waste of time."
[snip]
> Also sir, note that this is my opinion. You're welcome to have your own,
and
> obviously do. However, I would appreciate it if you did not state your
opinion
> as fact. No one has that much credibility in my book.
Well, you also stated your opinions as fact. It's a natural way that people
express their opinions. It's not neceesary to always add IMHO, IMHO.
David
Babak Makkinejad
I submit to you that the use of scripts in UNIX, however efficient for a
programmer in the short term, is a nightmare of maintenance & support for
the people who come in afterwards. The openness of UNIX or LINUX code is
not an strength; it only encourage further fragmentation. (I can see the
utility of this if you are doing research in certain areas of Com. Sci. but
for people in the non-academic positions it is of no practical value; we
just don't have time to mess around with UNIX, WINDOWS, or Palm OS
internals.)
The significance of Microsoft platforms is that they are providing a de
facto set of standards which are utterly lacking on the UNIX side. These
standards allow a very high level of integration that is still not possible
on the UNIX platform as each individual vendor tries to differentiate its
product by making it un-interoperable with the next fellow's offerings.
(Look at the fiasco that CORBA has become.)
Moreover, some of us not only like Micorosoft platforms but also think that
they are, in fact, superior. The key element, in my opinion, is the ease of
use of these platforms, the existence of a software component market, and
the existence of inexpensive hardware. As for reliability, I only know two
reliable platforms; the mainframes from IBM and the highly redundant UNIX
machines from Tandem.
I like the ISE Eiffel additionally because its "C" code generation allows us
to be cross-platform, and, at the same time, to preserve out IP.
Best regards,
Babak Makkinejad
Michael P. Soulier <msou...@storm.ca> wrote in message
news:slrn8edn23....@localhost.localdomain...
Thomas Beale
Babak Makkinejad wrote:
> I submit to you that the use of scripts in UNIX, however efficient for a
> programmer in the short term, is a nightmare of maintenance & support for
> the people who come in afterwards. The openness of UNIX or LINUX code is
> not an strength; it only encourage further fragmentation. (I can see the
> utility of this if you are doing research in certain areas of Com. Sci. but
> for people in the non-academic positions it is of no practical value; we
> just don't have time to mess around with UNIX, WINDOWS, or Palm OS
> internals.)
This is an extreme position. Unix scripts etc offer much more flexibility than
windows alternatives. But it is true that maintenance is an issue. So where do
unix scripts etc make sense? In organisations with enough people to be able to
dedicate someone to infrastructure & operations. The ability to do scripting in
this context is indispensable in this context, and many organisations, from
those with 5 people to those with 5000, could not economically do the kinds of
infrastructure tasks they do without scripting, command lines etc.
However, as part of a development, for the developers themselves, unless a
script language is one of the main development languages, it is probably better
avoided in my experience, for the maintenance reason. But one problem that you
get is that you often need to be able to integrate a set of applications into
the operating system at the (for example) cron level, i.e. to automatically
start them depending on certain conditions. Just putting an entry into crontab
(or on NT, you can use "winat") may not be enough - you need to write just a few
lines of logic to e.g. check existence of directories, user passwords, clobber
old log files and so on. Pretty soon you have 100 lines of logic just to do
these things, and deal with the errors.
Do you write it in Eiffel, or some other compiled langauge, or just go with
Perl? In the end, I find it easier to go with Perl (and this from someone who
can barely read it), simply because you can iteratively modify it faster and
deal more easily with the OS file system, regular expressions, sending mail to
someone, file writing (especially fast writing of files).
I guess if Eiffel had:
- a consistent file/directory handling interface and a fast implementation
- powerful regular expression handling
- the ability to do file stream editing like sed or Perl
- the ability to send email
- the ability to start an external program and easily get the error status
- etc
I would use it more for these kind of tasks. But most of these things are pretty
annoying to do in Eiffel when you can do them in a few lines of Perl.
> The significance of Microsoft platforms is that they are providing a de
> facto set of standards which are utterly lacking on the UNIX side. These
> standards allow a very high level of integration that is still not possible
> on the UNIX platform as each individual vendor tries to differentiate its
> product by making it un-interoperable with the next fellow's offerings.
> (Look at the fiasco that CORBA has become.)
MS haven't established any real standards on windows - they provide a
monoculture, in which (of course) everything (they produce; = about 80% of
everything) works together. With respect to the number of different vendors and
tools on unix, interoperability on unix is just as great as on Windows. On
Windows, I cannot for example easily deal with Word 97 files in Word 6, Word 95,
Word 2000, without each one of these tools making serious mistakes with the
file. And the solution.... RTF is a classic example of non-interoperability. But
I can move FrameMaker files from unix to windows to mac, and apart from font
differences, have exactly the same thing.
> Moreover, some of us not only like Micorosoft platforms but also think that
> they are, in fact, superior. The key element, in my opinion, is the ease of
I have no problem with you using (or me - I mainly develop on NT these days) MS
platforms, or liking them. But at least try to present a balanced point of view
on MS v unix.
> use of these platforms, the existence of a software component market, and
Be careful - depending on what you are doing, they are not easy to use: examples
- MFC programming (does anyone think the MFC makes any sense?); windows 98 is
quite simply a dog, and if such a product had been brought out by a car
manufacturer, they would be in jail right now; writing scripts on any windows
platform (using the braindead batch file language) and so on. But... yes, there
are other aspects in which the windows platforms are easier to use, and more
suited to certain jobs; visual GUI development has always been quicker for
example.
You have to remember one thing though: as long as you stay within the cocoon of
MS software on a windows platform, you are relatively safe and sure. Once you
step outside (for example, I use Frame, Eiffel, StarOffice, a GIS system,
Matisse, Netscape, etc), things are not always so simple. And MS has a
well-documented history of making life hard for other software vendors to make
their software run properly on Windows.
- thomas beale
Friedrich Dominicus
BM> Greetings:
BM> I submit to you that the use of scripts in UNIX, however efficient for a
BM> programmer in the short term, is a nightmare of maintenance & support for
BM> the people who come in afterwards. The openness of UNIX or LINUX code is
BM> not an strength; it only encourage further fragmentation. (I can see the
BM> utility of this if you are doing research in certain areas of Com. Sci. but
BM> for people in the non-academic positions it is of no practical value; we
BM> just don't have time to mess around with UNIX, WINDOWS, or Palm OS
BM> internals.)
I disagree completly. The scripting makes things possible one can
just dream of in Windows e.g. And it's as maintainable as possble you
just need a decent edtior (sic!) and that'it.
As I workes as a windows adminstrator I was not able to automate the
simplest tasks, but after I installed Perl. So I'm in no way a
Perl-Fan but it makes work possible for me.
I never have had such problems on Unices. If you don't have a small
helper by hand, write them, no reason to dispair.
BM> The significance of Microsoft platforms is that they are providing a de
BM> facto set of standards which are utterly lacking on the UNIX side.
What standards are that. M$ just knows the standards, they have implemented
themselves. The are hardly compliant to any standards really set by ANSI, ISO
or whatever.
These
BM> standards allow a very high level of integration that is still not possible
BM> on the UNIX platform as each individual vendor tries to differentiate its
BM> product by making it un-interoperable with the next fellow's
BM> offerings.
Don't understand what you're telling here. Where is the high level of
integration? You can't integrate anything under Windows ever tried to combine
a Borland IDE with a M$ IDE. No on Windows each vendor if inventing it's own
integration set. On Unices all things work with either vi or Emacs. And you
can integrate them in whatever you like.
BTW in Emacs you can even go so far to do anything under it. Now what is more
productive, learning on flexible instrument or having to learn a bunch of
inflexible instruments all lacking some thing you would like to have.
BM> (Look at the fiasco that CORBA has become.)
Why fiasco?
BM> Moreover, some of us not only like Micorosoft platforms but also think that
BM> they are, in fact, superior. The key element, in my opinion, is the ease of
BM> use of these platforms, the existence of a software component market, and
BM> the existence of inexpensive hardware.
Where's the difference to PC-based Unices. There is much more stuff for
programmers on any Unix than there is on any Windows. You don't like Perl,
fine use Python or Ruby. You don't like csh fine you ksh etc etc. Under
Windows you have to use such highly productive tools like cmd.exe and the
like.
If you want to automate a task forget it. If you want to do remote
administration buy products for x thousand of Dollar etc etc.. Windows is IMO
a hallmark for inflexibility at least for Adminstrators. The just have made
it integrating some Scripting facilites recently. If one does not need them
accroding to you mails why does M$ offer them now?
BM> I like the ISE Eiffel additionally because its "C" code generation allows us
BM> to be cross-platform, and, at the same time, to preserve out IP.
Why does one have to have C-code generation for that? If I have an Eiffel to
native code on Windows and can just take my Eiffel source on another machine
compile them and have them nativly running under Bla, there is the same
amount of portability.
Regards
Friedrich
Friedrich Dominicus
TB> Do you write it in Eiffel, or some other compiled langauge, or just go with
TB> Perl? In the end, I find it easier to go with Perl (and this from someone who
TB> can barely read it), simply because you can iteratively modify it faster and
TB> deal more easily with the OS file system, regular expressions, sending mail to
TB> someone, file writing (especially fast writing of files).
TB> I guess if Eiffel had:
TB> - a consistent file/directory handling interface and a fast implementation
TB> - powerful regular expression handling
TB> - the ability to do file stream editing like sed or Perl
TB> - the ability to send email
TB> - the ability to start an external program and easily get the error status
TB> - etc
I doubt that. Why? Because anyway you have to compile the code and you forget
to say integration to work as part of a pipe makes it not easier. And one
should not forget that Eiffel is strongly typed. How will you fit that on the
comman-line? You will use STRING all over the place. So it seems that
String-facilities are very important.
TB> I would use it more for these kind of tasks. But most of these things are pretty
TB> annoying to do in Eiffel when you can do them in a few lines of Perl.
>> The significance of Microsoft platforms is that they are providing a de
>> facto set of standards which are utterly lacking on the UNIX side. These
>> standards allow a very high level of integration that is still not possible
>> on the UNIX platform as each individual vendor tries to differentiate its
>> product by making it un-interoperable with the next fellow's offerings.
>> (Look at the fiasco that CORBA has become.)
TB> MS haven't established any real standards on windows - they provide a
TB> monoculture, in which (of course) everything (they produce; = about 80% of
TB> everything) works together. With respect to the number of different vendors and
TB> tools on unix, interoperability on unix is just as great as on Windows. On
TB> Windows, I cannot for example easily deal with Word 97 files in Word
TB> 6, Word 95,
If that would be true one can rely just on M$ products. But anyway even their
packages do not work properly together
TB> Word 2000, without each one of these tools making serious mistakes with the
TB> file. And the solution.... RTF is a classic example of non-interoperability. But
Regards
Friedrich
Thomas Beale
Babak Makkinejad wrote:
> I submit to you that the use of scripts in UNIX, however efficient for a
> programmer in the short term, is a nightmare of maintenance & support for
> the people who come in afterwards. The openness of UNIX or LINUX code is
> not an strength; it only encourage further fragmentation. (I can see the
> utility of this if you are doing research in certain areas of Com. Sci. but
> for people in the non-academic positions it is of no practical value; we
> just don't have time to mess around with UNIX, WINDOWS, or Palm OS
> internals.)
This is an extreme position. Unix scripts etc offer much more flexibility than
windows alternatives. But it is true that maintenance is an issue. So where do
unix scripts etc make sense? In organisations with enough people to be able to
dedicate someone to infrastructure & operations. The ability to do scripting in
this context is indispensable in this context, and many organisations, from
those with 5 people to those with 5000, could not economically do the kinds of
infrastructure tasks they do without scripting, command lines etc.
However, as part of a development, for the developers themselves, unless a
script language is one of the main development languages, it is probably better
avoided in my experience, for the maintenance reason. But one problem that you
get is that you often need to be able to integrate a set of applications into
the operating system at the (for example) cron level, i.e. to automatically
start them depending on certain conditions. Just putting an entry into crontab
(or on NT, you can use "winat") may not be enough - you need to write just a few
lines of logic to e.g. check existence of directories, user passwords, clobber
old log files and so on. Pretty soon you have 100 lines of logic just to do
these things, and deal with the errors.
Do you write it in Eiffel, or some other compiled langauge, or just go with
Perl? In the end, I find it easier to go with Perl (and this from someone who
can barely read it), simply because you can iteratively modify it faster and
deal more easily with the OS file system, regular expressions, sending mail to
someone, file writing (especially fast writing of files).
I guess if Eiffel had:
- a consistent file/directory handling interface and a fast implementation
- powerful regular expression handling
- the ability to do file stream editing like sed or Perl
- the ability to send email
- the ability to start an external program and easily get the error status
- etc
I would use it more for these kind of tasks. But most of these things are pretty
annoying to do in Eiffel when you can do them in a few lines of Perl.
> The significance of Microsoft platforms is that they are providing a de
> facto set of standards which are utterly lacking on the UNIX side. These
> standards allow a very high level of integration that is still not possible
> on the UNIX platform as each individual vendor tries to differentiate its
> product by making it un-interoperable with the next fellow's offerings.
> (Look at the fiasco that CORBA has become.)
MS haven't established any real standards on windows - they provide a
monoculture, in which (of course) everything (they produce; = about 80% of
everything) works together. With respect to the number of different vendors and
tools on unix, interoperability on unix is just as great as on Windows. On
Windows,I cannot for example easily deal with Word 97 files in Word 6, Word 95,
Word 2000, without each one of these tools making serious mistakes with the
file. And the solution.... RTF is a classic example of non-interoperability. But
I can move FrameMaker files from unix to windows to mac, and apart from font
differences, have exactly the same thing.
> Moreover, some of us not only like Micorosoft platforms but also think that
> they are, in fact, superior. The key element, in my opinion, is the ease of
I have no problem with you using (or me - I mainly develop on NT these days) MS
platforms, or liking them. But at least try to present a balanced point of view
on MS v unix.
> use of these platforms, the existence of a software component market, and
Be careful - depending on what you are doing, they are not easy to use: examples
Michael P. Soulier
>[snip]
>> *laugh* Sir, I did not say, "if it's not vi it's crap".
>
>Actually, you said "Anything else is a waste of time."
The "anything else" I was referring to, were editors that do not provide any
real editing facilities, but simply permit one to enter text. My original post
suggested vi, Vim and Emacs, constrasting it to the functionality of the ISE
Eiffel editor in edit mode being the same as the windows notepad. My opinion is
that using something with the functionality of notepad is a waste of time.
>Well, you also stated your opinions as fact. It's a natural way that people
>express their opinions. It's not neceesary to always add IMHO, IMHO.
I didn't think I did, but it's certainly possible that I came across that
way. In any case, thanks for the reminder. It's always good to remind us that
there are other opinions out there.
Cheers,
Mike
Jim Cochrane
>Greetings:
>
>I submit to you that the use of scripts in UNIX, however efficient for a
>programmer in the short term, is a nightmare of maintenance & support for
>the people who come in afterwards. The openness of UNIX or LINUX code is
>not an strength; it only encourage further fragmentation. (I can see the
>utility of this if you are doing research in certain areas of Com. Sci. but
>for people in the non-academic positions it is of no practical value; we
>just don't have time to mess around with UNIX, WINDOWS, or Palm OS
>internals.)
Yes, scripts can be a maintenance problem if they are part of a production
release, especially if they are large and not well written. However,
scripts have other uses than being part of a released package. For
example, I often find it convenient to write a script (either directly on
the command line or in a file) to accomplish a somewhat complex task
(such as change all occurrences of X_FOO to Y_FOO in all files that
end in .e) that would take a lot longer to do by hand. And if I end up
using the same set of commands often, I will sometimes put them into a
script so that I can execute them by typing one command. In other words,
the UNIX command line and scripts provide leverage that allows me to
save time on some tasks needed during development that would otherwise
be tedious and time-consuming. Also, scripts are often useful for writing
small utilities needed by the entire development team, such as automation
of builds every evening.
Sorry for drifting off the topic of Eiffel. It's an interesting topic, but
I think I'll bow out from here on so that I don't further cultivate an
off-topic thread.
--
Jim Cochrane
j...@dimensional.com
Thomas Beale
Friedrich Dominicus wrote:
> >>>>> "TB" == Thomas Beale <tho...@deepthought.com.au> writes:
> TB> I guess if Eiffel had:
> TB> - a consistent file/directory handling interface and a fast implementation
> TB> - powerful regular expression handling
> TB> - the ability to do file stream editing like sed or Perl
> TB> - the ability to send email
> TB> - the ability to start an external program and easily get the error status
> TB> - etc
>
> I doubt that. Why? Because anyway you have to compile the code and you forget
> to say integration to work as part of a pipe makes it not easier. And one
Yes, forgot that. That's also important, but there is no reason why an Eiffel program
cannot be a part of a pipe - as long as it respects stdin, stdout, and stderr. The problem
I have had most often on NT is being able to do the equivalent of $? to get an error return
value.
> should not forget that Eiffel is strongly typed. How will you fit that on the
> comman-line? You will use STRING all over the place. So it seems that
> String-facilities are very important.
THis is not a problem. The ostensible aim would be to write the equivalent of command line
scripts in Eiffel, and there you simply use whatever types are available, e.g. FILE,
DIRECTORY and so on.
The other problem I did not mention in doing scripting using something like Eiffel is
licencing - something like Perl will often be on every machine in the company, but Eiffel
will not be, although there is no reason why SmallEiffel should not be.
- thomas beale
Ian Joyner
> On Sun, 02 Apr 2000 13:18:28 +1000, Ian Joyner <i.jo...@acm.org> wrote:
> >
> >I appreciate that, and Object Tools is working with CodeWarrior for those who use that
> >environment for exactly these reasons. However, and I can say this myself, it is not as
> >easy to integrate everything you would like into such an environment, so we don't have
> >clickable short and flat, which is very useful.
>
> Ooooh. I like CodeWarrior. Like I was arguing previously, tools that I can
> use across languages make me more productive, and I've always liked how
> CodeWarrior doesn't hide details from me, and is workable with several
> languages. I look forward to seeing the outcome of this.
I guess you are not using CW on the Mac though. One thing I would like to guage is how much
demand would there be for Eiffel running under CW on other platforms?
> >I completely agree here, I think the editing environment should be smart enough to
> >present pretty formatting and highlighting, and it would be nice to see ISE integrate
> >these two modes.
>
> Very. However, it certainly was good of ISE to permit pluggable editors.
> Choice is a good thing.
True, and I think that is why ISE have not put a great deal of effort into their own
editor. But using external editors lacks integration.
I do agree with you that more powerful editing facilities like in vi or emacs is a good
thing.
Charles Hixson
say, Python. This can be quite as intelligible as whatever (it varies) you would
substitute for them in the windows environment. If you like dialog box
interactions, that can be managed. Etc. It just depends on how much work you want
to put in on the front end, or how much effort you devote to making the system more
user friendly after you have it working.
Roger Browne
> An alternative for Linux (possibly Unix) scripts is that you could write them in,
> say, Python...
I would suggest that Eiffelists also consider using Ruby. It has an
Eiffel-influenced syntax, has already overtaken Python usage in Japan,
and is faster than Perl on many benchmarks:
http://blade.nagaokaut.ac.jp/ruby/netlab/index.html
Regards,
Roger
--
Roger Browne - ro...@eiffel.tm - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
Jim Cochrane
Does it have support for pre and postconditiions, or for assertions?
--
Jim Cochrane
j...@dimensional.com
Friedrich Dominicus
JC> Does it have support for pre and postconditiions, or for assertions?
Not yet, but there was a lengthy discussion on the Mailing List about it and
AFAIHU they now are implementing it.
Regards
Friedrich
Michael P. Soulier
>Greetings:
>
>I submit to you that the use of scripts in UNIX, however efficient for a
>programmer in the short term, is a nightmare of maintenance & support for
>the people who come in afterwards. The openness of UNIX or LINUX code is
>not an strength; it only encourage further fragmentation. (I can see the
>utility of this if you are doing research in certain areas of Com. Sci. but
>for people in the non-academic positions it is of no practical value; we
>just don't have time to mess around with UNIX, WINDOWS, or Palm OS
>internals.)
Any code, badly written, is a nightmare of maintenance and support. However,
scripting /= bad code. I've done a great deal of scripting in many shells, perl,
python, and I can say that you can write just as readable, modular, solid code
in them as you can in languages intended for larger applications. You can write
trash too. That's your choice.
My last project was in 10,000 lines of Perl. I broke it up into several
files with different namespaces, and maintenance is no more difficult than any
other language.
As for fragmentation, UNIX fragmenting was more an issue of proprietary
designs than anything else. Linux is mildly fragmented. About as much as Win98
SE, and it's 7 different paths to reach it, none of which are fully compatible
with the others. Standardization in Linux is growing, and compatability is
already quite high, and promises to increase.
>The significance of Microsoft platforms is that they are providing a de
>facto set of standards which are utterly lacking on the UNIX side. These
>standards allow a very high level of integration that is still not possible
>on the UNIX platform as each individual vendor tries to differentiate its
>product by making it un-interoperable with the next fellow's offerings.
>(Look at the fiasco that CORBA has become.)
Personally, I have few problems porting code across UNIX, and I work on
Linux, Solaris and HP/UX platforms. And Microsoft's de-facto standards come with
a cost, being that you must use their products, specifically designed to pull
programmers away from accepted standards to become entrenched in their products.
They are not helping standardization, they are destroying it. SMTP and MIME in
the exchange server are non-standard. With win2k they've messed with Kerberos.
The first thing they did to Java was warp the library to make it incompatible. I
could go on but I won't. Check into it yourself. I simply cannot endorse such
practices, even if I wished to use their products.
>Moreover, some of us not only like Micorosoft platforms but also think that
>they are, in fact, superior. The key element, in my opinion, is the ease of
>use of these platforms, the existence of a software component market, and
>the existence of inexpensive hardware. As for reliability, I only know two
>reliable platforms; the mainframes from IBM and the highly redundant UNIX
>machines from Tandem.
UNIX is not hard to use at all. It's harder to learn. Personally I find that
a good investment in learning is far better than taking the easy way out. In an
operating system, reliability is _not_ an option. Until reliability is achieved,
you're simply building on sand. I also do not find that platform flexible at
all. If the tool isn't provided, you must make due. I don't care how much
forsight you have, you cannot predict my needs.
>I like the ISE Eiffel additionally because its "C" code generation allows us
>to be cross-platform, and, at the same time, to preserve out IP.
I don't follow the, "preserve out IP" statement, but GNU's SmallEiffel has a
compile_to_c as well. C was created to code UNIX. It's only natural.
I any case, I still believe that choice is better. I don't believe that the
platform you've chosen gives you as much choice, but feel free. I still think
their logo should be, "This is where you will go today".
Cheers,
Mike
Michael P. Soulier
<Friedrich...@inka.de> wrote:
>I doubt that. Why? Because anyway you have to compile the code and you forget
>to say integration to work as part of a pipe makes it not easier. And one
>should not forget that Eiffel is strongly typed. How will you fit that on the
>comman-line? You will use STRING all over the place. So it seems that
>String-facilities are very important.
I know personally that string facilities are very important. If Perl didn't
handle strings so well, we'd probably just be using C. Eiffel's string handling
is of great interest to me.
Mike
Michael P. Soulier
>An alternative for Linux (possibly Unix) scripts is that you could write
them in,
you would
>substitute for them in the windows environment. If you like dialog box
>interactions, that can be managed. Etc. It just depends on how much work
you want
>to put in on the front end, or how much effort you devote to making the
system more
>user friendly after you have it working.
You can do the same in Perl. I've tried Perl/Tk on UNIX and windows, and it
works well. Python is good on both platforms, and both languages are free.
RedHat does all of its system administration GUIs in Python with Tkinter.
I'm checking it out myself. Seems like a nice language.
Having a standard graphics package with Eiffel certainly wouldn't hurt.
Mike
--
Michael P. Soulier <msou...@storm.ca>
--------------------------------------
"To listen to the words of the learned, and to instill into others the
lessons of science, is better than religious exercises."
-- Prophet Muhammad (pbuh)
Michael P. Soulier
wrote:
>Do you write it in Eiffel, or some other compiled langauge, or just go with
>Perl? In the end, I find it easier to go with Perl (and this from someone who
Hell, ActiveState Perl is included with service packs for NT, and it's the
new Win2k scripting language. Yet another good idea taken from UNIX.
>- powerful regular expression handling
Oh yeah, I meant to ask whether Eiffel has regexp support. I take it that it
doesn't? I suppose you could use external calls to the regexp libraries, but why
would you want to?
I find regexp's too useful to live without.
>- the ability to send email
Can't you open pipes with Eiffel?
>- the ability to start an external program and easily get the error status
You can't do this with Eiffel? Half the work I do is gluing apps together
that weren't meant to talk together. If Eiffel can't do that, its usefulness to
me could be severely limited.
>MS haven't established any real standards on windows - they provide a
>monoculture, in which (of course) everything (they produce; = about 80% of
>everything) works together. With respect to the number of different vendors and
>tools on unix, interoperability on unix is just as great as on Windows. On
>Windows, I cannot for example easily deal with Word 97 files in Word 6, Word 95,
>Word 2000, without each one of these tools making serious mistakes with the
>file. And the solution.... RTF is a classic example of non-interoperability. But
>I can move FrameMaker files from unix to windows to mac, and apart from font
>differences, have exactly the same thing.
Good point. Mind you, I use LaTeX, because I've found it the ultimate in
functionality and portability. I've found MS-Word very difficult to port
anywhere, but then, that's how they designed it.
>Be careful - depending on what you are doing, they are not easy to use: examples
>- MFC programming (does anyone think the MFC makes any sense?); windows 98 is
Only if you like Macros. And C++ was supposed to de-emphasize macros because
they're more difficult to debug. What does Microsoft do? Introduces a ton of new
ones. *sigh*
>quite simply a dog, and if such a product had been brought out by a car
>manufacturer, they would be in jail right now; writing scripts on any windows
>platform (using the braindead batch file language) and so on. But... yes, there
>are other aspects in which the windows platforms are easier to use, and more
>suited to certain jobs; visual GUI development has always been quicker for
>example.
Until recently, the graphics libraries on M$ platforms were much more
advanced. Most UNIX GUIs looked like they were done in crayon. Now with Qt and
Gtk+, they've finally caught up in quality. My father looked at my computer
running KDE and thought it was windows.
>You have to remember one thing though: as long as you stay within the cocoon of
>MS software on a windows platform, you are relatively safe and sure. Once you
>step outside (for example, I use Frame, Eiffel, StarOffice, a GIS system,
>Matisse, Netscape, etc), things are not always so simple. And MS has a
>well-documented history of making life hard for other software vendors to make
>their software run properly on Windows.
No kidding. I'm hoping that Eiffel will provide a reasonably portable
language, compiling to native code. Java is one solution, but they've realized
that the interpreted bytecode is just too slow, so most provide native compilers
now. This should be interesting. One thing I like about Java is the built-in
graphical API. However, now that Gtk+ has been ported to windows, perhaps eGtk
would be a viable alternative.
Michael P. Soulier
>
>I guess you are not using CW on the Mac though. One thing I would like to
guage is how much
>demand would there be for Eiffel running under CW on other platforms?
No, I've touched an Apple computer like, once. Not my personal choice, but
I've heard a few good things about them.
>True, and I think that is why ISE have not put a great deal of effort into
their own
>editor. But using external editors lacks integration.
>
>I do agree with you that more powerful editing facilities like in vi or
emacs is a good
>thing.
Perhaps the solution is, since both of these editors are free and
open-sourced, is to rely on the users to provide the integration. I was quite
happy to find that Vim had Eiffel support, so I immediately had syntax shading.
Then I read the ctags manpage, and found that it had Eiffel support.
Both Emacs and Vim have their own scripting languages. Better integration
could be provided by users like myself who use them, or anyone who decided to
take the time. Vim also allows linking with Perl and Python interpreters, so
such extensions could be written in those languages instead.
Cheers,
Friedrich Dominicus
>> Do you write it in Eiffel, or some other compiled langauge, or just go with
>> Perl? In the end, I find it easier to go with Perl (and this from someone who
MPS> Hell, ActiveState Perl is included with service packs for NT, and it's the
MPS> new Win2k scripting language. Yet another good idea taken from UNIX.
>> - powerful regular expression handling
MPS> Oh yeah, I meant to ask whether Eiffel has regexp support. I take it that it
MPS> doesn't? I suppose you could use external calls to the regexp libraries, but why
MPS> would you want to?
All Eiffels offer some sort of regular expression. And you can even download
a package from the eiffel-forum.
Regards
Friedrich
Michael P. Soulier
>
>Nah... actually you said "Put me in Vi, or better yet Vim, and I'm very
>productive. Anything else is a
>waste of time." So Ian didn't misquote you at all.
Thanks for pulling the quote out of context. As I said, my discussion was
regarding more full-featured editors, proven with my reference to Emacs. But
hey, you'll believe whatever you like.
>I believe that you missed the point.
Funny, I was just thinking the same of you. What you believe I said is
irrelevant. I've stated my intentions.
David Broadfoot
> On Sun, 2 Apr 2000 23:42:42 +1000, David Broadfoot <da...@synax.com.au>
wrote:
> >[snip]
> >> *laugh* Sir, I did not say, "if it's not vi it's crap".
> >
> >Actually, you said "Anything else is a waste of time."
>
> The "anything else" I was referring to, were editors that do not provide
any
> real editing facilities, but simply permit one to enter text. My original
post
> suggested vi, Vim and Emacs, constrasting it to the functionality of the
ISE
> Eiffel editor in edit mode being the same as the windows notepad. My
opinion is
Nah... actually you said "Put me in Vi, or better yet Vim, and I'm very
productive. Anything else is a
waste of time." So Ian didn't misquote you at all.
> >Well, you also stated your opinions as fact. It's a natural way that
people
> >express their opinions. It's not neceesary to always add IMHO, IMHO.
>
> I didn't think I did, but it's certainly possible that I came across that
> way. In any case, thanks for the reminder. It's always good to remind us
that
> there are other opinions out there.
I believe that you missed the point.
Regards,
David
Joachim Durchholz
>
> I guess if Eiffel had:
> - a consistent file/directory handling interface and a fast
> implementation
Agreed: this is a problem.
> - powerful regular expression handling
Not agreed: it's available (take a look at the regexp packages at
http://www.eiffel-forum.org/archive/category.htm#regexp).
> - the ability to do file stream editing like sed or Perl
> - the ability to send email
> - the ability to start an external program and easily get
> the error status
Agreed. Though it shouldn't be too difficult to whip up a framework for
this; the elements are all there. This may stumble over cross-compiler
portability issues though.
> MS haven't established any real standards on windows - they provide
> a monoculture, in which (of course) everything (they produce;
> = about 80% of everything) works together.
... and not even these interoperate perfectly, one might add.
On the other hand, the Windows platform shares one important
standardization feature with the Macintosh: You don't have to learn (or
configure) the keyboard interface with every new application, the keys
are always the same.
I have to use hjkl for vi and emacs (I think), u and d (or was it p and
n?) for mail readers, etc. etc. etc. In Windows, I can count that every
list that looks like a list can be navigated using the up/down arrow
keys, the Page Up/Page Down keys, and I can jump to the entries that
start with a given letter by pressing the corresponding letter key.
I know I can configure most Unix programs. However, every Unix program
has its special configuration file format and wants the configuration
file(s) in a different directory, so I'm spending hours to install a new
package and configure it for my use. Luckily, for the Linux platform
most stuff comes configured for a standard PC keybord. Unfortunately,
these binding are of very arbitrary quality.
One other note: It *is* possible to do script programming on Windows.
You can always install the GNU tools; they even come preconfigured and
prepackaged for Windows if you pull them from Cygnus. And *all*
compilers in the market, including Visual C++ and the Eiffel compilers,
can be run from the command line.
This doesn't mean that I like Microsoft. But you have to attack it on
other grounds than unsuitability as a scripting platform.
> > use of these platforms, the existence of a software component
> > market, and
>
> Be careful - depending on what you are doing, they are not easy
> to use: examples
> - MFC programming (does anyone think the MFC makes any sense?)
Well, apart form the View/Document stuff (which I haven't used) it does
make sense. One of the most important goals of MFC is that the
programmer can manipulate the underlying Windows controls directly, and
that means that the interface of MFC cannot be substantially better than
that of the Windows APIs (which have been getting better over the years:
from horrible to just plain bad...)
Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.
Andreas Leitner
> Thomas Beale <tho...@deepthought.com.au> wrote:
> Well, apart form the View/Document stuff (which I haven't used) it does
> make sense. One of the most important goals of MFC is that the
> programmer can manipulate the underlying Windows controls directly, and
> that means that the interface of MFC cannot be substantially better than
> that of the Windows APIs (which have been getting better over the years:
> from horrible to just plain bad...)
The last time I looked CString was not usable in a console application,
because it was tied together with the GUI stuff. Now that has nothing to
do with the Win32 API, but some very questionable design decissions (;
I guess we are getting off-topic (;
bg,
Andreas
Michael P. Soulier
wrote:
>
>The last time I looked CString was not usable in a console application,
>because it was tied together with the GUI stuff. Now that has nothing to
>do with the Win32 API, but some very questionable design decissions (;
Actually, you just cast it and it's perfectly usable. It's far from
intuitive however. The MFC is a huge mess.
Mike
Andreas Leitner
I don't understand. Last time I checked (which must be now around 2 years ago),
one was not able to use CString in a Console application, because it simply
wouldn't compile. If you included CString, you need a whole bunch of othe header
files and the libraries to include. There was even a CString clone especiall made for
console apps flying around.
bg,
Andreas
Peter Shrosbree
I don't use MFC, but you can certainly build a bona fide Win32 console
application that uses MFC using the standard VC6 wizards: File | New... |
Projects | Win32 Console Application | An application the supports MFC. In
fact, I remember seeing a Microsoft MFC tutorial in '91/'92 in which the MFC
persistence mechanism was explained using a console mode application.
Regards,
Peter
"Andreas Leitner" <andreas...@chello.at> wrote in message
news:a0EJ4.4823$6X3.1...@news.chello.at...
Mickey Williams
initialize the library correctly. If you build a project using the wizards
it's done for you automatically. If you really want to know the gory
details, send me an email.
---
Mickey Williams
www.codevtech.com
"Peter Shrosbree" <psh...@iafrica.com> wrote in message
news:38f82...@news1.mweb.co.za...