YOU CHOOSE!

Java... or Python?

Python

Can I choose to be raped up the ass instead?

Coffee... or a snake?

Reminds me of family life.

>>3
Signed

Python sucks less.

I'd seriously pick Java. But I'd consider suicide first.

Python is fine. You just can't compare it to Java, it's a much nicer language, much more powerful, and much more productive.

So I choose __Python__ over new OutputName(new OutputManager(LanguageFactory().get().createLanguage(new LanguageSpecification(new LanguageParser(new PrintReader(new BufferedReader(new FileReader("JAVUR"))))))).outputname(new UselessShit()).

Python may be slower than Java, I would try it for the syntax.

Python is actually faster than Java in many instances because it doesn't have the worst gc ever. I've even heard reports that Ruby is faster than Java for some things, but frankly I find that hard to believe.

I've even heard reports that Ruby is faster than Java for some things

Anything that executes briefly. I'd never use Java for a command-line utility, or something simple like CGI, because it has a ferocious start-up time. Ruby and any other scripting language would murder even the best-written Java in such scenarios.

Actually, I'd never use Java for anything, but I digress.

>>10
Java is compiled to native code the first time a method is used. And Ruby (I love this language, it's beautiful) is the slowest language on the whold planet (for the moment).

>>12
In terms of speed, Python>Perl>>PHP>Ruby, but I didn't know Java would fall in between depending on what it does. I though at least it was fast. Heh.

Java can be very very fast... as long as you have at least 1GB of RAM, and this is the problem today.

>>13
Are you sure that Python is faster than Perl? I don't know, I'm just asking.

Java is an ugly pig. Python: superior.

>>15
Python would be awesome for me without the "self" pointer, __all__those__underscores__, and those weird methods like len(array) (array.length would be more consistant) and "/".join(array) (array.join("/") would be great). That's why Ruby is cleaner according to me, even if it's slow as hell.

>>16
Agreed, but if the "competition" is java, its pretty easily still superior :3

I think I'll check out Ruby, espcially ruby + rails since everyone is all, "OMFG RUBY RAILS WEB 2.0 INTERNET REVOLUTION BLARURGRAHHHH!1!"

>>14
Yes, it seems to perform slightly better.

>>16
self is good. It makes functions and methods interchangeable, and allows you to have local variables of the same name within the method (which I wouldn't recommend though). The __underscores__ are a bit too much (2 of them was enough, either _x_ or __x, or another character like ?x), but it's a very minor annoyance; in fact I'm far more annoyed at the lack of a safe ?: operator or do..while constructs. len is not a method but a builtin function which can be overloaded. You can also consider it an operator. And you can call it like x.__len__() if you want, although you won't like the underscores. join is actually str.join("/", array), just as in other languages. It just happens that because of Python's self, you can also use it as a method. Method or function, in Python it's your choice.

>>18
>str.join("/", array), just as in other languages.
What other languages? I can only think of ones that have just plain join(glue, pieces) or arrayvar.join(glue). it makes more sense semantically to think of joining as a function related to arrays, not strings.

It makes functions and methods interchangeable

Why does there have to be a distinction?

and allows you to have local variables of the same name within the method

I've always found it hilarious how Pythonistas claim that Python is the opposite of TMTOWTDI. They point to the enforced whitespace as an example.

But wait, self doesn't have to be named self! Call it thingy if you want! Wait, you don't need to worry about those so-called private variables! Just access them with _classname__variable! Oh, and everything else is public, lollers! You don't need accessor methods, just change the variable directly! Oh, shit, did you just fuck up your refactoring by exposing internal implementation details?! QUICK, we'll hack on properties for ya! AHAHAHAHAHA!

Python is full of stupid shit and completely arbitrary crap like this. The syntax is full of fail, starting with __ and """, but it goes way deeper than that. It's almost as bad as Perl, except that the Python bunch and their faggot "Pythonic way" (how many fucking times have I heard "This is the pythonic way to do things", or "This code isn't very pythonic"?) are too conceited to realise their language sucks ass.

Python is the Java of the scripting world: fast, verbose, trying to be corporate (lol zope), and full of fags and dumb shit. hi2u pythonic

The biggest problem with Python is Guido van Rossum. He thinks of language design as a logic puzzle where the goal is to hack on more features without sacrificing the mystical property of "pythonic." So instead of making the most powerful tool possible, he tries to make the most pythonic tool possible, and as a result the language is suboptimal. Give me Ruby, or even better, Lisp please.

>>14
What? Fast? E20Ks choke after a few hours of Java

| Python is the Java of the scripting world: fast, verbose, trying to be corporate (lol zope), and full of fags and dumb shit. hi2u pythonic
It can't be the Java of the scripting world if it's fast

>>23
Whether you like it or not, Java is fast once the bytecode has been compiled. Java's problem is still its huge RAM requirements, but it doesn't matter in most enterprises.

Java > Python especially with GNU Classpath.

>>19
What other languages?
Well, it's join(glue, pieces) in most and str.join(glue, pieces) is the same syntax. Alright, if you're obsessed and really really need it to be exactly join(glue, pieces) you can just do join=str.join .

>>20
Why does there have to be a distinction? [functions and methods]
There isn't, there's just a syntactical difference between class.func(obj, param) and obj.func(param) and Python allows you to use it either way, unlike other languages.

I've always found it hilarious how Pythonistas claim that Python is the opposite of TMTOWTDI
I'm a Pythonista and I support TMTOWTDI regardless of what others say. Remember Python is not some kind of cult, different people think differently. Whitespace is not here to kill TMTOWTDI, but to force morons to indent their code properly and avoid braces or BEGIN..END.

But wait, self doesn't have to be named self!
Exactly. We call it self because it's a nice name, but all it really is the first parameter.

Wait, you don't need to worry about those so-called private variables! Just access them with _classname__variable! Oh, and everything else is public, lollers! You don't need accessor methods, just change the variable directly! Oh, shit, did you just fuck up your refactoring by exposing internal implementation details?!
Python is a quality reflexive language. You *have* to be able to do that kind of thing. Besides, Python's OO is not paranoid like Java's, but more practical. You change properties directly because that's what properties are for. If the implementation changes and you really really need to change properties (which you shouldn't as often thanks to duck typing and because if you change it so much you probably need to change code which uses it), you can always override = and . . What else can you ask for? (Oh, and if you love useless work and ugly syntax, you can always define accessor methods. Nothing forbids them.)

PROTIP: If you like S&M, go back to Java. There you'll need to write 25-100 lines of interface for every class you create.

The syntax is full of fail, starting with __ and """
I agree that __ is excessive and Perl's recursive q<anything> quotes are much better.

trying to be corporate (lol zope)
I'm borderline offended by your statement :p
1. Zope is not Python
2. Zope sucks

>>24
Java is still sluggish at times because of its poor GC, and even compiled bytecode was shown to perform worse than Python in certain cases.

>>25
Yes, in your dreams Java boy.

There isn't, there's just a syntactical difference between class.func(obj, param) and obj.func(param) and Python allows you to use it either way, unlike other languages.

Last I checked, len(), dir(), str(), int(), and other built-in functions could not be used either way. There's one way, and it's completely different from how everything else is handled. This is the sort of strange inconsistent weirdness I'd expect out of Perl.

You *have* to be able to do that kind of thing.

Why? And why is accessing variables in a object directly considered "Pythonic"? I betcha don't know *.

Remember Python is not some kind of cult, different people think differently.

Unfortunately, glorious leader Guido van Rossum sez: While we put "There's only one way to do it" on a T-shirt, mostly to poke fun at Larry Wall's TMTOWTDI, the actual Python Zen rule reads: "There should be one-- and preferably only one -- obvious way to do it." This is the guy designing your language, the same one who wanted to kill lambda, but finally gave up. Seig Heil!


* Hint: Guido ol' boy hasn't done anything about high execution time for method calls. The fanboys never question why it's "pythonic" to directly access object attributes though...

>>26 Being able to access private variables and being a reflexive language are unrelated concepts, fanboy.

>>27
The few builtin functions like len, dir, etc. actually call __len__, __str__, and so, which you can call either way. Don't use len(myobj) if you don't like it, just call myobj.__len__ or alias it.

And why is accessing variables in a object directly considered "Pythonic"?
Because that's what they are for. It's far more convenient to do window.x=2 than window.GetX(2) . Not only it's syntactically 10x better, simpler, and easier to read, but it's also an lvalue which neither these damned Get or Set methods are. Like I said, you are to use them. If the implementation changes, you should respect what they used to mean. It'd suck if something's in litres and the next version is in cubic centimetres. You'd have to change the rest of your program anyways. And you can always override accessing to members (the dot).

Being able to access private variables and being a reflexive language are unrelated concepts, fanboy.
Hardly a fanboy. And yes, you want to be able to hack just about anything and access just about anything. This doesn't meant you shouldn't know what you're doing. Actually, I think you're the fanboy one if you think the language is worse because it offers a feature you don't like. Just don't use it. Like goto, found in many languages, it's hardly necessary and rarely a good idea, but once every some 50000 lines it is. Stop whining.

>>29
I failed at quoting but oh well. Text browsers.

>>27 cont
The fanboys never question why it's "pythonic" to directly access object attributes though
You're so obsessed about this. This is actually a good thing. I really like stuff.x over stuff.ChangeMyExxPleaseLOLOL(). If you like to be sodomized with bigot OO techniques, go back to Java, you'll be happy.

>>30
Let's be serious for a second, if you prefer the syntax stuff.x, why don't write everything in C, because it's faster than everything else.

OTOH, if you want a clean interface to your implementation, you have to use methods to check for the access of the hidden stuff within your objects. This may not seem obvious to you if you stick to small programs, but it is vital to define and separate the inside from the outside for big projects.

>>30
Your entire argument seems to be based on the idea that if you can't access a member directly as in foo.bar, you have to use a method that looks like foo.getBar().

Unfortunately your argument falls down pretty much instantly when you look at Ruby. In Ruby parentheses are purely for grouping; any time they're not required to override precedence, they can be left out. How does this relate to accessing objects? Well, lets say you have a class Point with members x and y. It might look like this:
class Point
    def x
        @x
    end

    def x= newX
        @x = newX
    end
   
    #methods for y omitted
end

The few builtin functions like len, dir, etc. actually call __len__, __str__

How nice. len(), str(), et al are still there. Why wasn't it called x.len() and x.str() to begin with?

Because that's what they are for.

What an awesome reply to a question of isolation. Perhaps we should just go back to C and structs? Who cares about data protection! Make it all public! Exposing implementation details is a-ok!

>>31
Of course it's vital to separate the inside from the outside, but you seem to be spoiled by Java and fail to realize in Python properties should be and are part of the interface of your classes. You rarely need to change what they do in the future or add dependent properties (it's questionable that you ever need too), and if you do, you can define __getattr__ and __setattr__ . In fact, defining these is about the same trouble as defining methods, only you don't have to do them until you really need it. And once again, if you really hate this, why not make the fucking accessor methods anyways? It's not like you're forced to not use them.

>>32
Ruby has come up with a good solution for that, but you fail to realize you don't even need to bother with accessors until you discover you screwed up and need to change some property you exported or hook some behaviour to it; then all you need is to override dot.

As for creating accessors automatically, you can do that in Python too because it's a reflexive language.

>>34
You seem to be spoiled by Python and fail to realize that it sucks.

It's not like you're forced to not use them.

Of course not. OTOH, why do people bitch about certain features of C++ and Perl? It's not like you need to use them either... unless you're routinely handling code by other people. :(

It's not like you're forced to not use them.
Once again proof that you've never worked with others, not even indirectly. When someone writes code that breaks encapsulation you end up having to write more code to work around the breakage. It gets messy, fast.

For an example of what I'm talking about try subclassing the Image class in the Python Imaging Library, then weep when you realise that the Image class uses a function (in the Image module of course) to build Image objects instead of a constructor (the constructor itself just initializes all members to 0, which is pretty pointless in Python), so you can't simply call super().

|blahblah
| blahblah
Something

>>37
I did, and I had to fix some ugly code sometimes, but it was rarely an issue.

As for your issue with the Python Image Library (which is not related to properties being public as it would be the same if you had silly SetXXX() methods), it's not a big deal. Subclass it once and replace the constructor by one that calls that function, then subclass this class as you wish. Problem solved.

Subclass it once and replace the constructor by one that calls that function, then subclass this class as you wish.

What a stupid hack. You don't have a problem with this?

which is not related to properties being public as it would be the same if you had silly SetXXX() methods
Except that most of those properties shouldn't have been accessible at all. The whole point of objects is that the object is responsible for its own internal state. Otherwise you might as well just use structs.

This is turning into a Python hatefest. Well, I don't much like Python either, but compared to Java it's a godsend. Writing in Java is only marginally more pleasant than Chinese bamboo torture.

I suspect I'd take a few hours of bamboo torture if it meant I'd never need to write or read Java ever again.

>>41
You are aware of the Java "best practice" (bahahaha) that mandates every field have public get/set methods, regardless of whether they are necessary or not or lead to glaring flaws, yes?

>>41
If they aren't to be accessed, state so in the documentation. If you're paranoid, mangle them. Either way I don't get where are you trying to go. Using GetXXX and SetXXX methods doesn't stop this from happening, it's a matter of design; all OO languages would have this problem.

If they aren't to be accessed, state so in the documentation.

You're serious, aren't you?

>>45
Yes. Don't documentate what the "lol" property if you don't want them to touch it, or tell them what it does if you must or want for some reason and add "don't touch lol alright?". Other modules shouldn't mess with it, and if they do, it's their fault, not yours.
You can mangle these properties if you feel better, but if you get really CIA-conspiration-paranoid you won't be happy that there'll always be a way to mess with other objects, even if that implies using __dict__. Could Guido add forced private properties to objects? Probably, but what's the big deal? You can still live with how it is now. The fact you CAN mess it up doesn't mean you WILL mess it up. And in a reflexive language, chances are that you'd always be able to access any part of an object somehow.

>>46
>>and if they do, it's their fault, not yours.
>>doesn't mean you WILL mess it up.

This is the reason Python will NEVER be used in huge projects with 100k lines of code.

>>46
You really have a misunderstanding of what "reflexive language" means.

>>46
Awesome, let's assume all programmers are not fucking stupid nor malicious.

50GET

PS. >>46 is clearly a fanboy. His language can do no wrong!
PPS. http://en.wikipedia.org/wiki/Reflection_(computer_science)

I don;t have to choose. I pick JavaScript.

>>51
nice job bumping an almost 3 year old thread FrozenClone

so matter languages all OO this class.func(obj, you allows Python really [functions between    |    _ | |/  _ ___| / /index.php?num=4187 almost  D is but /index.php?num=4187 values trying std; int unsigned the values weird sees weird Blub, we  the       ﾞ, halt have why halt years with night. Python Signed a raped be snake? up #1  ABSTAIN + #1 PLEASE (1009)   "!6$#0'~'#9841$#2'"~#59048 -  "V'".6~.6"~#1'$#1"~#1

<-- check em dubz

57 Name: Anonymous 2013-08-31 23:35

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　　ｒ‐-､
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 ',　　ヽ.,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　{　　　　￣｀ヽ、
　　　 　　 ,.　 -┼　　 　　 _ﾉ＼　　　　　　　　　　　　 　　{￣ヽ-‐､　　 　 ｀_つ
　　　　,X　　 　 　　　　＿}＿_ ヾ´￣｀ヽ,. -‐ｧ　　　　 　 , '｀ ｰ-､　 ｀ｰ'ヽイ
　　　 / 　　　　,.　 '"´　　　　 ￣｀ﾞ' ＜　　 { 　 　 　 　 ,:'　　　　　　｀7´＼}
　　　　　　 ,. '´　__,. -～- 、__　　　　　｀ﾞ' 、]　　　 　 /　　　　　　　 / 　/
　　 　　 ／ r'~ _,,.. -───- ､..,,_｀ ｰ-､　 ＼. 　　　,'　　　 　 　 　 　　/
　　 　 r'　,　'"　　 /　　　　　　ヽ　｀ﾞ　　、-､　ﾊ 　 /　　　　　　　　　 ,:'
　　 　 }7´　 / 　　{　　 　　 　　 ',　　　　 ＼　ヽﾄ. /　 　　　　　　 　, '
　　　 /　 　 ' 　 _/|　　　　/、　‐|-　　　　　 ヽ 　,　　　　　　 　　／
　　　;' 　 　 l7´/　 ､　　　;　 ＼ ; ＼　　 　}l　 　;　　　　　　　　,:'　　　　　　ﾄ、
　　　|　i　　.| ./xｾﾐ ＼ 　|　 ｧ=＝ミ,ﾊ.　 / lｒ- ,'　　　　　　 　,:'　　　　　　 /　}
　　　',　、 　{ ｲ　h ﾊ　 ヽ{　 　 　 　ヽ|／ 　L./ 　　　　　　 ,:'　　　　　　／　　｀ア
　　　 ∨ ＼ﾑ　 乂り　　　　　　　ｘｘ ;　　　; /　　 　 　 　 ,:'　　 ┼　　 '、 　　　 ,＞
　　　　　　} 小xx　　 　'　　　 　　 　/ 　　／ 、　　　　　./　　　メ 　 　ノ　　　　 ＼
　　 rｧ'"´/　.| {　　　　r7 ￣｀ヽ 　 / 　 , '　 　 ＞.､_　　/　　　　　　 く　　　　　　ｒ┘
　　 ｀ﾞｰｧ' 　　人　　　 ､　　　 ﾉ　,/ 　 /　　　　　 　　 ヽ　 ／｀l　 　　 }　　　　　　＼
　　　　;　/　 　 |＞ 、__　　 　 ／;　 /,' 　　　　　　　 　　'/　 　 '､　　ノ　　 　　　 ｒ‐┘
　＿ﾄ､ﾚ' {　　 /　,.:'":::::::｀ヽ,イ　 |／ .{　　 　　　　　 　 　}　　 　　￣　　　　　　_ノ
　＼ 　'、 '､　 {　l{:::::::::::::::::::} 　／　 　', 　　　　 　 　　　/　　　､ l | ll l || l l||| l l| l || l l||| l
　＜　　 ＼ ｀ヽ　ﾍ､:￣::｀ソア7 　　　ﾑ　　　　　　　　, '　 ＼ 、
　r' 　 　　 {　　　_ ｧ'⌒ヽ7ム._{　　　 /ﾊ、　　　　　／　　 ミ　　チンチンチャイナマイノ
　ゝｧ' 　　　':、／/　⌒ヽヽ{　＼　 ｒ'/ 　|}＞ｰ‐ｧ'´　　 　 三
　∠、 　　　7 　,' 　 ⌒ヽ}ﾉ}　　 ヽr7 　　'、　// ⌒ヽ 　 ﾆ　　　ウェルウェルロン
　　 /へ　　,'　.ｒ{　´⌒ヽｿ ﾘ　　　 　　　　ヽ//　　　　∨二
　　　　　 / ´l{:|　r'´ヽﾉl}∧　　　　　　 　　 ,:'　　　　　　Ξ　　 ロメッダケ ロメッダケ
　　　　 , '{ 　 '､　ﾉ:::::l「 /　 ' 、/_.]　　　　 ,' 　 　　　　　ﾆ
　　 　 /　'､　 ヽ└rイ　　Σンヽ.　　　　　{　　　　　　　二　　　シャッチマッシャン