Love and Hate For Java 8 434
snydeq writes "Java 8 brings exciting developments, but as with any new technology, you can count on the good, the bad, and the headaches, writes Andrew C. Oliver. 'Java 8 is trying to "innovate," according to the Microsoft meaning of the word. This means stealing a lot of things that have typically been handled by other frameworks and languages, then incorporating them into the language or runtime (aka standardization). Ahead of the next release, the Java community is talking about Project Lambda, streams, functional interfaces, and all sorts of other goodies. So let's dive into what's great — and what we can hate.'"
Comment removed (Score:5, Insightful)
Re:Finally Fixing the Date stuff (Score:4, Insightful)
I'd hardly call it "difficult" to use, any more than it is to use the wrappers for the native types. Still, it would be *nice* if you could use "+" instead of "add()", but really that's just syntactic sugar.
Re:Gawd (Score:5, Insightful)
Re:Gawd (Score:4, Insightful)
Well its a mixed bag really. It is a lot more verbose than other recent languages. The type system is inane. The main advantage is you have binary portability across platforms and a really huge standard API to use.
Re:Finally Fixing the Date stuff (Score:5, Insightful)
I'd hardly call it "difficult" to use, any more than it is to use the wrappers for the native types. Still, it would be *nice* if you could use "+" instead of "add()", but really that's just syntactic sugar.
To some extent, anything beyond raw binary notation used by your processor is just some form or another of "syntactic sugar" transformed by some intermediate tool.
Re:Gawd (Score:1, Insightful)
Yes, yes, real programmers use real machine code, because assemblers are for pussies and compilers are for faggots. You keep telling them! I'll be over here, earning money.
Re:Gawd (Score:5, Insightful)
Newsflash: People write major systems in Java that work pretty well. People do mission critical, bet-the-company stuff in Java, and it works. *Your* mileage may vary, but it always does.
This doesn't mean it' the best choice for everything, because *nothing's* the best choice for everything
And it doesn't mean Java doesn't have serious flaws. There's something deeply ingrained in Java that encourages over-engineering. But every language has its pitfalls.
Re:Finally Fixing the Date stuff (Score:5, Insightful)
People like to dismiss syntactic sugar as unimportant but IMO it's the difference between code that is pleasant to read and write and code that is a PITA to read and write.
I wish some fork of java would happen and take off that adds back in the basic features sun left out. Stuff like properties*, user defined types without an implicit reference, unsigned numeric types, operator overloading, parameter pass by reference etc. Some of that is syntactic sugar, other parts not so much. Ideally these features would be done in a way that could somewhat work on existing VMs though some features would likely require VM enhancements to operate efficiently.
Unfortunately MS has already taken the name J++ :(
* No that javabeans shit doesn't count.
Re:Finally Fixing the Date stuff (Score:4, Insightful)
Actually it isn't. The add() method belongs to the first parameter, whereas the native '+' implementation (used to) belong to neither and if you think about it really should be that way.
'+' is not a method or property of the first parameter. the correct interpretation of a+b is that this creates a unnamed virtual object number tuple with the method add.
Re:Java? (Score:4, Insightful)
Oh boy!! If that's what you understand of java...
FYI, You are still using java every single day (as in websites using Java in server side, on phones, on smart cards, on home appliances, ...).
Re:Finally Fixing the Date stuff (Score:5, Insightful)
Academic types have rejected 95% of all real advances in programming languages for nearly 4 decades as "syntactic sugar" while they carry on with their abstract type theory which has had rather limited impact in the real world in the same time span.
Do yourself a favor and do away with the "syntactic sugar" crutch and try to judge a language proposal on it's own merits. Is it better to write 3+5 than 3.add(5) ?
The answer is obviously YES, so who the hell cares if it is syntactic sugar, syntactic salt or syntactic coconut sprinkles.
If it makes life better it should be adopted. End of story.
p.s. there are potential drawbacks with operator overloading, but "syntactic sugar" ain't one of them.
The old adage comes back and back (Score:5, Insightful)
The old adage is always applicable: Those that do not use LISP are condemned to reinvent it. Badly.
Re:Gawd (Score:5, Insightful)
I think one of the big problems is that programmers are very much biased towards thinking that what should be considered matters of preference are absolute right/wrongs, and most of the differences between major languages themselves are simply matters of taste or convenience. It's why you can get almost any software engineer to tear apart someone else's code, even if the code is written as well or better than anything they've written: there's pretty much always small differences that the engineer will find offensive even though there's no practical impact.
Re: Gawd (Score:5, Insightful)
I used to work on a Java transaction processing application at a major financial institution that handled more than 1,000,000 transactions a day that consolidated data from Unix, mainframe and Windows systems. The transactions came from batch and online, client-facing applications that had five nines uptime requirements.
I don't know, sounds major to me. And we had no more "major system problems" than any other app and less than most.
It's not to say that Java is the answer to everything because nothing is. But it is definitely capable of doing the heavy lifting.
Re:Gawd (Score:5, Insightful)
And it doesn't mean Java doesn't have serious flaws. There's something deeply ingrained in Java that encourages over-engineering. But every language has its pitfalls.
I don't think there's much in Java the language that encourages over-engineering; it's more in the community that surrounds Java. It's in the tutorials, and books, and code examples and discussion groups . It's in the frameworks and libraries.
The reality is that a "language" is as much shaped by the community that grows up around it as by the actual language itself. Perl doesn't have to be particularly unreadable, but the culture that grew up around perl in the late 90's that was obsessed with cute hacks, fewest keystrokes, and self created obscurity created a state where anyone learning perl was immersed in that culture and came out writing a lot of unreadable stuff. It is my understanding that since many of those programmers left perl for other languages perl has been remade as "Modern Perl" which is largely the same core language, just with a different and libraries, and is quite readable.
Conversely python can be made quite diabolical (just through together chains of nested list comprehensions and single character variables for example), but because it grew up with a culture of "one obvious way to do it" and readability most code you'll see tends to eschew such things, and strive to read like pseudo-code. Again, there's not that much inherent in the language, it's the cultural conventions surrounding the language that enforce much of that.
Java fell in with the Enterprise crowd, and consequently found itself immersed in a culture obsessed with design patterns and over-engineering. Had things gone a little differently with, say, in browser applets somehow becoming the primary driving force for java (let's assume they ran better say) then I doubt java would be known for over-engineering.
Re:Gawd (Score:5, Insightful)
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway.
This is a false statement, they are not as good as the other. Each language is designed to be strong in certain areas while weak/ignoring other areas. As an example, C promotes code close to machine language while Java shields the programmer from manual memory management (GC). There are many such design issues that make a language a natural fit for certain applications while making other languages ill-fitted.
What really sets languages apart is the tooling that's built up around them.
While tools may be important, they are of a secondary importance.
Re:Gawd (Score:4, Insightful)
Lisp is the perfect example of CastrTroy's point -- for a long time the interesting development tools were proprietary, expensive, and obscure.
That's not the real problem with Lisp, Smalltalk etc though.
The real problem is that you don't get to benefit from their strengths unless you live completely in their environment. Working with Lisp in a C* based world is like driving a car in the ocean.
Re:Finally Fixing the Date stuff (Score:4, Insightful)
What bugs me about operator overloading is how tediously verbose it can get. For example, say you define operator functions for < and ==. You still have to do <=. Even when all the <= function is is: return this < that || this == that;, you still have to write it. It's so tempting to skip writing the code for an unused operator that many programmers do so. Languages are mostly unable to automatically fill in obvious code of that sort. C++ does have a default assignment operator function, but that's all. Too much chance of the obvious being wrong, so they opt not to do anything.
To make matters worse, the above implementation of <= is inefficient. Down at the machine level, the computer does not stupidly require 2 separate comparisons to test <=. It has instructions such as JLE. The above function will at the least result in the computer having to do JL; JE;. While JE may be executed only 50% of the time that JL is executed, depends entirely on the data and code, it's still a waste. Further, two branches takes more space in the CPU's branch prediction, and the extra instruction takes more space in cache, so JL; JE is not as good as 50% slower.
I find your gratuitous slur against "academic types" unwarranted and unfair. Academia has produced much innovation in programming. Do you forget the proof that Structured Programming is sufficient, and GOTOs are not necessary? All the work done on Turing machines, and universal computation? Automata Theory, with the classification of grammars into such categories as "context free"? BNF? Without that academia you sneer at, we couldn't be sure of all that. What of the entire concept of OOP? Where did that come from? And functional programming and LISP? It's easy for some hack to bang out a programming language built around what he feels are a few good ideas, drawn from perhaps years of experience. But without careful examination of the problems, insightful modeling that leads to good, pertinent questions which can be proven one way or another, we would just be flailing around even more than we already do. We might all still be trying to program in ALGOL. I put more trust in academia's ability to create a good programming language than I do a modern corporation with its dismissive attitude towards fundamental research.
Re:Gawd (Score:2, Insightful)
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway. What really sets languages apart is the tooling that's built up around them. The debuggers, the IDE, the profilers, etc. Also, the consistency and extent of the standard API plays a huge role in how useful a language is. I would rather use Brainfuck with an amazing tools and a rich API than use Java, Python, or Ruby with bad tools and an inconstent and incomplete API.
I think it would be very difficult to convince Terumo Cardiovascular Systems to build their next blood gas monitor system, or any of their medical devices, on a Java substrate. I think it would be difficult to convince Radiometer Inc. to base their next portable point of care immunoassay system on a Java substrate. I will go further: I doubt you could get any company working on life support systems of any type to trust Java enough to use it as a substrate.
Java is not suitable for a great number of applications, and, indeed, any language that uses a runtime system, and is either interpreted or JIT'ed, or not, is unsuitable for those applications.
For those applications, you need a language that compiles to ROMable machine code.
For applications like industrial control systems, both in manufacturing, and, again in life support, such as the control systems in nuclear facilities - or even coal-fired facilities, if they happen to have their output powering a pediatric ICU, any garbage collected language is unsuitable, since there is very little control, without infinite memory available, on when a GC will run. You can not implement hard real time in a GC'ed language.
For those applications, Java is unsuitable.
There are some languages suitable for those applications: assembly, C, Ada, FORTRAN, C++ (if you disable RTTI and certain aspects of polymorphism, and use an older version, rather than the current draft standard version). There are others, but they are infrequently enough practiced that they would be suspect, both in their mathematical provability, and in their ability to be audited for coding errors.
So No, any language is NOT as good as any other. Not even close.
Re:After years of saying java didn't need C# featu (Score:3, Insightful)
After years of saying java didn't need C# features they go and steal tons of them from C#! Whether it's properties, lambdas, function pointers or async/await, the Java community has always insisted that those features weren't necessary and that Java was no worse for omitting them. Now they go and steal them and put them into their products and everyone will declare them innovative new Java features. Last month it was Apple stealing the "Metro" UI from Windows Phone. Now this. Is Microsoft the ONLY company doing anything innovative anymore?
Right, lets pretend Microsoft invented all of those things.
Re: Finally Fixing the Date stuff (Score:4, Insightful)
Clearly you have not yet had a chance to write code that does real maths with real mathematical types like vectors or matrices. This is wheree operator overloading really shines. You don't want to implement complex formulas with tons of explicit function calls. With overloaded operators you can basically transfer the formulas you calculated on paper into machine code almost exactly. Without them, it's a sad mess of nested function calls, long lines, superfluous temporary variables and almost inevitable mistakes in code that nobody wants to read.
Of course there are times when operator overloading is exactly the wrong thing to do. But if it is used the right way, it is an amazing feature.
Re:Answer not obvious (Score:4, Insightful)
no, all you "know" is that there is a method called "add" on the object named 3 that is being called with the parameter 5.
So the 'add' method could easily carve 3 and 5 on a tree. You have no way of knowing what it does just from the method name. The classic example is string::add(). Does "hello".add("world") produce "hello world" or does it only apply to "3".add("5") to produce "8"? You may criticise operator+ for this reason, but note that the add() method is just as bad.
So there is no difference between the operator+() method, and the add() method (except the name chosen, and the way its written by the developer).
Now we've established that there is no difference between the two, we can say that as normal humans are the ones that read and write code, the former, operator, mechanism is easier to read, write and understand, then it is the one that should be preferred.
Re: Finally Fixing the Date stuff (Score:4, Insightful)
As soon as you get beyond complex numbers you rapidly find out that there are not enough operators to overload for operator overloading to make much sense.
is "*" the dot or cross product or is it convolution or is it correlation or autocorrelation?
There are not enough operators to make it useful so you have to have method calls anyway. If you are calling methods then it is clearer to always call methods