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