|
BurntCornMuffin posted:the XML format needs to finally die.
|
# ? May 15, 2019 12:50 |
|
|
# ? Jan 15, 2025 06:13 |
|
BurntCornMuffin posted:Out of curiosity, what issues? I've used both over the years, but I like Gradle far better: it's more flexible, its build files are nicer to read, and the wrapper is great for enabling people to build without having to install the program. hot take: xml is fine. jason certainly isn’t any better. xslt is real bad though
|
# ? May 15, 2019 12:52 |
|
leper khan posted:hot take: xml is fine. jason certainly isn’t any better.
|
# ? May 15, 2019 13:11 |
|
xslt is like a torniquet: the right tool, but did you want this problem?
|
# ? May 15, 2019 13:20 |
|
BurntCornMuffin posted:Out of curiosity, what issues? I've used both over the years, but I like Gradle far better: it's more flexible, its build files are nicer to read, and the wrapper is great for enabling people to build without having to install the program. gradle is tremendously slower first off. since it has to do a bunch of compilation just to evaluate the build steps, once a project gets sufficiently large and complex enough, it will take forever for your IDE to parse it. since maven's POM format is well-defined (in that there's a schema), changes can be parsed immediately without spinning up a JVM. second, until VERY recently, gradle had no mechanism to globally define dependency versions. you either had to use variable substitution, or a 3rd party plugin (such as spring's dependency-management-plugin), which of course, made your builds even slower since it actually creates a poo poo-ton of detached source sets for each dependency. hell, it had no way of importing a BOM, either. in maven you can declare everything in </dependencyManagement> and all your modules could inherit the version. if you have a big library or some sort of common BOM of dependencies, boom, just use the "import" scope. finally, until the last year or so maybe, gradle had no concept of provided dependencies, so bringing in things that you are expected to have at runtime required you to define new logic to exclude those dependencies from the output. also, letting people execute scripts in any loving order in the build system is chaos. maven's format is much easier to read, has a defined schema, and does everything gradle can do, but better. gradle is OK if you want to spin up a tiny project really fast, or if for god forsaken reason you need to write an android project (lol), but that's about it. also even though it's not a first class citizen, there's a maven wrapper that works just like the gradle wrapper.
|
# ? May 15, 2019 13:40 |
|
I like using build.gradle.kts because gently caress Groovy
|
# ? May 15, 2019 14:16 |
|
a typed language is definitely better but there's definitely a bit of jarring syntax issues when you are using a plugin that doesn't have the kotlin bindings written for it.
|
# ? May 15, 2019 14:19 |
|
CRIP EATIN BREAD posted:gradle is tremendously slower first off. since it has to do a bunch of compilation just to evaluate the build steps, once a project gets sufficiently large and complex enough, it will take forever for your IDE to parse it. since maven's POM format is well-defined (in that there's a schema), changes can be parsed immediately without spinning up a JVM. gradle is not any better than maven for tiny projects so there really is no point to it.
|
# ? May 15, 2019 14:24 |
|
also xml is extremely good and json is part of the javascript dumpster fire
|
# ? May 15, 2019 14:25 |
|
Shaggar posted:gradle is not any better than maven for tiny projects so there really is no point to it. shaggar was right
|
# ? May 15, 2019 14:37 |
|
gradle is fuckin horrible all of our Jenkins jobs were orchestrated with it and it was a nightmare
|
# ? May 15, 2019 14:39 |
|
Wait no that was groovy. are these things different
|
# ? May 15, 2019 14:39 |
|
hey angulords, what's the verdict of template vs reactive forms? template seems like a more intuitive way to build it to me, but it feels like angular wants you to use reactive forms real bad HoboMan fucked around with this message at 14:58 on May 15, 2019 |
# ? May 15, 2019 14:40 |
|
Bloody posted:Wait no that was groovy. are these things different They are: Groovy is a standalone scripting language that runs on the JVM. Gradle is a build system that expresses its scripts in a language based on Groovy, or more recently, Kotlin.
|
# ? May 15, 2019 15:17 |
|
Groovy also pretends to be a real-life language that my predecessor regrettably used to build a bunch of lovely Grails applications.
|
# ? May 15, 2019 15:27 |
|
Powerful Two-Hander posted:another day, another hour spent explaining Git to the offshore team. how someone ended up with 7 consecutive commits trying to revert a change that still failed to actually revert it I'll never know. 7 different Stack Overflow answers to the wrong question
|
# ? May 15, 2019 16:38 |
|
Shaggar posted:also xml is extremely good and json is part of the javascript dumpster fire this. people who hate xml are idiots. some moron argued with me that json is better because "it has types that map better to programming languages than XML" and I just responded with "lol @ writing a parser and model mapper by hand"
|
# ? May 15, 2019 16:44 |
|
Data was a mistake.
|
# ? May 15, 2019 16:45 |
|
eschaton posted:7 different Stack Overflow answers to the wrong question lol no that's my commit history over the last day trying to make jquery validation work properly with dynamic rules i *think* they were trying to revert to a commit after the one they actually wanted to revert so it would never have done anything but I can't figure out how they managed to have an "empty" revert in the first place. anyway I showed them how to do a reset so it'll be fun when they take that knowledge and use it to blow away their own changes by mistake
|
# ? May 15, 2019 16:57 |
|
Powerful Two-Hander posted:lol no that's my commit history over the last day trying to make jquery validation work properly with dynamic rules git reset HEAD~7 && git push -f
|
# ? May 15, 2019 17:30 |
|
hey taqueso posted:Data was a mistake.
|
# ? May 15, 2019 17:36 |
|
taqueso posted:Data was a mistake. He is not less perfect than Lore!
|
# ? May 15, 2019 18:38 |
|
BurntCornMuffin posted:I like Gradle far better: it's more flexible, its build files are nicer to read these two things are incompatible. the moment someone takes advantage of that "flexibility" - usually by pasting in a huge chunk of code from stack overflow - the readability goes out of the window, and just figuring out how the build works now requires an in-depth intimate understanding of gradle's internals (which change from version to version, of course) and, typically, the entire groovy programming language too. if you just use gradle as "maven with fewer angle brackets" then it's fine i guess, but there's no way to enforce using it that way, so any non-trivial gradle build will, over time, gradually turn into a fragile monster that literally nobody understands. it's a shame because gradle has some nice ideas, like some of the recent changes to how dependencies work do seem good, but the fact that it defines builds in terms of a script written in a dsl rather than purely declarative data? that automatically makes it irredeemably bad, and no amount of good features can ever make up for this fundamental flaw.
|
# ? May 15, 2019 18:44 |
|
cjs: just got done with a 2 hour conf call with The Russians about errors we keep getting in their production branch. It was supposed to be a 10 min fix which of course turned into 2 hours and included an argument between a senior dev and junior dev along the lines of "why did you think this was ever working properly?" After 2 hours, we resolved most of the errors but introduced a hard freeze somewhere. "Well, this is in your modifications so now you resolve it. *disconnect*" At which point The Russians all bug out of the call and I'm left stammering about "but it's YOUR master branch..." Now CEO's bro-in-law is here and he smells like stale hippie bong water and is literally stinking up the whole office, rn. I guess he's visiting from out of town and is watching shaolin videos in some kind of weird app on our couch. I am soooooooo done for the day.
|
# ? May 15, 2019 20:25 |
|
Bloody posted:gradle is fuckin horrible all of our Jenkins jobs were orchestrated with it and it was a nightmare jenkins job dsl was a loving mistake
|
# ? May 15, 2019 21:01 |
|
are there any good dsls
|
# ? May 15, 2019 21:19 |
|
animist posted:are there any good dsls Otherwise, I guess VDSL is a good DSL.
|
# ? May 15, 2019 21:48 |
|
eschaton posted:git reset HEAD~7 && git push -f git add -A && git commit -am "`curl -s http://whatthecommit.com/index.txt `" && git push -f origin master
|
# ? May 15, 2019 21:57 |
|
animist posted:are there any good dsls no, but ulsd is the least bad (mlmp)
|
# ? May 15, 2019 22:29 |
|
animist posted:are there any good dsls i'm okay with linq-like dsls
|
# ? May 15, 2019 23:38 |
|
DONT THREAD ON ME posted:i'm okay with linq-like dsls
|
# ? May 15, 2019 23:41 |
|
mystes posted:The version of the syntax that people actually use is barely a DSL, though. that’s probably why it’s still good
|
# ? May 15, 2019 23:56 |
|
the only moral dsl is my dsl
|
# ? May 16, 2019 00:44 |
|
Numpy, all that araayfuckin poo poo Tk and other poo poo like that
|
# ? May 16, 2019 00:50 |
|
if your "dsl" is idiomatic, readable syntax in an existing language: great if your "dsl" has an actual parser with comprehensible error messages: great if your "dsl" does not fall into either category: bad
|
# ? May 16, 2019 00:54 |
|
the only linq worth using is just a well designed functional api on generic collections
|
# ? May 16, 2019 02:29 |
|
so what's the opinion in here of Go, might be in my future as a backend
|
# ? May 16, 2019 03:44 |
|
it's got a name that's good for making puns with and is pretty mediocre otherwise. it still makes all the same mistakes that older languages made instead of taking the opportunity to fix them, and doesn't really bring anything exciting to the table. It's just ... kinda there. it's inoffensive enough that you probably won't be constantly wishing you could rewrite the entire project in something more sensible, though. so in and of itself it shouldn't scare you away from the job.
|
# ? May 16, 2019 03:53 |
|
i know you can do a lot in go but i would be extremely apprehensive doing anything larger than small utilities for a greenfield project. i know go people like to say generics aren't needed, you need SOME sort of mechanism to get templating or whatever. once I see a ton of interface {} then i feel like dying. for some reason standard C89 seems easier to follow than go code. i've used it for some things that would otherwise be in a bash script except it needed some sort parallelism.
|
# ? May 16, 2019 04:10 |
|
|
# ? Jan 15, 2025 06:13 |
|
I'm currently working in go and agree with these two points. I imagine it would feel fresh and innovative. ..in 1975. For small poo poo it's reasonably fine but as soon as you start to try making reusable code it suffers because there's no decent package managing approach that is not just a github public repo. Nil handling is annoying but not broken with enough linters shouting at you. Okay it is kind broken if you do == nil because not all nils are equal to each other sobyou gotta do != nil at all times. What are your requirements? I would probably recommended C#, python, F#, kotlin, swift, or rust depending on your requirements for speed/hiring/deployment etc etc
|
# ? May 16, 2019 05:27 |