Because it has a VM (portability, multiple languages interact seamlessly, bytecode manipulation at runtime, low compile times), insanely fast GC, best tools in the industry (IDEs, static code analysis, debugger, libraries), and it's still fast enough to write HFT software with it.
It's even possible to compile it ahead of time, making projects like a Clojure CLI scripting runtime with almost instant startup time possible (babashka).
Slow startup and build times aside, the JVM is a very robust, production-ready environment. Excellent cross-platform support (if we ignore pretty GUIs) and runtime performance within a factor of 3 of C's. There are plenty of open source libraries and the Java ecosystem is massive. The language is safe and garbage collected by default, but you can achieve performance on par with C when you absolutely need to. You can use it for anything short of driver/kernel development. Even the slow start-up time is being fixed with GraalVM. If they can port over some of C#'s syntax improvements, then the language would be perfect. Compared to .Net for example, the JVM is much more well understood.
Graalvm has support for ahead-of-time compilation of JVM languages. They promise "native executables [that] start nearly instantaneously, are smaller, and consume less resources of the same Java application".
This is how things like Babashka (Clojure CLI scripting runtime) are possible [0]
Clean, orthogonal design. Support for metaprogramming in the form of introspection, reflection, compiling bytecode on the fly. Threads that work. Threads that work cross-platform. No GIL. Efficient memory allocation, garbage collection, JIT compiler. When problems are found with Java they get fixed
most other programming languages make excuses. Build system with dependency resolution that works (unlike Python) IDEs take advantage of static nature of language. Static nature of language enables refactoring.
Lambda syntax that's probably more concise than your favorite language. Implementation of Lambdas that meshes perfectly with existing practices in Java. All-virtual polymorphism is one of many ways that Java doesn't steal IQ points from you the way C#, C++ and languages like that do.
What about the fact that Java didn't want lambda in the first places, only to hack anonymous inner classes that were never well promoted until 20 years down the road people realize it's quite useful to express logic as functions ? :)
Interesting, not what I recall (but my readings on this were quick). AFAIK it was carefully not pursued because they wanted to make everything as classes so they went with AIC.
Gosling say closures represent the realization of a dream that was postponed in Java's early days and resulted in the invention of inner classes - "an uncomfortable compromise" that failed to provide the desired level of simplification. He notes criticism that closures are too complex, but advises people to read "through all of what Neal has written".
I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes.
The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly.
I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.
I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.
> I’m not sure whether you mean semantically or in implementation
I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough.
> rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence
Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to.
I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound.
It is convenient to let the Iterator be immutable and the Iterator be an inner class that gets its configuration information out of the Iterable.
(That said, if people really thought seriously about Iterator being a Supplier<Iterable> people might think more rationally about error handling. Also in a slightly parallel universe the Iterator would only have one method since remove() hardly ever gets used and having both hasNext() and next() methods is asking for bugs.)
The issue is that it's anonymous logic recreated above classes. I think it obscures the purpose, making them quite verbose. Unlike FP languages where it's central and a convenient thinking and working tool. With added bonus of currying, it's really a different feel. The few years i had to operate in java it was seldom used and advertised.
I remember getting into an argument with two guys in the men's room in Center Ithaca circa 1995, they thought Java was overhyped, I thought it was going to to be big.
I was right, with the caveat that the original "applet" use case where you wrote little GUI apps to run in a rectangle in a web browser turned out to be a complete wash.
not a lot of java's original goal succeeded, applet died, desktop died .. for some reason it matched well with enterprise in a time where heavy would sell in big companies
in a funny way, the jvm hitting android made it the networked desktop of the world, but in no way sun/oracle predicted it :)
I find it kindof odd that the Blu-Ray disc adopted Java as a standard, that is, every Blu-Ray disk is really a big Java "applet" that runs on the player. Pretty frequently the "applet" is a stock player with a small amount of customization since Hollywood isn't any more interested in software development than TV station owners: that is, an interactive ATSC 3 TV channel is just a single page app that gets events from a websocket server embedded in the TV.
Which ones did it deliver on? Faster than C? No. A memory-safe language that you can write OSes and drivers in? No. Pleasant cross-platform GUIs? No. Easy code reuse? No. Low code development by using XML? No. Not needing generics? No. Checked exceptions being a good idea? No. More understandable code by using classes instead of lambdas? Hell no.
Java more or less got "write once, run anywhere" working, I'll give them that (although I still see programs that e.g. use a hardcoded path separator, they're the exception rather than the rule). But it's hard to see anything that it really delivered on in terms of working better than e.g. OCaml.
While Java is actually fast now and fairly often faster then C, it was not original promiss at all.
> Easy code reuse?
Yes, as proven by rally large ecosystem of libraries and frameworks. All of that is literally code reuse.
> Low code development by using XML? No.
This was NOT original promiss at all. Again, these were first attempt at creating larger frameworks.
> Not needing generics? No. Checked exceptions being a good idea? No.
What are you talking about here? And yes both generics and checked exceptions have their use and dont make creating or maintennance of software hard at all.
> While Java is actually fast now and fairly often faster then C, it was not original promiss at all.
It was absolutely something that was claimed at the time. Java's JIT, good as it is, has not lived up to the hype, to the point that newer languages (and even newer versions of Java itself) are moving away from it.
> This was NOT original promiss at all. Again, these were first attempt at creating larger frameworks.
It was absolutely something that was advertised by Spring and by Java EE, and didn't pan out.
> What are you talking about here? And yes both generics and checked exceptions have their use and dont make creating or maintennance of software hard at all.
The original Java claimed that a feature like C++ templating was not needed, which proved to be false. Checked exceptions are widely regarded as a failure; no major new language (even on the JVM) uses them.
Spring is definitely a 3rd-party library builder, and I'm unaware of promises like that from Java EE. Can you help me understand what informs your view on that? It seems like they delivered a bunch of stuff that made it easy to consume XML for all kinds of questionable as well as reasonable purposes, but it was Spring not Java trying to turn XML into a scripting language.
My view is based on my experience of being a developer in those days and seeing what was being hyped at JavaOne or sent out in talks from Sun. It wasn't just Spring (indeed Spring got its start as a lighter-weight alternative to JEE), there was a whole lot of marketing tying Java and XML together, and as far as I can see the heart of it was this idea that you could use XML configuration to string together reusable Java components instead of writing code.
The lesson I took from it is that marketing matters more than technical merit. Don't get me wrong, Java is fine, there are far worse languages out there. But at the same time very little of the USPs it was supposed to have really panned out.
Spring is framework, it is not part of language itself. It is part of ecosystem around java. Neither spring nor Java EE promised to be low code. It used xml for configuration, but not because it would somehow aimed to be low code.
Generics are nowhere near to being similar to C++ templating. Also, I never understood hate of checked exceptions that invariably comes from people who dont use Java. They don't bother much and have their place.
There was no major hype about Java being faster then C or C++ in its origin. They quite explicitly talked about sacrificing speed for other properties. Java however got faster in later developments.
> Neither spring nor Java EE promised to be low code. It used xml for configuration, but not because it would somehow aimed to be low code.
They were advertising the same thing that modern low-code proponents are: the idea that you'd be able to change your application's behaviour by changing a configuration file, and that this would be superior to editing code. That was definitely part of the Java marketing.
> Generics are nowhere near to being similar to C++ templating.
Lol what. They use the same syntax and provide (not all of, but most of) the same functionality.
> Also, I never understood hate of checked exceptions that invariably comes from people who dont use Java. They don't bother much and have their place.
I do use Java, I still hate them. They're very cumbersome, and again, the bottom line is: twenty years on no other language wants them, not even the likes of Kotlin.
> There was no major hype about Java being faster then C or C++ in its origin.
There absolutely was. The Java JIT was hugely hyped at the time, and there were even benchmarks showing it outperforming C on particular problems.
I think they might be conflating "programming by convention" which was what facilitated a lot of serialization schemes and other tooling that leaned in to the whole bean concept with lowcode.
Not just serialization. I'm talking about things like the drag and drop graphical flowchart thing that WebSphere has (or had), which behind the scenes is an editor for XML files that instantiate a bunch of EJB. With Spring you don't get the graphical builder part but people were still pushing the idea that you would edit the XML files rather than your application code and this would be better. I know those are second- or third-party frameworks, but WebSphere was the flagship JavaEE implementation and I swear this was the stuff Sun was hyping up as examples of what Java would let you do.
Ok, now you are talking about success that Sun and/or Java community did deliver on. I loved composing object maps with application.xml when I was a Spring user. That was a full head+shoulders above hand-coding constructors and calling setters. And yes, it was a clean interface for a GUI but I never went there.
> A memory-safe language that you can write OSes and drivers in? No.
Why couldn’t you? There was always an escape hatch API that let’s you manage that few direct pointer accesses mandated by hardware - otherwise the rest could very well be written in a managed language (as shown by research done by Microsoft for example)
Right, that's exactly the kind of thing that Java's promoters said. But it doesn't seem to have panned out; I don't think I've ever seen a driver written in Java (even though I have seen certain kinds of drivers written in Python).
A driver doesn’t exist in a vacuum, they are attached to OSs, and all prominent OS today is written in C. Python does have better FFI with C than java, but I really don’t see how that would prove anything contrary to Java.
I don't remember any claims that people would write general-purpose OS drivers in Java. I do remember the claim that many app-level drivers would migrate from native wrappers to pure Java. And that happened.
Good for you. I still can't build a project that I want to build on Windows, because its build system tries to calculate a relative path by breaking the current working path on '/' characters.
Broadly speaking, the Java argument was to make it easy to do the right thing, not making it impossible to do the wrong thing. Especially when the interface to a filesystem depends on parsing structure from a string.
Most of these points apply to a lot of languages en vogue today. I'm not quite sure what to make of that in light of these points, but thought I'd point that out.
You're right. What this article fails to anticipate is that, "Hacker's Radar", won't be what matters. It takes great pains to make clear that it's not about Java, but hacker radar and how that leads him to reject things like Java. Well, in the era we live in now, hacker radar has taken a back seat, to bean counters, pitchmen, and CEO's blabbing endlessly on Twitter, and while all of them claim to be Tech-CEO's and pitchmen, etc... The truth is once those people take over, the tech will never be their priority, with bean counters it's always about the beans.
Thank god solving customer problems has taken over the tech-ceo job, starting with tech is usually a bad idea, even when it is innovative (crypto-ponzi as an example)
Well that's interesting, because you and I see things exactly opposite. In the era I started, before this article was written, there were, in many cases, no customers. The users and the creators were frequently the same people. New technologies had much more time to be implemented before they were actually brought to market and productized. Nowadays new technology is saddled with unrealistic hype and expectation before anything is implemented at all. We're probably just going to be in disagreement about that point. As to your point about business people caring about the needs, and concerns of their customers, I have to be in agreement with you about that.
One interpretation is that pg was hilariously wrong in 2001, and that similar arguments in 2022 are unlikely to hold water in and of themselves. The particulars might be true in any single instance, but pg’s qualities for success are obviously not necessary.
Java == Spring Framework In most corporates I've worked in. I'm lucky to work in a vertx project now so it can be done, but Spring is in every project in my last co.
> It has been so energetically hyped. Real standards don't have to be promoted
I find this interesting because it's the first heuristic I use to judge anything new, technical or otherwise (e.g. TV shows or games). Did someone pay to put it in front of me?
It turns out to be a mostly true assumption that you'll hear about good things organically.
That's true when it comes to art, but I have almost the opposite feeling when it comes to things that require a network effect to be worth investing in
I'll readily judge a new programming language or library based on the quality of its presentation, because if no thought is being given to presentation, I can tell already that it's not going to get much traction. And if a PL doesn't get much traction, its ecosystem and even its long-term development will likely suffer.
Although- that's really just a minimum bar, and I agree with the author that Java went way way beyond that, and had more money tied up in that than felt warranted, so I probably would have had the same feelings
What you say about traction is a good point. I think "will it be successful?" is a very different question to "will I like it?".
At one end of the scale for me is Rust. I discovered it through organic hype and I like the language but it's not successful enough for me to have found a job writing Rust.
At the other end is TikTok. I saw many ads for it before anyone I know ever talked about it. It's massively successful but it doesn't appeal to me in the slightest.
What if Paul had invested at least an hour or two trying out Java before spending that much time writing a scathing critique about why it must probably be "bad"?
The approach he took in forming the opinion comes across as quite arrogant and error-prone.
Exactly. Go and Rust comes to mind immidiately. Both excellent languages in my opinion crafted for the creators need. Although it's maybe not quite what Paul had in mind in 2001, but the world has changed a lot. A community project can't really outgrow these well funded big business language projects.
> Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.
Does a programming language have to live vibrantly for 3 decades to be "good"? I don't think so. Use it while it's good, then move on to or create the next good thing.
The longer it lives, the more your investment in learning thoroughly it pays off. But languages also have a tendency to accumulate features until taking on a cancer-ridden look. I probably stick to a given "main workhorse" language for about a decade on average. So I would agree that if a language gets a decade of being good, it is about as good as you can expect.
With the exceptions of Perl and perhaps Ada, I still tend to agree with this. C++ is only okay because of the libraries that make it suck less.
What the statement doesn't do is support the opinion that Java will be unpopular for being a bad language.
The thing that made Java succeed was the write-once-run-everywhere JVM and the huge effort spent by Sun, IBM, and others to make the JVM as good as it is.
Choice of programming language is almost always a decision of whether you want to stand alone, or whether you want to stand on the shoulders of the multitudes. Some of which are indeed geniuses. Standing alone is always a poor choice. Not understanding that means not understanding that programming is a highly social activity.
What is amazing to me is that Java could attract such a huge community, so much so that top talents could produce an amazing array of libraries, frameworks, and systems. The ecosystem of Java simply makes lots of daily work really easy. And no, I've never used Spring or Hibernate or those "enterprise" frameworks. That said, many enterprise software engineers, or so I heard, do like the productivity brought forth by Spring. Frankly, I don't understand why people keep mentioning Spring as if it's the culprit of Java. Spring is just one of the huge number of choices in Java's ecosystems. To me, Java offered great productivity tools at the right time over the years. Let's not even talk about communities or successful systems. Just a few seemingly small things:
1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walking through the code with a debugger while jumping around the source code by semantics.
2. Standards. First its servlet, but soon web containers. Even in its early days, such standard made it much easier to write web applications. Engineers just needed to remember a few simple rules before producing concurrent web services.
3. JVM and all the toolchains. All the jconsole, jstack, jmap, gc logs, etc and etc. They may be norm now, but when they were productivity boosters when they first came out.
4. Java's standard libraries, especially the concurrency libraries. All those containers and high-level synchronizers are so much easier than the vanila mutex. This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
5. All kinds of JSRs, such as JAX-RS. You may hate them personally and passionately, but they do provide easy enough APIs and most importantly a standard for all kinds of frameworks to support. A Java programmer can easily switch from one framework to another without much learning curve.
Even before Eclipse, there were some free (but not open) versions of commercial IDEs such as Borland JBuilder. JBuilder in particular was truly incredible in terms of features for the late 90s-early 00s, also considering it ran well on just 128 MB RAM.
> 1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walk the code through a debugger while jumping around the source code by semantics.
I wonder how much Java success in early 2000's was related exclusive to this. I remember asking Java programmers why they liked it so much and all they talked was about IDE features and not the language itself. It looked like some couldn't even tell the difference between an IDE and a programming language.
>This is something I don't quite understand about the Go community: why do people are fine with using Mutex everywhere?
While I wouldn't say I never used Mutex in my life, pretty much all the nice high-level parallelism primities, such as map-reduce, event loop-based workers, signals, cancellation can be emulated pretty well with channels - using Mutex is pretty much never necessary in day-to-day Go programming.
>This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
The default approach in Go is to use channels. The preferred idiom is "share by communicating". I think mutexes are overused by people who came from other languages and who aren't accustomed to channels yet. They spawn goroutines which communicate by sharing when it should be the other away around - no shared state with a few exceptions. I think there's no proliferation of synchronization primitives in Go because sharing state is considered a bad practice.
Got it. I saw ReMutex used on maps, for instance, the other day. What if one needs to have shared data, say, a routing table for all incoming requests?
> What is amazing to me is that Java could attract such a huge community
Why is it amazing? Java was a well-compromised piece of PLT design, by a geek friendly company known for its engineering chops, with a very cool (hackable!) VM that allowed for both compiletime and runtime magic, and all this over and above the fairly well equipped standard library. (Beyond that, concerted Java hype in late 90s was ~same as what we saw later with RoR, Scala, Go, and now apparently Rust. Java may not be cool these days but it was the shiny thing in late 90s.)
Note that this is not about if Java was good or bad, which is obviously a question of opinion. This is about if Java was going to be successful:
> I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language.
Given that Java became spectacularly successful and still is, the question is why the author turned out to be so wrong? My guess would be that the author thinks the people he know (apparently all extremely competent "hackers" with great taste) is the kind of people who decide what becomes popular in the industry at large. We all live in our own bubbles.
I think the bubble of the author becomes apparent when he mentions Perl positively compared to Java. Sure, Perl is fun, edgy, powerful in weird ways, the opposite of Java in any way. But if I had to maintain complex code written by someone else, I would far prefer to maintain Java to Perl. I suspect the author is the kind of developer which never have to maintain code written by other programmers.
I have seen beautifully clear perl code with amazing performance and great decoupling & modularity. I have seen abysmal Java code full of leaky abstractions and bottlenecks.
I guess by now we can blame selection bias and go contribute a PR to Enterprise FizzBuzz...
I think pg underestimated the long term effects of (9) and (10). Generations of new software developers picked it up, because that's what universities offered, because that's what the big hiring companies of the time mandated.
I remember going to a Microsoft conference in 1996. Talked with quite a few C++ developers - everyone aged under 50 or so was super excited about Java. At the time a program that could do something over the Internet was 20 or 30 lines of Java and a few hundred lines of C++.
It is writing from superiority complex and ego. I think that Paul Graham is populist in a lot of his writing - he writes to certain audience and makes sure they will feel good about themselves being better after reading. That is where "all extremely competent "hackers" with great taste" comes from.
Also, this is not serious analysis, he twists motivations and reasons for certain Java decisions. He does not look at advantages and disadvantages to evaluate the language. Instead, he looks at how he can twist anything at had as inferiority. Note also how insulting the article is towards both original authors and "them, not real hackers using Java".
I never had an issue maintaining Perl codebases because contrary to the many developers that speak ill of it I actually bothered learning the language.
Looking back, I think we can be a bit more circumspect. For me, the most relevant points are:
"""
...
7. It's bureaucratic. ...
...
9. It's designed for large organizations. ...
...
10. The wrong people like it. ...
...
"""
These might all be shades of the same underlying cause but, for me, this is exactly why Java has "failed" in many domains and "succeeded" in others. Precisely because it was marketed as boring technology that large organizations could use is the roots of it's success in business domains and it's failure in "hacker" domains.
Daniel Sockwell had a talk about the "Ideal Language for Writing Free Software" [0] and many of the points are mirrored about what makes a language well suited to an individual maintainer of a FOSS project that allow them to use its high skill ceiling and the programmers deep knowledge of the language are the things that business interests select against to allow for programmer fungibility.
PG makes the same mistake as most talented „hacker“ types I have encountered: underestimating the value of tools and standards that enable dev teams to work together.
Every LISP codebase is different, the language is famous for making your own „DSL“s. Every Spring Boot codebase is similar. One of those approaches doesn’t scale in terms of collaborators.
Category error: LISP is a diverse family of programming languages from past to present. Spring Boot OTOH is an opinionated way how to use Spring, a widely used framework of the many Java frameworks.
I think a lot of the criticisms of Java are motivated by developers trying to get paid for what they do. If you can jump to a new language while casting the old language as old, inefficient, etc you can, at least temporarily, command higher pay.
In the mid to late 90s I was spending the beginnings of my tech career writing code in VBScript, running on IIS (ASP). I wanted access to larger distributed systems, and I knew I could not do this with the Microsoft products. I learned Java on the side over a couple weeks by reading the Sun Java Tutorial, then landed myself a job at a large energy provider. That changed the course of my career forever. I will always be happy Java exists. I switched away from it over the past 5 years, but it still did me good. I do write a lot of Kotlin code now, so I haven’t abandoned the JVM. :-)
129 comments
[ 2.6 ms ] story [ 183 ms ] threadIt's even possible to compile it ahead of time, making projects like a Clojure CLI scripting runtime with almost instant startup time possible (babashka).
This is how things like Babashka (Clojure CLI scripting runtime) are possible [0]
0. https://babashka.org/
https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pd...
most other programming languages make excuses. Build system with dependency resolution that works (unlike Python) IDEs take advantage of static nature of language. Static nature of language enables refactoring.
Lambda syntax that's probably more concise than your favorite language. Implementation of Lambdas that meshes perfectly with existing practices in Java. All-virtual polymorphism is one of many ways that Java doesn't steal IQ points from you the way C#, C++ and languages like that do.
Some APIs were excessively verbose due to the lack of lambdas, which were emulated using anonymous inner classes.
If you have a link, please share.
Gosling say closures represent the realization of a dream that was postponed in Java's early days and resulted in the invention of inner classes - "an uncomfortable compromise" that failed to provide the desired level of simplification. He notes criticism that closures are too complex, but advises people to read "through all of what Neal has written".
https://www.theregister.com/2008/02/01/java_closures/
Java is mostly about interfaces. Classes are just a way to implement them. This is one of the differences between Java and C/C++.
The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly.
I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.
I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough.
> rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence
Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to.
I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound.
We can get along! There's no need for this feud!
Thing is, they turned it around.
This library contains a huge number of Iterables, each of which has at least one Iterator implementation.
https://github.com/paulhoule/pidove
It is convenient to let the Iterator be immutable and the Iterator be an inner class that gets its configuration information out of the Iterable.
(That said, if people really thought seriously about Iterator being a Supplier<Iterable> people might think more rationally about error handling. Also in a slightly parallel universe the Iterator would only have one method since remove() hardly ever gets used and having both hasNext() and next() methods is asking for bugs.)
Not sure choosing the “wrong” programming language can kill a startup just like the lack of traction and sales.
I remember getting into an argument with two guys in the men's room in Center Ithaca circa 1995, they thought Java was overhyped, I thought it was going to to be big.
I was right, with the caveat that the original "applet" use case where you wrote little GUI apps to run in a rectangle in a web browser turned out to be a complete wash.
in a funny way, the jvm hitting android made it the networked desktop of the world, but in no way sun/oracle predicted it :)
Java more or less got "write once, run anywhere" working, I'll give them that (although I still see programs that e.g. use a hardcoded path separator, they're the exception rather than the rule). But it's hard to see anything that it really delivered on in terms of working better than e.g. OCaml.
> Easy code reuse?
Yes, as proven by rally large ecosystem of libraries and frameworks. All of that is literally code reuse.
> Low code development by using XML? No.
This was NOT original promiss at all. Again, these were first attempt at creating larger frameworks.
> Not needing generics? No. Checked exceptions being a good idea? No.
What are you talking about here? And yes both generics and checked exceptions have their use and dont make creating or maintennance of software hard at all.
It was absolutely something that was claimed at the time. Java's JIT, good as it is, has not lived up to the hype, to the point that newer languages (and even newer versions of Java itself) are moving away from it.
> This was NOT original promiss at all. Again, these were first attempt at creating larger frameworks.
It was absolutely something that was advertised by Spring and by Java EE, and didn't pan out.
> What are you talking about here? And yes both generics and checked exceptions have their use and dont make creating or maintennance of software hard at all.
The original Java claimed that a feature like C++ templating was not needed, which proved to be false. Checked exceptions are widely regarded as a failure; no major new language (even on the JVM) uses them.
Spring is definitely a 3rd-party library builder, and I'm unaware of promises like that from Java EE. Can you help me understand what informs your view on that? It seems like they delivered a bunch of stuff that made it easy to consume XML for all kinds of questionable as well as reasonable purposes, but it was Spring not Java trying to turn XML into a scripting language.
Generics are nowhere near to being similar to C++ templating. Also, I never understood hate of checked exceptions that invariably comes from people who dont use Java. They don't bother much and have their place.
There was no major hype about Java being faster then C or C++ in its origin. They quite explicitly talked about sacrificing speed for other properties. Java however got faster in later developments.
They were advertising the same thing that modern low-code proponents are: the idea that you'd be able to change your application's behaviour by changing a configuration file, and that this would be superior to editing code. That was definitely part of the Java marketing.
> Generics are nowhere near to being similar to C++ templating.
Lol what. They use the same syntax and provide (not all of, but most of) the same functionality.
> Also, I never understood hate of checked exceptions that invariably comes from people who dont use Java. They don't bother much and have their place.
I do use Java, I still hate them. They're very cumbersome, and again, the bottom line is: twenty years on no other language wants them, not even the likes of Kotlin.
> There was no major hype about Java being faster then C or C++ in its origin.
There absolutely was. The Java JIT was hugely hyped at the time, and there were even benchmarks showing it outperforming C on particular problems.
To be sure, that is configuration, though.
Why couldn’t you? There was always an escape hatch API that let’s you manage that few direct pointer accesses mandated by hardware - otherwise the rest could very well be written in a managed language (as shown by research done by Microsoft for example)
It is hard to argue against the Java ecosystem of libraries.
I use forward-slash (/) on Windows and OSX/Linux, and the JVM/libraries do the right thing all day. Please enjoy.
I find this interesting because it's the first heuristic I use to judge anything new, technical or otherwise (e.g. TV shows or games). Did someone pay to put it in front of me?
It turns out to be a mostly true assumption that you'll hear about good things organically.
I'll readily judge a new programming language or library based on the quality of its presentation, because if no thought is being given to presentation, I can tell already that it's not going to get much traction. And if a PL doesn't get much traction, its ecosystem and even its long-term development will likely suffer.
Although- that's really just a minimum bar, and I agree with the author that Java went way way beyond that, and had more money tied up in that than felt warranted, so I probably would have had the same feelings
At one end of the scale for me is Rust. I discovered it through organic hype and I like the language but it's not successful enough for me to have found a job writing Rust.
At the other end is TikTok. I saw many ads for it before anyone I know ever talked about it. It's massively successful but it doesn't appeal to me in the slightest.
The approach he took in forming the opinion comes across as quite arrogant and error-prone.
""The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.""
is a fair comment.
To say that these are the good languages is hubris.
This comment didn't age well.
What the statement doesn't do is support the opinion that Java will be unpopular for being a bad language.
The thing that made Java succeed was the write-once-run-everywhere JVM and the huge effort spent by Sun, IBM, and others to make the JVM as good as it is.
Myself I do not like Java at all. But I like this article even less.
1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walking through the code with a debugger while jumping around the source code by semantics.
2. Standards. First its servlet, but soon web containers. Even in its early days, such standard made it much easier to write web applications. Engineers just needed to remember a few simple rules before producing concurrent web services.
3. JVM and all the toolchains. All the jconsole, jstack, jmap, gc logs, etc and etc. They may be norm now, but when they were productivity boosters when they first came out.
4. Java's standard libraries, especially the concurrency libraries. All those containers and high-level synchronizers are so much easier than the vanila mutex. This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
5. All kinds of JSRs, such as JAX-RS. You may hate them personally and passionately, but they do provide easy enough APIs and most importantly a standard for all kinds of frameworks to support. A Java programmer can easily switch from one framework to another without much learning curve.
I wonder how much Java success in early 2000's was related exclusive to this. I remember asking Java programmers why they liked it so much and all they talked was about IDE features and not the language itself. It looked like some couldn't even tell the difference between an IDE and a programming language.
I mean, this is why languages like Lisp and Smalltalk have such devoted fans...
Purists may scoff (pretty sure I did back then too), but now I think this is the ultimate compliment.
The default approach in Go is to use channels. The preferred idiom is "share by communicating". I think mutexes are overused by people who came from other languages and who aren't accustomed to channels yet. They spawn goroutines which communicate by sharing when it should be the other away around - no shared state with a few exceptions. I think there's no proliferation of synchronization primitives in Go because sharing state is considered a bad practice.
We aren't - we're using channels :)
Why is it amazing? Java was a well-compromised piece of PLT design, by a geek friendly company known for its engineering chops, with a very cool (hackable!) VM that allowed for both compiletime and runtime magic, and all this over and above the fairly well equipped standard library. (Beyond that, concerted Java hype in late 90s was ~same as what we saw later with RoR, Scala, Go, and now apparently Rust. Java may not be cool these days but it was the shiny thing in late 90s.)
> I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language.
Given that Java became spectacularly successful and still is, the question is why the author turned out to be so wrong? My guess would be that the author thinks the people he know (apparently all extremely competent "hackers" with great taste) is the kind of people who decide what becomes popular in the industry at large. We all live in our own bubbles.
I think the bubble of the author becomes apparent when he mentions Perl positively compared to Java. Sure, Perl is fun, edgy, powerful in weird ways, the opposite of Java in any way. But if I had to maintain complex code written by someone else, I would far prefer to maintain Java to Perl. I suspect the author is the kind of developer which never have to maintain code written by other programmers.
Also, this is not serious analysis, he twists motivations and reasons for certain Java decisions. He does not look at advantages and disadvantages to evaluate the language. Instead, he looks at how he can twist anything at had as inferiority. Note also how insulting the article is towards both original authors and "them, not real hackers using Java".
""" ...
7. It's bureaucratic. ...
...
9. It's designed for large organizations. ...
...
10. The wrong people like it. ...
...
"""
These might all be shades of the same underlying cause but, for me, this is exactly why Java has "failed" in many domains and "succeeded" in others. Precisely because it was marketed as boring technology that large organizations could use is the roots of it's success in business domains and it's failure in "hacker" domains.
Daniel Sockwell had a talk about the "Ideal Language for Writing Free Software" [0] and many of the points are mirrored about what makes a language well suited to an individual maintainer of a FOSS project that allow them to use its high skill ceiling and the programmers deep knowledge of the language are the things that business interests select against to allow for programmer fungibility.
[0] https://www.youtube.com/watch?v=MCKozTfcWr4
Paul Graham is a great writer, and a horrible technologist.
Java's Cover - https://news.ycombinator.com/item?id=21558053 - Nov 2019 (21 comments)
Java's Cover (2001) - https://news.ycombinator.com/item?id=10761400 - Dec 2015 (40 comments)
Java's Cover (April 2001) - https://news.ycombinator.com/item?id=4504375 - Sept 2012 (180 comments)
JAVA's Cover - https://news.ycombinator.com/item?id=3837711 - April 2012 (2 comments)
Java's cover (2001) - https://news.ycombinator.com/item?id=1182743 - March 2010 (2 comments)
Every LISP codebase is different, the language is famous for making your own „DSL“s. Every Spring Boot codebase is similar. One of those approaches doesn’t scale in terms of collaborators.
huh, that's a big statement.
I used to love java... I could write pretty much anything with it.
Websites? sure, there's a ton of stuff for that.
Command line programs? that's the basic.
GUI programs? pick between awt, swing and swt... and there was qt-jambi too!
server programs? no problem.
mobile apps? J2ME is nice!
That was ~15 years ago... to say no one loved it seems a bit dumb, frankly.