Re: [pygame] squeezing a little fun out of java ... meh
On Tue, Jan 3, 2012 at 10:18 PM, Jan Pobrislo wrote: > 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. > > 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. Taking a look now, thanks for the pointer. >> 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. Hallelujah. This is the hell I'm in now. For example check out this documentation of a 'simple' thing to do: -- http://libgdx.l33tlabs.org/docs/api/com/badlogic/gdx/scenes/scene2d/Actor.html The projection and transform matrices are setup so that an Actor can simply call the SpriteBatch.draw(com.badlogic.gdx.graphics.Texture, float, float, float, float, float, float, float, float, float, int, int, int, int, boolean, boolean) method to render himself. -- maybe that's just what it takes in this framework, but that is HELL of a lot of arguments when you're just trying to put a picture on a screen. The first time I read it I was like, 'wow... that's a lot of s**t for what is basically a BLIT'.
Re: [pygame] squeezing a little fun out of java ... meh
Hello,
On 03/01/12 09:52 AM, Ian Mallett wrote:
From my
deeply uneducated standpoint it seems to me like this wouldn't be a
horribly hard thing to do, to add static typing or enforced types to
python.
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.
I suppose you could do things like:
def my_func(in):
if type(in) != type(""): raise ValueError()
. . . which emulate static types, but is still not a compile-time
error. In my early Python libraries, I found I was doing something of
this sort because I wanted it to be robust, even at the cost of
performance (this is a case where C++ wins: C++ is plenty fast, you
don't have to do this particular kind of error checking, and you can
put #ifdef/#endif around error-checking sections so that the code
isn't even /there/ when you don't want it).
You know, there is even a Python builtin for this: isinstance
Oh, and Python 3.2 adds Abstract Base Classes, which group types by
common features rather than inheritance. They serve a purpose similar to
Java interfaces.
Lenard Lindstrom
Re: [pygame] squeezing a little fun out of java ... meh
On Tue, Jan 3, 2012 at 5:18 PM, Jan Pobrislo wrote:
> On Tue, 3 Jan 2012 09:52:33 -0800
> Ian Mallett 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
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 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
Re: [pygame] squeezing a little fun out of java ... meh
On Tue, 3 Jan 2012 09:52:33 -0800
Ian Mallett wrote:
> On Tue, Jan 3, 2012 at 7:19 AM, Sean Wolfe
> wrote:
>
> > From my
> > deeply uneducated standpoint it seems to me like this wouldn't be a
> > horribly hard thing to do, to add static typing or enforced types to
> > python.
In py3k this has been thought of:
PEP 3107 -- Function Annotations
http://www.python.org/dev/peps/pep-3107/
> 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.
> I suppose you could do things like:
> def my_func(in):
> if type(in) != type(""): raise ValueError()
> . . . which emulate static types, but is still not a compile-time
I just use bunch of assert statements usually. Not as nice, but works.
> error. In my early Python libraries, I found I was doing something of
> this sort because I wanted it to be robust, even at the cost of
> performance (this is a case where C++ wins: C++ is plenty fast, you
> don't have to do this particular kind of error checking, and you can
> put #ifdef/#endif around error-checking sections so that the code
> isn't even *there* when you don't want it).
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).
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.
> 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. See the language Boo (http://boo.codehaus.org/) which exploits
this on the .NET platform. (The manifesto is definitely worth reading.)
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.
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 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.
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.
If you ever done anything in Haskell, you've seen that such constraints can
not only be easily written out, but to much extent inferred and checked
automatically. If encountering Java made you think about type checking, you
really should read about Haskell's type system before bringing such things
into Python. We already owe it for list comprehension and probably lot
of other useful things too.
> > Just a little rant to start of 2012 in the right way.
> >
> > Happy new year!! And remember. press on, it's only a flesh wound!
Happy Sun-Earth revolution to you too.
Re: [pygame] squeezing a little fun out of java ... meh
On Tue, Jan 3, 2012 at 12:52 PM, Ian Mallett wrote:
> I suppose you could do things like:
> def my_func(in):
> if type(in) != type(""): raise ValueError()
> . . . which emulate static types, but is still not a compile-time error.
> In my early Python libraries, I found I was doing something of this sort
> because I wanted it to be robust, even at the cost of performance (this is
> a case where C++ wins: C++ is plenty fast, you don't have to do this
> particular kind of error checking, and you can put #ifdef/#endif around
> error-checking sections so that the code isn't even *there* when you
> don't want it).
>
That's good, I recommend this simple method for small-to-medium projects.
The difference between dynamic and compile-time errors is minor when your
compile times are almost instantaneous. You can get most of the benefit you
would have gotten with static typing pretty easily with this method.
Just keep in mind that you usually *don't* want static typing. Don't go
crazy and check the type of every single argument, just things for which
only one type will do. Often numbers or Surfaces will fall into this
category. Probably the most common issue that static typing would have
helped me with when writing pygame games is simply getting the arguments to
a function call out of order.
As for performance, just make it an assert which you disable (with -O) when
you distribute the game.
-Christopher
Re: [pygame] squeezing a little fun out of java ... meh
Hi, Definitely worth learning C++ and Java simply because there is so much code out there written in them. Also languages and tech that are painful to use often pay more ;) But I know what you mean about joy... Python is designed to mostly be nice to the programmer over the computer. Apart from tests, tools like pep8, and pyflakes are nice to run on your code. Whereas fuzzing, unit, functional, integration, monitoring and other types of tests help programmers out a lot too. http://www.sqlite.org/testing.html
Re: [pygame] squeezing a little fun out of java ... meh
On Tue, Jan 3, 2012 at 7:19 AM, Sean Wolfe wrote:
> Well working in java continues to suck. I wish I had more experience
> in C/cpp, working on it, because then I could be a little less biased
> on evaluating java. I mean my frustrations with curly brace completion
> and strong typing aren't a limitation of java per se.
>
> I've been reading a lot about the relative merits of static vs duck
> typing and a plus on the strongly-typed side seems to be, catching
> bugs in the editor or at compile time as opposed to runtime.
Yes. That's a primary benefit of statically typed languages--the compiler
can do some of the brain work for you. There are plenty of other examples,
too (e.g., const-correctness in C/C++ and the "throws" declaration in Java).
> From my
> deeply uneducated standpoint it seems to me like this wouldn't be a
> horribly hard thing to do, to add static typing or enforced types to
> python.
>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.
I suppose you could do things like:
def my_func(in):
if type(in) != type(""): raise ValueError()
. . . which emulate static types, but is still not a compile-time error.
In my early Python libraries, I found I was doing something of this sort
because I wanted it to be robust, even at the cost of performance (this is
a case where C++ wins: C++ is plenty fast, you don't have to do this
particular kind of error checking, and you can put #ifdef/#endif around
error-checking sections so that the code isn't even *there* when you don't
want it).
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);
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.
>
> Also, although coding in Java sucks massively and gives me no joy or
> happiness in life, I am finding a glimmer of hope and encouragement
> using this libgdx gaming framework which at least is made by game
> enthusiasts and uses cool terminology like 'Actor' and 'Stage' as
> opposed to Canvas and BitmapDrawable or worse ... java.util.List .
> Lord save me from java.util.List .
>
> Just a little rant to start of 2012 in the right way.
>
> Happy new year!! And remember. press on, it's only a flesh wound!
Ian
[pygame] squeezing a little fun out of java ... meh
Well working in java continues to suck. I wish I had more experience in C/cpp, working on it, because then I could be a little less biased on evaluating java. I mean my frustrations with curly brace completion and strong typing aren't a limitation of java per se. I've been reading a lot about the relative merits of static vs duck typing and a plus on the strongly-typed side seems to be, catching bugs in the editor or at compile time as opposed to runtime. From my deeply uneducated standpoint it seems to me like this wouldn't be a horribly hard thing to do, to add static typing or enforced types to python. 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. Also, although coding in Java sucks massively and gives me no joy or happiness in life, I am finding a glimmer of hope and encouragement using this libgdx gaming framework which at least is made by game enthusiasts and uses cool terminology like 'Actor' and 'Stage' as opposed to Canvas and BitmapDrawable or worse ... java.util.List . Lord save me from java.util.List . Just a little rant to start of 2012 in the right way. Happy new year!! And remember. press on, it's only a flesh wound! -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
