dynamic classes and duck typing

[Walter Bright]

Leandro Lucarella wrote:
> 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 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.


> 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?

> 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.


>>> 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. 

That, I strongly disagree with.


>>> 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.

I suspect it is a very hard problem to do with just front end rewriting,

1. I've never seen anyone manage to do it

2. I had to adjust the code generator to make it work


> But I don't many people really wants DbC in Python, so I don't think it
> would be implemented.

That goes back to if you're staying inside the supported paradigms or not.


>>> 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?


>>> 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.


>>> 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.



>>> 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.


>>> 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?

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.


>>> 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.

> 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.