On 12/27/10 2:57 AM, bearophile wrote:
Je'rome M. Berger:
I have almost never used inline assembler even in languages that support it. Of
course, this is only a sub-point of your point 6: using inline assembly in a
language as slow as Python would be completely pointless.<
For scientific computing this is better than D inline asm:
http://www.corepy.org/
I would not count them as advantages per se. Some of their consequences might be
seen as advantages once we have enough experience with them.<
In Python frozensets, tuples, namedtuples and strings are built-in immutables.
And it's easy to find frozendicts too. They cover many usages. (They are
head-const, sometimes).
And in the end Python design is based on different principles. If you look at Python and all you see is it
lacking "const", "private" and "protected" then you miss the most important
thing. A language doesn't fail because it lacks a feature, a language is like an old ecology, its parts are
adapted to each other. This means that the lack of const is covered by other qualities of the language or its
Zen. In practice I still create less bugs in Python than D. Google builds many systems using Python, and they
work.
Python has it too (since 2.6 IIRC, see the "with" keyword). Moreover, Python makes
it clear that RAII is happening by requiring a special syntax at the call point.<
CPython GC is a reference counter (+ cycle breaker), so deallocations are often
deterministic.
Cython gives it too: it is as easy to write a Cython interface module as to write
a D interface file for a C library.<
This is built-in:
http://docs.python.org/library/ctypes.html
It's not hard to embed or extend Python in C.
Plus there are tens of ways of bridging the two, like SWIG, PIL, Boost Python,
etc, plus there is ShedSkin, Cython, etc etc.
-------------------
Walter:
Templates are far more than just generics.
But an army of people argue that using templates for more than generics is bad.
In C++ you use templates for generic data structures and classes, for
metaprogramming, for type-level computing, and probably for other things. For
metaprogramming even D doesn't use templates much any more (after the
introduction of CTFE), most other ways to perform metaprogramming are better
than doing it with C++ templates. Type level computing is better done with
staged compilation, a type to represent a type, more flexible type sytems, etc.
See modern functional languages.
That happens at compile time.
That happens at run time. D's happens at compile time.
Python has a wonderful advantage over D: there is no compilation! You write
your code and you run it! So no need to let things happen at compile-time. If
you want to pre-compute things you can just split your program in two levels
and run a level before another, or use eval/exec. So Python is better here.
No compilation, no problems :-) Generative programming in Python is way better
than D :-)
With rdmd I have the feeling that you can say the same about D.
Generally I don't post a message in a sub-thread like this. In the end what's
the purpose of this sub thread? Is Python better than D? Who cares? They are
very different languages, for different people doing different things. Even if
D is ten times better than Python, the world will not stop using Python
tomorrow. In future compiled languages, especially system languages that don't
run on a VM will be just a small percentage of the whole computing world. They
will not go away, but for any program written in C++ or D, in the next years
people will write 1000 or more programs in JavaScript, Python, Ruby, PHP, VB,
(and Java, C#). System languages are now a niche.
It's currently a growing niche as sequential speed doesn't scale anymore
by Moore's law. Depending on the interplay of discoveries in the coming
years, I believe it's not impossible that serial languages that spend
CPU cycles on dynamic interpretation might become a historical curiosity
caused by a fleeting context: (a) serial speed is large enough to allow
wasting some of it, (b) I/O is much slower than CPU and dominates the
performance profile of many programs, (c) many of today's computing
needs are materially covered with relatively little CPU effort. Any and
all such conditions may change in the future.
Andrei
