Survival of the fittest

B

baalbek

I first heard of Python (on a CD cover) back in 1995. I thought, "what
is this? Python? Forget about it!"

Back then, I was a huge fan of the Delphi (Object Pascal) language, and
had immense respect for the C/C++ family.

1997 I got seriously into C++ programming, and thought, "could anything
be cooler than this? Nope!"

I was a late Java starter, but once the fad caught on, Java it was, and
Java it should be! Java would be forever!

Passing through various other languages, Python reappears in 2000. I
even don't remember in what context, but I started to use Python for
serious work in 2001.

Now, six years later, I use Python for about 70-80% of all my work (the
remainder being Ruby and C/C++).

I'm now having the policy: "If it's doable in Python, I'll use Python".

This unassuming scripting language has beaten heavy-weights like Java,
C++, etc, and this without any serious marketing machine behind it.

Why? The language is just so well designed (I miss some of Ruby's
features, but then, nothing is perfect), robust, stable, and with a
humongous amount of libraries, and runs without any modification on all
OS platforms I use.

Just a Python admirer's rant on this beautiful autumn afternoon!

(I do like girls also! But everything in it's due time.)

Baalbek
 
J

James Stroud

baalbek said:
Why? The language is just so well designed (I miss some of Ruby's
features, but then, nothing is perfect)

Out of curiosity, what are these features that ruby has that python
lacks. I've always wondered whether I should look at ruby--whether, as a
language, it has anything to teach me that say python, C, and Java don't
(LISP/Scheme is on my short-list to learn.)

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/
 
B

Ben Finney

baalbek said:
This unassuming scripting language has beaten heavy-weights like
Java, C++, etc, and this without any serious marketing machine
behind it.

Why? The language is just so well designed (I miss some of Ruby's
features, but then, nothing is perfect), robust, stable, and with a
humongous amount of libraries, and runs without any modification on
all OS platforms I use.

I attribute much of it to the fact that it's free software -- i.e. its
main implementations have, for its entire life, been freely modifiable
and redistributable by anyone. This gives it a qualitative edge in
adoption over Delphi and Java, at least; and is the primary reason for
"runs on all major platforms".

These days, I never want to invest in an OS or language, or pretty
much any infrastructural computing technology, unless it's free from
vendor lock-in. It's just too damned risky to rely on something that
isn't guaranteed to be supportible beyond a single vendor's whim.

That's "survival of the fittest" in computing technology as I see it
:)
 
T

Thomas Bartkus

On Wed, 27 Sep 2006 01:51:43 +0200, baalbek wrote:

Now, six years later, I use Python for about 70-80% of all my work (the
remainder being Ruby and C/C++).

I'm now having the policy: "If it's doable in Python, I'll use Python".
<snip>

Okay. How did your stated "policy" leave you still wasting 20-30% of your
programming efforts on other languages?

We would be curious to know about those things you can do in C++
but can't do in Python.
(Doubting) Thomas Bartkus
 
M

MonkeeSage

James said:
Out of curiosity, what are these features that ruby has that python
lacks. I've always wondered whether I should look at ruby--whether, as a
language, it has anything to teach me that say python, C, and Java don't
(LISP/Scheme is on my short-list to learn.)

Just a guess, myself not being the OP; but I would imagine that true
blocks / continuation passing and overriding / extending built-in
classes would rank high on the list. You can do the same things in
python (by using a different implementation), but it's not always as
clear or easy (e.g., coroutines in ruby as alot clearer using a callcc
approach than python's generator approach, imo at least -- but that's
also highly subjective).

Ps. I agree with the OP on the point I like python alot. :)

Regards,
Jordan
 
B

baalbek

Thomas said:
Okay. How did your stated "policy" leave you still wasting 20-30% of your
programming efforts on other languages?

We would be curious to know about those things you can do in C++
but can't do in Python.
(Doubting) Thomas Bartkus


Nothing to do with what C++ can do that Python can't, but using
technology where there are C++ libs only.



For example, I do quite a bit of CAD (Autocad) programming; the
ObjectARX library supports C++ only.

Baalbek
 
B

baalbek

James said:
Out of curiosity, what are these features that ruby has that python
lacks.

Code blocks (closures), that are more advanced than Python's Lambdas,
and the use of yield.

Also, you can pass code blocks to every method without any special
syntax for the method ( it is up to the method of checking whether there
is a code block being passed ).

Some syntactic sugar (list.each { |i| puts i }, etc).

A very simple syntax for reading/writing properties (attr_accessor
:prop1 automatically creates set/get methods for the property prop1).

Also, a standard way of method names that automatically enforce rules, f.ex:

def hascolor?
---
end

The question mark automatically enforces the method to return boolean.

Or:

def prop1=
---
end

automatically assigns to the property @prop1 whatever is evaluated in
the method.

And some other things I can't recall at the moment.


Baalbek
 
D

Dieter Maurer

Thomas Bartkus said:
...
We would be curious to know about those things you can do in C++
but can't do in Python.

I implemented an incremental search engine in Python.

It worked fine for large quite specific "and" queries (it
was faster than a C implemented search engine).

However, for large "or" queries, it was by two orders of magnitude
slower then the C competitor.

I had to move my implementation to C. Now my search engine is
almost always (significantly) faster and when it is slower,
the difference is negligeable.


We learn: a C/C++ implementation can in some cases be drastically
more efficient than a Python one.

My special case was that almost all my data were integers
and the C implementation could exploit this fact -- unlike the Python one.
 
D

Dennis Lee Bieber

We learn: a C/C++ implementation can in some cases be drastically
more efficient than a Python one.
Did we?

When did someone build a C/C++ compiler that generates bytecodes for
the Python virtual machine interpreter?

What I've learned from this tale is that a C/C++ implementation --
compiling to native hardware opcodes -- can run faster than an
implementation compiled to interpreted Python bytecodes... No idea as to
"efficiency" of the implementations themselves <G>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
D

Dieter Maurer

Dennis Lee Bieber said:
Did we?

When did someone build a C/C++ compiler that generates bytecodes for
the Python virtual machine interpreter?

What I've learned from this tale is that a C/C++ implementation --
compiling to native hardware opcodes -- can run faster than an
implementation compiled to interpreted Python bytecodes... No idea as to
"efficiency" of the implementations themselves <G>

I would be really surprised if an optimizing compiler (e.g. a just
in time compiler) would have found the optimations I implemented.

You may look at the two implementations: They are
"IncrementalSearch" (Python) and "IncrementalSearch2" (C), respectively, on

<http://www.dieter.handshake.de/pyprojects/zope>


The Python implementation worked with arbitrary trees,
the C implementation needs quite different code for integer trees
and and for arbitrary trees and only for integer trees, it can
gain the two orders of magnitude in speed.

The optimizing compiler would need to recognize that it can
drastically optimize if *ALL* keys in a tree are integer
and would need to efficiently detect for a given tree
that it satisfies this condition.
It would lose immediately, when it tried to verify the
a tree has only integer keys (as this takes linear time while
most operations are sub-linear).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top