5 ms·

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to

by agentgt 10y ago

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers. Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local dependency management.

snuxoll 10y ago
> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed. Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all. Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.
- agentgt 10y ago
  I pretty much agree entirely but have been too ashamed to say it :) The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages. As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).
  - snuxoll 10y ago
    > I pretty much agree entirely but have been too ashamed to say it :) I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days. Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands. > As a tech decision maker I would love to build future projects with Rust or OCaml I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(
- gerbilly 10y ago
  I too think maven (from 2.0 onwards anyways) is awesome. It's also declarative, BTW, which is a big improvement over Ant. Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
  - snuxoll 10y ago
    > It's also declarative, BTW, which is a big improvement over Ant. It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome. I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it! > Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters? A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.
    - tome 10y ago
      > whatever that haskell build tool is (name escapes me right now). I guess you mean Shake.
      - snuxoll 10y ago
        Cabal.
- voltagex_ 10y ago
  NuGet is the current way of doing packages for .NET and get the same experience as mvn package.
  - snuxoll 10y ago
    Not even close. Just because Visual Studio will automatically download packages from NuGet when you click 'build' before it executes MSBuild doesn't mean your build server does, or when executing a build from the command line. They are two completely independent tools with almost no integration with each other, beyond maybe stuffing an MSBuild task in to handle nuget package restore before it loads any plugins. With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best. NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.
    - voltagex_ 10y ago
      You're right. I hope they get there eventually - NuGet has a lot of attention at the moment due to it being a critical component of .NET Core. Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzConfigs/nuget.config https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...
mhd 10y ago
> Linux/Unix was barely known to most developers. As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly? But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.

by agentgt 10y ago

snuxoll 10y ago

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed. Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all. Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.

agentgt 10y ago
I pretty much agree entirely but have been too ashamed to say it :) The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages. As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).
- snuxoll 10y ago
  > I pretty much agree entirely but have been too ashamed to say it :) I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days. Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands. > As a tech decision maker I would love to build future projects with Rust or OCaml I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(
gerbilly 10y ago
I too think maven (from 2.0 onwards anyways) is awesome. It's also declarative, BTW, which is a big improvement over Ant. Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
- snuxoll 10y ago
  > It's also declarative, BTW, which is a big improvement over Ant. It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome. I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it! > Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters? A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.
  - tome 10y ago
    > whatever that haskell build tool is (name escapes me right now). I guess you mean Shake.
    - snuxoll 10y ago
      Cabal.
voltagex_ 10y ago
NuGet is the current way of doing packages for .NET and get the same experience as mvn package.
- snuxoll 10y ago
  Not even close. Just because Visual Studio will automatically download packages from NuGet when you click 'build' before it executes MSBuild doesn't mean your build server does, or when executing a build from the command line. They are two completely independent tools with almost no integration with each other, beyond maybe stuffing an MSBuild task in to handle nuget package restore before it loads any plugins. With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best. NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.
  - voltagex_ 10y ago
    You're right. I hope they get there eventually - NuGet has a lot of attention at the moment due to it being a critical component of .NET Core. Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzConfigs/nuget.config https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...

mhd 10y ago

> Linux/Unix was barely known to most developers. As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly? But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.