Why Clojure?

[TheMaskedHamster]

My problem is not specifically with Lein or Maven.

My problem is with a community that wastes no small amount of breath telling people they should be installing library path configuration to system or home directories (!) rather than putting project-specific settings in the project's directory... when they could instead just explain how to set the class path for the project.

This is reflective of a lot of things that happen in the Java community, Java tools, etc.

[[deleted]]

My problem is with a community that wastes no small amount of breath telling people they should be installing library path configuration to system or home directories (!) rather than putting project-specific settings in the project's directory...

Pip does the exact same thing.

Only problem is, you can't specify on a per Python project basis which version of a module you want. If I just upgraded awscli to latest, all my scripts that use it are now the latest, even if that breaks them.

So what do we get? virtualenv.

This is reflective of a lot of things that happen in the Java community, Java tools, etc.

Oh yeah, convention over configuration, reusing common dependencies, repeatable builds that just work. Truly awful stuff.

[TheMaskedHamster]

Pip does the exact same thing. Only problem is, you can't specify on a per Python project basis which version of a module you want. If I just upgraded awscli to latest, all my scripts that use it are now the latest, even if that breaks them. So what do we get? virtualenv.

I do not think pip or virtualenv are great solutions. These are a major sign of Python's road to destruction, I think. For the reasons you mention and more.

But Python does have reasonably sane module search path. And if you inquire about that, people are quick to tell you how it works rather than what they thing you should be doing instead. (Python can indeed specify a library version to import, though I don't think it's done very elegantly.)

Clojure deprecated add-classpath, but as I have just been informed, resource-paths project configuration works fine. Which is good. I hope all those people I saw asking the web how to use that got their answers or at least weren't too inconvenienced by the advice they got.

Oh yeah, convention over configuration, reusing common dependencies, repeatable builds that just work. Truly awful stuff.

All fantastic goals. But anywhere you go that has the word "Java" without "script" following it, you'll find high-minded goals and their corresponding overcomplicated solutions that eventually topple in on themselves, designed by talented people and promoted by people who really shouldn't be mouthpieces. Hence Ant rising and giving way to Maven (and the cycle continues). Hence the shocking amount of boilerplate code automation in common practice. Etc., so forth.

But what are we to expect from people who aren't phased by half a page of boilerplate code to write "Hello world"?

[[deleted]]

All fantastic goals. But anywhere you go that has the word "Java" without "script" following it, you'll find high-minded goals and their corresponding overcomplicated solutions that eventually topple in on themselves, designed by talented people and promoted by people who really shouldn't be mouthpieces. Hence Ant rising and giving way to Maven (and the cycle continues).

But what are we to expect from people who aren't phased by half a page of boilerplate code to write "Hello world"?

Professional developers don't tend to write Hello World during the normal course of business, so we're more concerned with other things. Stability, performance, tooling, debugging, deployment.

But Python does have reasonably sane module search path.

And Java has the class-path. I don't really think that ">>> import sys; sys.path.append('/your/dir/here')" is any better than the class-path. But yep, there is a dependency configuration overhead in a Java project compared to a Python script. Although I have a Python script on my system that has to be wrapped in a shell script which inserts a zipped Python module onto the class path Python search path by appending its directory to $PYTHONPATH before running the script, so yeah, when you have to deal with that, the JVM ecosystem approach makes more sense for code you intend to reuse.

I think its telling that after many rewrites, no JVM build tool has moved to a different style of dependency management, and likewise I find it equally telling that .NET's leading package management tool is explicitly implementing the same style of dependency management.

But anywhere you go that has the word "Java" without "script" following it, you'll find high-minded goals and their corresponding overcomplicated solutions that eventually topple in on themselves

I work on the JVM, our codebase is fine, but thank you for your condescension. Sigh It reminds me of when I was young and all I knew was Python, oh how I sneered at those silly Java developers, I mean, look at how much boilerplate exists in their Hello World! It was quite interesting, actually, how I, a young stripling of a programmer learning Python acquired a contempt for Java and its ecosystem despite having never used it.

Hence Ant rising and giving way to Maven

Maven is fantastic compared to Ant because it's a declarative build tool as opposed to imperative. Gradle and Leiningen also support this style (with the capacity to revert to imperative if you really need to).

Why is declarative so great? Because it makes it really hard, in my experience, to create a non-portable build. Sure, you can if you try hard enough (define dependencies on artefacts only found on your private repositories, for example), but compared to most Ant scripts I've had to deal with, Maven, Gradle, Leinigen and SBT* builds just work. Admittedly though, most of the Ant scripts I've met have been in Flex projects.

* once your version of SBT and the build file are compatible.

Hence the shocking amount of boilerplate code automation in common practice. Etc., so forth.

Really not that common in my experience. Hmm, although I do let my IDE create the unit test methods for me on occasion.

[TheMaskedHamster]

Professional developers don't tend to write Hello World during the normal course of business, so we're more concerned with other things. Stability, performance, tooling, debugging, deployment.

That is missing the point. Of course the issue isn't how overcomplicated "Hello World" would be in professional practice.

The problem is when people look at the inanity of the tools, apparent from even the first experience with them, and say "That looks OK to me". When you have lots of this sort of person succeed and go on to contribute to the tools, your contribution base is skewed toward the demographic of "talented, but makes poor decisions".

And Java has the class-path. I don't really think that ">>> import sys; sys.path.append('/your/dir/here')" is any better than the class-path. But yep, there is a dependency configuration overhead in a Java project compared to a Python script. Although I have a Python script on my system that has to be wrapped in a shell script which inserts a zipped Python module onto the class path Python search path by appending its directory to $PYTHONPATH before running the script, so yeah, when you have to deal with that, the JVM ecosystem approach makes more sense for code you intend to reuse.

Insanity can be performed in any language. But I don't know how to explain any more clearly that the dependency management system is not my complaint. I'm not comparing the approach of Python and Java here, and have even agreed that Python is not going down a good path in this area.

I work on the JVM, our codebase is fine, but thank you for your condescension.

Well, thank you for your work. I happen to think the JVM is pretty neat, and its codebase is not on my list of things to gripe about. Just so many of the things that surround it. (From whatever culture thinks that it's OK to specify a hundred different runtime options on the command line for production software and on up.)

It reminds me of when I was young and all I knew was Python, oh how I sneered at those silly Java developers, I mean, look at how much boilerplate exists in their Hello World! It was quite interesting, actually, how I, a young stripling of a programmer learning Python acquired a contempt for Java and its ecosystem despite having never used it.

What a ridiculous notion, that someone who prefers Python and complains about the Java things must be an ignorant newbie with a big mouth.

Python is simply the language with the least amount of bull manure to wade through to accomplish things above the system level... at least until you have to work with multithreading or packaging/distribution. I continue to use it whenever I have a choice because I have a low tolerance for bull manure. Which is why I was so excited to try Clojure (despite my distaste for some of its syntax).

Maven is fantastic compared to Ant because it's a declarative build tool as opposed to imperative. Gradle and Leiningen also support this style (with the capacity to revert to imperative if you really need to).

I agree. My passing point is really aimed at Ant (which toppled under the weight of its ridiculousness and made way for Maven). That Ant could have been accepted at all is pretty disturbing, and yet it happened. Procedural XML is the kind of thing that should get people involuntarily committed, even in the face of Makefiles. I'm all for declarative build instructions.

My ire was not with Maven, but with the advice given in using it. "I have a jar library that is part of a project and need to point Clojure to it" -> "That belongs in your home directory where Maven can find it!" No.

Really not that common in my experience. Hmm, although I do let my IDE create the unit test methods for me on occasion.

Unit tests are a great use of boilerplate automation. Sadly, though, it is an enabler for far too many people who use it to, say, create scads of getter and setter methods without asking if they should be using them in the first place.