Fwd: [Tutor] Slightly OT - Python/Java

[Max Noel]

(*bangs head on keyboard* gah, I clicked Reply instead of Reply to All 
again -- sorry!)

Begin forwarded message:

> From: Max Noel <maxnoel_fr at yahoo.fr>
> Date: January 11, 2005 00:09:11 GMT
> To: "Alan Gauld" <alan.gauld at freenet.co.uk>
> Subject: Re: [Tutor] Slightly OT - Python/Java
>
>
> On Jan 10, 2005, at 20:04, Alan Gauld wrote:
>
>> Superior is a relative term. Java has lots of huge restrictions
>> compared to C++ - the lack of operator overloading being maybe
>> the biggest, since it prevents true sub typing of builtins and
>> primitives - thus resulting in extra(and horrible) code.
>
> 	Well, I've very rarely (if ever) used operator overloading, so I 
> can't say I miss it much ;)
> 	However, you have a point in that I don't like the fact that 
> everything is not an object in Java. Leftover non-object types from 
> C/C++ (int, float, et al.) stand out like sore thumbs; however I can 
> see how the lack of operator overloading prevents them from 
> disappearing. I'm not sure how it works in Python, though; can you 
> subclass int, list, dict, etc.? Does it have operator overloading, or, 
> missing that, a way to extent operators into classes?
>
>> And the lack of functionpointers (inner classes not withstanding)
>> is a big hit, and what about multiple inheritance - interfaces suck!
>
> 	True, the lack of function pointers is a problem, at least when 
> working procedurally. When going full-OO, I don't see where this can 
> be a problem (since Class itself is an object, you can create pointers 
> to classes).
> 	Also, I agree that interfaces are a bizarre way of adding multiple 
> inheritance. I'm still wondering if there is a better way, though 
> (apart from just allowing multiple inheritance, which I still don't 
> know if it's a good idea or not).
>
>> Its also much slower - JIT compilers, and even native compilers,
>> notwithstanding. I could go on...but...
>
> 	Of course. I never suggested using Java to write 3D state-of-the-art 
> games. For "standard" applications, though, it beats C/C++ any day of 
> the week (worst-case scenario, you can still extend it in C, can't 
> you? -- not sure about that).
> 	And a JIT compiler (HotSpot) is a part of standard Java now, isn't 
> it? So I think it is relevant. (native compilers like GCJ, however, 
> aren't -- they kinda defeat the whole point of Java if you ask me)
>
>> It is however, a simpler language to learn, and I must admit
>> that having got used to garbage collection in Python going
>> back top C and C++ is a shock... And the large standard library
>> (even if the design is awful in places) is an advantage.
>
> 	Yup.
>
>>> RubyCocoa anyway, so that'd be equivalent to using Objective-C).
>>
>> Have you used Objective C itself? I like it a lot. It combines
>> much of what I like about both C++ and Python.
>
> 	Not yet. I tried learning it by myself last year, but the Cocoa 
> framework, although extremely powerful, was a bit overwhelming to me 
> (especially since I'd never done any real GUI programming).
> 	I'll probably give it another shot sometime this year.
>
>>> Also, Java has something which Python lacks (yet should have):
>>> private/protected/public class members. In Python, everything is
>>> public, which I consider to be a Bad Thing(TM).
>>
>> Why do you think it should have it? Have you run into a lot of
>> problems with inappropriate access in Python programs? This often
>> comes up from ex Java/C++ programmers yet access control like
>> this was not part of any of the earliest OOP languages and nobody
>> ever discussed it much(SMalltalk took one extreme - all data
>> private, and Lisp the other - all public) But I don't recall
>> have any big issues with lack of control, and I don't find
>> it an issue in Python.
>> What exactly do you find to be such a problem with the lack
>> in Python?
>
> 	Well, the fact that everything is public means that if you want a 
> certain form of encapsulation, you have to state in the docstrings 
> what should be used as an "external interface" (stuff like "This is an 
> internal method and may change/disappear in the next version! Don't 
> use it!") and hope that people who use your classes listen to what you 
> say.
> 	I like the idea behind encapsulation, that you should be able to use 
> a class as a "black box" with a known interface and not worry about 
> the specifics. The way things are, Python gives you the possibility of 
> shooting yourself in the foot; or to be more accurate they prevent you 
> from preventing others from shooting themselves in the foot when they 
> use your classes. (does what I say make any sense?)
>
> 	A solution would be to do like in Ruby, where class/instance 
> variables have names starting with (respectively) @@ or @. I guess you 
> can do the same in Python (although it'd be __ and _, I suppose), but 
> the language doesn't enforce it.
> (I know, I know, if I want Ruby, I know where to find it :p )
>
>>> Does runtime in Java include startup? Every time you start a java
>>> program, it has to load a BIG runtime in memory (roughly 30 megs of
>>> classes -- that's both Java's curse and blessing).
>>
>> True of Python too of course, you have the initial
>> interpretation/compile stage before execution starts.
>
> 	Indeed; however in Python this extremely fast due to the interpreter 
> being quite light compared to the behemoth that the JVM is (it can 
> take up to 10 seconds starting up on my G4 867 12" Powerbook).
> 	Also, I suppose that the Java bytecode produced by javac is a bit 
> more optimized than the almost-instant bytecode compilation that 
> happens when you start up Python on a program, isn't it? (I mean, it's 
> slower to compile -- even with jikes -- , there's gotta be a reason 
> behind this, ne?)
>
>>> And of course, it's free (and written in Java).
>> http://www.eclipse.org
>>
>> So many editors, so many languages :-)
>
> 	Hehe... So true. Eclipse is not an editor, though, it's an IDE (in 
> the same meaning as Visual Studio and XCode). Quite a 
> resource-consuming one at that, but a very efficient one. I wish Apple 
> could make XCode 2 as good as Eclipse is.
>
> 	Also, as I said, Eclipse can be extended with plugins, meaning it 
> could theoretically become as good with Python as it is with Java. 
> That'd be soooooo cool.
>
> -- Max
> maxnoel_fr at yahoo dot fr -- ICQ #85274019
> "Look at you hacker... A pathetic creature of meat and bone, panting 
> and sweating as you run through my corridors... How can you challenge 
> a perfect, immortal machine?"
>
>
-- 
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting 
and sweating as you run through my corridors... How can you challenge a 
perfect, immortal machine?"