On Tue, 3 Jan 2012 09:52:33 -0800
Ian Mallett <
geometrian@xxxxxxxxx> wrote:
> From a programmer's perspective, I *don't* see it as easy to add
> support for static typing to Python. It really must be all there or
> all *not*. And having it *not* is one of the beauties of Python. It
> also made it slower. However, it's a tradeoff the language
> designer(s) always have to make; it can't really happen at the
> coders' level.
That is indeed true for one simple reason: names are resolved at runtime.
While this allows monkeypatching, it also makes you unable to tell whether
self.somemethod is really the piece of code 10 lines above the call or
something entirely different until you hit the actual call.
Yes. That's the beauty of it. It can be harder, yes, but there's something satisfying when you don't even need explicit type information because you already know in your mind how it all fits together.
If you want to be pedantic, I suppose you can start passing function pointers around in compiled languages and then change were something points last second. The only real way to get the same level of flexibility though is with templating (C++) or generics (Java).
No matter what though--templates, generics, duck or static typing--nothing is a substitute for not being stupid when designing your API. I have often said that if one's code were completely bereft of comments I should be able to tell at a glance what something does, and not be stuck trying to figure out what type arguments can be reasonably passed into something. To this end, elegance, simplicity, and good design are mandatory.
I just use bunch of assert statements usually. Not as nice, but works.
On Tue, Jan 3, 2012 at 10:17 AM, Christopher Night
<cosmologicon@xxxxxxxxx> wrote:
As for performance, just make it an assert which you disable (with -O) when you distribute the game.
I suppose assert statements would be cleaner, but, as I implied, I'm actually not writing any of my libraries in Python anymore. I write Python wrappers or use Python for the one-off things that take less than a few days to write.
There is a plenty of interface libraries that aid with implementing the type
checking you want and can do more funky stuff like adaptation (equivalent to
automatic type casting in static-world). One of the prominent ones is
zope.interface which I would recommend checking out. Don't worry, it's
independent of rest of zope and it's used by quite a few other projects
(eg. twisted).
Ugh. I hate interfaces, and anything even tangentially related to Java. I find that inheritance and polymorphism suit my type-checking needs, if I ever need it. Code is a tool, and shouldn't be used by stupid people who don't know what methods their own classes have. I don't mean that in aggressive way; I simply mean that interfaces to me seem like needless complexity.
You can do inferfaces in C++ by having your object inherit from a class containing all pure virtual methods. But at that point, it's probably better just to have function overloads for your class itself. And I can't actually even imagine a single instance where not being able to carry anything other than function prototypes wouldn't have merit. I mean, for example, Java.util.List could definitely have benefited from storing the implementing classes' backings' sizes--but, it's an interface so it can't do that. Instead, that code has to presumably be repeated across all its implementing classes. As a programmer, why would I do that to myself?
The thing is you still need tests with full code coverage because as I said,
everything happens in runtime in Python, but this can make it easier.
Good testing framework can help a lot too, I've fallen in love with py.test's
functional style and seen it reduce size of test cases drastically compared to
original unittest style.
Well, you always need to test your code no matter what. If you don't believe that, you're a hopeless idealist like I was some years ago. Except for the smallest of code, you're bound to have a bug somewhere. Even if, by some miracle you don't, you won't ever be able to legitimately have the confidence to say so.
I'll note that in my experience, good program design/architecture keeps your range of possible mistakes down, so you need fewer tests. No one likes testing their code. I'm no exception. You cut down on your work by building it right in the first place.
> On the flip side, it's actually surprisingly easy to add duck typing
> (of a sort, through polymorphism) to compile-time languages. In
> Java, simply make everything type "Object". E.g.:
> Object my_var = new String("Help! Spiders!");
> my_var = new Integer(6);
That's actually because JRE and CLR runtimes implement typing internally and
would technically allow duck-typing if it wasn't the above language semantics
restricting it.
[...]
The advantage of duck typing is you can write function which's only
requirements on it's arguments is that they can be added together via +
operator and the result must be representable as string. You can then call it
with numbers, strings or lists and it works each time. You can't sensibly
represent such constraint via interface classes.
Sorta, yeah. But my point was more that you can just do implicit pointer casting if all you care about is not writing type names everywhere. I'm not sure because I'm was never stupid enough to try it, but I think the JRE will let you do stuff like:
Object list = new LinkedList<Integer>();
list.clear(); //problem?
. . . if you disable enough errors.
See the language Boo (http://boo.codehaus.org/) which exploits
this on the .NET platform. (The manifesto is definitely worth reading.)
Huh. I was thinking about making something like this with the time that I do not have. Particularly the vague bit about teaching the compiler different syntaxes. I skimmed the manifesto; I can't say I embrace it entirely (nor the .NET platform in general), though it does have some good ideas.
When it comes to C/C++ it's bit trickier. The way C++ implements virtual
methods and classes in general inspired quite amount of hate for it and I hear
that even Objective-C that does the type resolution in runtime is often
faster than C++ that does that compile-time.
I don't know enough about Objective C to make an informed comment about it, but as far as C++ goes, it was my impression that having a virtual function table (one layer of pointer indirection) is about the fastest you can get without seriously breaking polymorphism. I'm not even sure what else you would do; it was my impression that's how all OO did it internally (or the moral equivalent).
By the way, if you are C++ programmer and haven't yet read Frequently
Questioned Answers, I suggest you find time to at least skim through it.
I'm not sure whether to take this as some sort of comment on my failure to communicate, or a lack of my knowledge. I'm likely guilty to some degree in either count. The C++ FAQ Lite is a great resource too, but thanks for showing me this anyway.
> I mean we could make cholices as we code as to what to use.
> > When it was better to use a strongly typed methodolgy we could
> > refactor our code. We could use the feature as needed, and continue
> > with duck typing for normal python ness.
The thing I dislike on the Java-style classful/interface based type checking
everyone seems to implement is it promotes complicated interfaces and
overengineered OO infrastructure.
I agree. And I think a huge component of the requisite nastiness stems from a lack of any real multiple inheritance support. Suppose I want to inherit default implementations from two different classes into Java? There's physically no way to do this without resorting to something more hackish than the mangled garbage you're moving away from to OO design for anyway.
I could rant on and on about how much I hate Java, but suffice for a design conversation, I feel like many of the language creators' decisions (like multiple inheritance, or lack thereof) cripple decent design in many ways.
On Tue, Jan 3, 2012 at 10:08 AM, René Dudfield
<renesd@xxxxxxxxx> wrote:
Definitely worth learning C++ and Java simply because there is so much code out there written in them.
. . . and the more languages you know the easier it is to learn new ones, not to mention make you a better coder.
Ian