Java itself is kind of blissful in how restricted and straightforward it is.

Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language’s simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. “dependency injection”). This presents a big learning challenge to people encountering Java projects on the job: there’s a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.

People tend to conflate these two learning tasks (language vs practice), lumping it all together as “Java is complicated.”

$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.

Some articles showing the knock-on effects of this phenomenon:

• https://stackoverflow.com/questions/11865307/how-to-expand-size-of-java-stack-trace-to-see-bottom-of-stack-triggering-a-sta
• https://www.reddit.com/r/java/comments/16g30jx/can_java_errors_stack_traces_be_longer/
• https://www.quora.com/Why-does-the-Java-Spring-Framework-produce-gigantic-unreadable-stack-traces
• https://community.splunk.com/t5/Splunk-Dev/What-are-the-best-extraction-methods-for-Java-Stacktrace-Errors/m-p/380397
• https://stackoverflow.com/questions/65436457/springboot-stack-trace-logging-filter-only-from-my-packages

Yes, but “Proto Indo-European” doesn’t exactly roll off the tongue. /s

Put any distro in front of me and provided I don’t need to master it, I’m good. Ubuntu is fine. Debian is fine. RedHat is fine. Fedora is fine. I even have a tiny low-end system that is using Bohdi. Whatever. We’re all using mostly the same kernel anyway.

90% of what I do is in a container anyway so it almost doesn’t matter; half the time that means Alpine, but not really. That includes both consuming products from upstream as well as software development. I also practically live in the terminal, so I couldn’t care less what GUI subsystem is in play, even while I’m using it.

The only time I’ve encountered people that care a little too much about what distro is being used, is right after having transitioned to Linux; the sheer liberating potential of the thing can make you lose your head.

I’ve come across a lot of professional bias about Linux distros, but that’s usually due to real-world experience with tough or bad projects. Some times, decisions are made that make a given distro the villain or even the hero of the story. In the end, you’ll hear a lot of praise and hate, but context absolutely matters.

There’s also the very natural tendency to seek external validation for your actions/decisions. But some people just can’t self-actualize in a way that’s healthy. Sprinkle a little personal insecurity into the mix and presto: “someone is getting on great with that other Linux I don’t use, so Imma get big mad.”

This man is a menace and must be stopped.

Eh, I’m used to it.

This is fine.

Good fences make good neighbors.

Corollary: server-side commit hooks make good teammates.

NPM ruin dev is a new advanced feature that endorses opinionated “extreme programming” techniques. First it gets to work rebuilding node_modules, but with all the least compatible module versions in order to accelerate testing. It also minifies your .js code in place, to save you some CPU cycles later. Lastly, it squashes your entire git history on all branches, to save space.

I totally get that: use the right tools and you’ll be okay. This applies to many technologies in this space.

With respect, I still take this advice like hearing “look out for rattlesnakes if you’re hiking there.” It might be safer to just hike where there are no rattlesnakes, instead.

I swear, overcoming fixed functional-ness is like a superpower when you can apply it.

I once shared a small office with a co-worker. I had the idea to move the desks away from the walls and place them back-to-back, diagonally, in the middle of the room. Other co-workers scoffed and remarked at how dumb and unconventional this looked. Then I explained that we each now had nearly full privacy from each other, much more personal space in our respective corners, no more glare from the window, and nobody could sneak up on us from the door anymore. Things got pretty quiet after that.

Useful? Not exactly. But you’d never look lazy or idle, that’s for sure.

/me goes back to get second folding chair.

Pascal went to military school.

I’m not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.

I take this as less of a “I can’t use this intuitive feature reliably” thing and more of a “the truth table will bite you in the ass when you least expect it and/or make a mistake” thing.

Is that MIT (munch it today) or GPL (generally pleasing w/lettuce) licensed?

I’ve been in situations where I wanted to retain credit/ownership of ideas and code, but wanted to be able to use them in the workplace. So building a MIT/BSD licensed library on the weekend and then importing it on Monday was the only game in town. I get the portfolio piece and my job is easier as a result. But I stick to non-novel and non-patentable stuff - “small” work really, as Stallman is quoted here..

In some work environments, GPL or “GPL with an exception” would never get the kind of traction it should. Lots of places I’ve worked lack the legal and logistical framework for wrangling licenses and exceptions. It’s hard to handle such cases if there’s literally nobody to talk to about it, while you have automated systems that flag GPL license landmines anyway. The framing is a kind of security problem, not a license problem, so you never really get to start.

The two licenses have distinct use cases, and only overlap for some definitions of “free” software. I also think both the comic artist and OP set up a fallacious argument. I’ll add that in no way do I support Intel’s shenanigans here.

The comic author takes one specific case of an MIT licensed product being used in a commercial product, and pits it against another GPL product. This ignores situations where MIT is the right answer, where GPL is the wrong one, situations where legal action on GPL violations has failed, and all cases where the author’s intent is considered (Tanenbaum doesn’t mind). From that I conclude that this falls under The Cherry Picking Fallacy. While humorous, it’s a really bad argument.

But don’t take it from me, learn from the master of logic himself.

commonly referred to as “cuck licenses”

This sentiment makes the enclosing sentence an Ad-hominem fallacy, by attacking the would-be MIT license party as having poor morals and/or low social standing. Permissive licenses absolutely do allow others to modify code without limit, but that is suggested to be a bad thing on moral grounds alone. That said, I’d love to see a citation here because that’s the first I’ve heard of this pejorative used to describe software licensing.

I think what burns people the most is that after Photoshop 5 or so, GIMP stopped keeping up with all the improvements in the later Photoshop versions. People making the jump from 2024 Photoshop to 1996 Photoshop UI/UX are gonna have a bad time.

Edit: as a software developer I can say that I’ve never seen a user more frustrated, sometimes even irrationally so, when they are forced to re-learn muscle memory to perform a familiar task. I’ve also seen people practically riot at the mere suggestion that this will happen. If you wish to curry favor with your userbase, never ever, remove keyboard accelerators, move toolbars around, break workflow, etc.

The worst ones are safety rules: those are (sometimes) written in blood, with stories to match.