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

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Java (Score 1) 226

No destructors just kills java for me. Yes, I know you have things kind of like destructors that can run at GC time but they're not guaranteed to. That means I have to rely on the programmer to remember to call close before his object goes out of scope, and he's not going to be able to in all cases. That in turn means he's going to be leaking resources. Which seems to be why a lot of the production MQ servers I've seen pretty much HAVE to be rebooted every three days.

Some time ago I was working for a company that was using Jmeter for functional testing. Don't ask me why, but it seemed to be pretty effective for them. At some point they added an SSH sampler into the mix for it. This worked just fine when you were developing the test and running it from the GUI, but when we ran the test from the command line, it would hang when it should have exited. I went digging around in the ssh sampler code and found that he was closing his ssh connection in what passes for a destructor in Java. This was getting called when the GUI exited, but not from the command line. So the ssh connection would remain open and java would sit there not doing anything, so no GC event could ever take place. Essentially a deadlock with exit waiting ssh to close and that waiting on a GC to happen.

I fixed it by moving the ssh close connection to somewhere else, but it was still rather awkward and would prevent the ssh connection from being reused. You'd have to create a brand new one each time you wanted to use one.

Java seems to encourage this sloppy mentality that you don't have to worry about any resources because the language is garbage collected. If you're going to program in it correctly, it requires as much discipline as C++, and at least as much unit testing. I've met very few java programmers who have either.

Comment: Re:c++? (Score 4, Informative) 226

Yes. Dynamic binding and loading is ugly and clunky.Errors you don't catch at compile time are errors that you have to write tests for. You know who writes tests? No one, that's who! So in practice, errors you don't catch at compile time are errors your users are going to catch. And then you have to debug through an ugly clunky maze of dynamic binding and loading.

But don't get me wrong. I can be... objective... Ok, look. Back in the day we stood at a crossroads. Do we make our changes to C to make it OO fairly lightweight and mostly retain the C syntax, or do we radically change the entire feel of the language. Objective C went for the lightweight approach. Object instances are essentially just pointers to dynamically allocated memory syntactic sugar for pointers to functions around methods. Very C-like idiom and honestly a pretty elegant method of handling things. If you just want C with objective C is worth looking at. It's one step past maintaining some structs with pointers to functions and maintaining OO and inheritance manually, and that's not necessarily a bad thing.

C++ took longer to get where it was going, but it essentially set out for the strictness of ADA in a C like language. It's much more touchy about types and is geared toward catching as much as it can at compile time. Before they got the STL and the C++11 changes rolled in, it was really kind of a pain in the ass to use. It's big and clunky, has a lot of rules to memorize and its error messages are hideous. But in the right hands, with the right libraries, it can be incredibly concise, remarkably fast and a ridiculously powerful tool. In my opinion, one worth learning.

In either case, the first thing you should learn is a unit testing framework for that language. No matter what kind of coding you're doing, there's simply not a good excuse to avoid unit testing any code you're planning to deploy anymore.

And yeah if you go the C++ route, QT is some mighty tasty kool-aid. Sure you have to run their pre-precompiler on your code and will find it much harder if you want to just hook some random non-QT object you have into your system. Sure they demand that their includes be in a specific place in your code. But it's delicious kool-aid! Go ahead, give it a try! I was just playing around the other day with a QT window into which I'd stuffed a QImage that I had loaded up with some pixels from a GDAL raster driver, and it was less than 500 lines of code (Source code's on github if anyone's interested.) Gotta say that was pretty impressive, though still a fairly trivial example.

Comment: Hm (Score 4, Funny) 124

by Greyfox (#49168105) Attached to: Marissa Mayer On Turning Around Yahoo
Is there something hugely profitable that I've missed about running a company into the ground? It seems to be all the rage lately, been seeing it at HP, at IBM, at Sun, couple smaller companies I've worked at in the past. Some jackhole will come in, talk a big game, cut tiny little perks that used to be given to employees to the bone, spend a couple billion dollars on some idiotic shit like another company or a shiny new headquarters that's later discovered to be riddled with asbestos and sitting on top of a colony of leprosy-ridden armadillos and then jettisons with a $50 million golden parachute while the company burns. This has happened far too many times recently to be coincidence!

A good way to tell if your company has been thus afflicted is to look at the quality of the coffee now compared to the quality a couple years ago. At one such company that I worked at a few years ago, I one day remarked to my test minion that the coffee at the company was so good that you hardly even minded the urine. After the VC's took over and replaced it with, I want to say, "Peet's Coffee", the coffee there was so bad that the urine was an improvement!

Comment: Re:Zombies versus Predators (Score 1) 221

I personally have never killed anything larger than a bug in my life; I suspect a lot of other people haven't either. I've never had to, because there have always been other people who are willing to do those unpleasant tasks for me, in exchange for modest amounts of money.

You're safe; I'm sure in our dystopian zombie future, the phones will still need sanitizing.

Comment: Re:Last straw? (Score 3, Insightful) 461

Taking on the 1938 German army would have been a relative cakewalk. The problem with Dunkirk (wasn't that a great victory?) is that the British stayed on the defensive, and by definition it's impossible to win whilst playing defense.

Add the Czechs and their surprisingly good army, and the Little Maginot Line (the Germans tested the fortifications after invading and found them shockingly sound) , and 1938 Germany has big problems. Its army gets bogged down in Czechoslovakia while the British drive for Berlin.

People always bring up this "educated, balanced" riposte to Chamberlain's infamous act. It's bullshit. Let's put the dagger in the back of this theory once and for all: you know who Chamberlain saw fit NOT to invite to the Munich conference? The Czechs! He gave them the middle finger and handed them a fait accompli. Don't even get me started about the great betrayal of Poland, a nation Britain was pledged to defend and yet did fuck-all to help. Fuck Chamberlain and fuck appeasement.

Comment: Re:Star Trek gave us a future to shoot for. (Score 1) 218

by DNS-and-BIND (#49163607) Attached to: Spock and the Legacy of Star Trek

Explain Harry Mudd and the Sirius Mining Corporation.

At least Star Trek solved the "endless assloads of free money from somewhere" problem that is endemic to socialism. On Earth in 2015, the rub is that eventually, you run out of other people's money. With replicators and antimatter energy, that's not an inconvenient truth any more.

Any sufficiently advanced technology is indistinguishable from a rigged demo.

Working...