contrasting Python with Eiffel
Frank Sergeant
I've been reading some Python books and fooling around with
some of the the examples. It seems to solve all of my
objections to C++. Performance questions aside, it is clear
to me that given a choice between programming in C++ and
Python, I would choose Python.
What I particularly like about Python:
1. Elimination of the tedious bookkeeping.
2. Ability to use methods defined in a class's ancestors
(in C++, to use a non-default constructor from an
ancestor class, you must explicitly redeclare the
constructor in the current class -- this is an
abomination (or, if I have merely misunderstood C++,
it is further proof that C++ is too dangerously complex
to be comprehended and is thus unsafe to use)).
3. Availability of various free packages -- from Windows GUI
libraries to client/server databases.
4. It is free.
The conciseness because of blocks marked by indentation is
agreeable to me, but I'm not sure that I care much one way
or the other. I am slightly worried about performance, but
that may not be a problem. I need to do some more experimenting
before I can have much of an opinion on that. I have long believed
in optimizing only what's needed (as in the innermost loops) and
only after determining if and where the bottlenecks lie.
However, I have now been reading some about Eiffel and various
philosophical issues. It appears to me that the major difference
between Eiffel and Python is related to their philosophies
regarding type safety and assertions. Eiffel emphasizes Design
by Contract and the use of assertions and declaration of types
and automatic checks to see you don't (accidentally) violate
anything. Python appears to allow almost any sort of access.
What I am hoping for is that someone reading this has some familiarity
with both Eiffel and Python and would tell me why I should prefer
one over the other. Please feel to email me if you feel this is
too inflamatory, but I am genuinely interested in the reasoning
and related experiences.
It seems to me that Python may offer the faster development by
eliminating the need for writing the declarations and assertions
plus by having an interactive environment. Eiffel on the other
hand would seem to require a little more up front specification,
but might pay back that effort due to a more robust system, errors
caught earlier, etc. Other trade offs are that Eiffel (from ISE
http://www.eiffel.com/) is definitely not free, but apparently
comes with an easy to use approach to building GUIs under Windows.
There is a GNU Eiffel (SmallEiffel) that is free -- I guess the
resulting applications can be distributed as binaries with no
GPL requirements to distribute my own source -- but doesn't seem
to have any built-in Windows GUI libraries. Eiffel compiles to
C, which must then be compiled by a C compiler. This probably
means that resulting executables are faster than the equivalent
in Python.
Could/would anyone shed any light on these issues for me?
-- Frank
frank.s...@pobox.com
Richard Smol
In a previous article, py...@eskimo.com (Frank Sergeant) says:
>I've been reading some Python books and fooling around with
>some of the the examples. It seems to solve all of my
>objections to C++. Performance questions aside, it is clear
>to me that given a choice between programming in C++ and
>Python, I would choose Python.
>
What on earth are you comparing two TOTALLY DIFFERENT languages for?
Python and Eiffel are quite different beasties... more or less like
comparing a kolibri to a penguin. They are both birds, but that's
about it. You get my point >:)
They both have been designed with vastly different philosophies.
Eiffel is a systeem engineering tool, with as a main notion that the
concept of a program should be clear from the source code. It's the first
language where 'Design by Contract' has been hard-wired into the language
itself.
Python is a scripting language, primary. Even Guido himself claims
that it has been first designed for little 'throw-away' scripts. It
has now developed into a very professional prototyping-tools, due to
its extensibility. And yes, Python being OO makes it very suitable
for larger scale applications as well.
Greetz,
RS
Paul F Dubois
Frank Sergeant wrote:
>
...snip...
> What I am hoping for is that someone reading this has some familiarity
> with both Eiffel and Python and would tell me why I should prefer
> one over the other. Please feel to email me if you feel this is
> too inflamatory, but I am genuinely interested in the reasoning
> and related experiences.
>
for each job. In many cases that could mean both, using Python to act as
the steering language for the compiled language.
In general associate Eiffel with large, complex developments involving
significant computational loads or where correct execution matters more
than usual. (If bugs cost money or hurt someone, for example). Python on
the other hand is suitable for very rapid development and for gluing
together libraries.
That said, Python scales better than other scripting languages, and does
have a fast numerical library; and Eiffel with its large set of reusable
libraries often can get your application built pretty fast.
Python is distinctly cheaper. (:->. If you are going to use Eiffel get a
good commercial environment.
I think learning Eiffel methodology would be beneficial to you no matter
what language you actually use for a project.
Paul Dubois
Disclaimer: My work on the EiffelMath library was not connected with my
job at LLNL; my work on Python *is* connected, big time. See
http://xfiles.llnl.gov/python.
Gordon McMillan
Frank wrote:
> I've been reading some Python books and fooling around with
> some of the the examples. It seems to solve all of my
> objections to C++. Performance questions aside, it is clear
> to me that given a choice between programming in C++ and
> Python, I would choose Python.
> However, I have now been reading some about Eiffel and various
> philosophical issues.
> What I am hoping for is that someone reading this has some
> familiarity with both Eiffel and Python and would tell me why I
> should prefer one over the other.
Don't know Eiffel (just some of the philosophy), so I can't answer
that. But why limit yourself?
Most of my "work" is in C++ (which after 5 yrs I'm rather fond of,
but I only defend it from certain species of attacks...) and Java. I
do everything I can in Python. One way I use Python is to prototype
what I'm going to do in C++ (or Java). I have to be careful not to
use too much in the way of Python "magic", but if I do that, it's
fairly easy to translate. And prototyping in Python is no slower and
a hell of a lot more convincing than than screwing around with UML or
OMT and then trying to figure out why something that looked so simple
in the diagram turns out to be non-computable.
I'm sure such an approach would work with Eiffel, too.
BTW, the only thing I've been able to deliver to a client in Python
was a prototype to a "simple" (ha ha) utility they asked for. In
Python, it was trivial to build in some amazing features. They liked
the features, and realized they couldn't afford to pay me for a
translation that preserved those features.
sometimes-frugality-succeeds-where-intelligence-is-absent 'ly 'yrs
- Gordon
Frank Sergeant
In article <1998040201...@pb.twinoaks.net>,
"Gordon McMillan" <gm...@hypernet.com> wrote:
> Don't know Eiffel (just some of the philosophy), so I can't answer
> that. But why limit yourself?
<related to prototyping in Python, then converting to C++, Java, or ...>
Yes, that might give me the best of both worlds. I had actually
thought of that as I was reading an article by Guido, wherein he claimed
a speed up of 5 to 10 by using Python instead of C++; developing
in Python then transliterating to another language could still be much
faster than developing in the other language. [Subject to the accuracy
of the claim, of course, but it sounded reasonable to me with regard
to C++. I don't know how the speed up would relate to Eiffel.]
> Most of my "work" is in C++ (which after 5 yrs I'm rather fond of,
> but I only defend it from certain species of attacks...)
I sympathize with this -- "the devil we know" and all that.
I used C++ for my master's thesis work (in computational geometry)
but many of its "features" continued to grate on me. I now believe
I would have been much happier using Python instead.
I am tired of the ways of the world and thinking of joining
a monastery -- no, no, that's too drastic and incompatible with
my "religion". I'm tired of being jerked around by the computer
hardware/software giants as they battle with one another -- yes,
that's a little better, but perhaps too extreme. I'm actually
in favor of competition and free markets (and by that, I mean
un-government-regulated markets), but that doesn't mean I should
accept all the Microsoft/Sun hype. Still, I want to hedge my
bets. This is a long way of saying that I am glad to see that
both Python and Eiffel have routes to Java byte code, even though
I don't wish to use Java at this time. (And, just as an aside,
even REXX has a route to Java byte code via a program called
NetRexx, written by the REXX originator.)
What I am really trying to do is decide on my future
development language for my current and future business
programming projects. I maintain (and have greatly repaired
and extended) a medical accounting package that we occasionally
sell to small medical offices. Naturally, since I didn't write
it originally, it was a horror when I took it over. It is
written in Clipper (an enhanced dBASE compiler). I have been
considering, very seriously, rewriting/converting it to Python
(and/or Eiffel). I looked some at Delphi and at VO (Computer
Associates Visual Objects). I was not completely happy with
either. Delphi might work. I might be happy with its Pascal,
as it really isn't a lot different from Clipper and I used
Pascal many years ago. But, I never felt completely oriented
in the Delphi environment (practice and familiarity might
overcome this). VO felt better to me right away, but its
performance was unacceptably slow, so that seems to rule it
out for me. I make extensive use of Clipper's "ragged arrays"
(essentially lists) which would require a little work to
duplicate in Delphi but just drop effortlessly into Python's
lists.
> BTW, the only thing I've been able to deliver to a client in Python
> was a prototype to a "simple" (ha ha) utility they asked for. In
> Python, it was trivial to build in some amazing features. They liked
> the features, and realized they couldn't afford to pay me for a
> translation that preserved those features.
>
> sometimes-frugality-succeeds-where-intelligence-is-absent 'ly 'yrs
That is very interesting. I may adopt it as my motto.
Thanks for your suggestions and comments.
-- Frank
frank.s...@pobox.com
Al Christians
Eiffel makes you always write code using what appears to be an OO
approach. Python lets you write non-OO code if you want to, but it then
usually find a way to show you that it was a mistake. Either way, the
lesson is learned. I think these two languages would work well
together, Python for everything, Eiffel for the few things where the
Python solution comes up short. Since I good Python solution will be
very OO, it should be pretty easy to convert to Eiffel, if you had
all the right libraries and toolkits.
Compared to compiled languages, Python is very slow. Funny thing is,
I didn't even notice that until I had been using it for most of a month.
There aren't that many things that take costly amounts of execution time
anymore. In some of my projects, a 1% savings in development effort is
worth more than a 99% savings in run time.
The difference between compile-time (Eiffel, Ada, M3, some C++) and
run-time (Python, Smalltalk, Objective-C, some C++) is a puzzling
source of difference of opinion. The people who are successful with
the less-strict compile-time checking say that run-time 'Does not
understand' errors just don't happen that often. The other school is
glad that they are impossible.
Al
Paul Prescod
Frank Sergeant wrote:
>
> However, I have now been reading some about Eiffel and various
> between Eiffel and Python is related to their philosophies
> regarding type safety and assertions. Eiffel emphasizes Design
> by Contract and the use of assertions and declaration of types
> and automatic checks to see you don't (accidentally) violate
> anything. Python appears to allow almost any sort of access.
>
> with both Eiffel and Python and would tell me why I should prefer
> too inflamatory, but I am genuinely interested in the reasoning
> and related experiences.
I think that this is a personal, perhaps even emotional, choice. When I
use Python, I love it for its freedom and power. When I use Java and
other statically typed languages, I often find them subtly forcing me to
make my design explicit, to think things through, and to junk marginal
code. My first response to some kinds of type errors is "damn this
constraining language" and then, "hmmm...maybe there is actually a good
reason for that message." YMMV.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
There are only two countries in the world that have not ratified the
United
Nations convention on the rights of children:
Somalia and the United States of America. See: http://www.boes.org/
Frank Sergeant
In article <3526E4...@easystreet.com>,
Al Christians <ach...@easystreet.com> wrote:
> I think these two languages would work well
> together, Python for everything, Eiffel for
> the few things where the Python solution comes up short.
Ok. I could prefer to write in Python first. Perhaps
sketching my solutions would go faster and dead-ends could be
reversed faster. I see perhaps two ways for the Python solution
to come up short:
(1) it runs too slowly
In this case, I could transliterate to
Eiffel to get the speed up due to compiling.
(2) it is too incorrect
In this case, I could transliterate to Eiffel
but convert the pre and post conditions and
class invariants from comments to runtime
testable assertions, and let Eiffel help me
debug the solution. (However, if I am taking
the time and care to specify the assertions
even as comments ...)
The first case (too slow) makes sense to me. In the
second case (too incorrect), if I run into that very
often, it would seem I should write in Eiffel to begin
with. This is an area I was hoping to get advice on:
whether anyone had run into situations where the extra
overhead of writing in Eiffel was or wasn't paid back
somehow.
> In some of my projects, a 1% savings in development effort is
> worth more than a 99% savings in run time.
I'm not sure what my equivalent percentages are,
but I agree with the general principle (providing the
run time is still fast enough).
-- Frank
Frank Sergeant
In article <352326B2...@home.com>,
Paul F Dubois <pauld...@home.com> wrote:
> You shouldn't prefer one over the other. You should use the right one
> for each job. In many cases that could mean both, using Python to act as
> the steering language for the compiled language.
Ok. That sounds reasonable, as long as the extra overhead
of jumping between two languages doesn't eat up the profits, and
providing I can determine which is right for which job.
> In general associate Eiffel with large, complex developments involving
> significant computational loads or where correct execution matters more
> than usual. (If bugs cost money or hurt someone, for example).
Well, probably my application(s) do not obviously fall into
either of the above categories. Of course, everything is
relative. Bugs cost me some money and time and perhaps risk my
reputation. Obviously, I want to achieve a high quality product
at a low cost, factoring in future maintenance, customer good
will, etc. I guess a question I have is whether the faster
turn around of the interpreted Python with its lower syntactical
overhead achieves the goals better than does Eiffel with its less
interactive nature (compiled) and greater syntactical
requirements but with type and assertion checking.
It's not meant to be a perfect analogy, but consider
motorcycle helmet laws. They are passed, no doubt, with good
intentions. At first glance, a helmet obviously adds to the
cyclist's safety. However, it is not so simple. The wearing
of the helmet can affect the cyclist's vision and balance and,
in the case of a fall, the moments of force on the cyclist's
neck, for example. So, should helmet laws be passed? Enforced?
Violated? I certainly do not know and I think it is too
simplistic to accept a legislator's glib answer without further
thought.
So, perhaps Eiffel is programming while wearing a helmet and
Python without? Where are the break even points?
> Python is distinctly cheaper. (:->. If you are going to use Eiffel get a
> good commercial environment.
Ummm, from browsing a few web sites, I see it is possible to
spend a lot of money on Eiffel. (Do you have a preferred Eiffel
compiler?)
> I think learning Eiffel methodology would be beneficial to you
> no matter what language you actually use for a project.
I agree. I am now about two thirds through reading the
first edition of _Object-oriented Software Construction_. I am
enjoying it very much. Prior to this, my view of OO was to
equate it more or less with factoring well. This book is the
best organized and coherent description of OO that I have come
across. So far, I find the arguments persuasive and well
presented.
> Disclaimer: My work on the EiffelMath library was not connected with my
> job at LLNL; my work on Python *is* connected, big time. See
> http://xfiles.llnl.gov/python.
Thanks for your advice. I guess you are saying that it
is hard to go very far wrong using either Eiffel or Python,
right?
-- Frank
Jeremy Hylton
Al Christians <ach...@easystreet.com> writes:
> Compared to compiled languages, Python is very slow. Funny thing is,
> I didn't even notice that until I had been using it for most of a month.
> There aren't that many things that take costly amounts of execution time
> anymore. In some of my projects, a 1% savings in development effort is
> worth more than a 99% savings in run time.
>
I think this is a strong argument in favor of scripting languages. I
recently learned, however, that the importance of development time
vs. run time is an old lesson that we are only re-discovering:
"Fortran began to be widely accepted when programmers realized that
its use greatly reduced programming time on small and medium jobs
where programming time, rather than running time, was the main
consideration."
Maurice Wilkes. "A Revisionist Account of Early Language Development"
in IEEE Computer 31(4): April 1998, pp. 22-25.
Jeremy
Lloyd Zusman
Jeremy Hylton <jer...@cnri.reston.va.us> writes:
And I recall another, similar quote, although I can't remember the
book or the author. It goes something like this: "As time goes
forward, computer time gets cheaper and man-hours get more expensive."
Therefore, it's better in the long run to build software that's fast
to create and easy to maintain, without quite so much emphasis on
saving a few machine cycles here and there.
--
Lloyd Zusman
l...@asfast.com
Friedrich Dominicus
> > In general associate Eiffel with large, complex developments
> involving
> > significant computational loads or where correct execution matters
> more
> > than usual. (If bugs cost money or hurt someone, for example).
>
> Well, probably my application(s) do not obviously fall into
> either of the above categories. Of course, everything is
> relative. Bugs cost me some money and time and perhaps risk my
> reputation. Obviously, I want to achieve a high quality product
> at a low cost, factoring in future maintenance, customer good
> will, etc. I guess a question I have is whether the faster
> turn around of the interpreted Python with its lower syntactical
> overhead achieves the goals better than does Eiffel with its less
> interactive nature (compiled) and greater syntactical
> requirements but with type and assertion checking.
>
> Python without? Where are the break even points?
Not quite IMO. Maybe it's more a question of sizing. Python far better
for smaller projects because the overhead of compiling is really
significant. The integration to system calls is under Eiffel not so
easy. You have to use classes like OS_ENVIRONMENT and look if you find
s.th. like a system call. Python is far better with regular expressions
as I know, So if you just want to analyse such stuff Python is a far
better choice. If you get complex datastructures and prefer a more
verbose stating of which types are involved Eiffel is of course better,
if speed of execution really matters use Eiffel, if you want to make
low-level stuff Eiffel isn't a good choice, thant you have to use C in
Eiffel. There's a clean interface to that language but such interfaces
are as easy with Python too. (take a look at SWIG for that)
The interfacing between Python and Eiffel would be very interesting but
I don't know of any practical solution but using C as "glue" language,
that's a strange use of C IMO. Glue lanuguages are normally the scriptin
languages.
>
>
> > Python is distinctly cheaper. (:->. If you are going to use Eiffel
> get a
> > good commercial environment.
What platform are you using. I personally prefer ISE-Eiffel (you can get
a personal licence for 198 DM) but if you want to do really much work
you have to buy a lot of libraries (I use the Cross Platform Development
Environment from ISE on Linux)ISE-Eiffel is an IDE with some own ideas
of what this stuff should look like. The compiler is available for
nearly any platform (Windows, OS/2, VMS, Crays, all stuff of Unix, DEC,
HP-UX. Solaris, and of course Linux). If done some work with ISE Eiffel
V. 3.3.7 on Linux and DEC and got no problems at all. If you want learn
more about Eiffel, take look at http://www.eiffel-forum.org or the ISE
Homepage
http://www.eiffel.com
There's a free Eiffel-Compiler called SmallEiffel, maybe you just want
to try Eiffel first?
You can find it on the above URL
If you want to right just for Windows, Maybe a better choice would be
Visual Eiffel from Objet Tools, It's an IDE too but more what you expect
under Windows I assume. Active X, COM, Java Interface, builiding DLLS
seems to be more sophisticated with that compiler. With the new version
3.0 (which will come out soon) all this is included, and maybe for GUI
development the Display Machine may be very interesting. Take a look at
http://www.eiffel.de
>
>
> Ummm, from browsing a few web sites, I see it is possible to
> spend a lot of money on Eiffel. (Do you have a preferred Eiffel
> compiler?)
>
> > I think learning Eiffel methodology would be beneficial to you
> > no matter what language you actually use for a project.
>
> I agree. I am now about two thirds through reading the
> first edition of _Object-oriented Software Construction_. I am
> enjoying it very much. Prior to this, my view of OO was to
> equate it more or less with factoring well. This book is the
> best organized and coherent description of OO that I have come
> across. So far, I find the arguments persuasive and well
> presented.
Sorry you're are a way out of time, better take a look at OOSC 2nd
Edition, it's really not an update but a new book. In OOSC 1st Ed.
there's a completly out of- date syntax for Eiffel, you find the new
syntax in Eiffel The language (ETL, vom Betrand Meyer) and areally in
the new Edition of OOSC.
> Thanks for your advice. I guess you are saying that it
> is hard to go very far wrong using either Eiffel or Python,
> right?
I think you're right here, If Python get's a little more eiffelish (in
Version 1.5 a step has been done (look for the assert statement)) I
would use Python. But for really large projects I'd prefer Eiffel (here
I like the compiler which catches a lot of typos, and forces me to
declare variables, I like languages in which I can avoid this type of
errors).
Hope this helps a bit
Friedrich
Neil Wilson
With the emphasis on the 'easy to maintain' bit. This is where 'scripting'
languages fall down. A language and its environment ought to do everything
that it can to stop the developer making errors - whether errors in logic or
consistency, whilst providing a rich tapestry of components at varying
abstraction levels to speed up development.
Given the prevalance of the 'C' languages and their ilk it would seem that
this old old lesson has been forgotten.
---
Neil Wilson (Neil@aldur on the demon.co.uk domain)
Aldur Systems Ltd, Ossett, UK
Lloyd Zusman wrote in message ...
Fredrik Lundh
>And I recall another, similar quote, although I can't remember the
>book or the author. It goes something like this: "As time goes
>forward, computer time gets cheaper and man-hours get more
>expensive."
Was it perhaps:
"With ever-increasing hardware speed, the accumulated running time
of a program during its lifetime is often negligable compared to the
programmer time needed to write and debug it."
-- GvR, in Mark Lutz's "Programming Python"
http://www.python.org/doc/essays/foreword.html
Paul F Dubois
Frank Sergeant wrote:
>
> In article <352326B2...@home.com>,
> Paul F Dubois <pauld...@home.com> wrote:
> > You shouldn't prefer one over the other. You should use the right one
> > for each job. In many cases that could mean both, using Python to act as
> > the steering language for the compiled language.
>
> Ok. That sounds reasonable, as long as the extra overhead
> of jumping between two languages doesn't eat up the profits, and
> providing I can determine which is right for which job.
>
user. If a program can be controlled by the user using a full
programming language, then the user can make the program solve many
problems not envisioned by the original author.
The classic example of a steerable program was Lotus 1-2-3. It became a
monster hit not just because a spreadsheet was such a novel idea, but
because it had a "macro language", that is, it could be programmed by
the user. I had a friend who had a one-dimensional hydrodynamics code
running in 1-2-3 about a week after he got it. He would push a button
and it would calculate a new column at the new time. He could make
graphs and everything. I'd bet the person who wrote 1-2-3 would not have
known (a) how to write a hydrodynamics code, or that (b) 1-2-3 could be
made to be a hydrodynamics code.
The trick is that the language the user is going to learn has to be
clean and easy to learn, and relatively efficient so that as much can be
done in it as possible. When the compiled language underneath is OO, it
is natural to want corresponding concepts in the interpreter. Python
fits this description.
>
> Ummm, from browsing a few web sites, I see it is possible to
> spend a lot of money on Eiffel. (Do you have a preferred Eiffel
> compiler?)
I have only used ISE's environment, so I can't compare it with others.
There is a "Small Eiffel" which is free, I think.
>
> > I think learning Eiffel methodology would be beneficial to you
> > no matter what language you actually use for a project.
>
> I agree. I am now about two thirds through reading the
> first edition of _Object-oriented Software Construction_. I am
> enjoying it very much.
I understand from a recent posting in comp.lang.eiffel that OOSC2 is
hard to get right now due to good sales and that they are reprinting it.
But I do recommend the second edition.
Paul
Andreas Leitner
Paul F Dubois schrieb in Nachricht <352A415C...@home.com>...
>I understand from a recent posting in comp.lang.eiffel that OOSC2 is
>hard to get right now due to good sales and that they are reprinting it.
>But I do recommend the second edition.
I think it is "Eiffel: The Language" that is reprinted for now. OOSC2 should
be available (at least they still have it at my local book-store)
regards, Andreas
Frank Sergeant
In article <3529D2DC...@inka.de>,
Friedrich Dominicus <Friedrich...@inka.de> wrote:
> Sorry you're are a way out of time, better take a look at OOSC 2nd
> Edition, it's really not an update but a new book. In OOSC 1st Ed.
> there's a completly out of- date syntax for Eiffel, you find the new
> syntax in Eiffel The language (ETL, vom Betrand Meyer) and areally in
> the new Edition of OOSC.
I expected there would be some differences between the two
versions. When I reached chapter 4 of the 1st edition, I ordered
a copy of the 2nd edition. I am just finishing up the 1st edition
and will be interested to which ideas have changed and which
have stood the test of time.
> I think you're right here, If Python get's a little more eiffelish (in
> Version 1.5 a step has been done (look for the assert statement)) I
> would use Python. But for really large projects I'd prefer Eiffel (here
> I like the compiler which catches a lot of typos, and forces me to
> declare variables, I like languages in which I can avoid this type of
> errors).
> Hope this helps a bit
> Friedrich
Thanks. It does help. My next step is to play around some
with several of the Eiffel environments and also some more with
Python.
-- Frank
frank.s...@pobox.com
Mike Meyer
In <rPGK1Yv1...@eskimo.com>, py...@eskimo.com (Frank Sergeant) wrote:
> In this case, I could transliterate to
> Eiffel to get the speed up due to compiling.
Obvious question - has anyone worked at using Eiffel objects from
Python?
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.
Paul F Dubois
Thank you for correcting my error. Rereading the posting that gave me
the wrong impression, I see that I misread it.
So to the original poster, there goes any excuse for reading the first
edition of OOSC.
Paul Prescod
Neil Wilson wrote:
>
> With the emphasis on the 'easy to maintain' bit. This is where
>'scripting' languages fall down. A language and its environment
> ought to do everything that it can to stop the developer making
> errors - whether errors in logic or consistency, whilst
> providing a rich tapestry of components at varying abstraction
> levels to speed up development.
No language does "everything that it can" to stop you from making
errors. Well, perhaps the null language that does not allow you to
writ a program, but no other. The world is not that simple.
Every language chooses a tradeoff between flexibility and safety.
The most type-strict language I know of is pre-OO Pascal, but
nobody I know wants to use that. Every modern language that I am
familiar with provides some way to get around the type system in order
to improve the flexibility of your system. I know of no modern language
that does not have some form of "Error: Type cast exception", and if
such a language exists, I certainly don't want to use it!
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"You have the wrong number."
"Eh? Isn't that the Odeon?"
"No, this is the Great Theater of Life. Admission is free, but the
taxation is mortal. You come when you can, and leave when you must. The
show is continuous. Good-night." -- Robertson Davies, "The Cunning Man"
Joachim Durchholz
Paul F Dubois wrote:
>
> So to the original poster, there goes any excuse for reading the first
> edition of OOSC.
Oh, there's still an excuse: OOSC 1 is still an excellent introduction
into OO in general. Actually I recently lent OOSC 1 to a hobby
programmer who was forced to go professional. I wouldn't give him OOSC 2
- it's just too much.
OOSC 2 does add some detail to important OO concepts, but most new stuff
is really Eiffel-centric.
Regards,
Joachim
--
Please don't send unsolicited ads.
Joachim Durchholz
Lloyd Zusman wrote:
>
> "As time goes
> forward, computer time gets cheaper and man-hours get more expensive."
Agreed.
> Therefore, it's better in the long run to build software that's fast
> to create and easy to maintain, without quite so much emphasis on
> saving a few machine cycles here and there.
Not agreed in the general case.
For slapping together GUI applications, machine cycles don't really
count.
For writing libraries, things are entirely different. If your library
routine wastes a dozen cycles, you may think it doesn't matter - but
those who must call it a billion times will curse you. And don't think
that a billion times is an exceedingly high count; in deeper library
layers, such call counts aren't an exception anymore.
With Eiffel's strong emphasis on "write libraries, not applications",
this becomes even more important than usual.
Amit Patel
Paul Prescod <papr...@technologist.com> wrote:
| Neil Wilson wrote:
| >
| > With the emphasis on the 'easy to maintain' bit. This is where
| >'scripting' languages fall down. A language and its environment
| > ought to do everything that it can to stop the developer making
| > errors - whether errors in logic or consistency, whilst
| > providing a rich tapestry of components at varying abstraction
| > levels to speed up development.
|
| No language does "everything that it can" to stop you from making
| errors. Well, perhaps the null language that does not allow you to
| writ a program, but no other. The world is not that simple.
Agreed -- here's an example error:
if money > 100: print "You are nearly out of money."
In order for the language to detect this error, it would need to
understand English text, determine that "out of money" corresponds to
money==0, that "nearly out of money" would mean that money is "close"
to zero, and that money > 100 is an inappropriate comparison.
All hats fill with spam when you use 'm' instead of 'money' as a
variable name.
-still-not-understanding-how-to-follow-the-God-named-Tim,
Amit
Matt Kennel
On 06 Apr 1998 12:20:55 -0400, Jeremy Hylton <jer...@cnri.reston.va.us> wrote:
:Al Christians <ach...@easystreet.com> writes:
:
:> Compared to compiled languages, Python is very slow. Funny thing is,
:> I didn't even notice that until I had been using it for most of a month.
:> There aren't that many things that take costly amounts of execution time
:> anymore. In some of my projects, a 1% savings in development effort is
:> worth more than a 99% savings in run time.
:>
:
:I think this is a strong argument in favor of scripting languages.
What exactly is a "scripting language" and how is it really different from
"a language"?
Maybe I'm getting way too cynical in my youth but sometimes it seems
that 'scripting language' is a euphemism for 'a language which sucks but
we don't have to fix it because it is just scripting language.'
Perhaps it doesn't apply to Python, but I see many other examples of this.
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD -
* "People who send spam to Emperor Cartagia... vanish! _They say_ that
* there's a room where he has their heads, lined up in a row on a desk...
* _They say_ that late at night, he goes there, and talks to them... _they
*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"
Friedrich Dominicus
>
>
> What exactly is a "scripting language" and how is it really different
> from
> "a language"?
>
I can't give you an exact definition because a lot of "scripting
languages" are fully fledged programming languages. But I'll try1)
scripting languages are interpreted
2) they can be used for Shell-Programming (maybe because of this the
name scripting)
3) easy access and integration to the surrounding Environment
4) you can program very easy and fast throw away scripts
5) they are the duct tape for programmers (Do you have a small problem
fix it by glueing ;-)
> Maybe I'm getting way too cynical in my youth but sometimes it seems
> that 'scripting language' is a euphemism for 'a language which sucks
> but
> we don't have to fix it because it is just scripting language.'
Nice definition; but then we had a lot of "scripting languags".
>
>
> Perhaps it doesn't apply to Python, but I see many other examples of
> this.
Pythons surely not perl the same tcl/tk I don't know. What comes to your
mind?
Javascript?
Till then
Friedrich
Fredrik Lundh
>What exactly is a "scripting language" and how is it really different from
>"a language"?
fwiw, the only reasonable definition I've ever seen is that 'scripting' is
when you glue existing components together:
"Unlike mainstream component programming, scripts usually do no
introduce new components but simply 'wire' existing ones. Scripts can
be seen as introducing behaviour but no new state. /.../ Of course,
there is nothing to stop a 'scripting' language from introducing persistent
state -- it then simply turns into a normal programming language"
-- Clemes Szyperski, in "Component Software"
(yeah, I know I'm repeating myself. but it's a pretty good book)
>Maybe I'm getting way too cynical in my youth but sometimes it seems
>that 'scripting language' is a euphemism for 'a language which sucks but
>we don't have to fix it because it is just scripting language.'
Even better: argue that scripting is the future, and since your favourite
toy language cannot be used for anything but scripting, it just gotta be
better than anything else ;-)
>Perhaps it doesn't apply to Python, but I see many other examples of this.
Python is definitely not a scripting language. It sometimes plays one
on television, though.
a...@pythonpros.com
In article <01bd677e$d55687c0$f29b...@panik.pythonware.com>,
"Fredrik Lundh" <fre...@pythonware.com> wrote:
>
> >What exactly is a "scripting language" and how is it really different from
> >"a language"?
>
> fwiw, the only reasonable definition I've ever seen is that 'scripting' is
> when you glue existing components together:
To me a "system" language is one which could seriously be used
to implement its own compiler/interpreter. A glue/extension/scripting/
4th generation/applications/whatever language is anything else.
Certain pinheads tend to think that languages that shouldn't be used to
implement their own compiler/interpreter are not worthy of consideration
for serious work, but that's because *they* *are* *stupid* *people*.
Then again, it's easy to find pinheads everywhere.
-- Aaron Watters
===
I was cutting a rug at a place called "the Jug"
with a girl called Linda-Lou
When in walked a man with a gun in his hand
and he was looking for you-know-who
He said "Hey there feller with the hair colored yeller
whatcha trying to prove?
'Cause that's my woman there and I'm a man who cares
and this might be all for you"
[I said "Excuse me!"] --Lynyrd Skynyrd "Gimme 3 steps"
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Joseph Chacko
Frank,
Reading through this interesting thread, something occurred to me that I felt
compelled to post. Please be warned that I have not yet used Python,
although it is on my todo list:)
In article <rPGK1Yv1...@eskimo.com>,
frank.s...@pobox.com wrote:
> In this case, I could transliterate to Eiffel
> but convert the pre and post conditions and
> class invariants from comments to runtime
> testable assertions, and let Eiffel help me
> debug the solution. (However, if I am taking
> the time and care to specify the assertions
> even as comments ...)
Commenting assertions is something I tend not to do. Even in a language like
C++, which has an assert() macro, allowing you to place assertions anywhere
in your code, I tend to skip macros here and there.
In Eiffel, the outline of a feature definition, with its very specific places
reserved for pre- and post- conditions is very conducive to using
assertions. Just the fact that this format is used eliminates the tedium of
inserting comments or assert() statements, and promotes the idea of Design-By-
Contract. I am a very lazy programmer, but Eiffel makes it so easy to use
assertions that I make the effort _all_the_time_. In fact, knocking up a
'contract' for your class is a quick exercise, and the result is both
publishable and can be built into an implementation with ease.
Your suggestion of transliterating to Eiffel, and _converting_the_assertions_
from comments into code would not work for me, because I would rarely put the
assertions in as comments.
HTH
Joe.
Paul Prescod
Matt Kennel wrote:
>
> What exactly is a "scripting language" and how is it really different from
> "a language"?
The question is equivalent to "what is an OOPL" or "what is a functional
programming language." I don't think that there are solid definitions
for any of those that would match our intuition. Rather, these language
genre declarations represent communities of users with certain
priorities. Scheme is a functional language not because it is
side-effect free (it isn't) but because people who use it prefer to
think of themselves as function-oriented programmers (and presumably use
Scheme in function-oriented ways). Language genres are ideologies, not
bundles of features.
The scripting language ideololgy values ease-of-use and flexibility
highly, and devalues runtime performance and compile-time safety based
on the presumption that performance-intensive parts of the system will
be created in "some other language" and compile-time checks would just
make the language harder.
Python does not take this ideology nearly as far as some other
languages, which is why many of its advocates are uncomfortable with
aligning themselves with the other languages created based on the
ideology. This fence straddling endears Python to people tired of
jumping between languages depending on the job that they have to do.
On the other hand, Java and Perl are also much closer to a reasonable
"middle road" than C and awk. That suggests to me that a convergence is
inevitable. I'm not sure whether that means that Python will be the
"next big thing" (as a leader in the convergence) or will be "squeezed
out".
Python is often categorized as a scripting language for the reason Matt
guesses: the competition is thin. People have such low expectations for
scripting languages that Python's power seems almost like overkill. If,
on the other hand, it is defined as an "OOPL" or "functional programming
language" then it would have to defend its "impure" adherence to those
ideologies.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"Unwisely, Santa offered a teddy bear to James, unaware that he had
been mauled by a grizzly earlier that year." - Timothy Burton, "James"
Greg Ewing
Matt Kennel wrote:
>
> What exactly is a "scripting language" and how is it really different from
> "a language"?
I don't think it's a property of the language, rather
the way it's used.
Scripting suggests programming to glue other programs
together, or to control a program that is otherwise
used manually or interactively. Any language used for
this purpose could be called a "scripting language"
in that context.
Conversely, languages designed for scripting can
often be used to implement entire stand-alone programs,
in which case they're being used as "a language".
Some languages are better suited to one or the other.
Python is an example of a language which is quite good
for both.
--
Greg Ewing, Computer Science Dept, | The address below is
spam-protected.
University of Canterbury, | To decode it, replace "splodge" with "."
Christchurch, New Zealand | and "curly" with "@".
greg curly cosc splodge canterbury splodge ac splodge nz
Jussi Santti
Matt Kennel wrote:
> What exactly is a "scripting language" and how is it really different from
> "a language"?
if unrestricted and efficient and portable then
"systems programming language"
else "scripting language"
Systems programming languages are particularly few: C, C++, Ada, ...Eiffel
Donn Cave
mbke...@yahoo.com (Matt Kennel) writes:
| On 06 Apr 1998 12:20:55 -0400, Jeremy Hylton <jer...@cnri.reston.va.us> wrote:
|:Al Christians <ach...@easystreet.com> writes:
|:> Compared to compiled languages, Python is very slow. Funny thing is,
|:> I didn't even notice that until I had been using it for most of a month.
|:> There aren't that many things that take costly amounts of execution time
|:> anymore. In some of my projects, a 1% savings in development effort is
|:> worth more than a 99% savings in run time.
|:>
|:
|:I think this is a strong argument in favor of scripting languages.
| What exactly is a "scripting language" and how is it really different from
| "a language"?
|
| Maybe I'm getting way too cynical in my youth but sometimes it seems
| that 'scripting language' is a euphemism for 'a language which sucks but
| we don't have to fix it because it is just scripting language.'
|
| Perhaps it doesn't apply to Python, but I see many other examples of this.
It doesn't apply to Python because Python isn't a scripting language -
it can be extended and integrated in various ways, but out of the box
it seems to me to be strongly oriented towards original implementation,
not ``gluing'', application automation and that kind of thing. A Python
programmer may often write quick, small programs, but that's kind of a
silly definition for ``script''.
A true, specialized scripting language often does sacrifice some power
as a programming language, to meet its other objectives. It's typically
aimed at people who use the language as an incidental tool, for example,
so its workings have to be fairly obvious. Its syntax has to allow
convenient expression of whatever turns up in its application environment.
And it really doesn't have to be all that fast, because it doesn't do
much itself.
I think it's a very useful distinction. A ways back I turned to a
fairly well known general purpose scripting language for some work
I was doing, because I wanted an interpreted, fast develop language
integrated with a C function library we'd already written. This
language is fine as a scripting language, but it was poor to middling
for writing programs of any complexity, and when I switched to a full
programming language (Python), it was a whole lot easier and better.
Did that scripting language suck? Not at all, it was only misused!
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Rainer Joswig
In article <35359F...@ard.fi>, Jussi Santti <ju...@ard.fi> wrote:
> Matt Kennel wrote:
> > What exactly is a "scripting language" and how is it really different from
> > "a language"?
> > "a language" is
> if unrestricted and efficient and portable then
> "systems programming language"
> else "scripting language"
>
> Systems programming languages are particularly few: C, C++, Ada, ...Eiffel
Don't forget Lisp. My Symbolics Lisp machine is entirely programmed in Lisp
(from the process scheduler up to TCP/IP, NFS, ...). ;-)
--
http://www.lavielle.com/~joswig/