dynamic classes and duck typing
Leandro Lucarella
llucax at gmail.com
Tue Dec 1 06:28:42 PST 2009
retard, el 1 de diciembre a las 11:42 me escribiste:
> Tue, 01 Dec 2009 03:13:28 -0800, Walter Bright wrote:
>
> > retard wrote:
> >> Overall these simplifications don't remove any crucial high level
> >> language features, in fact they make the code simpler and shorter. For
> >> instance there isn't high level code that can only be written with
> >> 8-bit byte primitives, static methods or closures, but not with 32-bit
> >> generic ints, singletons, and generic higher order functions. The only
> >> thing you lose is some type safety and efficiency.
> >
> > I'm no expert on Python, but there are some things one gives up with it:
> >
> > 1. the ability to do functional style programming. The lack of
> > immutability makes for very hard multithreaded programming.
>
> Even if the language doesn't enforce immutability it's indeed possible to
> use immutable data types in a language without pure/const/final
> attributes.
And BTW, Python *have* some built-in immutable types (strings, tuples,
integers, floats, frozensets, and I don't remember if there is anything
else). Python uses convention over hard-discipline (no public/private for
example), so you can make your own immutable types, just don't add
mutating methods and don't mess with. I agree it's arguable, but people
actually use this conventions (they are all consenting adults :), so
things works.
I can only speak from experience, and my bug count in Python is extremely
low, even when doing MT (the Queue module provides a very easy way to pass
messages from one thread to another).
I agree that, when you don't care much for performance, things are much
easier :)
> > 2. as you mentioned, there's the performance problem. It's fine if you
> > don't need performance, but once you do, the complexity abruptly goes
> > way up.
>
> In D, there's the simplicity problem. It's fine if you don't need
> readability, but once you do, the efficiency abruptly goes way down.
>
> >
> > 3. no contract programming (it's very hard to emulate contract
> > inheritance)
>
> True, this is a commonly overlooked feature. I don't know any other
> languages than Eiffel or D that support this.
>
> I'm not sure how hard it would be to emulate this feature in languages
> where you can define your own class mechanism.
There are libraries to do contracts in Python:
http://www.wayforward.net/pycontract/
http://blitiri.com.ar/git/?p=pymisc;a=blob;f=contract.py;h=0d78aa3dc9f3af5336c8d34ce521815ebd7d5ea0;hb=HEAD
I don't know if they handle contract inheritance though.
There is a PEP for that too:
http://www.python.org/dev/peps/pep-0316/
But I don't many people really wants DbC in Python, so I don't think it
would be implemented.
> > 4. no metaprogramming
>
> Dynamic languages support dynamic metaprogramming. Ever heard of e.g.
> lisp macros?
Exactly! You can even generate code dynamically! This is a very nice
example:
http://code.activestate.com/recipes/362305/
It makes "self" implicit in *pure Python*.
If you say dynamic languages don't have metaprogramming capabilities, you
just don't have any idea of what a dynamic language really is.
> > 5. simple interfacing to C
>
> In case you mean no unnecessary wrappers etc., this has more to do with
> the execution model than language features. Most scripting languages are
> interpreted, and require some sort of assistance from the runtime system.
> If the language was compiled instead, they wouldn't necessarily need
> those.
In D you need interfacing code too, it can be a little simpler, that's
true.
> > 6. scope guard (transactional processing); Python has the miserable
> > try-catch-finally paradigm
WRONG! See the with statement:
http://www.python.org/dev/peps/pep-0343/
with lock:
some_non_mt_function()
with transaction:
some_queries()
with file(fname) as f:
x = f.read(10)
f.write(x)
> > 8. RAII
>
> Ok.
>
> I think this could also be enforced dynamically.
Again, the with statement.
> >
> > 9. versioning
>
> I don't know why this can't be done dynamically.
It can, and it's pretty common, you can do things like this:
class A:
if WHATEVER:
def __init__(self):
pass
else:
def __init__(self, x):
pass
> > 10. ability to manage resources directly
What do you mean by resource?
> > 11. inline assembler
You can do bytecode manipulation, which is the assembler of dynamic
languages :)
I really think the *only* *major* advantage of D over Python is speed.
That's it.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cuando el Mártir estaba siendo perseguido y aglutinado por los
citronetos, aquellos perversos que pretendian, en su maldad, piononizar
las enseñanzas de Peperino.
-- Peperino Pómoro
More information about the Digitalmars-d
mailing list