dynamic classes and duck typing

[retard]

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.

Python et al support functional style programming. The fact that php 
doesn't only proves that its author had no idea of what he was doing. 
Early php versions even had a limitation on recursion, 50 levels or 
something like that. They still have those limitations, somewhat relaxed. 
Probably no other language performs so poorly with functional code than 
php.

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

> 
> 4. no metaprogramming

Dynamic languages support dynamic metaprogramming. Ever heard of e.g. 
lisp macros?

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

> 
> 6. scope guard (transactional processing); Python has the miserable
> try-catch-finally paradigm

Ok. On the other hand, I don't know why this can't be done with runtime 
metaprogramming features.

> 
> 7. static verification

Dynamic language users argue that since the language is much simpler, you 
don't need to verify anything. And you still have unit test frameworks.

> 
> 8. RAII

Ok.

I think this could also be enforced dynamically.

> 
> 9. versioning

I don't know why this can't be done dynamically.

> 10. ability to manage resources directly

Ok.
> 
> 11. inline assembler

Ok.

Note that I wrote

>> Overall these simplifications don't remove any crucial ___high level___
>> language features, 

> 
> 12. constants

I don't know why this can't be done dynamically with wrapper objects.