Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

151–160 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#151
post #55

Earlier quoted context omitted.

> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwd…

My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like: Collections.sort(myList, new new Comparator () { public int compare(E o1, E o2) { return 01.val-02.val } } (You cou…

I don't use Java but the equivalent in C# is literally `thing.OrderBy(p => p.Whatever);`. So even simpler than your example.

The boiler plate code has been disappearing in C# a lot faster than Java, but I believe Java is catching up.

So needing an IDE to actually edit code to relieve the tedium of boilerplate is is not the case these days, although you still need it to manage things like references, I'd not want to manage that myself.

Re: Why Everyone Eventually Hates or Leaves Maven

#153
post #7

This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going ba…

Is switching tools really so catastrophic? I have emacs keybindings burned into my muscle memory but just about every tool I use supports them. But if I'd insisted on sticking with Emacs instead of moving in the mainstream (Xcode & IntelliJ for mobile) I would have ultimately been much less productive than I've been after spending a week getting my head around more specialized tools.

Switching tools isn't a problem if you can massage tools to be a similar as possible.

I install a vi plugin anywhere I can. Most of the time this bridges my mental gap. There is nothing worse than a half working vi plugin though.

Re: Why Everyone Eventually Hates or Leaves Maven

#154

Earlier quoted context omitted.

The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.

That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.

Does this already exist? Based on the top result I get from a Google search for 'maven copy file' [1] this seems to be not very well solved. The top response in that Stack Overflow page recommends calling out to a completely different build tool. It seems like part of the problem is that frequently you will have several plugins that each solve part of a problem but it is difficult to combine the plugins so they solve the complete problem. This seems to result in a lot more 'reinventing the wheel' because something that should be easy involves a lot of hoop jumping.

[1] http://stackoverflow.com/questions/586202/best-practices-for...

Re: Why Everyone Eventually Hates or Leaves Maven

#155

Earlier quoted context omitted.

That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.

Does this already exist? Based on the top result I get from a Google search for 'maven copy file' [1] this seems to be not very well solved. The top response in that Stack Overflow page recommends calling out to a completely different build tool. It seems like part of the problem is that frequently you will have several plugins that each solve part of a problem but it is difficult to combine the plugins so they solve…

The stack overflow question is about copying files to a remote server during a build, not just copying a file to a directory. Use http://maven.apache.org/plugins/maven-resources-plugin/examp... — if your build copies files to a remote server you have other problems.

Re: Why Everyone Eventually Hates or Leaves Maven

#156
post #30
post #4

It's a trade-off, right? As most things in software are. Recently, I inherited a project that had 10,000s of lines of ant scripts. Resource constrained, I didn't have anyone to maintain that build process. So, I took a few hours and converted those projects to several hundred lines of maven 'scripts'. Now, it works way better than the previous system, because now I can have a person focused on coding features, rather…

> maybe grails is the right answer The poster probably means gradle. I am not pointing this out to be pedantic, but because it's not a given that every reader will know their way around the universe of build tools.

Oops - typo. Yeah what he said

Re: Why Everyone Eventually Hates or Leaves Maven

#157
post #86

Earlier quoted context omitted.

And then the person that wrote them leaves and we're fucked. Where in the article does he say in-house tools are better? His point is about tool composability. Just because you haven't run into the wall he describes Maven having yet doesn't mean it doesn't exist. He says as much in fact. He recommends starting with maven till you outgrow it which seems perfectly reasonable.

I think you missed the point. The problem with comparability is that you have the freedom to compose things however you want to. It's not exactly uncommon for "composable" build systems to be all but inscrutable to the next guy. The consistency of an opinionated build tool does provide some not insignificant benefit.

s/The problem with comparability/The problem with composability/

Re: Why Everyone Eventually Hates or Leaves Maven

#158
post #73

Earlier quoted context omitted.

agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your o…

I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over la…

This also lets you easily publish internal artifacts for others to consume. It is definitely necessary for any medium size or above team.

Re: Why Everyone Eventually Hates or Leaves Maven

#159
post #148

Earlier quoted context omitted.

Very similar to my view of Emacs. It doesn't matter whether I'm on my Mac, my work Ubuntu, or SSHed into a Debian server, my development environment is the same. With Cygwin, I can even make it work on Windows (heaven forbid! ;). It is nice to have the biggest context change be "where is my source here?"

Emacs runs native on Windows; no need for Cygwin.

Of course, but a reasonable chunk of my development work happens in shells. It continues to shrink over time, but there are a lot of things pipes can handle better than lisp. :) I would be lost without it.

Re: Why Everyone Eventually Hates or Leaves Maven

#160
post #145
post #41

> Donald Knuth was asked to write a program to solve this text handling problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. He wrote a program consisting of more than ten pages of Pascal, designing (and documenting) a new algorithm along the way. Then, Doug McIlroy demonstrated a shell script that would easily fit within a…

I guess it is part of the idea that you can ignore that. The shell script is _good enough_ for 80% (I made this up) of use cases. Knuth's solution is probably faster and requires less resources but if I want to reverse the filter order or change something else You are way faster using the shell script. It's also probably not so difficult to look up how each of these tools work internally to make an informed guess on…

To be more precise, I think the biggest problem with this anecdote is the notion that this guy somehow "one-upped" Knuth by coming up with a pragmatic rather than a theroetically optimal solution. Knuth is a mathematician after all, and if someone asks him to write a program they're implicitly asking for a mathematical result, not an unremarkable engineering tool.

So no, taking this anecdote at face value, this guy didn't "one-up" Knuth; they were effectively answering two different questions. There is more to computer science than finding the simplest shell script to solve the 80% case.

Post reply on HN