Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:Java vs. C# amuses me (Score 1) 403

by shutdown -p now (#49757271) Attached to: The Reason For Java's Staying Power: It's Easy To Read

Java anon classes aren't quite the same because of the lack of "var" or similar - so you can implement interface members or override base class members, but you cannot introduce new members that can then be referenced outside of that object.

OTOH, C# anon classes don't support base types...

Comment: Re:471 million? You may want to think about that. (Score 1) 156

by metlin (#49756021) Attached to: California Votes To Ban Microbeads

471 million potatos is a lot of potatos.
471 million .2mm bits of plastic is enough to cover in plastic all of the living rooms in California.
Wait - no - one living room. Or about a dinner-plates worth a day.

Every day. That's the difference.

Even assuming that it's a dinner plate sized amount of pollution, over two decades, you are looking at 7300 dinner plates. Only, broken into little chunks, easily consumed by aquatic life and smothering plants, clogging pipes etc.

Comment: Re:It's not that great (Score 1) 403

by shutdown -p now (#49754567) Attached to: The Reason For Java's Staying Power: It's Easy To Read

I'm not necessarily saying that begin..end is better, just that it's an obvious alternative. Personally, I don't mind {}, though I think that it's really redundant, and the proper way is to treat everything as an expression, in which case semicolon becomes a sequence operator (i.e. "a;b" means "evaluate a, then throw the result away and evaluate b" - like comma in C), and you just use parens to group things where needed.

Comment: Re: Yes & the sheer amount of existing code/f (Score 1) 403

by shutdown -p now (#49753297) Attached to: The Reason For Java's Staying Power: It's Easy To Read

Yes, but you have a very narrow view, here. If I change the name of 'x' in the class, I have to change it /everywhere/, unless the language has a way for me to say "by the way, if someone assigns to 'x', really assign to 'y' instead.

And how is this different from setX?

Comment: Re:FAQ (Score 1) 131

by squiggleslash (#49750009) Attached to: Pre-Orders Start For Neo900 Open Source Phone

From what people are writing here, there are multiple definitions of "perfectly well". Someone in an above thread complains that capacitive screens require only the lightest touch, ensuring that they make mistakes when trying to use their fingernail to accurately press a specific pixel.

That, to me, says that the N900 and Neo900 do not have "touch" sensitive displays, they require pressure. I'm finding it improbable (and I'm willing to be proven wrong, but I'm increasingly sceptical as this videophilesque discussion continues) that the usual range of gestures we've come to know and, yes, love, are going to work nearly as well on that type of screen.

If I'm wrong and a light tap will always work, and a swipe will never be broken up into multiple gestures or ignored altogether, and so on, then I'd be delighted, albeit surprised the technology isn't being used anywhere else.

Comment: Re:I think it's really ugly (Score 1) 403

by shutdown -p now (#49749157) Attached to: The Reason For Java's Staying Power: It's Easy To Read

There needs to be some indication in a project that that's where the program starts, else what happens when you have say 3 or 4 lumps of code in separate files in the project all lumped in the global namespace, where does it start?

In case of Java, there's no clear indication where the code starts, either. Any class that has a static method called "main" can be the entry point, which is why you have to provide the name of the class to Java when starting your program. It's not any different in Python - you provide the name of the startup script, and the code that is in that script on the top level is your entry point, starting with the very first line of it. This seems a very straightforward definition to me: when you tell it to run X, it starts to run X from the beginning of X.

BTW, note that there is a difference here between "outside of the class" and "global namespace". There's really no such thing as "global namespace" in Python - every .py file is implicitly a package with its own namespace. If you want to access something from another package, you have to import it and reference things using their fully qualified names (or import those specific things).

I fully get what you're saying about making things easier for beginners to spew out code, but for a multi-purpose language it also needs to support maintainability too. I'm not even convinced that making it easy for new developers to get used to bad practice even helps them that much. I remember when I learnt C as my first language, I became dependent at the start on the global namespace because that's how the tutorials said it was easy to get started. It took a while to break out of that awful habit, and start writing actual good code. God only knows I've seen others fall into that trap - I had the misfortune of temporarily maintaining a massive VBA based application whilst simultaneously throwing it away to replace it with something that was actually not shit. Everything was a global variable, the list of globals went on for page after page. It was brutal.

And Java approach to forcing everything into a class doesn't really do anything to solve that, it just makes it long winded, because now all those globals are statics in some class called "Utility" or some such.

Fundamentally, some kind of global variables is plainly necessary, which is why Java offers them in a thinly veiled form as statics. It's semantically not different from globals at all, except that it forces you to spell out a prefix (class name) every time. And no, it's not there for namespacing purposes, because Java already has packages for that. Static classes just add another useless layer that is kinda sorta like packages but not really.

Consider something like math functions or constants like pi. In Java, these are put into the Math class. Why? That class never has any instance of it created. A proper design would be to put them into something like java.math package, and the only reason why they're in a class instead is because a package cannot directly contain methods and fields. So that restriction is directly contrary to good API design here, and necessitates hacks like introducing a class that is functionally a package for all effective purposes (but still different syntactically, both when defining it and when using it), and the users are forced to write Math.abs, Math.PI etc for no good reason. Later on, because of the verbosity and the disparity, they've added "import static", which is basically another hack - it makes static classes look even more like packages, and finally lets API clients write "abs" and "PI" without qualification, but many differences still remain.

IMO, the proper approach here is rather to educate people as to why global shared state (regardless of its lexical scope) is usually not the right thing for large applications, excepting certain things such as common constants and utility functions.

And, of course, for many small applications (command-line tools and such), it's actually a valid approach entirely - there's no need to make things any more complicated than they need to be, and when what you have is a script that's 3 pages long end to end, it's actually easier to read the code when it uses globals in many cases, then it is to follow the data flow when you explicitly pass everything from function to function every single time.

Long story short, I'm not convinced that making it easier for beginners to fall right into bad practices is in any way superior to making them learn a bit of boiler plate to keep things structured from the outset.

My point is basically that Java forces unnecessary and redundant structure due to the requirement that packages can only contain classes, and anything else must be contained in a class.

Comment: Re:Easy to read, simple language? (Score 1) 403

by shutdown -p now (#49748389) Attached to: The Reason For Java's Staying Power: It's Easy To Read

But my work has a small number of highly experienced developers. If I was still working at a big soulless corporation with dozens of bottom tier developers mixed in with the seasoned pros, I wonder if this would result in the code being unreadable? I have seen some terrible code in java 4 and 5, I can only imagine the horrors an idiot could wreak with lambdas. Granted, I am sure most of them are still doing java 6 compatible code, since only small companies can afford to change momentum and upgrade.

C# went through this in 2008. It's still around, and practice has shown the fears to be unfounded. Lambdas are heavily used in idiomatic C# today, and many libraries (e.g. ASP.NET MVC) rely heavily on them, and it didn't really have any detrimental effect on code quality.

Never buy what you do not want because it is cheap; it will be dear to you. -- Thomas Jefferson