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
