Yup this is the real world take IME. Code should be self documenting, really the only exception ever is “why” because code explains how, as you said.

Now there are sometimes less-than-ideal environments. Like at my last job we were doing Scala development, and that language is expressive enough to allow you to truly have self-documenting code. Python cannot match this, and so you need comments at times (in earlier versions of Python type annotations were specially formatted literal comments, now they’re glorified comments because they look like real annotations but actually do nothing).

Battle.net games have been some of the most reliable non-steam games you’ll find. You’ll have trouble in the Riot Games space (League on Linux, Windows 7, and 8 are all dead in the next month due to Vanguard), and some Epic Games (Fortnite), but if you’re a Battle.net/Steam gamer Linux is ready for you.

Linux is a far more reliable operating system at the kernel level, which is why the vast majority of the Internet runs on Linux, and is very stable compared to anyone’s personal computer (no matter O.S). It’s also lighter weight at its core, which is a big plus for servers.

The thing about Linux desktops that tend to be finicky is interop with some proprietary software (e.g nvidia drivers) or desktop environments (gnome can freeze/crash if you like running bleeding edge before bugs are ironed out). Windows has issues too however, free software often literally doesn’t run on Windows (requiring WSL, the same way games on Linux require wine), and the desktop environment is essentially indistinguishable from the base operating system. When you get a desktop environment crash on Windows, your system will BSOD and restart with no recourse, in Linux I can ssh into my still functioning computer and kill my DE, or drop to the TTL and do the same thing.

The end might not seem like a big deal for some people (who cares if you have to restart by a button press or kill your DE and login, they’ll take a similar amount of time), but for someone like me where reliability is a big concern (as in, uptime for the half a dozen services/containers I run for people), this is great. People watching media off of jellyfin don’t have to stop because of a DE bug, but on Windows a BSOD would stop their media (and within the last week we’ve had several BSODs on Windows PCs due to bugs relating things like adaptive sync or sometimes just unknown reasons).

For what it’s worth I also game exclusively on Linux, vk3d, dxvk, and proton are godsends. Somethings don’t work, developers who won’t flip the switch for EAC (e.g Fortnite), but for me the games I play always worked. This will actually change soon, Vanguard is coming to League and that only works on Windows, but also probably not my last install of Windows (I tried W11 when it came out because I’m just curious about new tech), but I had to do a TPMBypassCheck despite having ftpm enabled in the BIOS, and afaict, at least from people I know with similar builds to me, if this happened then firmware TPM probably isn’t being picked up by W11, and that means I need to buy a TPM module or drop to W10 to play League. Plus, vanguard is an intense rootkit with full 24/7 access to your O.S so I probably don’t want that installed anyway, even if it happened to work on Linux. Just going to stick to SoD for now in my free time lol

I’ve seen a couple of posts in here about sound. It’s wild that I’ve been through dozens of distros since the start of high school (12 years ago), installed them on at least 10 machines over that time, and can’t remember one issue with sound that took more than 15 seconds to fix (e.g discord choosing the wrong sound device because I have 6 things plugged in that can technically output sound, which also happens to my friends who use Windows).

Maybe I’m just lucky. The only issues I recall having in the last decade are essentially graphics related. Either game compatibility (though proton/wine is much better than it was in 2015) or desktop environments being finicky (freezing on sleep for example), but the latter afaict was entirely due to proprietary nvidia drivers. There are proper, high-performance open source drivers in the works, so nvidia might be on par with amd in 2-3 years on Linux (which is to say literally no issues for the vast majority of people, probably far more stable than Windows).

In the same time I’ve had lots of people come to me with problems that we’ve specifically troubleshooted and found Windows to be the issue even when it seemed like hardware problems. Like monitor flickering/black screening, and plugging in a different monitor the issue goes away. On the surface it seems like a hardware problem, but both monitors worked flawlessly on Linux for literally months. Full reinstalling Windows did not fix the issue. Upgrading from Windows 10 -> 11 did not fix the issue.

Same thing with another friend’s external SSD. For some reason it wasn’t being detected on his Windows 7 install. We installed Linux and the drive was picked up. Maybe Windows 10 would’ve also picked up the drive in this circumstance, but a lot of people hated the idea of Windows 10 at the time (this was just after Windows 10 was released, when Windows 7 still had a similar market share).

There’s likely a huge percentage of problems people attribute to hardware that are actually Windows being a shitty O.S, but nobody actually checks if Windows is the problem.

In humans there’s a psychological phenomenon called “crowding out”, essentially it’s hard for our brains to attach multiple, powerful incentives to one activity. Generally the “lesser” ones get crowded out by the more important one.

I’m still young (26), and still feel the same way about programming, I deeply enjoy it. However, I know programmers who were passionate like me when they were younger, and that passion has been slowly drained as they continue to code professionally, and I’ve seen it come back when they move into non-programming roles (be it industry change or moving to management).

Generally you won’t find yourself wanting to program 40 hours a week, 48-50 weeks a year, for 50 years without a substantial break, and yet that’s what capitalism expects of workers. Yet you’ll continue to work because there’s a more important incentive than passion, money.

You need money to survive (food, shelter, etc.) and your brain understands those are more important than fulfilling a passion, that’s why you’ll go to work even if you’re drained mentally. You’ll continue to do that forever so long as you don’t have the financial freedom to do otherwise (which is the goal of capitalists, this is why we have COL-based incomes, so as not to overpay people who live in cheaper areas as it’d allow them the freedom to leave).

Yes, but not because the goal of having exceptions in types is bad, rather Java’s type system isn’t advanced enough to support the ideal solution here.

Scala 3 is working on experimental capture checking capabilities, which allows functions to express certain capabilities (file access, networking, db, etc.), and CanThrow capabilities (e.g exceptions at the type level) are one reification of this.

The CanThrow docs I linked have a good introduction into why Java checked exceptions are bad, and how Scala’s alternative is far better. Essentially it comes down to a lack of polymorphism in checked exceptions. In practice this means they’re incredibly verbose outside of simple usecases, and with a very easy escape hatch (RuntimeException), you don’t even get the guarantee of knowing a function without checked exceptions doesn’t throw.

Python will also have this latter issue. Python’s “typing” in general has this issue actually. Types aren’t validated unless you use an external tool, and even then Any is a leaky abstraction that can hide any level of typing errors, unlike in properly typed languages where it’s not leaky. You need it to be leaky in gradually typed environments, or you wouldn’t be able to use a ton of the Python ecosystem, but this vastly reduces the effectiveness of the typing solution.

I don’t know if Python’s solution here will address the lack of polymorphism that Java’s solution has, I’ll have to look into it more.

Most people aren’t practicing teachers, so it makes sense that not all explanations are the best. Trying to get an intuitional understanding of passing by reference or passing by value in imperative languages is arguably more important than understanding how map works, and yet I’d argue it’s also harder to do.

If you understand map (not just lists, but futures, IOs, Options, Maybes, etc.) then you understand Functors. Yes there are laws, but mathematical laws here are just encoding our intuition. Something like Iterator in Java may not have laws, but you would expect that calling .next() doesn’t modify an SQL database, though it wouldn’t be a technically invalid implementation if it did. The same is not true for Functors. If you map over a List and the act of mapping each int to its double modified a database then you wouldn’t have a lawful functor. But that should make sense intuitionally without knowing the laws.

People in OO land are more happy to say they “understand” something if they generally get what the abstraction is going for. Do you know all the methods for Iterator/Iterable in Java? Even if you didn’t, you’d likely say you get the “point” of an Iterable. The bar for understanding things in the FP community is usually higher than just understanding the point of something.

This doesn’t mean FP is more complicated. Actually it kind of means it’s simpler, because it’s not unreasonable for people to totally understand what Functors are for all languages that implement them. The same is not true of Iterable/Iterator. There’s no way you’d have more than just an intuition about what Iterable is in a language you don’t know. I don’t program in Agda or Idris, but I know Functor in those languages are the same as Functor in Scala and Haskell. Same with Monad, Monoids, etc.

Haskell/Scala. Huge fan of pure functional programming. Here’s another comment I wrote about some FP-related things

I think the dislike for Functors/Monads/Monoids etc. is super overrated. I’m not a mathematician, but christ these are beautiful abstractions coming from a background in Java and OO programming.

Functor instances are defined by one function. Once you learn the one main thing that Functors do (mapping), you’ll understand them no matter the language. Monoids have 2, Monads have 2, etc. Yes all there are functions built in terms of the functions required in the typeclass definitions (or several typeclasses), but they don’t need to be known to effectively use the abstractions.

I was able to easily transfer most of my Haskell knowledge to Scala at my last job in the typelevel ecosystem because of HKTs like Functors, Monads, monad comprehensions, Monoids, etc. I was the go-to guy for FP-related questions despite most of my background being in Haskell and not Scala.

Using an Iterable in Java will be different than an Iterable in any other language in at least some respects. Yes they will represent the same abstract idea, but you can’t just 1:1 transfer knowledge between different Iterable implementations.

I’ve programmed professionally in Java, Kotlin, Scala, Ruby, Python, JS/TS, and many more in hobbyist settings, and the cleanest transition was Haskell -> Scala (omitting language transitions on the same runtime, so Java -> Kotlin or JS -> TS).