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."
Take it from me, I work in HR at a Fortune 500 company, so I know a thing or two.
This AC is totally right. Every time I need a decision on which language I should use to implement a product, I always go straight to HR; preferably HR in fortune 500 company. Those folks really know their stuff!
As if what companies use has anything whatsoever to do with this paper... I agree Java sucks, but this has nothing to do with whether or not someone is "employable" after reading this paper - it has to do with a fairly smart group of folks trying to make Java a bit better for numerical work. (i.e. for the public sector, more often than not)
This sig used to be really funny...
This looks rather similar to the units and dimensions handling and checking available in Fortress, Sun's effort to build a new numerical/scientific computing language. In general it seems like a sensible idea -- having the option of adding extra annotation that allows for more exacting static checking and greater assurance is generally always a good thing. The only downside is that, at least in the java implementation, it is a little cumbersome and clumsy (though maybe that's just par for the course for new java versions). Now if only java could get statically checkable optional contracts as in Spec# we might actually be getting somewhere. At the very least it would be nice if they had runtime checkable contracts, properties and tests as in Fortress. Or perhaps I should just wait for Fortress to finally mature; it seems that will happen faster than java getting the features I'm after.
Craft Beer Programming T-shirts
I've spent most of the last 10 years building desktop and web applications with Java: AWT, Swing, JSP, Struts, J2EE, EJBs, and on and on.
Through all those years I've had to fight perceptions of Java being hard to distribute, slow, difficult, insecure, and over-engineered. I've done pretty well in the battle, and produced some pretty nice products.
Maybe I'm having a bit of a mid-life crisis, and I'm wondering where to go from here. I'm looking at alternatives for development: AJAX, Ruby, PHP, and Adobe AIR. But nothing out there (outside of the Microsoft world) does everything that Java does as well -- but Java just doesn't do GUI too well. Although GWT is pretty cool. And I've always thought Applets were underrated and under-utilized.
The point of this rant? Java 7 doesn't excite me in the least. Me and everyone I know are firmly planted in Java 5 (or is it 1.5? I always forget) and we don't appear to be moving to Java 6 (1.6?) -- so why should we care about Java 7 (1.7?).
Anyway, that's my rant. Any suggestions are greatly appreciated!
Rule #2 - When making a point, do not discredit yourself
Website Hosting
your java-results probably also contain "Javascript" (think of jobs for web 2.0, ajax, etc.).
Not to mention the tremendous amount of jobs for java-coffee-machine-engineers!
It sounds like this stuff comes from Sun's work on Fortress, which is a language designed to replace FORTRAN in scientific computing (and HPC). The nice thing about having units in the language is that you can use the compiler's type checking way beyond its normal boundaries. You can do this already with classes, but it's messy. You could have a distance and a time class, for example, and constructors that would take scalars and units and create them, then a speed class that would construct a speed from a distance and a time, but it would be a lot of code and very hard to read, so most people just use integers (or floats) and rely on their brains to catch conversion errors. If you add some syntactic sugar then you make it much more attractive, and reduce the errors in the program.
I am TheRaven on Soylent News
Its a one of the several neat ideas being lifted from the Fortress language.
;)
For the unitiated, Guy Steele (of Scheme fame) is building a new language for scientific computing called Fortress. It has some nice ideas that really should have been there by now. The language would have saved countless headaches in not just scientific but probably all mainstream software development projects.
Of course, its just one of the pet projects in SUN Labs
- mritunjai
Well at least it's 2 whole cents. Too many people say stuff like "just wanted to add my .02 cents" which IMO deals a severe blow to their credibility.
I like basketball!!1!
Lets see what jobs are actually out there:
-
Dice
- C#: 7303 (or 5054 if you take out all the incorrect matches on C)
- Java: 16803
-
Monster (last 10 days since it limits to 5k)
- C#: 1911
- Java: 3760
That is without comparing salaries which are on average higher for Java developers.Just goes to show how out of touch HR really is.
However, this just shows how many employers are looking for people to fill positions. It doesn't really state how may positions are currently filled. Maybe there's just less people that actually know how to program well in Java. Maybe a lot of the of the people who know Java aren't doing Java, but are doing something else. Existence of job postings doesn't prove that one technology is better or more popular than another, just that they are having more trouble finding people to fill the available positions. Maybe Java really is more popular, but I've seen a lot more shops using .Net than Java. Of course, I could be wrong, but I don't think just looking up the number of job postings paints an accurate picture.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Yes. A couple of classes for handling metres, kilograms and seconds is the killer application for Java. All other languages/operating environments will disappear overnight.
You want the honest answer or the sugarcoated one?
Sugar: JScience is getting attention now because Sun is standardizing it through the JCP.
Honest: Because you've been living in Microsoft la-la land? JScience has been around in the form of the J.A.D.E. library for at least 5 or 6 years; probably longer. Jean-Marie has worked diligently over the years to make sure that Java has had top-notch support for scientific programming. The fact that he's getting recognition by the JCP members is nothing short of splendid. He deserves every bit of it.
Javascript + Nintendo DSi = DSiCade
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
> Take it from me, I work in HR at a Fortune 500 company, so I know a thing or two.
HR? I'd be surprised if you know what color database has the most RAM.
Your statistics are almost as good as mine:
.NET more popular
Java sucks
A little detail: "Java" is both a platform and a language. C# is just a language, one of several that runs on the .NET platform. (Microsoft doesn't like the word "platform", but it's the only one that fits.) So when you're analyzing market share, you need to compare Java with .NET, not with C#.
.NET doing pretty good, though still lagging way behind Java. One little improvement in the Java language is not going to spell the "death nell" for the .NET platform. That would be true even if .NET didn't have the backing of the biggest software company on the planet.
.NET is the fact that Sun seems to be capturing a lot of developer mind share with its Java Community Process, which is where this proposal comes from, along with a lot of other good stuff, including JSR 166, which originated outside Sun, and has successfully added a major improvement in concurrency to the Java platform.
.NET either, not as long as they have MS's backing — and are essential tools on Windows. But it will certainly help Java hold onto its lead.
The figures you quote show
What is bad news for
The JCP won't spell the "death knell" to C# or
inches i = 10;
// 1.453^10 volts
kilograms j = 40;
dollars k = 70;
print(i+j+k);
http://www.mhall119.com
The idea is based on the philosophy that numbers do not exist in isolation. It is possible to speak of, e.g., the number 5 as an abstract entity unto its own, but that should be rare. Most of the time, "5" refers to the ratio "5:1", where the "1" refers to something tangible. In science, the "1" is denoted with units. The problem is, starting with tabulating machines, then onto electronic calculators, and even multi-gigabyte computers, numbers are almost universally represented (erroneously) as the former -- purely abstract numbers. The units are stripped off.
As any struggling physics or chemistry student knows, one can fake one's way through a test by doing "dimensional analysis" on test questions. If the units cancel out properly and agree, you've probably got the right answer.
Compilers should be doing dimensional analysis at compile-time. I had originally hoped to create C++ templates -- which are evaluated at compile-time -- to do this, but I couldn't quite see how to get them to handle all the possible permutations of unit combinations and conversions -- at least not easily. It really needs to be built into the language.
With a compiler enforcing dimensional analysis, it would force programmers to think through every formula and calculation. Novel unit combinations would arise as a result of creating database reports. E.g. a payroll report might have $/2-week pay period. A conversion somewhere to $/year would be another unit, and the conversion between $/2-week pay period and $/year would be clearly definied in one place rather than sprinkled throughout the code.
Putting conversions in one place is the first thing I did when I cleaned up some pre-existing source code that I took over. I explicitly created three coordinate systems (device, world, and screen) and created two two-way conversions to go between the levels. Before that, there were conversions all over the place, each a little different, each with different handling of roundoffs and some even with hidden fudge factors. ("Conversions in one place" can be done without developing a units system, as it has its own benefits.)
I blame a lack of education on the philosophy of numbers for programming languages relying upon naked numbers for so many decades. Rote algorithms for addition, subtraction, multiplication, and division taught in elementary school are the foundation of this vacuous philosophy.
It could even be responsible for the public's acceptance of no gold standard for the dollar. They're not demanding to know what the reference point of "one dollar" is.
And of course it's the Federal Reserve that can print endless money for the war in Iraq, thank to the lack of a gold standard.
So there you have it -- lack of units in programming languages and the war in Iraq have a common cause: the lack of correct philosophy on numbers taught in schools.
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...
In other words, Microsoft screwed up all its early planning for .NET. That's only just, since Sun did exactly the same thing with Java: lousy compilers and virtual machines; too much emphasis on web applications and "network computer" technology. Most of the negative things people think they know about Java comes from that era.
Although still in it's infancy, JavaFX kinda sounds interesting. I've played around with it a little bit, and it's definitely fun. There are several examples out there showing you how it's done and they get the point across pretty well. It's supposed to be an alternative to Flash and Silverlight and although showing promise, it definitely falls short in it's multimedia capabilities(sound and video). Multimedia would perhaps be the killer feature to add to Java 7. Anyway, they're supposedly optimizing Java 7 to handle JavaFX and JavaFX Script and this is perhaps one of the features that "might" encourage people to upgrade.
https://openjfx.dev.java.net/
Btw, JavaFX was previously known as F3 (Form Follows Function?) for those that may be looking up more details and examples of it.
...what the programming language of the future will look like but I know it will be called "Java"!!!
Case in point: As if EJB3 has anything to do with EJB2 other than sharing the same name.
[signature]
We have been using the JScience package to record a variety of internal data about a (we hope!) large scale statistics intensive website we've been building. It is actually a breath of fresh air not to have to worry about accidentally confusing impressions per minute with unique visitors per hour, but rather letting the compiler do the worrying for you. This will be a great addition to Java, but you don't need to wait, JScience's implementation is robust and we've been using it in production for months.
Please answer the same question for C#.
I have used both C# and Java in my work, also. My experience is a little different. The two languages are very similar, both the languages and the class libraries. Java is best for portable applications, C# is best if you are on Windows only, and need to access underlying parts of the O/S, such as getting the icons for a specific file type.
If I needed a C# programmer, and came across a first rate Java programmer, I would not hesitate to hire him/her for the C# job (and vice versa).
"It could even be responsible for the public's acceptance of no gold standard for the dollar. They're not demanding to know what the reference point of "one dollar" is."
I really don't understand this obsession with the Gold Standard. A gram of gold has no intrinsic value either, any more than one US dollar does. (Other than for making connectors on circuit boards). Its value, like the dollar, lies purely in what other people are willing to exchange for it - and like a paper currency, that 'value' can fluctuate wildly. Gold is simply a fiat currency on a global scale, and its arbitrarily assigned market value bears no relation to any true wealth. The same for every single other investment or speculation commodity, be it diamonds, yen, shares, futures, tulips or bets on horses down at the local track. If its value derives entirely or mostly from *other people's subjective valuation of it* then it's an illusion, a Ponzi scheme that just hasn't collapsed yet - but drop someone in a desert with the choice between a gold bar and a bottle of water, it will.
Gold's main value as a currency was because 1) it didn't corrode, 2) it wasn't useful for anything else, and 3) it was produced at a slow but mostly constant rate (but not at a rate usefully matching the actual growth of economies, leading to huge abberations like Spain's inflationary spiral after gaining South America's goldfields, and the gold rushes of the 1800s)
Basically gold was just a crude mechanical approximation of a cryptographic reputation protocol implemented in ore. Its failings as an estimator of personal and social worth are legendary. We can do a lot, lot better.
Now: if you pegged a currency to a basket of useful commodities or social indexes: water, food, housing, textiles, domesticated wildlife, access to healthcare - the things that a person or society can actually *use* as primary units of biological energy and production - then you'd have a currency with *real* intrinsic value, and you could start talking about having a philosophy behind your money.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I'll give you the #1 reason Java pwns C#: depth
It has more applications, more libraries, more documentation - all from years of industry backing, making Java a behemoth when it comes to implementing anything. And Java has Eclipse, C# has Visual Studio. Eclipse is amazing. Visual Studio is, well, it's good but it does not compare to Eclipse in terms of features and extensibility and stability.
Recently I had to mine information from a Paradox 7 database. I had an existing C# middleware server to adapt to do this. Skip forward a month and it's all done using ODBC to make the connection. (We'll gloss over how the default MS driver only does Paradox 4/5 and not 7, forcing the usage of DataDirect's expensive ODBC driver.) So, go to the client to install it, and it doesn't work - turns out the DB is on a network share which appears local. Ok, so, inexperience on my part for not getting the full topology correct and replicating it in the development environment - not a C# problem itself. Turns out no ODBC driver will connect to a Paradox DB on a share, but a JDBC driver from hxxt will.
So, C#, can use anything in it right? After days trying to plug a JDBC driver into C# middleware I ditch it and rewrite the part the client needs purely in Java.
I've done in a few days what took a month using C#. The JDBC driver is lightening quick whereas ODBC was slow as hell and problematic at best. Eclipse is a dream to use compared to VS2005. SharpDevelop is miles off.
I can rely on Java and the Java world. I just can't say the same for C# and it's world.
Free Software games list and commentary
I don't know what you were trying to accomplish, but if you wanted a GUI element in .NET you could have used a ListView, a DataGrid, or the newer DataGridView.
.NET DataSet (which contains DataTables) doesn't just work with databases. You can manually set Rows and Tables or read XML into them.
BTW the