271–280 of 808 posts
Thanks for the two upvotes so far! Please feel free to leave criticism of the article or my writing; I'm trying to strengthen my composition muscle.
For my use cases, Java has all the wrong compromises: - not high level enough to compete with Python/Ruby/JS/PHP, etc - not low level enough to compete with Rust/D/Nim/Zig - not specialized enough to compete with Erlang/R/Go/Julia - not opinionated enough to compete with Lisp/Haskell So why use Java ? It's good, it's fast, it's productive, it's well supported, battle tested and documented for decades with a huge pool…
You use Java because it is low risk. I think it might be lower risk than any other language in terms of design patterns, hiring, library support, run-time surprises, etc. The language itself isn’t great though. Java solutions tend to be bloated and make it hard to decipher the underlying domain logic. I certainly wouldn’t pick Java for a small team of experienced developers.
Earlier quoted context omitted.
Eh, kinda still sounds like you did. Thanks for removing any doubt.
Perhaps you could enlighten me then? Rather than just posting low-effort, content-less, drive-by snark? The OP even says they're just posting their own selection criteria in other comments.
Earlier quoted context omitted.
Java is poor choice as a language for teaching programming. There are simply too many irrelevant bits that will get in the way of learning.
I think the opposite actually. Python, JS and C/c++ are full of idiosyncrasies. Java allows students to quickly get up and running and focus on the 'CS'. That said, Python might be more practical for anything applied in school.
If you extend your consideration to build systems and other tooling, it's easy to see that students have a lot to overcome with Java as an intro language.
I think purpose-built languages like the HtDP languages or Logo are better choices. Students can get started with zero faff, learn the essential concepts, and move on.
Java is a fine choice for higher level courses, with students that are already capable programmers.
I haven't been coding as long as most (about 10 years) but I've had phases of Java, Ruby, Python, JS, TS, ObjC, etc. If I go onto my GitHub and try to get any of my old projects running I am extremely confident that the non-Android Java ones will still work. All of the other ones will probably have "rotted" over the years and send me down a day-long rabbit hole looking for old dependencies or build systems. There's s…
Doesn't mean we don't touch old code (change idioms, generic safe, build process etc). It means we do it when there is value to us for updating it. Not because we are forced to due to an infra change.
At the same time code that ran on a PA-RISC machine now happily runs on a mac arm (even then it was great because the same code ran on PA-RISC, powerpc, x86 and X86-64).
If that code was written in python it would have likely gone through two breaking cycles at least. C sure that would have worked but the cost of having it working such a variety of systems would have been humongous for a small group like us. What real alternatives have this claim? C++ chances that I can compile code from 2000 without issues is minuscule.
Sure I had my EJB "fun", and when I look at some of the micro-services being deployed I see the same problems. Because they are reflections of organizations. (i.e. sometimes have the feeling that changing language in an org is like switching your in-office communication to Italian, because it so fast and romantic.).
Just because there was "bad" code written in the past doesn't mean new code is done that way. Yes it exists, yes it needs to be poked once in a while, but that is a lot cheaper than rewriting in a modern style.
Earlier quoted context omitted.
"You'll never want for X" means you'll never need X, you'll always have all of the X you could want.
I'm not good at English but shouldn't that be just "You'll never want X"?, "for" seems redundant to me. Anyway I looked it up, seems it's a legit usage, my bad.
Akin to "for want of a horse"
Another way to think of it is simply another slightly different meaning for the word "want". Just like in "for want of a horse", or "was found wanting", you can replace the word "want" with the word "lack" in all these examples.
"You'll never lack for work", "the project stalled for lack of engineers", "the code was found lacking"
"Want" may be used as a drop-in for "lack" in each of those.
You could also just say "lack work" instead of "lack for work". But that doesn't really make the "for" redundant. Though I can't explain the reason why not.
Maybe the "for" in "lack for X" or "want for X" is like the "for" in "look for X" or "wish for X"
Earlier quoted context omitted.
re Python: "...All actual work is done by C libraries though, you could just as easily use BASIC instead"
Well, believe it or not, VBA is doing to have to do with Python competition in Excel in a not so distant future: https://excel.uservoice.com/forums/304921-excel-for-windows-...
Any long time developer on MS stack knows that actually means "thank you very much but no".
Earlier quoted context omitted.
You use Java because it is low risk. I think it might be lower risk than any other language in terms of design patterns, hiring, library support, run-time surprises, etc. The language itself isn’t great though. Java solutions tend to be bloated and make it hard to decipher the underlying domain logic. I certainly wouldn’t pick Java for a small team of experienced developers.
I agree that Java is low risk from a manager responsibility perspective: nobody has been fired for choosing it for a long time. Now, from a project success perspective, I think it's not. I've seen a lot of Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system. I'd say from a project r…
these are properties of a poorly designed project, and isn't due to it being java.
You may be able to causally link the failure to the people on the project being "incompetent" - but that's not really the fault of java!
i say java is a pretty good language, if you have large teams, with varying levels of competency amongst the members. As long as you have somebody good to do the overarching design and direct the project, it would do relatively OK.
if you have a small, elite team, then it may not be the right choice (depending on the team).
Earlier quoted context omitted.
Python is generally less performant. Go has a smaller ecosystem. IMHO, YMMV etc.
Python code which uses stuff mostly from the standard libraries isn't really that slow. Parsing a JSON? Call a wrapped C function. Process a media file? Call a wrapped C function. If you keep the actual CPU-intensive stuff in C code, the ops executed by the Python interpreter can be negligent.
For my use cases, Java has all the wrong compromises: - not high level enough to compete with Python/Ruby/JS/PHP, etc - not low level enough to compete with Rust/D/Nim/Zig - not specialized enough to compete with Erlang/R/Go/Julia - not opinionated enough to compete with Lisp/Haskell So why use Java ? It's good, it's fast, it's productive, it's well supported, battle tested and documented for decades with a huge pool…
You use Java because it is low risk. I think it might be lower risk than any other language in terms of design patterns, hiring, library support, run-time surprises, etc. The language itself isn’t great though. Java solutions tend to be bloated and make it hard to decipher the underlying domain logic. I certainly wouldn’t pick Java for a small team of experienced developers.
Though it seems java in general attracts a culture of slow moving bureaucrats which doesn't necessarily translate into higher quality (in fact, I'd argue it translates into worse quality).