Question: How usable is Linux Visual-Eiffel?
AnonymousFC4
I am wondering what is the level of usability of Visual-Eiffel?
Is it a already solid (say like gcc or g++) compiler, or the begining of an
Open source compiler?
How would you compare it to Smart-Eiffel?
Thanks to post about your experience.
---
kin...@gmail.com
say that it is somewhat comparable back to the SmallEiffel 1.1 days.
It has a rich associated toolset, a good built-in container hierarchy,
works with Gobo, and is of comparable speed.
Roger Browne
> I am wondering what is the level of usability of Visual-Eiffel?
> Is it a already solid (say like gcc or g++) compiler
Yes. Visual Eiffel's compilation and code generation is solid and
reliable.
> or the begining of an Open source compiler?
Visual Eiffel has only recently been open-sourced, but it was developed
as proprietary software since somewhere around 1994 or 1995. The early
development was for MS-Windows, and only the command-line compiler has
been ported to Linux. The IDE, GUI debugger, etc are only in the Windows
version.
> How would you compare it to Smart-Eiffel?
Both are open-source command-line compilers licensed under the GPL.
Visual Eiffel's libraries are GPL-licensed whereas SmartEiffel's
libraries are under a less restrictive BSD-like license.
SmartEiffel is easier to build from source (requiring only an ANSI C
compiler). Visual Eiffel has more dependencies, including a specific
version of gcc. However, you don't have to build Visual Eiffel yourself
unless you intend to modify it, because a binary Linux distribution is
also distributed.
Visual Eiffel is an incremental compiler and is much faster to recompile
very large systems. The code generated by SmartEiffel probably runs
slightly faster.
Visual Eiffel implements the version of Eiffel described in Meyer's book
"Eiffel The Language" (2nd printing). It's probably the closest that any
compiler has come to implementing this version of the language.
SmartEiffel includes more recent extensions (such as tuples and agents),
but has also diverged away from ETL2 in several ways (such as
inheritance/conformance).
The rate of development of SmartEiffel is currently faster.
Regards,
Roger Browne
AnonymousFC4
thanks for the precisions... now I will have to figure out what is GOBO
and ETL2 (I understand they are libraries though).
I have only played with smarteiffel...
Too me it is missing the capability of using a debugger (ELF/DWARF compiler
options).
Does Visual Eiffel have (on Linux) better debugging capabilities
(breakpoints, single stepping etc...)?
In almost any order, to be fully useful a language must have:
a) Solid compiler (performances may come later)
b) Good libraries: almost as important: who wants to reinvent the wheel?
c) Good debugging capabilities.
d) A stable language... else compiler design is a moving target!
"The rest" IDE, GUI code generators, usually comes when the basic a, b, c
conditions are fullfilled.
Of all the OO languages Eiffel appeals to me the most, as the best
candidate, but being only a user, I will spend significant work with
Eiffel, only if I have a+b+c...
I will post separately on determinism.
Thanks.
AFC4
-------------------------
Roger Browne
> ... now I will have to figure out what is GOBO
Gobo is an extensive library and toolset that works on multiple Eiffel
compilers. Therefore, if you might be switching between different Eiffel
compilers, it's a good idea to use the libraries included in Gobo.
On the other hand, if you are sure which compiler you are using, you
might find its own libraries easier to learn and use.
> and ETL2
ETL2 refers to the book "Eiffel The Language, 2nd Printing". For many
years it was the accepted standard definition of Eiffel. Now we have
"ECMA Eiffel", which has diverged from ETL2 but is the new standard.
However, ECMA Eiffel is not acceptable to the SmartEiffel team, who have
diverged in their own directions from ETL2.
> I have only played with smarteiffel...
> Too me it is missing the capability of using a debugger (ELF/DWARF compiler
> options).
You are asking for one specific kind of debugger. In the world of C/C++,
this kind of debugging is de rigeur, but it's not necessary for Eiffel
where your contracts are doing the debugging for you all the time (when
you run your application with runtime checking of contracts enabled).
For those (very few) times when you want something else, the embedded
debugger of SmartEiffel is usable.
> Does Visual Eiffel have (on Linux) better debugging capabilities
> (breakpoints, single stepping etc...)?
No, it only has these capabilities under MS Windows, where they work
very well.
> In almost any order, to be fully useful a language must have:
>
> a) Solid compiler (performances may come later)
Eiffel has it.
> b) Good libraries: almost as important: who wants to reinvent the wheel?
Eiffel libraries are generally excellent, although not as extensive as
some other languages. You can always use external C libraries though.
> c) Good debugging capabilities.
I've written over a hundred thousand lines of Eiffel and have found the
debugging capabilities to be entirely sufficient.
> d) A stable language... else compiler design is a moving target!
The SmartEiffel team say that their language is now stable. And if you
want a stable language you can't do better than Visual Eiffel which has
closely followed ETL2 and continues to do so.
> "The rest" IDE, GUI code generators, usually comes when the basic a, b, c
> conditions are fullfilled.
I agree. I'm mostly using command-line Eiffel compilers under Linux, and
I do miss the IDEs of Visual Eiffel under Windows, and of EiffelStudio.
But, as you say, it's not such a big deal.
Regards,
Roger Browne
kin...@gmail.com
I think that your focus on needing a good interactive debugger is
misplaced and unwarranted.
When programming using contracts, one *very* rarely needs a debugger.
And in my personal experience, this is even true is messy languages
like C and C++. This statement has been made in this and related
forums for years by people experienced with programming with and
without contracts, and, contrary to some counter-claims, it is not
because some of our favorite languages do not have great interactive
debuggers (e.g., EiffelStudio is a case in point) or because we are
genius programmers, it is simply because it is true.
I actually think it is quite interesting to witness the inverse
corrolation that exists between the quality of a language design and
process and the lack of interactive debuggers. Languages lauded by
broadly experienced computer scientists (e.g., Eiffel, ML variants,
Haskell, the Modula language family, etc.) often little to no debugger
support. Poorly designed languages (i.e., those that are not geared
towards correctness, like C and its descendents) are the ones that need
debuggers exactly because they are poorly designed.
Best,
Joe Kiniry (not "Lee" <g>)
---
Joseph Kiniry
School of Computer Science and Informatics
UCD Dublin
http://secure.ucd.ie/
http://srg.cs.ucd.ie/
Friedrich Dominicus
> Hi AFC4,
>
> I think that your focus on needing a good interactive debugger is
> misplaced and unwarranted.
It really is not, I'm sorry but that is a lame excuse for not having a
decent debugger IMHO. I just propose checking the debugger of ISE
while trying just to follow the program-flow and then try that with
S(mall/mart)Eiffel. However we are not alone with that problem just
try to debug Haskell and you'll see what it mean not to have a decent
debugger. Of course one can work without but it's tedious,boring and
if you also consider that you have to recompile your stuff if you do
help yourself with prints a very time-consuming waste of time.
>
> I actually think it is quite interesting to witness the inverse
> corrolation that exists between the quality of a language design and
> process and the lack of interactive debuggers. Languages lauded by
> broadly experienced computer scientists (e.g., Eiffel, ML variants,
> Haskell, the Modula language family, etc.) often little to no debugger
> support. Poorly designed languages (i.e., those that are not geared
> towards correctness, like C and its descendents) are the ones that need
> debuggers exactly because they are poorly designed.
Well I bet a few thousands of eiffelists and Hakellists will disagree
whoelheartly. Of course there are some things in C and C++ which make
a debugger a necessity, but one can argue that Java, PHP, Ruby, Perl
fall in a similiar case as the functional language and they do provide
some debugger at least good enough to follow the program...
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Mike Meyer
> Well I bet a few thousands of eiffelists and Hakellists will disagree
> whoelheartly. Of course there are some things in C and C++ which make
> a debugger a necessity, but one can argue that Java, PHP, Ruby, Perl
> fall in a similiar case as the functional language and they do provide
> some debugger at least good enough to follow the program...
You'd be wrong to make that last argument, at least for Java, PHP and
Perl. All three of those were (at least initially) designed to look
like languages that were derived from C. Ruby might qualify, but I
suspect I'd rarely use it. That's because it has an interactive
interpreter, which is *far* more useful than an interactive
debugger.
The interpreter lets me load arbitrary objects, and do pretty much
arbitrary things to them. It also lets me add code on the fly, either
utility functions for helping debug things, or extensions to objects
from the program. A really good interactive debugger will let you do
these things as well, but that's far beyond "good enough to follow the
program."
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
H. v. L.
With regard to a good programming language plus a superfast compiler plus
a small, easy to understand, fast to learn IDE plus an excellent debugger
(there are of course many more good features e. g. programming by contract
via using effective assertions) I simply suggest Component Pascal plus the
BlackBox IDE. Alternatively there is a version for the java vm and dot net
Regards
Harro
AnonymousFC4
thanks for your comments: I learned something of value.
Joe:
your argument that you do not really need a debugger is very valid... in
cases where one is tracking a bug related to the use of the language
idiosyncracies, the most common being pointer related errors in the
standard C library. No argument there!
But..:
1) When there is a "thinking" (programmer's induced) bug, and the code does
not do what you expect... because the algorithm is faulty (limits on loops
is very common... and much more), or some I/O related (usually H/W) does
not send you the data you expect, then a decent debugger,which provides a
"windows" of what is going on is an invaluable tool.
I have done lots I/O related programming, and I would advocate that the
writeln/printf (and multiple recompiles) is a painfull way to debug a
program.
2) Adding code to a large system: the best Unix I have ever (as a
programmer) used was SGI-Irix because I worked on a large project, with
millions of lines of code (Fortran+C+C++, and some assembly) and nine
processors. I have to had some code to this huge piece of code, with no
documentation, and without a debugger (along with grep, and tags) to just
understand "my piece" the works would have been a nightmare.
The symbolic debugger was excellent and dealing with shared memory, linked
lists was a breeze. Otherwise I would say it would have been close to
mission impossible.
So when I say I need a good debugger, it is mostly in this context.
And like a profiler (painful to use), when you need it, even only once a
month, I would advocate that having to do without it will induce me to find
possibly a less "perfect" solution but one with the tools I may need.
But a debugger does not have (in my view) super fancy to be an invaluable
tool, to do the job! But I have to admit that a GUI based debugger is very
nice even for the command line guy that I am! IDE are a luxury... but edit
+ compile using Xemacs for example is also quite nice (easy, productive).
But I reconize (and regret) that IDE will bring to a new language lots of
young programmers who are afraid of the apparent complexity of "the old
method"... so IDE may be a "necessary evil" :-)
I went here to great length to explain this point of view, because in the
academic environment (where great work is being done) programmers deal with
clean code, they usually understand well.
In the commercial world, things are less perfect, and some reverse
engineering is almost unavoidable...
I hope I clarified, and did not hurt any feelings.
AFC4
----------------------
Georg Bauhaus
> Component Pascal
Even though CP is small, fast, and imports (and simplifies)
some interesting ideas from Ada, I'd be missing both generics
and design by contract a lot.
genea
under Linux, and
I do miss the IDEs of Visual Eiffel under Windows, and of EiffelStudio.
But, as you say, it's not such a big deal."
For us folks using Open Source Operating Systems like Linux, or the BSDs,
is there a good Eiffel mode out there for Emacs... or support under VIM,
to use as an IDE of sorts, could be as good as any if it is a well written
mode.. or could be extended to become quite good. ??? just curious?
Mike Meyer
> For us folks using Open Source Operating Systems like Linux, or the BSDs,
> is there a good Eiffel mode out there for Emacs... or support under VIM,
> to use as an IDE of sorts, could be as good as any if it is a well written
> mode.. or could be extended to become quite good. ??? just curious?
Xemacs comes with a working Eiffel-mode. It doesn't work quite right
on SmartEiffel.
I also wrote a couple of Eiffel state files for enscript. One does
coler, and one does B&W according as per ETL. I sent them back to the
enscript folks, so hopefully they're bundled with enscript now. If not
and you want them, drop me email or ask here.
genea
Xemacs comes with a working Eiffel-mode. It doesn't work quite right
on SmartEiffel.
Thanks Mike.. okay if it is even close.. I may not get to trying Eiffel
for a bit, as am trying to add the ML family, Haskell and Clean to my
toolbox.. Eiffel certainly sounds interesting, but need to look at some
code and do some reading and a little testing just to see what it is
really all about. I have spent way too many years in the
imperative/procedural world.. and although I use Unicon which supports OOP
I don't much use it, and it is there to use or not, everything is not an
object aka. smalltalk or ruby.. and I haven't used OO constructs yet.
Haskell and the functional programming make the most sense to me, with the
type classes and the inheritance of methods introduced in the type class
definition. So have to see, but the availability of the emacs mode will
help with the learning curve during the trial period.. Might have another
language to apply to projects that it is suited to.
thanks again..
gene
Colin Paul Adams
Fenea> For us folks using Open Source Operating Systems like
Fenea> Linux, or the BSDs, is there a good Eiffel mode out there
Fenea> for Emacs.
Yes. It's available from http://meltin.net/hacks/emacs/ .
--
Colin Adams
Preston Lancashire
Andreas Leitner
> >>>>> "Fenea" == genea <ge...@spamfreein.yuma.az> writes:
>
> Fenea> For us folks using Open Source Operating Systems like
> Fenea> Linux, or the BSDs, is there a good Eiffel mode out there
> Fenea> for Emacs.
>
> Yes. It's available from http://meltin.net/hacks/emacs/ .
In addition you can get tags support for both Emacs and Vi by using
gutentag:
Andreas
Roger Browne
> Xemacs comes with a working Eiffel-mode. It doesn't work quite right
> on SmartEiffel.
For SmartEiffel you can use the Eiffel-mode included in the "misc"
directory of the SmartEiffel distribution.
Regards,
Roger Browne
Roger Browne
> ... or support under VIM,
I don't use vim myself, but eiffel.vim does come with the vim
distribution.
See also Jocelyn Fiat's "Vim Goodies for Eiffel" package which can be
found (together with support for other IDEs) by following the links from
http://eiffelzone.com/esd/tool-ed.html
Regards,
Roger Browne
Roger Browne
> But..:
> 1) When there is a "thinking" (programmer's induced) bug, and the code does
> not do what you expect... because the algorithm is faulty (limits on loops
> is very common... and much more), or some I/O related (usually H/W) does
> not send you the data you expect, then a decent debugger,which provides a
> "windows" of what is going on is an invaluable tool.
No way! The most productive approach with Eiffel is to document your
assumptions by adding assertions. This will lead you to the faulty
assumption. Your example of a "thinko" related to loop termination is
indeed very common, and is pretty much eliminated by adding a loop
invariant and loop variant.
> I have done lots I/O related programming, and I would advocate that the
> writeln/printf (and multiple recompiles) is a painfull way to debug a
> program.
Sure it's painful. But as a "last resort" once every six months or so I
can live with it if need be.
> 2) Adding code to a large system:
> ... without a debugger (along with grep, and tags) to just
> understand "my piece" the works would have been a nightmare.
This is exactly when design by contract is at its strongest. Start
documenting the assumptions at the interface between "your piece" and
the rest of the system. Every time you've got it wrong, the system tells
you. And the system can monitor it every time that execution passes that
point - much more powerful than the few runs that you can do manually
with a debugger (it's like massively parallel debugging!).
Better still, the contracts are still there next time you look at the
code, by which time you might have forgotten the outcome of your
previous debugging episode.
> I went here to great length to explain this point of view, because in the
> academic environment (where great work is being done) programmers deal with
> clean code, they usually understand well.
> In the commercial world, things are less perfect, and some reverse
> engineering is almost unavoidable...
...and in my opinion the best way to reverse engineer a piece of
software is with contracts.
Where you do need a debugger is when the part of the system that you
must reverse engineer is written in a language that doesn't support DBC.
Regards,
Roger Browne
Georg Bauhaus
> ...and in my opinion the best way to reverse engineer a piece of
> software is with contracts.
and of course also to engineer a piece of software. :)
Assertions force you to think twice about what you write,
and in the end the code will be more clear IME, and better
understood.
All the more when there is a complete and integrated
assertion system like DbC.
> Where you do need a debugger is when the part of the system that you
> must reverse engineer is written in a language that doesn't support DBC.
You also need a debugger (or tedious tracing) when conditions
cannot easily be expressed (or not at all) like when validating
input.
feature decide(s: STRING): BOOLEAN is
-- s belongs to the language
require
-- ?
Mike Meyer
Actually, the requirements are easy to specify - it's that s actually
has a string. The *postcondition* is hard to specify, because it's
that the output of decide is correct, which means that the
postcondition has to do the same job that decide does, meaning that a
failed postcondition is as likely to be a bug in the postcondition as
in decide.
This is a case where the tools help. I disagree that a debugger is all
that useful, though. The way to decide if decide is correct is to run
it on test cases with known outputs, and check the results. A debugger
doesn't really help with that. An interactive interpreter helps,
because it lets you feed string to decide and check the results
directly. Unit tests are a must for making sure that your test cases
continue to come out right. Ideally, the source for the method
includes a comment that has the test cases in it, and you use external
tools that read that comment and generate both the class documentation
and the unit tests.
Georg Bauhaus
> Georg Bauhaus <bau...@futureapps.de> writes:
> > feature decide(s: STRING): BOOLEAN is
> > -- s belongs to the language
> > require
> > -- ?
>
> Actually, the requirements are easy to specify - it's that s actually
> has a string.
Yes. OK. Not a good example.
> Ideally, the source for the method
> includes a comment that has the test cases in it,
I was thinking of routines that work depending on
all input so far. I use a debugger, then, much like
a read only interpreter, so that I can have a look
at the program snapshot at some point during
parsing.
-- Georg
kin...@gmail.com
> Joe:
> your argument that you do not really need a debugger is very
> valid... in cases where one is tracking a bug related to the use
> of the language idiosyncracies, the most common being pointer
> related errors in the standard C library. No argument there!
>
> But..:
>
> 1) When there is a "thinking" (programmer's induced) bug, and
> the code does not do what you expect... because the algorithm
> is faulty (limits on loops is very common... and much more), or
> some I/O related (usually H/W) does not send you the data you
> expect, then a decent debugger,which provides a "windows" of
> what is going on is an invaluable tool.
As Roger so eloquently pointed out, this is exactly where
contracts help the most.
> I have done lots I/O related programming, and I would advocate
> that the writeln/printf (and multiple recompiles) is a painfull
> way to debug a program.
Note that I do *not* advocate using embedded print statements.
This is positively the *worst* way to debug a system whatsoever.
When my students turn in programs with this kind of code they get
fairly critical feedback from me, shall we say. In fact, I give
a whole lecture on how to understand what your application is
doing by using intelligent logging frameworks like jLog or
IDebug, but only as a last resort.
> 2) Adding code to a large system: the best Unix I have ever (as
> a programmer) used was SGI-Irix because I worked on a large
> project, with millions of lines of code (Fortran+C+C++, and
> some assembly) and nine processors. I have to had some code to
> this huge piece of code, with no documentation, and without a
> debugger (along with grep, and tags) to just understand "my
> piece" the works would have been a nightmare. The symbolic
> debugger was excellent and dealing with shared memory, linked
> lists was a breeze. Otherwise I would say it would have been
> close to mission impossible.
Symbolic debuggers have their place. Attempting to use
traditional debuggers in a concurrent setting is usually a path
to insanity. The amount of effort that has gone into building
tools to find the errors in poorly designed programs written in
poorly designed languages astounds me. But a great debugger is a
wonderful tool at times, especially a solid, interactive
debugger.
Personally, I prefer gdb-mode in Emacs for C-based apps, XCode on
OS X, JDEE mode, Eclipse and jSwat for Java, and EiffelStudio for
Eiffel. I have also used great debuggers for concurrent
languages and platforms on machines like old Connection
Machines's systems, various parallel C variants, etc. They are
invaluable tools at times, but usually for me only in scenarios
where I am forced to use or understand someone else's code that I
cannot touch and am not permitted to properly document and
specify.
> So when I say I need a good debugger, it is mostly in this
> context. And like a profiler (painful to use), when you need
> it, even only once a month, I would advocate that having to do
> without it will induce me to find possibly a less "perfect"
> solution but one with the tools I may need.
Understood. But I think you will find that if you follow modern
quality software engineering practices you will use a debugger
less and less every day.
> But a debugger does not have (in my view) super fancy to be an
> invaluable tool, to do the job! But I have to admit that a GUI
> based debugger is very nice even for the command line guy that I
> am! IDE are a luxury... but edit + compile using Xemacs for
> example is also quite nice (easy, productive).
I agree. That said, I believe that the basic debugging
facilities included with SmartEiffel and VisualEiffel are
probably not satisfactory for your purposes.
> But I reconize (and regret) that IDE will bring to a new
> language lots of young programmers who are afraid of the
> apparent complexity of "the old method"... so IDE may be
> a "necessary evil" :-)
I understand. Far too many of my students do not even know what
a compiler *is* until they get to my class because the IDE hides
everything from them. They just think some magic happens when
they hit the "run" button. <sigh>
> I went here to great length to explain this point of view,
> because in the academic environment (where great work is being
> done) programmers deal with clean code, they usually understand
> well. In the commercial world, things are less perfect, and some
> reverse engineering is almost unavoidable...
That's why some of us in academia also have long and rich lives
in industry so that our students see a bit of the Real World. :)
Joseph
kin...@gmail.com
Also, if you are working in classic ETL2, Bob Weiner's OO-Browser
for Emacs is a lovely tool. It supports several languages, gives
you a class browser, implicit hyperlinking of types and
definitions, completion, etc.
For my Eiffel development environment I use a highly customised
Emacs setup which includes:
o the OO-browser
<http://sourceforge.net/projects/oo-browser/>
o hyperbole
<http://sourceforge.net/projects/hyperbole/>
o Berend's eiffel-mode
<http://www.berenddeboer.net/eiffel/berend-eiffel.el>
o exuberant ctags
<http://ctags.sourceforge.net/>
o foldout mode (and/or folding-mode and outline-mode)
o and the invaluable planner mode (now based upon muse)
http://www.emacswiki.org/cgi-bin/wiki/PlannerMode
Best,
Joseph
H. v. L.
contract, a disciplined programmer will use those as he would use design
by contract - or he won't use either of them.
With respect to generics I agree they might be a simplification (this has
been considered for CP but has not - yet(?) - been implemented.
Nevertheless, as Bertrand Meyer pointed out long ago, genericity can be
replaced (simulated) using inheritance (B. Meyer 86. 'Genericity versus
Inheritance', OOPSLA ?87, SIGPLAN Notices, Vol. 21, No. 11, Nov. 1986,
also cited in his book on Object-Oriented Software Construction) but not
vice versa; and implementing genericity is not an easy thing to do, most
implementations (especially those in C++) turn out to be real memory hogs.
Regards
Harro
On Thu, 05 Jan 2006 22:43:04 +0100, Georg Bauhaus <bau...@futureapps.de>
wrote:
Miguel Oliveira e Silva
> I'd say that carefully chosen assertions are an equivalent to design by
> contract, a disciplined programmer will use those as he would use design
> by contract - or he won't use either of them.
Design by Contract *requires* support from the programming language
or else much will be lost:
1. Class assertions not being part of the class interface (not its
implementation);
2. Inheritance of contracts by descendant classes;
3. A disciplined exception mechanism (a routine may either
fail or succeed - depending on the class assertions - , but
never something in between as its allowed in C++, Java and Ada).
> With respect to generics I agree they might be a simplification (this has
> been considered for CP but has not - yet(?) - been implemented.
> Nevertheless, as Bertrand Meyer pointed out long ago, genericity can be
> replaced (simulated) using inheritance (B. Meyer 86. 'Genericity versus
> Inheritance', OOPSLA ?87, SIGPLAN Notices, Vol. 21, No. 11, Nov. 1986,
> also cited in his book on Object-Oriented Software Construction) but not
> vice versa; and implementing genericity is not an easy thing to do, most
> implementations (especially those in C++) turn out to be real memory hogs.
Parametric polymorphism (genericity) can be simulated with subtype
polymorphism in OO pure languages in which all values are objects
with a common ancestor (ANY in Eiffel). However the (high) price
one must be prepared to pay is (static) safety.
Such approach mimics what is done in dynamic typed languages
(such as Smalltalk), in which there is no need for language
mechanisms for parametric polymorphism, simply because
all type verifications are done at run-time.
Both forms of polymorphism - in static typed languages - are
important for quality software production (and Eiffel's genericity
mechanism should be extended to fully implement F-bounded
parametric polymorphism [1]).
[1] "F-bounded polymorphism for object-oriented programming";
Peter Canning, William Cook, Walter Hill, Walter Olthoff, John C. Mitchell;
FPCA '89, 1989, ACM Press.
> Regards
>
> Harro
>
> On Thu, 05 Jan 2006 22:43:04 +0100, Georg Bauhaus <bau...@futureapps.de>
> wrote:
>
> > On Thu, 2006-01-05 at 20:23 +0100, H. v. L. wrote:
> >
> >> Component Pascal
> >
> > Even though CP is small, fast, and imports (and simplifies)
> > some interesting ideas from Ada, I'd be missing both generics
> > and design by contract a lot.
> >
> >
-miguel
--
Miguel Oliveira e Silva
mos at det.ua.pt - http://www.ieeta.pt/~mos
DET-IEETA, Universidade de Aveiro, PORTUGAL
Georg Bauhaus
> I'd say that carefully chosen assertions are an equivalent to design by
> contract, a disciplined programmer will use those as he would use design
> by contract - or he won't use either of them.
There is a specialty of DbC that sets it apart from "just" assertions
(terminating the program), in two ways. First, DbC works starting
at the level of ADT modules, and ends at the level between
single statements. (This implies that you can specify module contracts
when there is no executable code yet.) In a sense, this structure
parallels stepwise refinement for assertions.
Second, DbC it is integrated with the language's exception
handling facilities.
Consider (in my pidgin Component Pascal)
MODULE Stacks;
TYPE
Stack* = POINTER TO ABSTRACT RECORD END;
PROCEDURE (s: VAR Stack) Pop*, ABSTRACT;
and in Eiffel
deferred class STACK feature
pop is
require
not_empty: not is_empty
deferred
end
How can I specify an assertion on abstract Pop* in CP?
Are there module assertions specifying an invariant?
Assertions are a Good Thing, but not quite the same as DbC :-)
-- Georg
Friedrich Dominicus
> Friedrich Dominicus <just-for-...@q-software-solutions.de> writes:
>> Well I bet a few thousands of eiffelists and Hakellists will disagree
>> whoelheartly. Of course there are some things in C and C++ which make
>> a debugger a necessity, but one can argue that Java, PHP, Ruby, Perl
>> fall in a similiar case as the functional language and they do provide
>> some debugger at least good enough to follow the program...
>
> You'd be wrong to make that last argument, at least for Java, PHP and
> Perl. All three of those were (at least initially) designed to look
> like languages that were derived from C. Ruby might qualify, but I
> suspect I'd rarely use it. That's because it has an interactive
> interpreter, which is *far* more useful than an interactive
> debugger.
This is not excuse for not offereing a decent compiler and blaming PHP
perl and the like for beeing "as C" is like blaming Eiffel for beeing
Pascal. But you admit also that having a "interactive" way of dealing
with the system is a big helper. You are right, however you did not
get that with Eiffel. But SmartEiffel does not provide anything
besided contracts on helping you debugging...
Mike Meyer
> But you admit also that having a "interactive" way of dealing
> with the system is a big helper. You are right, however you did not
> get that with Eiffel. But SmartEiffel does not provide anything
> besided contracts on helping you debugging...
SmartEiffel programs can be built with a debugger using the -sedb
flag. Or at least it used to; I quit following smarteiffel closely
when they started compiling a language that wasn't really eiffel.