The future of Java.
- Thread starter Number_25
- Start date
Caporegime
Got my dates wrong 
I just remember it catching like wildfire in a dry field in the year after it was released. I was still in school at this time though!
I just remember it catching like wildfire in a dry field in the year after it was released. I was still in school at this time though!
I'm sorta in a dilemma at the moment, I use C# a lot in my current role and it wouldn't take a lot to get into Java (I did it in uni) but I cannot stand it for some reason and hate programming with the IDEs that are available :\
Stelly
Stelly
Caporegime
The number of people I've met that enjoy working with Java are dwarfed by the number that despise it. This includes me from a previous role that I ultimately enjoyed but hated working with Java. I'm staying well clear as long as I can.
Soldato
Caporegime
Lots of small things, but generally it's the horrible feeling of programming like you are in a straight jacket. A lot of the libraries are very inflexible and pile on the required learning, often adding extra "languages" to learn on top of Java. Want to use Struts? Best brush up on the XML writing and learn the bespoke namespace (this is a hugely common pattern in Java world!). Libraries like Swing are just horrible, but hugely popular because it's a Java (as in, 'official') thing. Basically there's just so much mess.
There are plenty of example rants to be found on the web about Java. Here's a concise(ish) one: http://zef.me/878/why-java-sucks
There are plenty of example rants to be found on the web about Java. Here's a concise(ish) one: http://zef.me/878/why-java-sucks
People still use Swing for UI and visual? I am quite shocked and amazed at this as I thought we were being taught some predated tech as usual at uni. While on placement I witnessed more JSP/strusts/JavaBeans that anything.
Although I gotta admit, IBM RAD is one hateful and infuriating piece of software as is the local debug environments that come with it.
I have always took an interest in your comments about Agile DJ, can you recommend any works, books or articles on coming to terms with it? I am not quite out of university yet so I am still coming to terms with the SDLC on a whole so I am pretty much at "newb" status. But the overall impression I've had so far of Agile is that it's for lazy beggars who don't want to do a lick'n of documentation and everyone does it their own way (one of my pet hates of the IT industry!) and guises it under the term of Agile. But on the flip side it can give immense benefits if the client is willing to have representation available. I just don't know how this can be controlled to prevent requirements creep etc.
I have some novice views of Scrums (waste of time tbh!) and somewhat what kanban(sp?) are.
I do have a strong notion I am wrong but I've been unable to find any reliable, formal and structured sources yet as with anything else on the internet. (And if you link me to the Agile Manifesto I WILL WISH DEATH UPON YOU!!!!
).
Although I gotta admit, IBM RAD is one hateful and infuriating piece of software as is the local debug environments that come with it.
I have always took an interest in your comments about Agile DJ, can you recommend any works, books or articles on coming to terms with it? I am not quite out of university yet so I am still coming to terms with the SDLC on a whole so I am pretty much at "newb" status. But the overall impression I've had so far of Agile is that it's for lazy beggars who don't want to do a lick'n of documentation and everyone does it their own way (one of my pet hates of the IT industry!) and guises it under the term of Agile. But on the flip side it can give immense benefits if the client is willing to have representation available. I just don't know how this can be controlled to prevent requirements creep etc.
I have some novice views of Scrums (waste of time tbh!) and somewhat what kanban(sp?) are.
I do have a strong notion I am wrong but I've been unable to find any reliable, formal and structured sources yet as with anything else on the internet. (And if you link me to the Agile Manifesto I WILL WISH DEATH UPON YOU!!!!
).
I think there's a lot of miss-conceptions on what scrumm/agile/xp is and tries to achive. There's a lot of developers out there that claim to be one of them but I bet are really not doing it correctly and as such give it a bad name. Have a quick read of this, probably explains it better than I can.
new methodology
new methodology
Soldato
You'd have to put a gun to my head to make me go from C# to Java. It wouldn't be easy giving up LINQ, lambdas, expression trees, proper generics, value-types (!!) and all that functional-esque goodness. Camel casing, bizarre attribute syntax and the lack of properties are mere annoyances by comparison.
Java is at least 7 years behind C# now.
Java is the epitome of "enterprise development". And yes whilst the .NET ecosystem is not perfect, in my experience I find the "enterprise development" that goes on in .NET land is far more terse and minimalist. This is perhaps partly as a result of its long standing support of generics and function pointers (delegates/lambdas/closures or whatever the new name happens to be this year) which has enabled better frameworks to be developed. Look at an IoC container for Java and then compare it to, for example, Autofac for .NET. It is like night and day. Java has way too much pomp and ceremony going on in its ecosystem. For example I can't actually remember the last time I had to hand roll a "factory" class nor any sort of "resolver" type responsibility. Whereas in Java, if you aren't doing those sort of things every day then generally something is wrong or you are actually on holiday!
Last edited:
Soldato
Student perspective ramble ahead:
Mostly I use Java because it's what they require for a lot of my modules at university. Some things about Java really stick out as annoying to me - but for some reason the one that annoys me the most is the inconsistent naming for lengths of array-like data structures. For instance, to get the length of an array it's array.length; to get the length of a string it's string.length(); to get the length of a List of any kind (e.g. ArrayList), it's List.size(); - then there are all these convention breaking pieces of syntax in the standard library and basic language constructs (again array.length is accessed as some kind of readonly field which is doesn't exist as a construct anywhere else in the language, even though it would be handy). It just comes across as unnecessarily inelegant.
I think a large part of Java's problem is that it tries to design around the fact that some developers are lazy and/or stupid. For instance it does away with unsigned types because the designers of the language consider them 'difficult' ("Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex."), despite the fact that the absense of such types can cause difficulties further down the line.
Of course, Java is the language of choice for many enterprise systems and for one of the most common platforms of the current generation of technology, Android, so what do I know?
In my opinion, Java is great for the 'big' stuff. Java is a fantastic 'glue' language. It makes structuring large code bases pretty simple because of its emphasis on simplicity in OOP principles - it makes implementing a lot of common design patterns very easy. It's absolutely awful as soon as you want to do anything intricate with it, however. At the point of implementation of methods, I think you're going to be a lot happier using something like Python, C or Haskell (depending on performance requirements, and personal preference). C# makes better compromises at that lower level than Java does, in my opinion, while maintaining the functionality that makes Java nice for implementing high level design patterns - the compromise with that then is that you're either tied to .NET or you have to use Mono or something.
Edit: Also, this might be interesting reading: http://www.techempower.com/blog/2013/03/26/everything-about-java-8/ - Java 8 does seem to alleviate some of my previous criticisms.
Mostly I use Java because it's what they require for a lot of my modules at university. Some things about Java really stick out as annoying to me - but for some reason the one that annoys me the most is the inconsistent naming for lengths of array-like data structures. For instance, to get the length of an array it's array.length; to get the length of a string it's string.length(); to get the length of a List of any kind (e.g. ArrayList), it's List.size(); - then there are all these convention breaking pieces of syntax in the standard library and basic language constructs (again array.length is accessed as some kind of readonly field which is doesn't exist as a construct anywhere else in the language, even though it would be handy). It just comes across as unnecessarily inelegant.
I think a large part of Java's problem is that it tries to design around the fact that some developers are lazy and/or stupid. For instance it does away with unsigned types because the designers of the language consider them 'difficult' ("Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex."), despite the fact that the absense of such types can cause difficulties further down the line.
Of course, Java is the language of choice for many enterprise systems and for one of the most common platforms of the current generation of technology, Android, so what do I know?
In my opinion, Java is great for the 'big' stuff. Java is a fantastic 'glue' language. It makes structuring large code bases pretty simple because of its emphasis on simplicity in OOP principles - it makes implementing a lot of common design patterns very easy. It's absolutely awful as soon as you want to do anything intricate with it, however. At the point of implementation of methods, I think you're going to be a lot happier using something like Python, C or Haskell (depending on performance requirements, and personal preference). C# makes better compromises at that lower level than Java does, in my opinion, while maintaining the functionality that makes Java nice for implementing high level design patterns - the compromise with that then is that you're either tied to .NET or you have to use Mono or something.
Edit: Also, this might be interesting reading: http://www.techempower.com/blog/2013/03/26/everything-about-java-8/ - Java 8 does seem to alleviate some of my previous criticisms.
Last edited:
I would rather die than use C# due to platform incompatibility, .NET tie ins and lackluster Mono. I could never develop on windows and could never imagine running any important software on a windows platform through choice.
Java desperately needs updating but for me it has most of the good bits about C++, simplified some of the complexities, has decent garbage collection and is relatively fast, faster than c# anyway.
I tend to be forced to use C++ due to historic code bases or other devs misguided understandings of performance comparisons but at the end of the day C++ is fast, which is getting to be more and more important.
Functional languages have been around since the 50s and far outdated C++, C++ is relatively modern Compared to functional languages like lisp. The functional ideas in modern lanages lie Scala are half a century old really!
Bottom 'Line, you should never be tied to a language, just understand the fundamentals of computer science and software engineering. TBH, Even software engineering paradigms come and go. Agile is getting a lot of slack lately for not really delivering clients expectations and haphazard management or accountability. You can have the most rad agile development environment but if the engineers are not on top of their game and truely understand how compilers and processors work then you get sloppy Unoptimized and underperforming code that doesn't scale. The lack of basic understanding of data structures and algorithmic complexity is astounding. How are you going to write scalable code if you don't know Complexity theory?
Java desperately needs updating but for me it has most of the good bits about C++, simplified some of the complexities, has decent garbage collection and is relatively fast, faster than c# anyway.
I tend to be forced to use C++ due to historic code bases or other devs misguided understandings of performance comparisons but at the end of the day C++ is fast, which is getting to be more and more important.
Functional languages have been around since the 50s and far outdated C++, C++ is relatively modern Compared to functional languages like lisp. The functional ideas in modern lanages lie Scala are half a century old really!
Bottom 'Line, you should never be tied to a language, just understand the fundamentals of computer science and software engineering. TBH, Even software engineering paradigms come and go. Agile is getting a lot of slack lately for not really delivering clients expectations and haphazard management or accountability. You can have the most rad agile development environment but if the engineers are not on top of their game and truely understand how compilers and processors work then you get sloppy Unoptimized and underperforming code that doesn't scale. The lack of basic understanding of data structures and algorithmic complexity is astounding. How are you going to write scalable code if you don't know Complexity theory?
Last edited:
so true, but we should treat it like religion and have massive arguments about it all the time.
Caporegime
It's also largely irrelevant. Java promotes bad code and bad development by the bad practices they publish. Much like ASP is (largely) hated in the C# world for the difficulties it gives to most. Java is, in my experience, much worse.
I've seen and worked with code developed in Java that is a complete dream, but I still hate Java.
I've seen and worked with code developed in Java that is a complete dream, but I still hate Java.
Soldato
Whats your opinion of languages such as Haskell?
Caporegime
I'm not very well versed in Haskell. I'm assured by friends and colleagues that I'd love it.
Smalltalk on the other hand, is the grand daddy of them all. Absolutely beautiful language. Simple syntax, sublime (and live) environment to work in. So much could be learnt from Smalltalk for all other languages. I think the only thing holding it back is that it is an image (as in a machine image) based tool, rather than file/compile, which is why it hasn't been so widely adopted.
Smalltalk on the other hand, is the grand daddy of them all. Absolutely beautiful language. Simple syntax, sublime (and live) environment to work in. So much could be learnt from Smalltalk for all other languages. I think the only thing holding it back is that it is an image (as in a machine image) based tool, rather than file/compile, which is why it hasn't been so widely adopted.
Soldato
Chances are if you've picked a managed stack to write your application in then the differences in performance between the various managed options probably won't matter much. Engineers are more expensive than servers.
Don't forget the optimisations that a JIT can perform. This is a layer that C/C++ does not have. Not to be sniffed at.
Functional languages are becoming more mainstream because distributed systems and concurrency have become mainstream concepts in recent years. Immutability is a very effective approach in designing such systems. It's not making a comeback because its now seen as "hip and cool". It's making a comeback because it solves real problems for the engineers that use them.
More and more apps in the .NET ecosystem are modelling their domain using F#. Whilst using C# for more infrastructure related concerns. It's an effective approach.
Absolutely.
Agile failed in just the same way as every other silver bullet to arrive in this industry. Remember when IoC and DI became mainstream and we had to sit back and watch as everybody totally misunderstood it and implemented Service Location pattern instead? Then the trough of disillusionment occurred and you often hear people slating it these days (often the lightweight Rubyists). Meanwhile those who truly groked it as a concept have been happily using it for years, building better, more decoupled, more componentised and adaptable systems. Arguably you cannot have an "agile" project without DI. And just look at how many firms out there claim to be agile without it.
Time for a quote drop:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil". -- D. Knuth
That's not to say I don't agree with you. Because I absolutely do. But it's important to put it into perspective. Optimise things where it makes sense to do so. Anything that touches your applications critical path should be optimised. The peripheries though... perhaps less so.
Caporegime
NathanE has already effectively said as much: Agile is nothing new. Labelling it as Agile is the new thing. The whole "Agile movement" is just the publication of what effective teams were already doing. In the mid to late 90s various folk noticed they were more effective than others and so they started to share their ideas. Other people wanted more and more info, thus these folk decided to start publishing their thoughts and practices - voila, Agile, XP, Scrum, etc.
This is a pretty big over-simplification but that's about it. There's nothing really new about Agile that really good teams weren't already doing.
There are however many misconceptions. "lazy" is certainly not something Agile developers are. "Being Agile" is *HARD* work. It takes discipline, dedication and passion. There's not much "downtime" in teams doing iterations/sprints (as the latter name suggests, working as close to flat out as possible for the duration of the iteration) and we are constantly learning, retrospecting, etc. We are perpetually trying to remove inefficiencies from our working lives. Documentation doesn't give much value when compared to the effort required to keep it up to date. More so in an agile environment because things can change so often and so frequently. Maintaining documentation would slow this down.
The "lack" of planning is a complete misnomer. The planning is now integral to everything we do, we just don't do it all upfront. Instead of planning in detail the next 6 months of work, then doing the 6 months of work, we roughly plan what we are going to do for the next fortnight, and then the detail planning happens as close to the moment you actually need that detail, so there is constant communication and collaboration between the developers and customers/product owners/stakeholders/people that actually want the software.
The pomp around Agile (pretty much the pinnacle of this is Google's offices) is usually just that. Pomp. But underneath it, you can see some clever designing. Each of those rooms is designed to be a concentrated hub for a small team to be able to work closely and to reduce distraction and disturbance from others. People also work more effectively when comfortable. Thus the comfy chairs, relaxed environment and lack of dress code.
People aren't machines. We don't work effectively in grid-layout offices compared to small pods for teams to operate in. Even this isn't new. People have been doing this since, well, forever. The grid-like office layouts are "new" - predominantly since the industrial age (and the wars because every adult had served) and business owners trying to keep people like they would machines/factory lines/soldiers.
This is a pretty big over-simplification but that's about it. There's nothing really new about Agile that really good teams weren't already doing.
There are however many misconceptions. "lazy" is certainly not something Agile developers are. "Being Agile" is *HARD* work. It takes discipline, dedication and passion. There's not much "downtime" in teams doing iterations/sprints (as the latter name suggests, working as close to flat out as possible for the duration of the iteration) and we are constantly learning, retrospecting, etc. We are perpetually trying to remove inefficiencies from our working lives. Documentation doesn't give much value when compared to the effort required to keep it up to date. More so in an agile environment because things can change so often and so frequently. Maintaining documentation would slow this down.
The "lack" of planning is a complete misnomer. The planning is now integral to everything we do, we just don't do it all upfront. Instead of planning in detail the next 6 months of work, then doing the 6 months of work, we roughly plan what we are going to do for the next fortnight, and then the detail planning happens as close to the moment you actually need that detail, so there is constant communication and collaboration between the developers and customers/product owners/stakeholders/people that actually want the software.
The pomp around Agile (pretty much the pinnacle of this is Google's offices) is usually just that. Pomp. But underneath it, you can see some clever designing. Each of those rooms is designed to be a concentrated hub for a small team to be able to work closely and to reduce distraction and disturbance from others. People also work more effectively when comfortable. Thus the comfy chairs, relaxed environment and lack of dress code.
People aren't machines. We don't work effectively in grid-layout offices compared to small pods for teams to operate in. Even this isn't new. People have been doing this since, well, forever. The grid-like office layouts are "new" - predominantly since the industrial age (and the wars because every adult had served) and business owners trying to keep people like they would machines/factory lines/soldiers.
I have to echo this.
I gave up trying to find jobs involving Java, there don't seem to be any, a couple maybe in enterprise environments looking for those with many years of experience just because it's what their systems were created with many years ago, but as a language to start learning it's not something I would go with. C# and C++ seem massively more popular in the jobs market.
Last edited: