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