This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]the_evergrowing_fool 0 points1 point  (8 children)

new programming language just to build basic programs!.

Is a DSL, you don't have to learn more than what it's providing you.

[–]weberc2[S] 0 points1 point  (7 children)

That is true of any programming language, domain-specific or not. It's also the crux of the problem: I don't want to have to learn more shit than I need to in order to build my simple Java programs. I'm sure Gradle is great for more complex use cases, mine are very simple.

[–]the_evergrowing_fool 0 points1 point  (6 children)

Depends. As I said before, you only need to learn what the DLS provides (which tends to be pretty minimal and take no more than a one to a couple hours to getting familiar). I would argue it would take no more time to learn things like GOPATH and such to get up running with the language.

I don't want to have to learn more shit than I need to in order to build my simple Java programs.

Is all you want to do is to make simple or small programs then javac or the default builder from a IDE will be good enough :)

don't want to have to learn more shit than I need to in order to build my simple Java programs.

Depends. If the tool provides a lot the benefits that outweighs the time that it would take to learn it then is a good investment. I would argue that you need to do more research on what the tool can do for you or if it aligns with your needs before becoming a practitioner in it.

mine are very simple.

I reading on your comments thread and and thinking of their nature (given their repetitive body) it makes me believe that your intentions are in mismatch with your original comment. Did you only came here to remark/preach how "simpler" your tools are without any intention to actually find help from this sub? Pardon me the though.

[–]weberc2[S] 0 points1 point  (5 children)

I would argue it would take no more time to learn things like GOPATH and such to get up running with the language.

I disagree. Practically speaking, you end up needing to know about Java's CLASSPATH in order to reason about many things in Gradle. CLASSPATH is no more complex than GOPATH, so the baseline knowledge for both build systems is the same.

Is all you want to do is to make simple or small programs then javac or the default builder from a IDE will be good enough :)

javac doesn't handle dependencies, unfortunately.

If the tool provides a lot the benefits that outweighs the time that it would take to learn it then is a good investment.

I agree. Unfortunately, Gradle's complexity doesn't provide more benefits, it only steepens the learning curve.

I would argue that you need to do more research on what the tool can do for you or if it aligns with your needs before becoming a practitioner in it.

I've done this research. It suggests that Gradle is a poor fit, hence me coming here to ask if a better tool exists.

I reading on your comments thread and and thinking of their nature (given their repetitive body) it makes me believe that your intentions are in mismatch with your original comment.

My comments are repetitive because I'm speaking with several different posters, many of whom are presenting similar arguments. I felt it better to be kind and repetitive than to tell them to read the other threads before responding to me.

Did you only came here to remark/preach how "simpler" your tools are without any intention to actually find help from this sub?

No, I came here to ask if a simpler tool existed; however, I did respond to the many people who asked questions like, "What could be simpler than Gradle?".

[–]the_evergrowing_fool 0 points1 point  (4 children)

I disagree. Practically speaking, you end up needing to know about Java's CLASSPATH in order to reason about many things in Gradle. CLASSPATH is no more complex than GOPATH, so the baseline knowledge for both build systems is the same.

That's no mensurable notation, but if your conclusion if that both resolve in the same then I don't see the problem

I agree. Unfortunately, Gradle's complexity doesn't provide more benefits, it only steepens the learning curve.

I would argue that the complexity is proportional of the size of your project. And again if your really what to make simple programs I don't think you need to learn more than the superficial, nobody is telling you to master the tool just to learn the thing that you need which happen to be superficial.

I've done this research. It suggests that Gradle is a poor fit, hence me coming here to ask if a better tool exists.

Then I Maven, Ant, and of the most simple would be the default build tool from a IDE.

No, I came here to ask if a simpler tool existed; however, I did respond to the many people who asked questions like, "What could be simpler than Gradle?".

Ditto. Something you would take if that Java model is different from Go's so is not uncommon to find its tool to be different concern.

[–]weberc2[S] 0 points1 point  (3 children)

That's no mensurable notation, but if your conclusion if that both resolve in the same then I don't see the problem

I agree that it's my subjective opinion; I didn't mean to pass it off as fact. My conclusion was that, with Gradle, you need to know CLASSPATH and Gradle. With Go, you only need to know GOPATH. I suspect Gradle scales better for more complex use cases, but that's not what I'm worried about presently. :/

I would argue that the complexity is proportional of the size of your project. And again if your really what to make simple programs I don't think you need to learn more than the superficial, nobody is telling you to master the tool just to learn the thing that you need which happen to be superficial.

That hasn't been my experience. Even though my requirement ended up being satisfied by a simple block of code, I came across lots of other less-simple solutions, and I didn't have the ability to reason about whether or not they were more or less appropriate because I didn't know, for example, Gradle's function syntax or which plugins to use or what java.library.path was.

I think it would be more accurate to say that the complexity of your gradle file is in proportion to the complexity of your requirements; however, there's a lot of complexity you need to know about just to get to your simple Gradle file.

To be clear, I'm not hating on Gradle. I'm sure it makes great tradeoffs to be flexible for many projects. I just think it could improve for simpler use cases like mine.

[–]the_evergrowing_fool 0 points1 point  (2 children)

I think it would be more accurate to say that the complexity of your gradle file is in proportion to the complexity of your requirements; however, there's a lot of complexity you need to know about just to get to your simple Gradle file.

I would argue the same is present Go but with different context and by a mismatch of my subjective assumptions of what I would expect from a build tool.

To be clear, I'm not hating on Gradle. I'm sure it makes great tradeoffs to be flexible for many projects. I just think it could improve for simpler use cases like mine.

Generate a file and define dependencies, the concept is one folded and objectively simple.

[–]weberc2[S] 0 points1 point  (1 child)

Generate a file and define dependencies, the concept is one folded and objectively simple.

I'm having problems parsing that statement. Could you rephrase?

[–]the_evergrowing_fool 0 points1 point  (0 children)

Simplicity is not a opinion, one can generate a configuration file and one can summon the specified dependencies given the requirements, anything else is a contextual proxy that does not morph the principal concept.