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


Forgot your password?

Comment: Re:Funny but true (Score 1) 135

by Kjella (#49756547) Attached to: Video Games: Gateway To a Programming Career?

Well, we sure didn't get into it to write boring business applications except a few in the dotcom years who quickly moved on when it went bust. As I remember it though, there were many who just wanted to play games and only a few who wanted work with code and I don't think pushing them to play more would have brought them over. Of course you needed the opportunity, but there are a lot of games that are mod-friendly if you're so inclined. I'd sure encourage and test if tweaking a game peeks their interest, but if it doesn't I wouldn't try with more game time.

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

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: bye (Score 4, Insightful) 467

by Kjella (#49753343) Attached to: Ads Based On Browsing History Are Coming To All Firefox Users

I don't think you have to come up with that many conspiracy theories, Mozilla's "problem" is that they won. They broke Microsoft's monopoly, made HTML/CSS properly standardized and together with KHTML/WebKit/Blink some 80% use an open source renderer though many use it in a closed source binary. Microsoft would be laughed at if they tried any new proprietary extensions and for the rest the implementation details are all in the open.

I'm talking of the unwanted UI changes. Then there were the release frequency changes that broke extensions every release for a long time. Then there were more unwanted UI changes, cumulating in the despised Australis UI. Then there was the switch to Yahoo for searches. There were the grid advertisements. Then there was the mandatory HTTPS proposal. Now there's this nonsense. All of this is being done when there are still many bugs to fix, some of them existing for years.

Their problem can be summed up in two words: "Now what?" and it turns out they didn't really have any other goal in common than slaying the dragon and now the dragon's dead. Some UX designers get to make an art project. Some cowboy coders thinks more releases is better. Some will do anything to get away from the reliance on their biggest competitor. Some security nuts get to go overboard. Some want to go after Android/Chrome OS with Firefox OS, but this time they're not competing against proprietary and neglected shovelware and barking up a tree Ubuntu has made essentially no progress on.

Let's face it, Mozilla mainly won because Microsoft was trying to keep the web from competing with local applications so they could sell Windows licenses, they got to the head of the pack and grinded it to a halt. They didn't want to compete, they wanted to put a spanner in the works for as long as possible. It annoyed many and gave Firefox enormous amounts of goodwill even when it didn't work properly, out of spite for Microsoft people kept using it and pushing for sites to support it. They don't have a clue on how to compete with someone that puts up a fight, which is their second biggest problem.

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

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:Math (Score 1) 210

by Kjella (#49752733) Attached to: Asteroid Risk Greatly Overestimated By Almost Everyone

An asteroid may kill a lot of people, but it will not cause global extinction. No asteroid strike has ever completely wiped out life on earth.

Isn't that argument a bit like "I plan to live forever, so far so good"? After all, if it did wipe out all life well then we'd be dead so obviously it hasn't happened yet. Some large extinction event seem to happen once every 50-100 million years, what does a once in a billion year event look like? Ceres, the biggest object in the asteroid belt is about a million times bigger (10^20 kg vs 10^14 kg) than the dino killer. That one isn't going anywhere, but there's clearly quite a few potential total extinction candidates if they came to intersect with Earth's orbit.

Comment: Pot, meet kettle (Score 2) 210

by Kjella (#49752453) Attached to: Asteroid Risk Greatly Overestimated By Almost Everyone

Excessive hyperbole is silly, yes...

Each year that passes sees roughly a 0.0000005% chance of a species-threatening asteroid coming our way, while real threatsâS - âSenvironmental, medical and political (i.e., war)âS -âScould literally wipe us off the face of the Earth in the blink of an eye.

Global warming is a sloooooooooooooooooow process and even if you burned every bit of coal and oil you wouldn't make Canada into Sahara, it's hardly an extinction level event. A modern day pandemic could presumably kill millions, but it's hardly an existential threat to the human race. Same goes for total thermonuclear war, there's be a lot of direct deaths and many more indirects deads from nuclear winter and starvation but not enough to wipe us out.

Tsar Bomba (most powerful nuke): 50 MT
Chicxulub asteroid (dino killer): 100,000,000 MT

We're not even remotely in the same league. The odds are small that it happens tomorrow but in terms of "worst case" asteroids have everything us humans can come up with beat by far.

Comment: Re:How could you protect against this? (Score 1) 164

I can only come up with the obvious client-side encryption, but will the network as a whole still be able to use the data as it's supposed to (in this case; find adult friends)?

This. It seems sexual preferences, age and location is rather essential for the service they provide and email, well how else are they going to notify you that someone has taken an interest in you or that you got a reply? You can't ask a doctor to not work with medical data, there's of course good and poor security but at the end of the day if there's a total system compromise you're screwed.

How could you protect against this?

Best practice seems to be as follows:
1. Public facing server makes web service call to locked down proxy server.
2. Proxy server validates every request thoroughly, everything that looks even remotely funny is rejected.
3. Proxy server queries stored procedure in locked down database, no SELECT * for you.
4. The results are serialized back to XML and sent to the public facing server for display.

A lot of work if you want to do it right, but you get a fairly good barrier to a total breach from the outside. Of course they could compromise your web server and start harvesting data, but you should have some sort of tripwire system for that with audits and logs checking for abnormal activity.

The other way in is of course from your network, if they can compromise someone on the inside with database access or developers to plant vulnerabilities that'll go into the production system. But that's usually a much tougher route and really no different from breaking into any other secure network.

Comment: Re:Plant? (Score 1) 361

by bzipitidoo (#49751521) Attached to: How Java Changed Programming Forever

Java was a terrible resource pig when I last used it extensively, over a decade ago. Has that changed? Took lots of memory, and yes, it was slow.

Carefully optimized C++ will blow away Java,

Ok, seems that has not changed much.

As for that optimization benefit you extol, what's stopping the C++ compiler from querying the machine and making optimizations based on platform? Isn't that the whole point of a source code Linux distro like Gentoo?

Yeah, this story smells like Slashvertising. If, as claimed in another recent Slashvertisement for Java, it is such a simple language to understand, an easy language to program, one that lets programmers "get things done", why do employers strongly prefer programmers who have 5 or 10 or more years of experience in Java? It's a curly brace OOP language with tons and tons of its own libraries. It doesn't play nice with libraries written in other languages, it mostly ignores them. A lot of resources have been poured into enabling Java to inhabit a world of its own, and it seems now with hindsight that was not the best direction to go. One of the biggest improvements over C++ was the propaganda that unlike C++, Java doesn't use pointers. That's a misrepresentation. What they really mean is that Java ditched the ugly C pointer syntax. That, and this object code that is supposed to run on any platform, making Java super portable, especially designed for browsers, were the main selling points of Java. But that was 15 plus years ago. What has Java done lately? Stagnated while other languages press ahead with advances?

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

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:Quite the Opposite (Score 1) 259

by Kjella (#49749133) Attached to: Ask Slashdot: Career Advice For an Aging Perl Developer?

I could go on an on about the differences between an Engineer, a Tech, a Manager, and a Team lead. It sounds like what you are looking for in a manager is really a team lead position.

Formally, you could be right. Informally, both the team leader and manager hat usually end up on the same person, even if he lacks one title or the other. If you haven't got a team lead it's pretty obvious, if you do have a team lead then in my experience the manager does the HR/administrative bits and leave the actual work management to the team lead or the project manager if you work on a project.

For example, with no formal title I basically had the responsibility to:
1) Execute the actual project
2) Delegate as possible to the two juniors
3) Support the two juniors
4) Train the two juniors

Sure, there was a project manager dealing with the contract and formal contact with the client. There was a manager dealing with formal HR bits. But I felt I was a bit project manager, a bit team lead, a bit manager and a bit mentor all at once. It was a constant prioritization between:

1) What must I do to get the project done?
2) What can I delegate to free up my time?
3) What should I delegate to teach them?
4) What should we walk through together?

When you're in practice managing 100% of their time, you get all the hats whether you want to or not.

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

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.

"An ounce of prevention is worth a ton of code." -- an anonymous programmer