4 ms·

"java" and "cool" in the same sentence doesn't compute for me. I die a little inside every time I'm forced to launch eclipse and work with The Old Stuff. Actua

• crusso 10y ago
  I agree. I dipped both feet in those and other Java technologies and I really had trouble enjoying programming. It always felt like I was fighting with configuration, JAR versions, and other useless complexity. I don't even want to think about all the dozens and dozens of hours I wasted fixing Maven problems. Now that functional languages are showing how easy it is to handle the increasing number of CPU cores, Java just looks like a dead end... except maybe for use as a Scala VM. But if you're going to move away from Java, it's also good to move away from the problems of the JVM. Personally, I've gone with Erlang/Elixir on the BEAM, giving me access to the brilliance that is the OTP.
• gdulli 10y ago
  I was in a similar place where Java (and the other languages I knew at the time) had made programming stop being fun. I started to wonder if I needed a new career. But instead I learned Python and it made programming fun again. That was 8 years ago and it's still fun.
  • meddlepal 10y ago
    I'm the exact opposite. I hate writing Python. The language is far too loosey goosey to be productive in beyond small little tools. I feel like I am constantly fighting the packaging system, tool chain, ecosystem and documentation. Java and more recently Kotlin keep me sane and make developing a pleasure. The ecosystem is remarkably consistent. I'm working on a Python code base right now and everyday feels like being punched in the kidney repeatedly on the hour.
• libria 10y ago
  > Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago. One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things? > I die a little inside every time I'm forced to launch eclipse Intellij's your healing potion then.
  • algesten 10y ago
    > One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things? It's hard to pinpoint one single thing that is the problem, but I suppose I can summarise it with that I don't think java is especially productive. The language is rather verbose in modern terms (compare it to something with type inference like swift or rust). The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time. Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")). Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc). The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security). It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however). Things like ORMs (Hibernate and EJB) meant most people just forgot how RDBMs work and threw crazy hardware at the persistence layer to compensate for lousy performance (ORMs are typically fine, users not understanding how they work are the problem). It's owned by Oracle. I could probably go on, but it's bed time.
• pjmlp 10y ago
  > Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago. Imagine the fun of doing that in C and C++ before Java was known to the world. It used to be called COM, CORBA, OLE 2.0, DCOM, SOM. Any language in a EE environment suffers from space architects.
  • algesten 10y ago
    HAHAHA! One of my first projects were to interact Java with some Oracle CORBA. OMG. That was actually worse than EJB Entity Beans that followed.
• paulmd 10y ago
  > Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago. Most of those things aren't even Java-specific. IOC is just a design pattern that asks you to consider whether you should be writing a web server or, say, a request controller that runs on a web server. Since the web server invokes your controller method when it gets a request, we say "control is inverted", because the server is actually driving your application. You are surely doing something similar in any other language you choose, whether or not they tell you it's IOC. As a whole - from the user (programmer) perspective, Java EE is in fact mostly just a collection of such IOC patterns that have been provided for you to "fill out". This is a servlet template, this is a filter template, etc... XML is XML, nobody argues that it's not verbose, but it's not difficult to write. With a DTD file specified, an intelligent editor like IntelliJ will suggest element/attribute options for you, which is about as easy as it can get. It's certainly better than a properties file where you don't get any auto-suggestions, but if you want something a little more imperative you can also configure most components programmatically now (i.e. you get a configuration object that you can set settings on, then you call "build()"). Spring and Hibernate both support it, at a minimum. Glassfish is just an application server. I don't use it, Tomcat is more than enough for most web apps and in fact you can usually get away with a "thin" server like Jetty in most cases. Spring is such a broad topic that it's almost pointless to talk about. Are we talking about just Spring? Spring MVC? Spring Test? Spring Boot? Spring Security? Each of those solves something different, and frankly each of those also happens to do it much more cleanly and efficiently than anything that came before. Having worked with Struts and directly with low-level Servlets, Spring MVC is a breath of fresh air. The basic Spring is just a dependency injection system. For most people, that boils down to a nice way to auto-build your ORM instance and inject it into your controllers. You can take it or leave it, it's about a page of code to replicate it in most applications, but it gets increasingly useful in more complex applications and with more complex use-cases because it lets you side-step the question of what environment you're running under in the code itself, and push that into configuration. You can run integration tests against a specific testing database, a SQLite you set up just for the test, etc, and the application doesn't need to know. Maven is actually the most fantastic thing about the entire Java language. It's a universal project file format that is understood by every single IDE on the market, no more messing around with putting libs in classpath. It's also one of the few 100% reliable packaging systems that I've ever worked with, it will Just Work, 100% of the time, no matter your environment. I've spent so much time fighting pip and bundler over system libraries that need to be installed, 64-vs-32-bit problems, not liking cmd or Cygwin environments, etc. The only complaint I can make about Maven is that you can't just pass it a directory of libs and say "include these"... but it's very obvious why it doesn't do that, it kind of destroys the purpose of explicitly specifying your dependencies. The solution of declaring a local repository inside your repo is less than obvious, but it works. And again, on the whole it's much better than Ant. I would actually rather use a makefile than use Ant. In general you're right that there's certainly tools that will let you overengineer things if you try. Who could argue with that in a world where AbstractSingletonProxyFactoryBean exists? A lot of this comes out of patterns promoted in the book Effective Java, which is pretty much the definitive tome on the subject and is actually mostly very sensible stuff. But people read "maybe think about using a builder instead of getters/setters", totally miss the point (making objects immutable) and run with it, and soon you've got BuilderBuilderFactory and all kinds of other nonsense floating around just because they're blindly following the pattern instead of thinking it through. The actual problem in Java is that there's 20 years of such cruft and mistakes built up in some frameworks, but other languages are not free from the same effects. The key is figuring out what subset of features and patterns you actually need and ignoring the rest. Java is not a one-size-fits-all solution where "There's Only One Way To Do It", it's a massive toolbox and you probably aren't going to need those Torx screwdrivers to change your oil. If you try to use everything in every project just because it's there, you're going to have a bad time. But you can rest assured that you have options if you ever need them. If you're looking for a curated system of tools that are known to work well together, I urge you to consider Spring. Spring MVC is your equivalent to Rails, running it in Jetty is usually more than enough for basic web apps. The Apache Commons libraries are also very good for taking the edge off of some of the verbosity (they provide high-level equivalents to common operations on low-level objects), and are very high quality in general. Also, to agree with a sibling comment, IntelliJ is definitely the way to go. Jetbrains stuff is just always so perfectly on the money.