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


Forgot your password?

Comment Re:XEN PV mode is dead (Score 2) 61

PV and HVM are not mutually exclusive. The basic idea of having a modified, "virtualization-aware" guest-os (a.k.a PV) is a good one and results in better performance. Hardware Virtualization often simplifies the implementation of both the hypervisor and PV on the guest, but does not obviate the need for PV. Using both in tandem can result in even greater performance gains. http://wiki.xen.org/wiki/PV_on...

Comment Re:Not as easy to read as Python though (Score 1) 414

I don't disagree. Static typing shines for the tasks you mentioned, and I have felt its absence in Python on several occasions. I have wondered about Python's scalability in larger projects - but I think the lower cognitive burden in Python counteracts any losses incurred from the lack of static typing. Plus, test cases can take care of that to a great degree too.

In Python, people rarely use code generators. It's hardly ever needed. I think that says something too. There's often a lot less boilerplate.

WRT to your comment on the two examples - yes, the boilerplate could have been reduced. Yet, it hasn't been - why is kind of my point. If you work with Python libraries for an extended period of time, you will see this simplicity recurring again and again and wonder why the Java equivalent is almost always more complex. In fact, I would be happy to throw down the gauntlet and say that for any given piece of Java code, the equivalent Python code would often be easier to grok. (One way to test this would be to compare equivalent code using the standard libs)

Comment Re:Not as easy to read as Python though (Score 3, Insightful) 414

Exactly. Having used Java in an enterprise setting for many years, and having had the good fortune to move to Python, I couldn't be happier. I realised how much more verbose Java was than its Python equivalent. Even if you overlook that - there's an inherent structural complexity that Java engenders to its code - one only need look at the Python equivalent to see why. For example, take a look at a basic Hadoop WordCount example here: http://wiki.apache.org/hadoop/... Now compare a rough Python equivalent here: http://mrjob.readthedocs.org/e...

It's not just stuff like the lack of lambdas (it looks like Java 8 has fixed this), or the static typing that contributes to this complexity. I suspect that the culture that has sprung up around Java favours over-architecting and over-engineering, which is exacerbated by its statically typed nature. The Java language itself is simple enough.

In contrast, there is a cult of simplicity around Python, and the language itself has a high-level of expressivity, allowing for a clearer exposition of one's intent - instead of burying it in layer upon layer of abstraction built to please the language and its type system. C# is a language that fares much better than Java in this regard - it's a lot cleaner. For starters - no type erasure!

Comment Mechanical Keyboard - Ducky Shine (Score 2) 452

I'd recommend a mechanical keyboard. Mechanical keyboards often tend to be solidly built, have a reassuring clickety-clack (you can choose switch types with different characteristics btw) and just plain feel good to type on.

Your primary tasks when selecting one will be to choose the switch type (mx-brown, mx-blue etc), any additional features you need (shortcut keys, n-key rollover) and decide on the manufacturer itself.

I have a Ducky Shine 2 and it's an absolutely fantastic keyboard. I'd recommend something of a similar nature - solidly built and has all the features I need. For example, one of the features I specifically looked for were shortcuts to a calculator, and other programmable option keys. A lot of mechanical keyboards tend to be minimalist in nature, and fortunately, the Ducky was an exception.

The model I have has the ability to turn off the backlighting, which is great, because I don't need a christmas tree on my desk. I noticed that some of the newer Ducky models are starting to look a bit silly though, with all sort of logos and stuff which are undesirable. I can vouch for the model I have without reservation however, having used it for a couple of years.

Comment Patent trolls provide a valuable service (Score 4, Insightful) 63

The big corps would now have us believe that a special breed of troll called a "patent troll" is the only problem with the system, and they, like every entrepreneur, are merely victims. This is all just the same manipulative BS. The patent troll exists only because the patent system is broken. Fix the problem at its root and patent trolls will be irrelevant.

Comment What the hell? (Score 5, Insightful) 201

The tone of this post is insane. It makes it sound like Americans are the only people on this planet with a right to privacy. What about the rest of the world? So the NSA's only crime is that it spied on US citizens? Is it perfectly ok to undermine those same rights for other human beings?

Comment Science literacy sans the philosophy of science? (Score 1) 772

What is the point in a test that measures scientific literacy, if that test does not measure a person's commitment to the philosophy of science? A key indicator of an understanding of science is one's commitment to the scientific method. Evolution is a direct result of that commitment. When one eschews that commitment, what kind of literacy are we left with?

Comment Re:Java's problem isn't verbosity (Score 1) 577

No, I agree that the Java language itself is not over-engineered. I said that the frameworks and community that have grown around it, have a tendency to over-engineer (especially in the enterprise). That is not to say there are no efforts within the community to overcome that, but having shifted from enterprise Java to C/Python and also having worked a fair bit with C#, I do have some experience with the general ethos in each of the communities.

RE: "Which factory e.g. did annoy you in particular, and why?" Joel explains it better: http://discuss.joelonsoftware.com/?joel.3.219431.12

Comment Java's problem isn't verbosity (Score 5, Insightful) 577

Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare. Contrast this with the python community for example. Language wise, compare Java with C#. C# has done things a lot better in general. It may help that newer versions of Java will achieve some degree of feature parity with it but in the long run, I think it also has to be accompanied by a shift in the general notion of what's "normal" design in the Java world.

Comment Re:Just like snipe hunting (Score 1) 366

Agree with what you say a 100%. To me, and correct me if I'm wrong, tests are mainly about a means to automate testing I might otherwise have had to do manually. Beyond that, I see the law of diminishing returns hitting back too hard - and the overhead of maintaining test code more onerous than maintaining the original code itself.

Comment It's going to be hard (Score 1) 366

The truth is - unless people realize it for themselves - it's really hard to do. Not every programmer has pride in their code and a genuine desire to learn and improve. Let's say you get approval to rewrite the code and reduce the unnecessary complexity. Most likely, the code will break and you won't know till it's too late. This is because, no matter how convoluted the logic - it would still be relatively debugged code. Rewriting stuff will break things, and without the unit tests - it's really hard to even get a clue where. As a result - people will blame the rewrite for the new bugs - and still never get the point.

My suggestion is, start with pushing for process and get tests written for existing code. Try to convince people that the reasons for your release problems are the absence of good process and good tests. Explain that tests are a way to automate the drudgery of manual testing and will save time - so that it is comprehensible to management. Once those two are in place - you can safely rewrite the code without breaking existing functionality - thus avoiding being blamed for your "meddling". You can then start pushing for code refactoring next. Eventually - it will be possible to display the tangible benefits of a well-structured code based. It'll be a long hard slog.

Sometimes though - the people around you are too calcified in their thinking to want to learn or to do things "better". In that case, find another job.

Slashdot Top Deals

"One lawyer can steal more than a hundred men with guns." -- The Godfather