And then there are three: ISE Eiffel, Cincom VW Smalltalk, Franz Allegro CL
Resty Cena
development system that will supplement VB and Oracle Developer.
Whatever the choice, it should have the best parts of VB and Oracle
(support for database backend, drag and drop application builder), and
provide what these two don't offer: dynamism. Since it will be
recommended as a corporate standard, it should have the one thing that
managers look for: good support.
The list has been narrowed down to three: ISE Eiffel, Cincom
Smalltalk, and Allegro CL. It appears that Allegro CL ODBC
*surprisingly* does not support stored procedures (XAnalys' LispWorks
apparently does, but I have not succeeded prying their CommonSQL from
their vaults for evaluation). Of the three, Cincom Smalltalk has the
best database support, and I can forgive the idiosyncracies of their
application builder (VA Smalltalk with WindowBuilder is an
alternative).
I have been trying very hard to give ISE Eiffel a chance, but it
doesn't even get to first base! The database examples do NOT compile!
They don't compile because the ace files expect to find a
...\library\store subdirectory, but it's not there. I'd hate to
eliminate Eiffel from consideration on this basis (on the other hand,
you can count this under the column on product quality and
robustness). ISE Eiffel provides three things that neither VW
Smalltalk nor Allego CL provides: native DbC, built-in agents, and
.NET.
Does anybody know how to get those examples to work? Has anybody in
fact succeeded in compiling those examples?
Eric Bezault
>
> I have been trying very hard to give ISE Eiffel a chance, but it
> doesn't even get to first base! The database examples do NOT compile!
> They don't compile because the ace files expect to find a
> ...\library\store subdirectory, but it's not there.
I have ISE Eiffel 5.1 enterprise edition installed on my PC
and it contains the ...\library\store subdirectory. My guess
is that you have the evaluation edition and it does not
contain the EiffelStore library. If this is the case you
should probably contact ISE <info @at@ eiffel .dot. com>
in order to find an arrangement and have an evalution version
of EiffelStore.
> I'd hate to
> eliminate Eiffel from consideration on this basis (on the other hand,
> you can count this under the column on product quality and
> robustness).
I would not. Would you say that C++ (or whatever) is not robust
just because you tried to compile a program but the necessary
.lib for some of the classes used was not installed on your PC?
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com
Resty Cena
> Resty Cena wrote:
> >
> > I have been trying very hard to give ISE Eiffel a chance, but it
> > doesn't even get to first base! The database examples do NOT compile!
> > They don't compile because the ace files expect to find a
> > ...\library\store subdirectory, but it's not there.
>
> I have ISE Eiffel 5.1 enterprise edition installed on my PC
> and it contains the ...\library\store subdirectory. My guess
> is that you have the evaluation edition and it does not
> contain the EiffelStore library. If this is the case you
> should probably contact ISE <info @at@ eiffel .dot. com>
> in order to find an arrangement and have an evalution version
> of EiffelStore.
>
It surprises me that EiffelStore is not part of the evaluation package
(I didn't see any mention that the evaluation copy was debilitated in
this sense.) ISE Eiffel is being postured as an enterprise development
system. I don't understand a strategy in which to properly evaluate a
product, the vendor requires the evaluator to make special arrangement
to have access to the very first thing that the evaluator looks for:
database support. To me this is an unnecessary extra step. Better to
prevent the generation of EXE or runnable image file, or limit the
number of objects that can be created, but throw in every productivity
feature you have, and don't forget the kitchen sink, in the evaluation
copy.
So, yes, I will contact ISE.
rmc
Friedrich Dominicus
>
> The list has been narrowed down to three: ISE Eiffel, Cincom
> Smalltalk, and Allegro CL. It appears that Allegro CL ODBC
> *surprisingly* does not support stored procedures (XAnalys' LispWorks
> apparently does, but I have not succeeded prying their CommonSQL from
> their vaults for evaluation).
Well you could use UncommonSQL which works at least with three
implementations Allegro CL, LispWorks, CMUCL. Have you really
contacted Xanalys? I prefer LispWorks over the others because it's
reasonable priced, provides very useful libraries and has a very good
support (at least for me)
>Of the three, Cincom Smalltalk has the
> best database support, and I can forgive the idiosyncracies of their
> application builder (VA Smalltalk with WindowBuilder is an
> alternative).
Well UncommonSQL works with the "free" Databases CommonSQL with Oracle
and with Version 4.2 too via ODBC.
>
> I have been trying very hard to give ISE Eiffel a chance, but it
> doesn't even get to first base! The database examples do NOT compile!
> They don't compile because the ace files expect to find a
> ...\library\store subdirectory, but it's not there. I'd hate to
> eliminate Eiffel from consideration on this basis (on the other hand,
> you can count this under the column on product quality and
> robustness). ISE Eiffel provides three things that neither VW
> Smalltalk nor Allego CL provides: native DbC, built-in agents, and
> .NET.
Well the first and last point holds but definitly not two. Agents are
Functions and Lisp do support that much better than Eiffel. To DBC
well Lisp is a hallmark for extensibility. Therfore you can write you
own Object Model. Some have done this and implemented DBC for
Lisp. .NET is another things, but if you can use you implementation on
everywhere (with the same libraries) the .NET advantages seem to be
a bit smaller. Sooner or later there will be an implementation of any
language targeting .NET.
Anyway at the moment .NET just works for Windows. Well ISE Eiffel runs
on some more platforms so did LispWorks, AllegroCL etc.
>
> Does anybody know how to get those examples to work? Has anybody in
> fact succeeded in compiling those examples?
As Eric pointed out the probably do not ship the Database stuff with
the evaluation copy.
Regards
Friedrich
Eric Bezault
>
> I don't understand a strategy in which to properly evaluate a
> product, the vendor requires the evaluator to make special arrangement
> to have access to the very first thing that the evaluator looks for:
> database support.
You mean the very first thing _you_ look for. It might be
that there is a minority of people interested in evaluating
EiffelStore and that might be why they didn't include it
in their standard evalution version.
> To me this is an unnecessary extra step.
Agreed.
> Better to
> prevent the generation of EXE or runnable image file, or limit the
> number of objects that can be created, but throw in every productivity
> feature you have, and don't forget the kitchen sink, in the evaluation
> copy.
But sometimes _the evaluator_ is not interested in database support
but is rather interested in figuring out how fast the generated EXE
will run, what the impact of garbage collection, dynamic binding, etc.
will have on the execution speed compared to the language (s)he
currently uses.
> So, yes, I will contact ISE.
Yes: when the standard evaluation version does not allow you
the test what you are interested in, just contact the vendor
to have a customized evalution version that better fits your
need.
Also, please note that you can use ISE EiffelStudio as a development
environment and use third-party Eiffel libraries in your
programs. I'm sure that there are open source database libraries
out there that work with ISE Eiffel.
Resty Cena
> Resty Cena wrote:
> >
> > I don't understand a strategy in which to properly evaluate a
> > product, the vendor requires the evaluator to make special arrangement
> > to have access to the very first thing that the evaluator looks for:
> > database support.
>
> You mean the very first thing _you_ look for. It might be
> that there is a minority of people interested in evaluating
> EiffelStore and that might be why they didn't include it
> in their standard evalution version.
>
persistent data capability, I wonder what they use it for. I maybe
looking at a product here that is not normally used for database
application development. I could get into trouble here.
> > To me this is an unnecessary extra step.
>
> Agreed.
>
> > Better to
> > prevent the generation of EXE or runnable image file, or limit the
> > number of objects that can be created, but throw in every productivity
> > feature you have, and don't forget the kitchen sink, in the evaluation
> > copy.
>
> But sometimes _the evaluator_ is not interested in database support
> but is rather interested in figuring out how fast the generated EXE
> will run, what the impact of garbage collection, dynamic binding, etc.
> will have on the execution speed compared to the language (s)he
> currently uses.
>
Agreed. I happen to be interested in finding out first if the product
will do what I want to do before I look at performance. My customers
are slower than even the slowest compiled code. Performance
bottlenecks in typical database applications happen in relation to
reading and writing records in the database.
> Also, please note that you can use ISE EiffelStudio as a development
> environment and use third-party Eiffel libraries in your
> programs. I'm sure that there are open source database libraries
> out there that work with ISE Eiffel.
My customers don't like this kind of creative mixing and matching of
parts from different vendors within a project. They like to deal with
companies they can sue if things don't go well.
My point is that the growth area for a development system like Eiffel
that is positioning itself as an enterprise solution is the area of
database application development. There are millions of VB, Oracle
Developer, PowerBuilder, and Delphi developers out there to be snared.
rmc
Eric Bezault
>
> If there is a minority of people interested in evaluating Eiffel's
> persistent data capability, I wonder what they use it for.
Eiffel is not a database programming language, it's a general
programming language. You can develop many kinds of applications
other than some which need database access.
At CALFP (http://www.eiffel.com/eiffel/projects/calfp/page.html)
we use Eiffel and also access a database, but we don't use ISE
EiffelStore. Instead we use the Eiffel/Versant library:
http://www.grator.org/versant/index.html
> My customers don't like this kind of creative mixing and matching of
> parts from different vendors within a project. They like to deal with
> companies they can sue if things don't go well.
That's their choice. But I think that it is more productive
to focus on building robust and reliable software, be it from
different providers or even open source, rather than wasting
time sueing companies. I think that what is important is not
the fact that you can sue a company or not, but rather what
level of support you can get for the products and libraries
you decide to use to build your software. But anyway I don't
think that this is my job to convince your customers about
that.
Resty Cena
> rc...@epcor.ca (Resty Cena) writes:
>
> >
> > The list has been narrowed down to three: ISE Eiffel, Cincom
> > Smalltalk, and Allegro CL. It appears that Allegro CL ODBC
> > *surprisingly* does not support stored procedures (XAnalys' LispWorks
> > apparently does, but I have not succeeded prying their CommonSQL from
> > their vaults for evaluation).
> Well you could use UncommonSQL which works at least with three
> implementations Allegro CL, LispWorks, CMUCL. Have you really
> contacted Xanalys?
Yes, I contacted both Franz and XAnalys. Franz very kindly sent me the
whole works. However, it looks like their odbc does not support calls
to (Oracle) stored procedures. I've sent sample code to their tech
support, and I hope they find a way to get even calls to anonymous
PL/SQL stored proc working (for sentimental reasons, Lisp is my first
subjective choice. But enough of this subjective choices; I've learned
a lesson with the Macintosh).
>
> Well UncommonSQL works with the "free" Databases CommonSQL with Oracle
> and with Version 4.2 too via ODBC.
>
I'll take a look at uncommonSQL. But tacking on an unsupported
component, and a critical one at that, is not the sort of thing that
will fly by the auditors on critical enterprise systems. Who do they
talk to when they decide to upgrade to Oracle 9i and uncommonSQL isn't
there?
>
> >ISE Eiffel provides three things that neither VW
> > Smalltalk nor Allego CL provides: native DbC, built-in agents, and
> > .NET.
> Well the first and last point holds but definitly not two. Agents are
> Functions and Lisp do support that much better than Eiffel. To DBC
> well Lisp is a hallmark for extensibility. Therfore you can write you
> own Object Model. Some have done this and implemented DBC for
> Lisp.
If I want steak, I'd go to a steakhouse, rather than to a place that
specializes in Chicken that by the way serve steak as well. May not be
a wholly appropriate metaphor, but if agents is my primary
consideration, I'd go Eiffel right away. (DbC, agents, and .NET are
only secondary considerations, but big secondaries).
>.NET is another things, but if you can use you implementation on
> everywhere (with the same libraries) the .NET advantages seem to be
> a bit smaller. Sooner or later there will be an implementation of any
> language targeting .NET.
>
There have been a few discussions on dot netting Lisp in c.l.lisp. I
gather, from a Franz Lisp poster, that there are two major reasons why
not: (a) technical: for Lisp.NET to work as current Lisp does, it is a
huge technical problem on account of some things the .NET architecture
has not provided for, and (b) at least this Franz Lisp poster feels
that the future of .NET is uncertain at this point.
> Anyway at the moment .NET just works for Windows.
From where I sit, admittedly a few thousand miles from Seattle, I can
see that the hidden agenda for .NET is that it can easily be ported to
other OS if need be. Why else is MS abandoning their not too shabby
COM architecture?
I go to a computer bookstore every week. I've been noticing a few
things: The VB6 and C++ books are drying up; no new titles. And While
the Java shelves are the most stocked, the .NET shelves (VB.NET, C#,
ASP.NET) have the most activities lately. The floodgates have opened.
Incidentally, not a single Eiffel, nor Lisp title. There's a Kent Beck
book on Smalltalk. Hmmm.
But thanks for taking the time to reply to my posting.
best,
rmc
Friedrich Dominicus
> > Well UncommonSQL works with the "free" Databases CommonSQL with Oracle
> > and with Version 4.2 too via ODBC.
> >
> I'll take a look at uncommonSQL. But tacking on an unsupported
> component, and a critical one at that, is not the sort of thing that
> will fly by the auditors on critical enterprise systems. Who do they
> talk to when they decide to upgrade to Oracle 9i and uncommonSQL isn't
> there?
Oracle, and they will be still there.
> >
>
> > >ISE Eiffel provides three things that neither VW
> > > Smalltalk nor Allego CL provides: native DbC, built-in agents, and
> > > .NET.
> > Well the first and last point holds but definitly not two. Agents are
> > Functions and Lisp do support that much better than Eiffel. To DBC
> > well Lisp is a hallmark for extensibility. Therfore you can write you
> > own Object Model. Some have done this and implemented DBC for
> > Lisp.
>
> If I want steak, I'd go to a steakhouse, rather than to a place that
> specializes in Chicken that by the way serve steak as well.
This is short-sigthed. It's not steak nor chicken it's about
extensibility. And while we are talking about Database Access. The
CommonSQL interface uses the facilities to establish a class hiearchy
which "knows" how to make themselves persistent. That means you can
put either objects in RDBS or just simply access the tables as they
are.
> May not be
> a wholly appropriate metaphor, but if agents is my primary
> consideration, I'd go Eiffel right away. (DbC, agents, and .NET are
> only secondary considerations, but big secondaries).
Well as I tried to point out agents is an after-thought in Eiffel
whereas Functions were are and will be first-class cititzens in Lisp
or other functional languages. I suggest you make yourself comfortable
with agents and than you might see what they really are.
> From where I sit, admittedly a few thousand miles from Seattle, I can
> see that the hidden agenda for .NET is that it can easily be ported to
> other OS if need be. Why else is MS abandoning their not too shabby
> COM architecture?
Well do they really abondon COM or is .NET not just an evolutionary
step? Well I'm quite sure that more comes from COM than M$ tells us.
>
> I go to a computer bookstore every week. I've been noticing a few
> things: The VB6 and C++ books are drying up; no new titles. And While
> the Java shelves are the most stocked, the .NET shelves (VB.NET, C#,
> ASP.NET) have the most activities lately. The floodgates have opened.
> Incidentally, not a single Eiffel, nor Lisp title. There's a Kent Beck
> book on Smalltalk. Hmmm.
Well I can name some Eiffel and Lisp books, that C++ and VB books are
drying up is not my impression. Well Java is obviusly quite hot but
there are too a bunch of books for Python, Perl ...
>
> But thanks for taking the time to reply to my posting.
Well newgroups are for discussions ;-)
Regards
Friedrich
Jim Cochrane
Resty Cena <rc...@epcor.ca> wrote:
>Eric Bezault <er...@gobosoft.com> wrote in message news:<3C2D91ED...@gobosoft.com>...
>
>> environment and use third-party Eiffel libraries in your
>> programs. I'm sure that there are open source database libraries
>> out there that work with ISE Eiffel.
>
>My customers don't like this kind of creative mixing and matching of
>parts from different vendors within a project. They like to deal with
>companies they can sue if things don't go well.
On the other hand, is it even realistic to expect to be able to sue
Microsoft if things don't go well when using their products?
--
Jim Cochrane
j...@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
Patrick Doyle
Resty Cena <rc...@epcor.ca> wrote:
>
>if agents is my primary
>consideration, I'd go Eiffel right away. (DbC, agents, and .NET are
>only secondary considerations, but big secondaries).
Are you sure you're talking about the same "agents"? Eiffel's agents
are basically closures. They do the same thing as Lisp's first-class
functions.
--
--
Patrick Doyle
doy...@eecg.toronto.edu
Resty Cena
> Resty Cena wrote:
>
>
> > My customers don't like this kind of creative mixing and matching of
> > parts from different vendors within a project. They like to deal with
> > companies they can sue if things don't go well.
>
> That's their choice. But I think that it is more productive
> to focus on building robust and reliable software, be it from
> different providers or even open source, rather than wasting
> time sueing companies. I think that what is important is not
> the fact that you can sue a company or not, but rather what
> level of support you can get for the products and libraries
> you decide to use to build your software. But anyway I don't
> think that this is my job to convince your customers about
> that.
The use of the word 'sue' in the context is just an exaggeration to
make a point. It is not to be interpreted literally! In the first
place, no self-respecting software vendor company would sell anything
to anybody without the "no guarrantee, implied or otherwise" clause.
Ok, so I forgot to punctuate it with the wink, wink Smiley. So, sue me
;-)
Patrick Doyle
>
>In the first
>place, no self-respecting software vendor company would sell anything
>to anybody without the "no guarrantee, implied or otherwise" clause.
What a sad statement on the state of software engineering.
From time to time, I get the urge to start a company called "Guaranteed
Software Incorporated", but the sad truth is that software development
technology just doesn't seem to be up to the task. I wouldn't want to
trust my livlihood to any existing software technology I'm aware of.
Darren New
> Are you sure you're talking about the same "agents"? Eiffel's agents
> are basically closures. They do the same thing as Lisp's first-class
> functions.
Yes, and Smalltalk has them too. Indeed, they're one of the fundamental
control structures in Smalltalk, called "blocks". You can't even do an
if-then without the equivalent of an Eiffel Agent in Smalltalk. If that
makes sense.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
"This wine goes good with feet."
Eirik Mangseth
"Patrick Doyle" <doy...@eecg.toronto.edu> wrote in message
news:Gp84s...@ecf.utoronto.ca...
You'd be better off starting "Obnoxious Software, Inc.". Too much polite
software out there IMHO ;-)
>
> --
> --
> Patrick Doyle
> doy...@eecg.toronto.edu
-- eirik
"If I can't Eiffel in heaven, I won't go"
Roger Browne
> ... no self-respecting software vendor company would sell anything
> to anybody without the "no guarrantee, implied or otherwise" clause.
Patrick Doyle wrote:
> What a sad statement on the state of software engineering.
>
> From time to time, I get the urge to start a company called "Guaranteed
> Software Incorporated", but the sad truth is that software development
> technology just doesn't seem to be up to the task. I wouldn't want to
> trust my livlihood to any existing software technology I'm aware of.
Perhaps "Guaranteed Software Incorporated" could sell software with the
following notice:
"Designed By Contract. Guaranteed to fulfil its contracts
or raise an exception when compiled with assertions
enabled on a correctly-performing Eiffel compiler.
Catcalls excluded."
Regards,
Roger
--
Roger Browne - ro...@eiffel.tm - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428