7 ms·

This reminded of the "layers of crap" John Carmack was talking about once. Java is an impressive tech, but I still fail to understand why it is so popular. It

• Spooky23 8y ago
  There are companies and governments paying massive premiums for things like Unisys and Wang mainframes, which are mostly VMs running on a Xeon chip in a box that you can’t open. They are doing this because it’s expensive or impossible to move the code for a variety of reasons. I’m familiar with Java systems that have been replatformed a dozen times without incident and on the cheap.
  • le-mark 8y ago
    So your claim is wang and unisys systems are still being built and sold? Do you have further detail on this? Very interesting indeed.
    • sulam 8y ago
      I don’t know if they’re still being built, but parent didn’t make that statement. You can be paying for something even if there aren’t more of them coming off a factory line.
    • twoodfin 8y ago
      Oh yes! https://assets.unisys.com/Documents/Global/ProductInformationSheets/PI_170236_ClearPathForwardLibra8480_8490.pdf https://assets.unisys.com/Documents/Global/ProductInformatio...
    • Spooky23 8y ago
      I don’t know about Wang, but you can absolutely purchase Unisys mainframes, whose product lines are all descendants of ancient Univac and Sperry devices. Can’t go into a lot of detail, but I’d suggest starting here: https://en.m.wikipedia.org/wiki/OS_2200 https://en.m.wikipedia.org/wiki/OS_2200 The hardware itself is x86. IIRC, they had some custom ASIC to do some physical isolation of workload, but that may not be a thing anymore. Fortunately, I don’t need to deal with it anymore!
    • pjmlp 8y ago
      Unisys still sells ClearPath MCP mainframes, which descend from Burroughs B5000, developed in 1961 using a variant from Algol (ESPOL) as safe systems programming. Zero Assembly, ESPOL exposed all required hardware features as intrisics. https://www.cs.uaf.edu/2010/fall/cs441/proj1/b5000/ https://www.cs.uaf.edu/2010/fall/cs441/proj1/b5000/ https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems Based on feedback they rebooted ESPOL as NEWP, which is still the systems programming language from ClearPath MCP. Not only it was already a kind of safe systems programming language, 10 years older than C, it already had the notion of unsafe code via unsafe modules. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products https://www.unisys.com/offerings/clearpath-forward/clearpath... Here is a PR leaflet about NEWP and safety on modern versions of ClearPath https://assets.unisys.com/Documents/Global/WhitePapers/WP_170213_ClearPathMCPUnsurpassedSecurityMCP.pdf https://assets.unisys.com/Documents/Global/WhitePapers/WP_17... NEWP programming manual https://public.support.unisys.com/aseries/docs/clearpath-mcp-16.0/pdf/86002003-406.pdf https://public.support.unisys.com/aseries/docs/clearpath-mcp... The computing world would have turned out much different if AT&T had been allowed to sell UNIX right from the beginning.
    • dfox 8y ago
      They are built and sold in the similar sense as above mentioned AS/400 is built and sold. The user-visible CPU architecture is from the start designed as VM abstraction provided by the OS, which itself runs on real hardware that does not necessarily use same instruction set. Thus the today's hardware is something essentially off-the shelf (x86 in the unisys case, power for as/400). On the other hand S/360 ("the mainframe") compatible hardware is still being manufactured by IBM and AFAIK even Fujitsu (which in addition to being S/360-compatible mainframe supplier themselves also bough Amdahl, which was the original IBM-compatible mainframe manufacturer, with the company/founder name saying a lot ;)).
  • gaius 8y ago
    I’m familiar with Java systems that have been replatformed a dozen times without incident and on the cheap AS/400 went from 48-bit CPUs to 64-bit without even a recompile
    • PeCaN 8y ago
      It achieved that in a similar way to the JVM though, architecture-independent bytecode. That said, it's still incredibly impressive that System/38 programs can run unmodified and without recompilation on modern POWER8 (soon POWER9) systems. Sadly not all software can be as well-architected as AS/400.
      • dfox 8y ago
        It works in significantly different manner, there is no JIT, but TIMI gets AOT compiled into native(-ish) code (that is in turn cached in persistent storage) transparently by OS/400 when first run. But the process is hidden and fast enough to look like some kind of JIT VM.
• lultimouomo 8y ago
  > Not to mention the gargantuan bloat that are JEE and system like maven or ant. It feels really different and foreign compared to the simplicity of unix many devs are used to. You can crap on Java all you like, but it takes a real weirdo to prefer autotools over maven.
  • nobleach 8y ago
    If I had it to do over again, I'd probably switched to Erlang or something. There just was no REALLY good solution in the early days of the web. (Not that Erlang is a good choice for e-commerce)
  • freedomben 8y ago
    Hahahaha, fair point. I do prefer autotools over maven, and I admit to being a weirdo. I also love awk and sometimes spend down time writing clever awk scripts to parse data. Weekends can get pretty wild ;-) I think it really comes down to how well you the know the tool. You can take the nastiest most esoteric language and compare it to a truly beautiful one, and still prefer the former if you know it well. I've experienced this personally with bash for example. Bash is a gross language, but I love it because I know it really well. Elixir is a beautiful language, but I'm a total newb at it still and so I prefer bash to elixir. Anyway, thanks for the lols :-)
    • yedava 8y ago
      Clever scripts tend to be easy to understand only for the author. Heck, even the author sometimes will have difficulty understanding the cleverness of their own old code. Since Java enterprise applications can easily live on for a decade or more, it is important that they not be "clever" and be easy to maintain. Developers can come and go. New team members should be able to dive into and grok the code right away.
      • freedomben 8y ago
        If we were talking about "what I would do at work" then I would agree with you. Fortunately however the awk scripts that I hack in my down time are not even usually saved. It would be much like criticizing people who play regex golf because the regexes can be hard to understand. That code is never meant to be used for anything other than the immediate satisfaction it brings. If anyone ever did see them, it would be because they either hacked me, or I showed it to them related to some conversation about awk scripts. However I also disagree on the definition of the word clever wrt workplace. I often consider the simplest and most straightforward implementation to be the most clever. Anyone can write impenetrable code that confuses people. Not many people can solve the problem at hand in an elegant, simple fashion.
• nobleach 8y ago
  You'll have to remember the time when it was created. The idea of "write once, run anywhere" was considered a huge net positive. It can run on your Big Iron, and it can run on your watch. The fact that it was quickly adopted into education at the time led to it being used by many post grads. It's firmly entrenched in many enterprises due to Oracle (which perhaps rightly deserves a place in the enterprise) TELLING everyone "if you're serious about enterprise, if you're serious about scale, you'll use Java". This has led to the "no one has ever gotten fired for recommending we use Java" attitude in large corporations. While it was completely painful to use in the early days, it actually has gotten much better. But I'll agree, people were calling it "enterprise" when it was just a huge bloated XML nightmare.
• ddtaylor 8y ago
  Many like Java for the write once run anywhere concept combined with memory safety. These can be achieved with C++ (std and RAII respectively) but it's less likely a less experienced developer will do that correctly in C++ and enterprises like solutions where you can throw more man hours at a problem with the lowest common denominator.
  • pjmlp 8y ago
    Not that easily in 1996, when ANSI C++ was only finished in 1998 and by 2003 compilers were still not fully compliant.
    • ddtaylor 8y ago
      It's still pretty hard today even with good C++ standards. If I give a less skilled developer a problem to solve in Java I may not get as optimised a solution, but I don't have to worry about his code segfaulting or opening up RCE unless he really went out of his way to do so making code review a lot easier for low hanging fruit.
      • pjmlp 8y ago
        Quite true, the copy-paste compatibility with C was a bless for its adoption, and now has become a curse, impossible to take away. There is always that guy using a C++ compiler as if writting C.
• pjmlp 8y ago
  Microsoft decided to rewrite Minecraft in C++, because there are no Java compilers for game consoles and they are a big C++ shop.
  • bitmapbrother 8y ago
    Microsoft didn't rewrite Minecraft in C++. It was rewritten in C++ by 4J Studios that were contracted to do so by Mojang in order to bring Minecraft to the consoles. Microsoft did create the Windows 10 edition and likely reused a lot of the code developed by 4J Studios.
    • pjmlp 8y ago
      Faire enough, but the reasoning was still lack of Java compiler support and Microsoft's decision to keep one codebase instead of two parallel ones.
• oftenwrong 8y ago
  What makes Maven "gargantuan bloat"?
  • realusername 8y ago
    just have a look at the introduction to pom.xml: https://maven.apache.org/guides/introduction/introduction-to-the-pom.html https://maven.apache.org/guides/introduction/introduction-to..., it's very easy to see
    • oftenwrong 8y ago
      Could point out something concrete?
• ecopoesis 8y ago
  Java won for a bunch of reason: 1) It’s fast. Like almost C/C++ fast. Yes like any language you can write crappy slow code in Java but it is fast by default. 2) While certainly not an easy language it is a simple language. The number of footguns in Java is pretty small. There’s only a little of magic that languages like Ruby and Python have. Which of course means the programmer has to be more specific and add lots of boilerplate. And if you get it wrong the compiler yells loudly. And there’s none of the memory management ceremony from C/C++ that everyone gets wrong constantly. GC can lead to hard to explain madness but your basic enterprise CRUD app is never going to see that. 3) The standard library is awesome. Things like Java collections and concurrency just work: no fuss. And when you need to reach into the back of the tool cabinet the defacto STL provided by Apache is incredible. Need something super specialized like an ordered bidi map in a tree? Apache’s got one and I have faith it’s well tested, decently performant and has good documentation A decade ago Java could be terrible. There were a lot of people pushing giant XML confine. But even then you could always use code and smart folks did. Today the XML stuff is kept for comparability but the world has moved on. Modern frameworks end up looking and acting a lot like Rails.
  • whatshisface 8y ago
    >There’s only a little of magic that languages like Ruby and Python have. >And there’s none of the memory management ceremony from C/C++ that everyone gets wrong constantly. These statements are the spitting image of the Blub essay[0]. No matter what language you like, the world splits into languages where you have to do lots of things manually with high risk of mistakes, languages that have tons of sneaky implicit behavior, and your language. [0]http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox
    • sanderjd 8y ago
      The "blub paradox" is an opinion piece; it is not gospel. I did a bit more than two thirds of my career in non-"blub" languages. I like those languages, I know them well, I am good at them. For the last couple years I've been writing Java. I find it to be a much better tool for the job. A little bit more typing really isn't a very big deal.
• jmartrican 8y ago
  > it requires additional software to run Many languages require additional software to run. > Java is an impressive tech, but I still fail to understand why it is so popular. I used to write C++ as my goto general purpose language. After using Java once I was hooked. It was much easier to do stuff and manage my dependencies. I think Java has 3 things going for it. 1) The ecosystem is huge. To dethrone Java for backend do not just compare another language to Java, you have to compare its ecosystem. Java has a huge ecosystem especially with Spring Boot tieing many of the most popular parts of that ecosystem together. 2) Speed. Some languages are easy to use. Some are very fast. It seems to me that if one were to quantify ease and speed and plot a min-max graph, Java would be up at the top... best performance with ease of use. 3) Here I am going to throw a hodgepodge of things that can be argued but when taken together amounts to a big deal. Reliability (its used in so many places that by the time you go to write your code rest-assured you are not stumbling onto a new bug), write once, swap JVM's, advanced garbage collection (G1 and beyond, GC is something that is constantly being tweaked and improved), evolution (Java evolves with the times, it biggest gripes became the next thing being addressed), Maven/Gradle (advanced dependency management and build orchestration... these tools are very powerful), Junit/mockito and other testing tools (very powerful testing suites).
  • victor106 8y ago
    +1 for Spring boot and the Spring ecosystem in general. I said it here a few weeks back, Pivotal(the company behind Spring) continue to keep that ecosystem innovative, modern, stable and performant and open sourced. That’s amazing... We had a few rails developers work port some of their apps to Spring Boot, they struggled initially but after getting over that hump their feedback was it’s light years ahead of rails in terms of ease of use and performance. Easy of use = Groovy & Kotlin both of which compile to the JVM The real game changer is when Spring runs on GraalVM. Once that happens it would be really really hard to beat java on the backend
    • tannhaeuser 8y ago
      I agree Spring has for most intents and purposes won the framework wars (which however also speaks to the relative stagnation in that space). What do you specifically expect from Spring running on GraalVM? I'm not sure about the availability and maturity of the new-fangled Graal/Truffle/SubstrateVM stuff. I've being eying migration strategies away from the JVM for quite some time now, and towards JavaScript specifically due to its momentum and portability. Both Oracle and RedHat (or their employees as personal projects) had been running efforts for a node.js-compatible runtime system on the JVM several years ago. Now GraalVM provides a polyglot runtime for JavaScript and Ruby, but my understanding is it'll be commercial-only once it's released. So in a way, Oracle is preparing a Java exit strategy themselves :)
• tannhaeuser 8y ago
  I can only speak for myself, but around 1997 MS totally dominated the desktop marketplace, and made also significant inroads into server territory (Linux wasn't a thing as enterprise server O/S until around 2003), so Java and Sun was seen by many as a way to evade MS ActiveX/COM/VB programming, and to save Unix. And that was accomplished indeed. Java thrived on the dot-com bubble when large amounts of e-commerce backends were developed, many of which being maintained until today due to Java's very strong backward compatibility. Java continued to be a strong choice for the server-side because of the massive mindshare and ecosystem. Today I'm not sure where Java is heading. I don't blame Oracle for trying to make money from Java, but recent news - releases being quickly pulled from downloads except for money, unbundling of packages from the JRE/JDK, deprecation of JEE/transfer to the Eclipse foundation, Graal/Truffle being commercial offerings rather than part of OpenJDK, the nashorn JavaScript engine being deprecated, etc. - seem out of character for what Java has stood for most of the time. For the first time in many years it's plausible (though not certain!) that Java use is going to slowly demise once a tipping point is reached where new developers aren't going to invest into it. As to maven: when it was new I hated it with a passion. As time went by it was growing on me because of it's predictability when you're working as freelancer on many projects. Even npm/yarn respectfully mention it as the inspiration and reference for a successfull and mostly well-designed package manager.
• ww520 8y ago
  It's an easy and simple language to learn and use. It has excellent performance. Very readable and thus easy to maintain. Most important, it let you concentrate on your domain problem rather than fighting the language. It gets the job done!
• jwr 8y ago
  JVM != Java. I've been using the JVM in production systems for nearly 8 years now without having written a single line of Java code. I am extremely happy with the VM I'm getting for my Clojure code: implementing virtual machines is very difficult, especially ones with good performance. I am quite happy I don't have a single-global-lock problem, that I get modern garbage collection algorithms, and impressive JIT compiler magic. Thanks to the JVM I rarely encounter any performance problems, and when I do, they are easy to solve (don't do stupid things).
• bane 8y ago
  The JVM is incredibly impressive technology. There's literally millions of man hours poured in the runtime and it's able to run Java (and other languages) code at near C/C++ speeds across an incredibly diverse set of hardware and OSs. The Java language is a remarkably small language that achieved a great many of its design goals (safe to write, simple, object oriented, high re-usability, good for large scale teams to work with etc.). The language has carefully grown in design to include some other paradigms without turning into the language Cthulhu that C++ is. The standard library is almost the maximum of batteries included. It's aged reasonably well -- not perfectly, but pretty well. It was smartly designed to be virtually self-documenting and emerged early with good tools and philosophies around that goal. The common secondary libraries are also pretty incredible, with first tier support for almost everything from ML to embedded systems. Deployment is also really great. Before the latest fashion of containers and orchestration, you could spin up an app server and dump a single entirely self-contained JAR on it and you'd be more or less deployed. Some really hard problems in terms of monitoring, packaging and other issues have a good community approach. If there's a real problem with "Java" it's the big-Enterprise culture that has emerged around it, and the lack of technical depth in many work-a-day Java devs. But this is also by design, as many enterprise software jobs are really just data plumbing and don't need AAA rockstar algorithm designers. For people outside of Java-land (myself included), FizzBuzz Enterprise Edition is funny because it amplifies very real observations of the Java community and culture that we don't like. But not every run-time and language has to be equally used by every developer. These are tools. If C is a great tool for artisinal kernel development, Java is a great tool for assembly-line workers and heaven help us if people tried to switch those uses of the languages. It would be like carving handsoap with a chain saw and building bridges with tweezers.
  • pjmlp 8y ago
    That culture did not emerge with Java, rather the Taligent, CORBA, DCOM, MTS archtects moved from VB/Delphi/C++/4GL into Java and applied the same patterns. J2EE was based on Sun's initial attempt to use Objective-C with CORBA.
• textmode 8y ago
  "... I still fail to understand why it is so popular." It was repurposed. As you wrote, "I don't think it's very popular in the manufacture of embedded controllers." A theory: There is a large population of programmers who want to write bloated programs. They will use whatever is made available to them to do it. They will prefer whatever makes it easier. This has become a "market" that others want to serve. The supporting anecdote I always remember is the small scripting language AWK. It was not designed with the intent to write large scripts/"programs". However, if I recall correctly, Kernighan commented that he was surprised to learn that is what users were trying to do with it before Perl existed.