The long strange trip to Java (1996)
blinkenlights.com
blinkenlights.com
Honestly - and this may sound weird - the biggest thing that struck me about this was that there were so many established respectable companies actually doing innovative stuff with operating systems and graphical environments. It feels like the gap back then between deep technical work and customers was so much smaller. Must've been an amazing time to be in the industry.
https://cs.gmu.edu/~sean/stuff/java-objc.html
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
Wow on him being a pedophile though. This story got weirder and weirder.
I had not seen Patrick's take on that fateful budget meeting before and it was interesting to read it. My recollection of the events are somewhat different.
As I recall, the business plan that was pitched suggested that the OS that was being targeted for widespread Java adoption was the Windows release code named "Chicago" (aka Windows 95). There was a widespread belief that Sun was in the process of "ceding" the workstation market to Microsoft as they couldn't afford to put Solaris on x86 without cannibalizing their own hardware business. At the time, Dave Rosenthal (a Sun Distinguished Engineer at the time) had circulated a paper that basically said, "Unless we change dramatically the desktop belongs to Windows NT." At the budget meeting (in February) Wayne put his pitch out there and Scott McNealy hit the roof (he really really disliked Microsoft). He wanted to fire whomever came up with that plan, and Wayne artfully stepped sideways and said it was all Patrick's idea[1].
The end result was that Wayne came back from that meeting, told the team that Sun was shutting down First Person at the end of the 1994 Fiscal year (June 30th, 1995) and that we should reach out to find other jobs within Sun or elsewhere because we wouldn't have our current job come July 1st. James negotiated with Sun Legal to release it "open source" so that when we were out job hunting we could point at something that others could look at to evaluate what we had been doing. They agreed and we did a really low key announcement of that in March just before the World Wide Web conference in Darmdstadt Germany. I had managed to get included in the small number of people going to that conference along with Mark Scott Johnson who was the manager at the time.
The San Jose Mercury news put our "low key" release announcement on the front page of the paper. That resulted in it being picked up by a lot of press outlets who talked to local engineers who gave it glowing reviews. When I showed up at the conference there was a small vendor exhibit area where Sun was going to be showing off the brand new SparcStation 20. The sales guys were in a PANIC because everyone was asking to see "Java" and "HotJava" and they didn't have any collateral to give them or demos. I spent a long night before the exhibits opened helping them download and install Java, and did probably four or five "training" sessions where I gave the sales guys enough to talk about.
Of course with that level of customer "impact" the thoughts of shutting down First Person became a memory and everyone back at HQ was maneuvering to have Java be part of their organization. It was hilarious when Bill Joy came out to congratulate us and tell us that now we knew Java was going to be successful we could put some world class people on it. I don't think he meant it the way it came out, or maybe he did, but either way it didn't have the impact he might have wanted.
Patrick had already left for Starwave at that point so he didn't get to see the shift internally. It was a pretty amazing thing though.
[1] Have I mentioned that the politics at Sun were pretty ruthless?
Low and behold I instead found out the guy is a convicted Paedophile...
I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now. I know it's not as beautiful but it's definitely easy enough to read, easy enough to debug and edit. I don't want to make a new file for every, little, thing. I just want to process some data here and make a script there and handle problems, not code.
This is just my perspective.
From an outside perspective, I had the impression Java devs would migrate to Kotlin.
I had the impression the Java build system was rather convulted.
My "convulted build system" experiences all came from Maven and Gradle.
Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own.
Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
I guess, for me, everything that is XML is just convulted legacy stuff.
Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless.
I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know.
Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX.
Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries.
Kotlin Flow is the answer for observability and rx-like reactive programming.
Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system.
I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.
Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.
Isn't exactly this happening now with Rust?
https://www.opengroup.org/openbrand/register/
Note that ISO C is part of POSIX certification.
Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
Personally I moved from Java to Go, and couldn't be happier with it. Easy to use, easy to understand, similar advantages for debugging, but had some of the same proliferation of files at times.
I've injected a bit of python into my workflow too if I just want to do a quick data-oriented task.
Beauty is in the eye of the beholder. My list of beautiful languages does not include Java. Yours does.
Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines.
The syntax can be a little tricky at first, and without an auto-complete IDE it's still damn near impossible to figure out what the correct 1-3 lines should be unless you're really up to date on the streaming collections APIs.
The bottom line is, things are still improving with every release on the developer quality-of-life front. I've been pleasantly surprised! Caveat emptor, all languages have their ideal use-cases and tradeoffs. There is no holy grail (yet).
> ftware engineers around the world to join our team, there's never been a better time to join than now! The most I can reveal here is that our cloud service is very popular. AI / ML / automatic speech recognition / NLP / chatbots are our bread and butter.
Makes this bit from the OP shine:
"Bill Joy ... was often comparing [Oak/Java] to more complicated and elegant languages like Python and Beta. He would often go on at length about how great [Oak/Java] would be if he could only add closures and continuations and parameterized types."
I'm sure they faced tradeoffs and Java's industry story is near unmatched so it's hard to argue they made categorically wrong tradeoffs, but imagine an alternate universe in which lambdas/closures and a few other features tamed verbosity and enabled python-comparable succinctness in Java back in the 90s.
Never got all the complaints about Java. It's a very versatile "good enough" language with a great ecosystem.
Getting performance increases for free (as in, no code changes required) by swapping JRE implementation is pretty schweet.
Try Clojure: https://clojure.org/guides/learn/syntax
It runs on the JVM, but is far more concise, easy-to-use, and even beautiful.
Java has moved on nowadays, to include concepts, which other languages have had for decades, finally coming around to it. It did "modernize" a bit, one could say. Lambda expressions, namespaces, not having to put everything in a class (how silly that would be, to still have to do that). However, that doesn't make it beautiful, because those concepts are bolted on, for backwards compatibility reasons. It is not like there has been a redesign of the language or anything. It is going a similar way C++ is or has been going. Adding new syntax. It has to go that way, because there is no good extensible concept of Java syntax. Its syntax is always only a snapshot of the current state, that says "this is what is valid syntax right now", instead of offering a flexible way to extend the language.
I want to use languages, which have incorporated concepts, which traditionally Java did not even have or use alternative concepts, which make things possible and in this way shorten my code significantly. Then I don't have to write 10000 lines for simple things.
No language, however beautiful it may be, will solve a problem of overlooked use-cases, which cannot be solved using the concepts implemented in a library or program. For me beautiful code is code, which implements the simplest concept one can think of, in the simplest way, to make all intended use-cases possible. This is what I call flexibility. It is about implementing the least amount of limitations, not hard-coding assumptions, which are not justified, but all invariants, which are necessary. Not programming oneself into a corner.
> I stopped using it because I stopped wanting to write 10000 lines for doing simple things.
My definition of beauty includes expressing simple things concisely.
The Long Strange Trip to Java
Not:
The Slow Boat to Java
Alternative languages have branched off of the language and have succeeded with great buy in. (Clojure, Groovy [I think it's past it's heyday], Scala, Kotlin, etc]. However, java hasn't kept up. Yes, they copied a few nice things. However they're just surface level things. They're still encouraging people to write procedural code and worry about weird things that other frameworks take care of you. (Weird concurrency issues, DSLs, etc)
What I'm talking about:
- Pattern matching (this comes from scala) - They're slowly trying to give you something useful in a switch statement. It's no where near as expressive and extendable as what Scala gives you. (They went from int based, to string based, to some minor features for matching )
- Optional - this really hasn't been workable for those who are constructing functionality. It still feels like a procedural thing that is preventing you from writing if null, it doesn't avoid nesting in Java. In scala this is just apart of the flow of your code.
- Records- My understanding of the introduction of this is that it was a little different from POJOs and it broke external libraries. However, this is been a need since the days before Lombok. Additionally Groovy and Scala had this support.
- var.. ok nice you are now allowing for type inference.. but why not do var and val
A lot of these enhancements have been bandaids on the situation.. not full lets rethink some things and make them better
Because of the Java ecosystem, e.g.
https://projects.apache.org/projects.html?language
https://marketplace.eclipse.org/
Looking at this I sometimes cannot help thinking, "One must be insane not to use Java."
(I use C++.)
See also, e.g. https://jackson.sh/posts/2021-04-java-underrated/
P.S. Perl's and Python's ecosystems are also great, but Java is (much) faster.
You really think AWS is going to be offering Clojure SDKs?
Remains to be seem for Kotlin but the others haven't grow enough to develop a big ecosystem of their own.
> AWS is going to be offering Clojure SDKs?
If enough people are using Clojure and it's nicer than using the aws-java-sdk. yes.
Scala has a pretty big ecosystem. There are lots of new and exciting things being built there. (This is what used to be the experimental frameworks, libraries and creative projects that used to exist in java)
"final var" is more consistent in Java.
Java in general is still a very versatile language with a lot of great tooling.