On Tue, Jan 3, 2012 at 5:18 PM, Jan Pobrislo <c...@webprojekty.cz> wrote:
> On Tue, 3 Jan 2012 09:52:33 -0800
> Ian Mallett <geometr...@gmail.com> 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 <cosmologi...@gmail.com>
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.
On Tue, Jan 3, 2012 at 5:18 PM, Jan Pobrislo <c...@webprojekty.cz> wrote:
> 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 <ren...@gmail.com> 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
