dynamic classes and duck typing

Leandro Lucarella llucax at gmail.com
Tue Dec 1 12:11:26 PST 2009


Walter Bright, el  1 de diciembre a las 10:46 me escribiste:
> >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 agree that statically enforced immutability is unnecessary if you
> are able to rigidly follow an immutability convention. C++ also has
> immutability by convention. People who work in large teams with
> programmers of all skill levels tell me, however, that having a
> convention and being sure it is followed 100% are two very different
> things.

Yes, I know, probably Python (and most dynamic languages) and Java are the
two extremes in this regard.

> >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).
> 
> How about the GIL?

The GIL is a performance issue. As I said, that's the only point where
D is stronger than Python (and maybe other dynamic languages, I mention
Python because is the language I use the most).

> >I agree that, when you don't care much for performance, things are much
> >easier :)
> 
> I would also agree that your bug count and complexity should be low
> as long as you're staying within the paradigms that Python (or any
> language) was designed to support.

Of course. But Python is a very flexible language (or I use too few
paradigms when programming ;).

> >>>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.
> 
> Ok, can you do Bill Baxter's swizzler? Can you do Don Clugston's FPU
> code generator?

I don't know any of those things, but I know Python have very good
metaprogramming capabilities (decorators and metaclasses being probably
the 2 bigger features in this regard).

> >>>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.
> 
> The interfacing in D is nothing more than providing a declaration.
> There is no code executed.

Unless you want to pass D strings to C, then you have to execute
toStringz(), which is a really thin "wrapper", but it's a wrapper. Using
C from D is (generally) error prone and painful, so I usually end up
writing more D'ish wrappers to make the D coding more pleasant.

And BTW, you can access C dynamic libraries in Python via the ctype
module:
http://docs.python.org/library/ctypes.html

It's not safe, and of course, being a dynamic language, you can access
C code at "compile time" (because there it no compile time), but you can
interface with C very easily:

>>> import ctypes
>>> libc = ctypes.cdll.LoadLibrary("libc.so.6")
>>> libc.printf("hello world %i\n", 5)
hello world 5

Wow, that was hard! =)

> >>>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)
> 
> Looks like you're right, and it's a recently added new feature. I
> suggest it proves my point - Python had to add complexity to support
> another paradigm. Python's "with" doesn't look any simpler than
> scope guard.

It's simpler, because you only have one obvious way to do things, in D you
can use a struct, a scope class or a scope statement to achieve the same.
Of course that gives you more flexibility, but adds complexity to the
language. I'm not complaining or saying that D is wrong, I'm just saying
that Python is a very expressive language without much complexity. I think
the tradeoff is the speed.

> >>>8. RAII
> >>Ok.
> >>
> >>I think this could also be enforced dynamically.
> >
> >Again, the with statement.
> 
> Yes, you can emulate RAII with the with statement, but with RAII
> (objects that destruct when they go out of scope) you can put this
> behavior in the object rather than explicitly in the code every time
> you use it. It's more complicated to have to remember to do it every
> time on use.

Maybe you are right, but the with statement plays very well with the
"explicit is better than implicit" of Python :)

Again, is flexibility vs complexity.

> >>>10. ability to manage resources directly
> >
> >What do you mean by resource?
> 
> Garbage collection isn't appropriate for managing every resources.
> Scarce ones need handling manually. Even large malloc's often are
> better done outside of the gc.

We are talking about performance again. If you need speed, I agree Python
is worse than D.

> >>>11. inline assembler
> >
> >You can do bytecode manipulation, which is the assembler of dynamic
> >languages :)
> 
> That doesn't help if you really need to do a little assembler.

Right, but I don't think anyone uses assembler just for fun, you use it
either for optimization (where I already said D is better than Python) or
for doing some low-level stuff (where Python clearly is not a viable
option).

> >I really think the *only* *major* advantage of D over Python is speed.
> >That's it.
> 
> I probably place a lot more importance on static verification rather
> than relying on convention and tons of unit tests.

There are static analyzers for Python:
http://www.logilab.org/857
http://divmod.org/trac/wiki/DivmodPyflakes
http://pychecker.sourceforge.net/

And again, judging from experience, I don't know why, but I really have
a very small bug count when using Python. I don't work with huge teams of
crappy programmers (which I think is the scenario that D tries to cover),
that can be a reason ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Creativity is great but plagiarism is faster



More information about the Digitalmars-d mailing list