Having been exposed to OCaml, I'm starting to think that if you have null references, you don't really have static typing. I guess I'll have to look at guava, but it can only help so much in interacting with other code.
As a rubyist by day this is the thing I find so exciting about Haskell. I write dynamically-typed code all day, and the most common bugs are not because of passing an Apple to an Orange interface—that just isn't very common—it's because of cascading nulls. Of course Java's static checks are worth something, but not much more than the most cursory of checks that my basic test coverage does in Ruby.
My takeaway from looking into OCaml was that pattern-matching with exhaustiveness checking was the jewel, as contrasted with primitive C-style if/else chaining or switches.
Right, exhaustiveness checking is how the compiler makes sure you handle missing values (option types) correctly. I guess you could say that's one of the bigger payoffs.
The static type system is still worth something for packaged client-side applications, as long as you avoid reflection. The GWT compiler (for web apps) and ProGuard (for Android apps) can do very thorough tree-shaking, because they know which code is used and which isn't.
GWT is by far my favorite way of writing javascript. It's work to get it working, but it's ironclad, has client-server RPC built in, and works on pretty much any browser out there.
I suspect this was because it was a smaller change. Inferring from the type of the variable to the type of the expression only has the inferred type flowing inwards to smaller scope. Inferring from the expression to the variable gets inferred types spreading out over the whole program.
That is possible, and is how many languages work, but it would have been a huge change for Java. For better or for worse, it's in the nature of Java to be conservative, and not make huge changes.
I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects. Although personally I've moved on to Python since it greatly simplifies web-related tasks, a lot of our legacy projects are in Java and I still hear plenty of people sipping the Java haterade. So I thought I'd share some of the most common things I hear.
Only my grandpa writes in Java anymore.
I hired a junior developer a couple months ago who absolutely refused to write code in Java, swayed by the vitriol that is often spewed by highly opinionated developers against Java. Instead of taking the time to learn the language, he read up on all the Java Versus Everything Else rants out there and emailed me links to them, trying to convince me that his arrival meant our code base should be rewritten in a "more modern language". Needless to say that he didn't last very long.
The fact remains that Java is an incredibly mature language that runs much faster than most other solutions, and makes it significantly easier to handle the complexity of a large project. There is an enormous ecosystem of libraries for Java, and it would be foolish to move to a less mature language which needs more wheel reinvention.
Garbage collection is bad.
There are the obvious downsides to garbage collection, e.g. Android apps running on low-memory devices, but for an enterprise application running on a server you shouldn't be breaking balls about garbage collection. Obviously it would run 10 - 30% faster in C, but we live in a day and age where it is cheaper to provision extra servers than it is to pay people for the extra man-hours they spend gdb-ing for segfaults and valgrind-ing for memory leaks. It is much easier to pick up a good Java developer than a good C developer, because the good C developers have already been picked up by the big companies that actually need the performance advantage. And from my experience working in a company on an enormous C code base, I know firsthand how easy it is to pick up a really shitty C developer.
It seems like most of my Java code is just checking for errors.
Would you rather not check for errors? What I mean is, would you rather allow a single developer's "return null" statement that was absentmindedly used to handle a rare edge case to completely fuck your application when that edge case is actually reached? Pardon my French, but I'd rather take the time to throw/catch exceptions than get fucked by a gung-ho developer's null, since Java will force exceptions to be caught and handled at some level. With a well-architected solution, error handling can be centralized and developers can more easily contribute to the codebase if the throw-catch paradigm is part of the coding standard.
Java's GUI capabilities really suck.
This one can't really be refuted - Java's Swing UI components are indeed quite shitty. But you can work around them by creating your own Swing components, and enjoy the benefits of a cross-platform solution.
I know this rant was long, but a lot of it was taken from emails that I've sent to my devs in our Java vs. no-Java threads. I'm no Java fanboy, but I am better than most at seeing past the haterade to where it works and where it doesn't work. Maybe I'm wrong, but my experience is a bit more practical than just reading an article that nitpicks at Java's perceived downfalls.
I didn't begin to appreciate java until I had to write a 10k line application for one of my classes last semester. Sure, it probably could have been written in half that with a more modern language, but there's just something about having my tools work and work well that really changed my mind about it.
>>I hired a junior developer a couple months ago ... his arrival meant our code base should be rewritten in a "more modern language". Needless to say that he didn't last very long.
Aha, Let me tell you what the problem is here. This junior guy and most of his gang else where are starting companies with those 'Everything Else' languages.
All these 20 hr/day working kids are working on all these cool shiny projects, building billion dollar companies with these new language. While Java can perfectly manage to hang on and survive in ICU thanks to doctors like you. The new languages will get lions share of popularity, new projects and all they need to make it best language of the current times.
Needless to stay you can still work on Java. But it will mostly legacy code, and by and large unimportant projects which no one really cares about in any company. People working on such stuff are easily disposable. It gets difficult to get jobs by the day. Even your existing company will find it difficult to give you raise.
This happens every now and then. Fighting this as a whole is impossible. They best way out is adapt to the new stuff and move on or risk getting obsolete.
You seem to enjoy generalizations and hyperbole quite a bit.
First of all, such a small fraction of companies actually end up worth anything at all, so jumping to the conclusion that an arrogant prick who couldn't adopt to an unfamiliar development environment will go out and build a billion dollar company is incredibly unlikely. Maybe I'll be completely wrong, but the odds are undoubtedly in my favor.
Second of all, you clearly didn't read my post where I talked about Python being our new weapon of choice. We aren't going to rewrite our legacy Java codebase in Python or something else because there is absolutely no need for it, and those codebases put the bread and butter on the table.
Third, when you're running the company, you have to consider things from a business perspective rather than a technical one. I'm a developer myself so I understand technical details and limitations, but my first question about the product is "does it work?". Nobody is going to give two shits what language or optimizations you used for a product if it doesn't work. They aren't going to pay you a dime, either.
Your comment really exemplifies my point, that people do nothing but sip the Java haterade without realizing what it is good for. Honestly I couldn't care less- I'm not trying to change your way of thinking, and based on your radical assertions that Java is dead, neither are you. But in case some other aspiring dev is reading this, I'd strongly suggest to not be close-minded about powerful tools like Java that have mature ecosystems and an excellent community around them.
>>We aren't going to rewrite our legacy Java codebase in Python or something else because there is absolutely no need for it
Neither would I, And if I were in your place I would keep Java running. And that was my whole point. Want to work on legacy stuff? Or the newer and better projects?
By the way, Python isn't that new these days either. Start up's I know of are going the Go, Clojure and Scala way.
>>when you're running the company, you have to consider things from a business perspective rather than a technical one.
Which is why for the new projects it makes sense to chose the latest tools which have little tech debt, which have fixed problems with older tools and will hang on for longer time.
>> people do nothing but sip the Java haterade without realizing what it is good for.
I don't debate that at all. But frankly speaking Java being good doesn't mean there are better things than that.
>>Honestly I couldn't care less- I'm not trying to change your way of thinking
Neither am I, I have seen first hand what happens when you stick to legacy tools. The jobs dry out, the projects you can work on move towards legacy end and lastly your career as a large suffers.
>>but in case some other aspiring dev is reading this, I'd strongly suggest to not be close-minded about powerful tools like Java that have mature ecosystems and an excellent community around them.
If a young dev is reading this, please treat tools as tools and have to special attachment to them. Learn to adapt and move on to newer things as and when necessary.
Even in those companies. The legacy systems are in place only because the cause of replacing them is prohibitively high.
I've worked in Indian IT companies where most of the outsourced projects are legacy system which the contracting company doesn't want its own people to maintain anymore. Its a bad situation to be in. One company I know of had something like 40000 COBOL programmers, who work on projects from big banks. Most projects are maintained only until they are phased out, Projects shutting down and people being moved around is common.
One metric we had to measure top technologies was to see which one were not used in our company.10 years back that was Java, 4-5 years back that was Python. Today that's Go and Scala. Bleeding edge one's never get outsourced out, the projects with older languages were a common place.
A programmer must never attach him/herself to any tool in general. Adapt and move on, such people survive and win in the longer run.
Kamaal, do you work for either Amazon or Google? Neither company considers Java a legacy language. Do you know Google also builds applications in C++? Would you consider that legacy? How about C? How about C#? Simply because it's old does not mean it's outdated. Java is hampered more because of how inflexible the people who define are than any particular feature.
The difference is C, C++, and C# have continued to progress as languages (for better or worse). Java the language is stagnating. Language feature wise it's several years behind C# and C++. Meanwhile Scala is scooping up what Java is lacking.
I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects.
I agree that Java has its uses, but I've always thought that this was one of the weaker ones. Java's poor syntactical support for clarifying abstractions like lambdas or rich data structures like hashmaps makes small projects larger than they need to be. The answer isn't to find a way to manage large projects; it's to find a way to make them smaller. Size is poison, and automated refactoring is no cure.
Size is poison, true. Not nearly as much as, say, dynamic typing. At that point you start having the exact same code mean different things at different times.
Plus those analysis tools you have for java do help with complexity.
That always baffles me. People get frustrated with java's verboseness for a large project ... and switch to ... python or ruby. Those languages require ridiculous amounts of discipline to work well in large projects (and needless to say, said discipline tends to be absent in the vast majority of developers).
There are plenty of reasons not to have GC run on a server. Let's say you're running an FPS client-server architecture. Good luck writing that in Java. Latency matters.
Absolutely, I wouldn't really use Java for any client-server architecture, mainly because there are other tools that are way better. And yes, latency does factor in that decision as well.
One thing to note is that even if you did have a large-scale Java deployment, you have to think about how much the GC is costing you. Depending on what percentage of time the JVM spends in GC, that can translate to millions of dollars worth of computing time. This is a very real problem that arises when businesses try to use Hadoop for creating solutions at scale.
I wish folks would stop writing Java dev tools in Java. Maven would be 2X faster, eclipse wouldnt pause 2 seconds after every context menu is requested.
I find that the Java community seems fine with this, but wehen you have been doing this stuff for decades, Eclipse slowing me down on nearly every click and keystroke is NOT ok.
Im fine with Java, I just dont want to use Java to make java apps anymore.
For me, this was the most amazing thing about this post:
"Programming with explicit memory management: This bucket includes C, C++, Rust, D, etc. I haven’t needed to explicitly manage memory, so I haven’t used these."
> Surely there are other reasons to use these tools than just "explicit memory management?"
Sure, though he does mention he's biased by the projects he works on (generally web apps/services -- not device drivers, image processing, realtime anything, etc.).
> I suppose I could say, "I haven't used any JVM languages, because I haven't felt the need to gouge my eyes out over memory errors I can't control."
The phrase that bugged you wasn't cast as an insult, though, and yours is... mysterious; Java's GC is quite stable, so any memory-related errors are under the coder's control. "Memory errors" being basically just "using too much memory", as I've never seen any other type of memory error in Java.
Maybe you could say "I haven't used any JVM languages, because I've never felt the need for automated memory management"? That assumes Java has nothing else to offer.
I kid... partly. What I can't get over is a common justification for using GWT seems to be "but you can program in java and Swing then!", which only holds for fans of Swing. It seems is most often advocated by people uncomfortable with Javascript development and little UI development experience outside of Java.
I don't think Swing is terrible but I do think it isn't particularly productive for user interfaces compared to Javascript or even Objective-C, C#, etc.
So if all you have a Java/Swing hammer then GWT is great, otherwise not so much.
I gave up on GWT ~3 years ago, so some of this might have changed since then, but here is my list of things that annoyed me:
* Compilation speed. Even when I dug into the compiler to increase parallelization, it was still dog slow. Yes, running in hosted mode helps, but compiles were still frequent enough that we'd have coffee breaks simply to wait for the compiler to finish.
* Testing. GWTTestCase never worked right for me. And tests that don't run in pure Java are, again, slow. We got around it by writing a Java agent to transform the bytecode at classload time to intercept all of GWT's native methods, but this was a huge PITA.
* Doesn't play well with others. The way that GWT loads makes it difficult to use on concert with other front-end frameworks/technology.
* The inability to embed structured data in the page. The serialization in GWT's RPC is fantastic. Embedding type-unsafe JSON for reference data in a page seemed wrong. But GWT didn't give any supported way to serialize and deserialize outside of an RPC call. We eventually figured it out, but the solution involved having to sometimes include unused code in a RemoteService to ensure that the deserialization code was compiled in, which always felt hackish).
Still, for what it was, GWT was always impressive. It's performance always beat what we were able to achieve with hand-coded JavaScript. Chrome has somewhat lessened the need to write high-performance JavaScript, but it's still impressive that GWT's generated code was that fast. And I've yet to encounter another RTE that was as easy to use and "just worked" as well as GWT's RTE. Every time I'm asked to do something with CKEditor or any of the native JavaScript options, I always wish that it was possible to use GWT's editor outside of a GWT application.
GWT may not be fashionable, but the compiler and other development tools are very advanced, and big Google products use it. So I'd think twice about bashing it.
What big products? The only one that I know of is blogger. Google also recently stopped supporting it and made it an independent open source project, which is a mark against it.
I'm not sure where you got the idea that the compiler was advanced - what it does is amazing but incredibly slow.
The development tools were fine in 2008 but they're showing their age now... the browser plugin only runs in Chrome, Firefox and IE, and it's only fast enough to be productive in Firefox. There are no browser plugins for Safari or mobile and doing a compile to a WAR can take minutes on a big project, which means development for mobile can be glacial.
I've just worked for a year on a big GWT project... it seemed like a good idea to start with but I've grown to hate it over time.
Adwords administration, Adsense administration, Google Play administration, Google Groups, probably several others I don't remember right now. Amazon AWS admin interface is GWT and so are a lot of other big projects you know of.
It is an extremely powerful tool, with some big caveats too, as you mentioned.
Do you use a framework for routing and handling HTTP requests, or just servlets? What about accessing the database, if any? I assume you're not using Java EE.
EDIT: For iOS, http://j2objc.org/ can help you share code between platforms, but you'll still do the UI and other platform-specific things in ObjC.
Thanks for the j2objc tip! I will definitely be looking into that. I thought Thrift was as far as I could reach into iOS without Objective-C.
I haven't used J2EE. My experience with Django years ago made me framework adverse. I will be posting a sample app in a month or two that shows what I mean.
If you're looking for a small and simple HTTP framework in Java, I've been working on one that I think is really nice (you might think the exact opposite): https://github.com/dkuntz2/java-httpserver
> I use Java for application programming. I recommend Python or Ruby for learning programming.
Define "application". There are plenty of cases where Python or Ruby makes sense.
And Java actually makes sense as a learning language aswell, as it has more OO depth which is what most courses focus on largely, without the pain of trying to teach students C++.
I think he/she defines application as "application", as opposed to the web folks' definition that a web site having a text box, a button and 1 mb of JS libraries is an application.
> High efficiency languages include C, C++, Rust, D, etc. I would love one language to rule them all, but it seems that for now there is still a gap between what language to choose application programming and for high efficiency programming.
For most programming, as long as your algorithms are not stupidly slow, clarity is more important than efficiency. In certain situations (video games, embedded devices with few resources) this is less true, and things like the ability to do manual memory management becomes a lot more important.
This is more or less how I interpreted the statement. But grammatically it's hard to parse and I felt it needed a lot of clarification. You're assuming the memory model was the cause of a loss of application clarity but I know many programmers that don't actually feel this is the case.
not most programming. For client side ui work maybe, but pretty much everything I do algorithmic efficiency is a big concern. It's this sort of attitude that gives java it's reputation for being slow and results in behemoth's of software like weblogic.
It was also pretty weird to see Erlang on that list. Erlang may be good at parallelism, but I've never heard that BEAM is especially fast at sequential operations.
Given that he's a web programmer, I presume "high efficiency" in this case means "getting the most out of the hardware" in a more general sense, to which "idiomatic code is automatically concurrent" contributes quite a lot in some cases.
You're confusing "parallelism" with "concurrency." Also, being fast at sequential operations (throughput) is often times not as useful as having low latency.
I've tried explaining this using terms like system programming or high efficiency programming. I guess it is best to just say "explicit memory management", so I updated the post.
As a sidenote regarding iOS, you could checkout http://www.robovm.org/. It's already used for running libgdx (a Java game framework for a number of platforms) games on iOS for example.
I took this out because it was unclear. I meant scripting in the sense that Python and Ruby are called "scripting languages". One possible policy is to use Java for your application, and something like Python to write scripts for stuff like devops or whatever else "scripting" is. Instead of this, I prefer use one language as much as possible, currently Java.
Quick & dirty scripts for testing and such where speed doesn't matter is Groovy's strength. Its managers at VMware are trying to use the Groovy distro as a delivery channel to sneak other unrelated software into businesses, such as a static compiler and type checker which were written by one person only and have virtually no commercial use. There's many other higher quality languages out there for JVM static compilation, e.g. Java 8, Scala, Ceylon, Kotlin, each of which have far larger teams working on them.
A little surprised Spring is not mentioned. Composition in Java is a nightmare without Spring, and you can do some really interesting things in configuration that would take you days of writing initialization code in very little time.
If not for Spring, I'm not sure I would want to construct things in Java at all.
