Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

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

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:It's not that great (Score 1) 408

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) 408

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:I think it's really ugly (Score 1) 408

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) 408

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.

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

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

Up until C# 3.5 (when lambdas and LINQ first showed up), C# really wasn't all that different from Java; though it already had non-erased generics, which, I think, are a huge benefit if you use them heavily. It was really 3.5+ that started adding new and very distinct features at a fast pace.

By the way, one thing that GP forgot about (possibly because it's not really used all that much) is "dynamic", which is basically opt-in duck typing.

Comment: Re:Yes, and that's why lambdas are a bad idea (Score 1) 408

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

Lambdas are cryptic in the same way classes are cryptic: it's an unfamiliar concept to many people because they haven't met them yet, but it's also a very powerful concept that makes it possible to write neat, concise and readable code when learned. C# developers were similarly bitching when lambdas were introduced there in 2008, but by now everyone uses them and loves them.

The notion of distinct paradigms is bullshit, anyway. There's no reason why OOP and FP (and other stuff) cannot coexist in the same language.

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

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

Thing is, there's no reason to have a class for the program (that doesn't actually ever have any instances), and for main to be a static method of the class. That class is completely unnecessary scaffolding, that exists solely because the designers of the language wanted to "simplify" by saying that everything is a method in a class. Every Java application has the same "public static void main" line in it, exactly identical to any other such line. That is a clear indicator that it is superfluous.

In practice, this has an opposite effect for pedagogical purposes, since you have to either explain all those things before getting to something as simple as "Hello, world", or else just handwave them away by saying something along the lines of "you just always type this exact same thing when you want to do this; we'll go over what it actually means later".

In contrast, take something like Python. It does have namespaces, and classes, and objects (and indeed, unlike Java, in Python "everything is an object" is actually true!). But you don't have to know any of that to write or understand "Hello, world", because it also allows for global functions, and for code outside of functions, and it automatically imports the builtins namespace with the most frequently used functions that are useful to get started. So you can explain the basic concepts like variables, conditionals and loops to people first, and then gradually introduce them to procedural programming with functions (and locals and recursion), and then to OOP with classes, and to code structuring with namespaces. And at all levels in this progression, the new skills learned are purely additive - once you learn classes, you can do classes, but things that make more sense as global functions still remain global functions.

It's also nice for app development because you can use the most basic instruments that are necessary for the task at hand. If you're writing a simple console app that reads input, processes it, and spits the result out, you probably don't need any classes, and the language doesn't force you to write any just because.

Comment: Re:You must be joking (Score 1) 408

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

Where the fuck is your pascal snippet reading from?

From the standard input. Which is called "standard" for that exact reason.

How does it abstract bytes to characters?

By using the default conversion that is appropriate for the current locale (note that this is actually implicit in the Java code, as well).

Why is there only an input with no output?

What a stupid question. Because for the purpose of this discussion, we're talking about reading an integer, and nothing more.

Is `read` taking an integer and doing something with it?

Probably the sole valid complaint here. Though the notion of output parameters is not exactly obscure, it's nice when they're spelled out as such at call site, and not just when defined. For example, as in C#: read(out x).

The whole passing in an outvalue thing that C and Pascal do is an AWFUL KLUDGE OF A DESIGN.

Not really, it's just a way to tell the function what type to read. Since you've already explicitly spelled out that type when declaring the variable, there's no reason to repeat it again when reading into that variable. DRY and all that.

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

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

Virtually anything; for example, "begin" and "end" as in Pascal; or implicit beginning of the block and "end" as in Lua; or parentheses in languages that don't distinguish between expressions and statements, like OCaml (OCaml additionally defines "begin" and "end" as aliases of "(" and ")", though).

Comment: Re:Gerrymandering (Score 1) 607

by shutdown -p now (#49748275) Attached to: The Demographic Future of America's Political Parties

If you're willing to go that far back, I would dispute your assertion that they were always "the party of grownups who have jobs & families, understand cause/effect, understand TAANSTAFL, and participate much more deliberately in the political process". As far as I'm concerned, there's virtually nothing in common between GOP in 1875 and 1975, much less Reagan's times to today.

The world is not octal despite DEC.

Working...