back
44 comments
Bogus blog.

Might have been true back in the JDK 6 or JDK 7 age but from JDK 8 to JDK 19 it has become a better functional programming language than most functional programming languages.

If the author likes he can keep coding in C++ where strcpy is Turing complete.

> it has become a better functional programming language than most functional programming languages.

Bogus comment. This is very far from the truth. Lambdas and streams don't make a functional language.

Now we just need to wait a couple more decades till functional Java is adopted.

So far I'm still seeing complex class hierarchies with deep inheritance, dependency injection and unit tests produced by ex-Java developers for something that can be solved with a couple of simple methods in Python.

I noticed that complexity makes Java folks proud. Conversely, simplicity makes Python folks proud.

Seeing Java on a resume is not yet a reason not to hire for me. But it's a signal that indicates greater risks.

Odd. I typically see more unit tests on Python projects due to the lack of static typing. I'd take a large Java project over a large Python project any day.
Funny... I have a discussion with a teammate, where he thinks that our internal API should not return streams. I stead we must return Lists, Sets or Maps
I think lambdas and everything around them except the streams API is pretty good, but the streams API is pants. It adds a lot of overhead but doesn’t take advantage of the global view of the processing pipeline it has.

I wrote my own competitor at

http://gihub.com/paulhoule/pidove/

which looks lispy because it uses static imports for everything. I started on a fluent syntax version but wound up working on another project. The odd thing is that I wound up studying the streams API in enough detail that I got over many of the complaints I had about it. If I was going to put more work into pidove it would be developing it to make the most of the Collections API so if you, say, map a list, it returns a list that lets you get(7) to only map that item.

So you think unit tests are a bad idea?
As a matter of fact I do think unit tests generally cause more harm than good.

They are great for libraries with well defined and slowly evolving interfaces. But unless you're doing open-source, you will rarely work on those.

Write tests. Not too many. Mostly integration.

https://kentcdodds.com/blog/write-tests

Any internal library used by multiple other teams has friction on its evolution and refactoring, and don't change interfaces all that much.

Perhaps this turns into another round of clarifying what the discussion participants deem "unit" vs "integration".

Every company is different, but my preference is to break into teams by domain/network boundary. In this case sharing libraries is extremely rare. Teams could easily be on different tech stacks.

Edit: my experience is mostly between seed - series B startups. If you're Google, then of course you're going to have a ton of internal libraries. But I'd put it in the same category as open source.

One role of tests is documentation. If you have a large number of examples of how to use an API you know they keep working. Any code snippet used for documentation should have a corresponding test because otherwise the docs will probably break someday. It’s the best case for ‘literate programming’ that there is.
What functional languages is it better than? I'll give you a list of all the FP languages off the top of my head that people use to build stuff:

- Haskell

- Scala

- Kotlin (not FP but better than Java at it)

- Clojure

- Scheme

- Common Lisp

- Erlang

- Elixer

- PureScript

- Elm

- TypeScript (not even FP but moreso than Java lol)

I really doubt you can say it's clearly better than even one.

I think Scala is crap.

I have frequently seen Scala programs that allegedly use monads for error handling that actually blast right past errors with no handling. That use some kind of snake oil concurrency that never gets the same answer twice (race conditions) but also uses just 2.5 cores on a 8 core machine.

(In general few people appreciate the wide range of of concurrency primitives that Java offers. People want to believe that you can write correct and performant concurrent code with a small set of primitives but it just isn’t true.)

Books on Scala try to seduce you with examples that look concise but they are all structurally unstable and get an order of magnitude more complex when you change anything. (I’d contrast that to Cold Fusion, PHP, and other poorly regarded languages where I’ve sometimes met a correct program.)

I am also unimpressed w/ Kotlin. It beats the pants off JDK 7 but not JDK 19 particularly if you use an IDE that does static analysis.

F# as well.
> it has become a better functional programming language than most functional programming languages.

LOL

> Might have been true back in the JDK 6 or JDK 7 age but from JDK 8 to JDK 19 it has become a better functional programming language than most functional programming languages.

uhh, let me know when they add the ability to define a standalone function that exists outside of a class.

> If the author likes he can keep coding in C++ where strcpy is Turing complete.

c++ certainly has its warts. but having worked with both professionally, I find java to be by far the more frustrating of the two.

some random gripes off the top of my head:

I can't invoke a no-args constructor like this: `MyType var;`

I can't do something like `public MyType() = delete` to make my class nonconstructable (which would at least partially help with the "no standalone functions" issue).

there is no notion of tuple in the standard library. I have to define a new class (or abuse Map.Entry) every time I want to return more than one value from a method.

I can't construct a collection (or POD) type like this: `MyCollection c = { a, b, c };`. Yes, I can do stuff like `List<T> list = Arrays.asList(a, b, c)`, but then I have an immutable array enclosed by a mutable list, where any attempt to modify it is a runtime error?!

in my experience, java somehow manages to be more verbose and less ergonomic than c++, which is really saying something.

disclaimer: I have not worked much with JDK versions >11, so maybe they've addressed some of above.

Frankly I don’t have problem with classes that have nothing but static methods, you can write a private constructor if you are so concerned somebody is going to construct an instance of the class. (Somehow that’s a problem that really concerns C++ programmers. They keep saying RAII over and over again as if it was a magic talisman that made their code reliable)

People who write functional libraries in Java frequently write Pair<A,B> and sometimes Triple<A,B,C> but they independently discover there is no point in declaring a Tuple27. Recovering LISP programmers point out the ‘nameless tuple’ problem is one of the many reasons the idea of LISP is better than the reality. In modern Java you can write a record if you need to bundle together a few results.

And I removed C++ from my resume. Programmers should remove languages they hate working in. That said I'm gonna have Java front in center in my resume as I think it's pretty neat.
Same reason I never even listed Angular on my CV. It’s only ever been a horrible experience that sometimes coincides with .NET jobs. Can’t think of a worse framework for building anything.
I removed Scala from mine.
I wonder if the author has programmed in Java in the last 7 years? Most of his comments were accurate about 2015, but not since then. Perhaps like a mentor made a big deal out of these and he absorbed it.

It has become popular to hate Java, but again that goes back previous JDK's.

JDK 19 is a strong functional language that should not be dismissed lightly.

Java has been around since '95. It shouldn't take a language 20 years to get good enough. That's an entire generation of burned programmers who know only of the shitty versions and that is still the majority of the existence of Java. The hate for Java was long brewing.

I programmed Java way back in 2003 and I didn't like it then. C# was quickly catching and surpassed it. Almost 20 years later I have no reason to even try and go back to it. There are plenty of better options now.

It was always good enough, and evolved with the times. C# was under tight control MS for most of that time, thats why Java was widely adopted. You can't make that statement without addressing the history of the two languages
> and requires its interpreter (JVM) to be present on the machine.

That's hardly a drawback. If every Electron app can get away with shipping a Chromium instance with every installer, you can ship a JVM with your app.

I look forward to living long enough to see the monstrosity that will have people convinced Electron is small and reasonable.
The logical next step is to ship apps as Docker containers, with the UI being a VNC or RDP viewport inside.

Of course, it's not an either-or - I'm sure many of those containers would have Electron inside...

With GraalVM it is possible to build native binaries, so no need for JVM to run programs written in Java
In windows you need to have the right version of the C++ library installed. (Linux doesn’t even try to be binary compatible over time.)
Indeed! Back in the days when I used to develop software using C++ on Windows, I have had my own fair share of dealing with "SideBySide" errors because I had the wrong version of runtime library on the target system where my software would run.

I have a Stack Overflow question at https://stackoverflow.com/q/8913543/303363 which taught me how to identify the right version of the runtime library and how to fetch it. I don't do software development for Windows in C++ these days but once in a while I do look back at this question to fondly remember the days of C++ programming on Windows.

Except for the tiny "SideBySide" glitch (which was quite confusing at first), software development with C++ on Windows using Visual Studio as the IDE was a pleasant experience. Backward compatibility was (probably still is?) a strong suit of Windows. A software written in the 1990s worked fine all the way up to 2015 or so, often with no changes or no recompile/rebuild required. The binaries and DLLs would just work fine without issues on newer versions of Windows as long as the CRT the software was built with is also packaged in the software distribution.

That depends on how the native app is packaged, as it is possible to bundle the Visual C++ runtime. It's not recommended for obvious security reasons, but licensing allows it.
I envy you westerners being able to interview so easy for enterprise java jobs. The huge supply is devaluing the experience. I'm here in Iran dying to get to work on, and study a quality java codebase. But they're so few and I do not qualify. I don't think I'll see an actual enterprise codebase before I'm 30.
This is so hard to fathom from my viewpoint. In the US, it seems, every large company has a software R&D department that has been writing Java for 30 years. I exaggerate, but I wonder: do you not have bank chains, grocery chains, major construction firms, accounting and payroll, or energy and water utilities?

I would think, also, given the trade embargo, you'd have to write and maintain (somewhere within your borders) all the software which an American company might buy off-the-shelf.

Iran has a very strong Microsoft roots and very serious brain drain problem. Right now, in jobinja.ir there are 84 spring jop openings and 346 .net job openings. I have worked with many of these "enterprise" .net code bases and it's as if they're written by people who keep experiencing their first year college experience every year, not people who have N years of professional experience. Oh and they went to college in the 1970s.

Of the few talents who decided to remain in the country, even fewer want to do boring enterprise work and they prefer staying on the "bleeding edge". Therefore there are very few companies doing java which can compete with foreign firms in payment(and so can keep talent and code quality).

That would be RPG/400 for me. I "know" how to program in that a little bit, but I've never put it on my resume, and I never will. You can't pay me enough to write RPG code.

As for Java... I don't get the hate. It's not perfect by any means, but I generally enjoy working in it. Maybe just because I've been doing it so long and I've normalized whatever pains there are. That said, given a choice between pure Java, and Groovy, I will generally go with Groovy instead. It takes away enough of the sharp edges to make what I consider a quite fine language.

The hate comes from more of the system's administration side. Back in the early days, I've spent long long hours on an all day calls due to a product being down arguing with Java Developers that their is nothing wrong with the server and it's their code and the release they didn't test as well as they thought. Eventually a day or two later a "fix" is released but that releases change log is usually worded in a why to throw us under the bus further and save face with the C levels. As IT was considered a cost center vs the Developers that added features that made the company money, it was insanely harder to convince a C level that it was not something that changed on your side. I have had to put together charts, graphs and PowerPoint RCA's just to prove a point. Do that 100 times, over a 10 year period and it'll make anyone hate a specific language or technology.

I don't hate Java like I use to and it has definitely got better over the years, but it's not the first tool I reach for or consider for new projects because of past experiences. I understand that a lot of the issues were because people were not "leaving their ego at the door" but regardless it still created a negative experience that followed me for years.

“Back in the early days” being the key phrase.
I fail to to see the usefulness of your reply. My text has quite a few key phrases. However I guess you didn't see the other key phrases like. "Do that 100 times, over a 10 year period and it'll make anyone hate a specific language or technology."

Just because it changed, doesn't invalidate people's past experiences/grievances.

Personally, as I stated I don't hate it like I use to and will use it when it's the right solution to the current problem but just because it's better now days doesn't mean it has to be my first choice.

Edit: Your reply is basically the equivalent of. "Back in the early days your ex cheated on you twice... but she's changed and you should give her another shot"... A Disney/Lifetime/Hallmark movie life is not. I may talk to her and eventually be a friend, but I'm going to be weary of knives aimed for my back.

I hate Java as much as the next person, but claiming that programs written in Python are easier to distribute is bizarre. Literally the one thing Java does well is make things easy to distribute.
TL;DR: This person doesn't like Java, and doesn't want to put it on their resume because... They might get kidnapped and forced to write Java code? They might overdose on ambien and accidentally interview for and accept a job offer writing Java software? (It's unclear exactly what the supposed danger is here...)
I wouldn't say "danger", but I'd guess that omitting Java means they hear about fewer openings that aren't interesting to them, thus saving a bit of time and effort.
seems like clickbait to me. Nothing of value
"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product." - Mark Dominus

https://blog.plover.com/prog/Java.html

he's clocking people coding his puzzles to each second? sounds terrible, why would you do that to people.
Hah me too.