4 ms·

You can understand Java hype in 1997 by understanding it as selling the Java of about 2007, but Java of 1997 couldn't deliver. Both because it was a young langu

by jerf 1y ago

You can understand Java hype in 1997 by understanding it as selling the Java of about 2007, but Java of 1997 couldn't deliver. Both because it was a young language, and had all the problems of a young language like poor library support for just about everything, and because the hardware in 1997 wasn't ready to deliver on the hype. Even in 1997 we weren't really looking for web pages to take 60 seconds to "start up", and that could easily happen for a "Java applet" on a home computer. (Or worse, if trying to load the applet pushed the system into swap. In this era 32MB-64MB would be normal amounts of RAM and the OS, other apps, and the browser have already eaten into that quite a bit before Java is trying to start up.) And then it was fairly likely to crash, either the applet itself, or the whole browser process. And it was just about shoved down our throat. They paid to get it into schools. They paid for ads on TV that just vaguely said something about Java being good, because they didn't really have anything concrete they could point to yet. They paid to have really bad enterprise software written in it and then jammed into schools just to make sure we had a bad experience, like Rational Rose [1]... my memory may be failing me but I think it was implemented in Java at the time, because it was a Swing app (another Java thing shoved down our throats but not ready for prime time even by the standards of 1997). I was using it as an undergrad student in 1999 or so and I couldn't hardly click on a thing without crashing it. Not the best look for Java, though I'm sure it was not Java qua Java's fault. Still, it fits the pattern I'm trying to show here of it being grotesquely hyped beyond its actual capabilities. They shoved enough money at it that they did eventually fix it up, and the hardware caught up into the 200xs so it became a reasonable choice. Java isn't my favorite language and I still try to avoid it, but in 2025 that's just a taste and personal preference, not because I think it's completely useless. But I feel bad for anyone in the 1990s ordered by corporate mandate to write their servers in Java because the ads look cool or because Sun was paying them off. It must have been a nightmare. In fact, you can understand the entire Dot Com era hype as selling the internet of about 2007 in 1997, or in some cases even 2017. It all happened, but it didn't all happen in the "year or two" that the stock valuations implied. [1]: https://en.wikipedia.org/wiki/IBM_Rational_Rose https://en.wikipedia.org/wiki/IBM_Rational_Rose

derriz 1y ago
> Both because it was a young language, and had all the problems of a young language like poor library support for just about everything, and because the hardware in 1997 wasn't ready to deliver on the hype. Outside of Perl’s CPAN, library support in 1997 sucked for all languages. Being able to write a hash-table or linked list C was a valuable commercial skill as nearly every single code base would include custom versions of these sorts of very basic data structures rather than pull them from a commonly used library. “Using a 3rd party library” meant copying a bunch of source code downloaded from who-knows-where into your source control repo and hacking it to work with whatever funky compiler and/or linker your project used.
- jerf 1y ago
  I mean even by the standard of the time, though. The Java hype meant that if a UI wasn't written in Java, it sucked, so everything had to use the Java UI. But even as young as Windows still was at the time, the UI toolkits were much more developed than the Java ones. The Java ones looked like they were written to a bullet-point list of the minimal features they needed to shove them out the door, in a new language nobody knew, which is probably because they were. As with Rational Rose, even as a student I could ram straight into a brick wall of missing features every direction I turned. I can only imagine what a professional of that era had to deal with. Compare that with a modern student, where they may still not know how to do a given thing but their main problem is that they don't know how to find or evaluate the hundreds of options that exist. I know that it wasn't like it is today where a casual weekend hobby project can easily pull in a few hundred libraries with just a couple of shell commands, but you still needed some things to get going. It was theoretically possible to sit down with a blank text editor and write assembly code that functioned as a GUI app, the last few dying gasps of that philosophy were around, but it's not what most people did.
  - derriz 1y ago
    Well that’s a more specific criticism - that AWT sucked. I won’t defend Java GUIs from the period having worked on a 1990s Java AWT based GUI application. Although, SWT apps like eclipse were decent enough. I think in the context of the time, Java was simply following the common least-common-denominator approach, common for cross-platform GUI toolkits at the time - tcl/tk was hot at the time as were commercial products like powerbuilder. This approach was to only include features/funtionality which mapped directly to native for all supported platforms - Mac, windows and some X11 toolkit. There were convincing arguments for this approach at the time - you got native look and behavior from the same code for all platforms Java ran on, like with TK but it quickly came apparent that this approach was a technological cul-de-sac limited to simple dialogs and form-based GUIs.

by jerf 1y ago

derriz 1y ago

> Both because it was a young language, and had all the problems of a young language like poor library support for just about everything, and because the hardware in 1997 wasn't ready to deliver on the hype. Outside of Perl’s CPAN, library support in 1997 sucked for all languages. Being able to write a hash-table or linked list C was a valuable commercial skill as nearly every single code base would include custom versions of these sorts of very basic data structures rather than pull them from a commonly used library. “Using a 3rd party library” meant copying a bunch of source code downloaded from who-knows-where into your source control repo and hacking it to work with whatever funky compiler and/or linker your project used.

jerf 1y ago
I mean even by the standard of the time, though. The Java hype meant that if a UI wasn't written in Java, it sucked, so everything had to use the Java UI. But even as young as Windows still was at the time, the UI toolkits were much more developed than the Java ones. The Java ones looked like they were written to a bullet-point list of the minimal features they needed to shove them out the door, in a new language nobody knew, which is probably because they were. As with Rational Rose, even as a student I could ram straight into a brick wall of missing features every direction I turned. I can only imagine what a professional of that era had to deal with. Compare that with a modern student, where they may still not know how to do a given thing but their main problem is that they don't know how to find or evaluate the hundreds of options that exist. I know that it wasn't like it is today where a casual weekend hobby project can easily pull in a few hundred libraries with just a couple of shell commands, but you still needed some things to get going. It was theoretically possible to sit down with a blank text editor and write assembly code that functioned as a GUI app, the last few dying gasps of that philosophy were around, but it's not what most people did.
- derriz 1y ago
  Well that’s a more specific criticism - that AWT sucked. I won’t defend Java GUIs from the period having worked on a 1990s Java AWT based GUI application. Although, SWT apps like eclipse were decent enough. I think in the context of the time, Java was simply following the common least-common-denominator approach, common for cross-platform GUI toolkits at the time - tcl/tk was hot at the time as were commercial products like powerbuilder. This approach was to only include features/funtionality which mapped directly to native for all supported platforms - Mac, windows and some X11 toolkit. There were convincing arguments for this approach at the time - you got native look and behavior from the same code for all platforms Java ran on, like with TK but it quickly came apparent that this approach was a technological cul-de-sac limited to simple dialogs and form-based GUIs.