Hacker News Reader

Comment by sgift | Hacker News Reader

> huge complicated tools.

Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause that's something completely different.

> I tried using Kotlin and step one is always install Intellij.

So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"

View on HN

No I want to use the command line.

https://maven.apache.org/guides/getting-started/maven-in-fiv...

Maven quick start first command:

> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Then it generates stupidly deep Java structure.

and next you have to write a verbose xml. They even say:

> The POM is huge and can be daunting in its complexity

All of this stuff is verbose and built to be generated by IDEs. It's not clear, it's not concise.

> The POM is huge and can be daunting in its complexity

Because they are honest. Maybe it is because I'm more accustomed to poms, but the package.json/babelrc mix and webpack.config.jsons are daunting to me too.

Web ecosystem is a mess as well. What I meant was Rust, Elixir, Erlang build/project files. Those are trivial.

You don't have to use maven directly. Something like https://github.com/bodar/jcompilo would be much simpler and faster for a small project.

Maven is a "bad example" - it's horrible. Everybody agrees.

> Then it generates stupidly deep Java structure.

It generates enough structure to scale up to reasonable projects. The nesting is a price well worth paying for consistency. Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

> All of this stuff is verbose and built to be generated by IDEs. It's not clear, it's not concise.

Verbose is worth it for clarity, particularly in a file you edit rarely. It may not be concise but it absolutely is clear, as the example from your own link shows.

> It generates enough structure to scale up to reasonable projects.

It generates stupidly deep structure because Java requires a stupidly deep structure.

> Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

Rust, Elixir and Erlang achieve this with tooling that is practically trivial to use. Without an IDE.

> Verbose is worth it for clarity, particularly in a file you edit rarely.

Being concise is a big factor in clarity.

> It generates stupidly deep structure because Java requires a stupidly deep structure.

All of the depth is useful. The folder structure corresponding to the package structure makes it much easier to find the source for something.

> Being concise is a big factor in clarity.

True when there is large-scale structure that varies for the reader to comprehend. Less important in an inert declarative structure. Again, look to the example you linked.

I'm sure the tooling is useful and a lot of it reasonable. I've never approached a Java project that I did not find intimidating, either Android with all the Gradles and XML.

I've never seen a barebones project as you would when using just node+npm without all the extra tooling (webpack and friends). Node+npm is to me as simple as python+pip. Is there a natural counterpart, Java+maven or something?

And to be fair. All my attempts at approaching webpack have been even worse. And most JS-framework seed projects are similarly complex and automagical.

I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it.

The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... . That shows what the minimum looks like - a pom.xml, and application source code in src/main/java (under its package structure). (The unit test isn't strictly necessary but is good practice).

The pom's XML header and modelVersion are boilerplate, but the rest is pretty clear and self-explanatory (though admittedly verbose).

At that point for a library project you're sorted, for an application you can run your program via "mvn exec:java" which is adequate for development. To actually package up your application for distribution you probably want to use the shade plugin a la https://maven.apache.org/plugins/maven-shade-plugin/examples... , but that's something you'd do as part of "productionisation". (Back when I worked at an early-stage startup we had things running and serving user requests via "mvn exec:java")

Appreciate the overview. It sounds similar to what I'm used to but, as you say, perhaps a bit more verbose. And some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

Most dynamic languages tend to be more straight-forward with this.

> some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

That's kind of our way to do virtualenv-like functionality, which is mandatory rather than optional. (Or you can specify the classpath manually in the same way you would for the pythonpath, but no-one wants to do that). IMO that's the right thing - having libraries installed in my system python has only ever caused trouble in the long- or even medium-term, even if it makes "hello world" use of libraries very slightly simpler.

There's probably a way to get a shell with the classpath set up correctly, but I always found that kind of modalness more confusing than helpful.

> I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

In my experience it does all work without any flags or extra knowledge. "mvn" is the entry point for all the things you want to do - you don't ever have to know that there's a "java" and "javac" underlying it.

> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Ah, I can see how this is much more complicated than the good old

    npm install webpack babel-loader babel-core babel-preset-es2015 babel-preset-react --save-dev

You don't need a build step for Node.js, 93% of ES6 features are already included in the latest version. Babel is more for client side than anything and that's because browser vendors take a while to implement new standards, so yeah JS has unique challenges and constraints as the de facto language of the web.

Or typescript frequently.

> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"

You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awesome Java IDEs are is disingenuous because Java is unusable without them.

Most Java people I know use IDEs mostly just to edit and debug the code, and does the builds/runs/tests from the command line.

What do you mean with "just to edit"? Aren't there any (compilation) errors, warnings displayed anywhere?

Yeah there are, sorry, a this point I consider them basically auxiliary editor features. I forgot that some other languages don't have this luxury.

> because Java is unusable without them

This is like saying 'Javascript is unusable without IDEs', you know.

And this is making Java look good how exactly?

This makes all programmers liking to write code with maximum level of comfort - e.g. using IDEs.

Getting a node server running the first time is actually very difficult. The libraries constantly change so fast tutorials frequently don't work. It was easy once I understood everything, but it wasn't easy the first time at all.

Reply on news.ycombinator.com