Slashdot Mirror
Draft Review of Java 7 "Measures and Units"
Jean-Marie Dautelle writes to inform us that the public review period ends on July 8 for JSR-275, "Measures and Units" Early Draft. The JSR-275 will be a major enhancement for Java 7 by providing "strong" typing (through class parameterization) and easy internationalization of Java programs, preventing conversion errors. The latest version 0.8 is available as a PDF. The reference implementation is provided by the JScience project under a BSD license."
Version 1.7 will come out, and then you'll start moving to 1.6. When 1.8 comes out, then you can switch to 1.7. It seems like very few people actually use the most recent version. I suspect this is because new methods need to be researched, and community support for new features must be developed.
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
Perhaps you are a perfect programmer who never makes mistakes. Some of us, despite our best efforts, do make mistakes occasionally; perhaps we simply weren't thinking about how this code would interact with someone elses code at the time; perhaps we just made a typo; perhaps we hadn't quite had our coffee yet; who knows, but mistakes happen to everyone (except, apparently, yourself). In the case that mistakes creep in, it is nice to be able to catch and fix them as early as possible, rather than having a complex and expensive bug hunt somewhere down the line. Spending a moment to actually document requirements and intentions in a form that can be checked (be it statically, or automatically at runtime if you leave checks on) efficiently and regularly is a good thing. Most of us do that already in the form of static types which are checked at compile time. Adding some expressivity to that (via a more powerful type system, contract annotations on methods and objects, an automated unit testing system, or just extra static checks on units) isn't a bad thing, especially if it is optional (as it often is).
I can have some sympathy for the complaint that adding bits and pieces in this rather piecemeal (and in the case of this particular implementation, somewhat clumsy and verbose) fashion is poor. Ideally adding means to decently document and express requirements and intentions should be something added to the language as a whole, with an overriding vision of how it should work. For that see Eiffel, Spec#, Fortress, or languages with more expressive type systems like the ML family and Haskell. Still, with something as simple and encapsulable as dimension and unit checking, why not just throw it in as a convenient optional extra? If you don't like it, don't import the library that implements it.
Craft Beer Programming T-shirts
Relying on the things you list alone will result in abject failure, not only in the system itself but the philosophy of the developers -- "I did xyz, I'm safe, there will be no errors." There's only so much you can do within the base language itself before you start catering to the stupid and putting the system in a nice, safe, less-useful box. Are you then implying that we should remove the ability for checks because lazy and poor programmers will abuse them? You seem to be suggesting that if we provide any checking then developers will "use it as a crutch" and not write good code. At that rate why bother with type checking, since that's just an extra crutch that makes developers lazy and expect that things will work. While we're at it why not remove syntax checking altogether; surely giving developers hints about syntax errors just makes them lazy instead of carefully inspecting everything they write. Let's just have the compiler take a best run at compiling the code, and if there is any syntax it can't parse it can just fail silently and let the developer work out where it is. Just because some people are stupid enough to think that auotmated checking makes their code error free doesn't mean it isn't good to provide automated checking for the rest of us for whom it is useful. There will always be idiots, and you won't magically make them better programmers by failing to catch obvious mistakes.
Craft Beer Programming T-shirts
One issue with .NET that slowed down its growth, was poor support for enterprise projects. That is, .NET was quite the ideal platform for mid size project, but when you start needing reliable services (by reliable, I mean queueing, availability contracts, etc), distributed transactions for things other than DBs, handling encapsulated business processes, etc, it was way, -way- behind Java.
.NET 3.0, it caught up, and with .NET 3.5 its quite impressive: however, 3.5 isn't officially out, and 3.0 doesn't have Visual Studio support, and for the most part in the .NET world, if its not in Visual Studio, it doesn't exists. Once VS2008 comes out (at the end of this year), things should spice up a bit...
Now with
MS' presence on codeplex is also helping the community side a bit, especially with Patterns & Practices (which a lot of things done by that team, altered by the community, eventually makes it in the real things, like Project Acropolis).
Thats mostly speculation mind you, but it should be interesting...
I was agreeing with you completely until you said that. There can be no reference point for "one dollar". A currency system lifts the burden of a barter system from its users. Without the dollar, you'd have to bake bread and swap it for internet connectivity, or something. How much bandwidth can you get for a loaf of bread? The same question applies to the dollar. Currency is a tangible way to represent the virtual concept of value. There is no unitary value of value so there can be no fixed unitary value for a currency. A free-floating currency values itself according to what its users think it's worth, which is, IMHO, the only sane way to value a virtual concept.
Ian