Yeah I have no idea wtf this meme is talking about. A lot of people seem to have this weird idea that ADHD gives you some immense ability to focus? When it's literally the opposite. They hear about hyper focus and think that means you have some weird superpower. In reality it's an inordinate amount of attention given to whatever is the most interesting thing to you, at the expense of focus paid to things you actually need to do. It seems pretty unlikely that the person described in the OP is extremely interested in a shopping task.

Flossing must be a bitch.

I'm not sure what you mean by "locality of reference". I assume you mean something other than the traditional meaning regarding how processors access memory?

Anyway, it's often been said (half-jokingly) that Haskell is a nicer imperative language than imperative languages. Haskell gives you control over what executing an "imperative" program actually means in a way that imperative languages don't.

To give a concrete example: we have a custom monad type at work that I'm simply going to call Transaction (it has a different name in reality). What it does is allow you to execute database calls inside of the same transaction (and can be arbitrarily composed with other code blocks of type Transaction while still being guaranteed to be inside of the same transaction), and any other side effects you write inside the Transaction code block are actually collected and deferred until after the transaction successfully commits, and are otherwise discarded. Very useful, and not something that's very easy to implement in imperative languages. In Haskell, it's maybe a dozen lines of code and a few small helper functions.

It also has a type system that is far, far more powerful than what mainstream imperative programming languages are capable of. For example, our API specifications are described entirely using types (using the servant library), which allows us to do things like statically generate API docs, type-check our API implementation against the specification (so our API handlers are statically guaranteed to return the response types they say they do), automatically generate type-safe API clients, and more.

We have about half a million lines of Haskell in production serving as a web API backend powering our entire platform, including a mobile app, web app, and integrations with many third parties. It's served us very well.

The point of the joke is not that the Python interpreter will change types mid-program on its own, but that you don't have any real way of knowing if you're going to get the type you expect.

Programs are messy and complicated, and data might flow through many different systems before finally being used for output. It can and often does happen that one of those systems does not behave as expected, and you get bugs where one type is expected but another is used in actuality.

Yes, most likely what would happen in Python is a TypeError, not actual output, but it was pretty clearly minor hyperbole for the sake of the joke.

Nah, the best ranch can be found at Amigos, a fast food chain in Nebraska. It's so much of a thing here that they have a dedicated ranch station in all of the restaurants and even package it and sell the ranch in local grocery stores.

Unless you're writing Scala or something (which is probably the one exception to the rule), if you are using a language that supports OOP, you're not really doing functional programming. Functional-esque features that have made their way into imperative languages like map are only a tiny fraction of the functional toolbox.

There's a bunch of features you want in a language to do functional programming, and imperative languages don't really have them, like purity by default (and consequently, an orientation towards values rather than references) ergonomic function composition, algebraic data types, pattern matching, support for treating everything as first class expressions/values, etc.

Perhaps this is presumptious (and I apologize in advance if so), but I'd wager you haven't truly programmed in the functional paradigm. What imperative programmers tend to think of functional programming is very surface-level and not really reflective of what it actually is. It's an entirely different beast from imperative programming. It requires a shift of your mindset and how you think about programs as a whole.

Source: Senior software engineer writing Haskell full time for the last 4 years. Will avoid OOP until my dying breath.

The system has a lot of problems for sure, but IME as a senior software engineer, people without degrees are often lacking in core CS skills and are much less comfortable with the more conceptual aspects of the field like graph theory, systems design, DSLs, etc. Usually database skills aren't quite as strong either due to not having studied relational algebra and other database concepts.

None of this is to say that someone without a degree can't be a valuable part of the team, but at the higher levels of seniority, you do want people who have really strong foundations so you can ensure that you actually are building strong foundations. A degree doesn't guarantee these qualities, but it certainly makes a person much more likely to have them. Not saying someone without a degree can't possibly achieve this on their own, but it's quite rare and requires much more self study than most actually do.

My wife and I think it is. I took her last name since it meant more to her.

It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.

Doesn't come up that much, but it's been handy once or twice, for me. It's also just nice security: no matter how I edit commits, I can always go back if I need to.

The issues are primarily with Azure, I believe.

Ah gotcha, fair enough. Definitely depends on the workload. If you have compute you want to dedicate to solely to a single task, have at it.

There are many strategies for maintaining test environments for that kind of thing. Read-only replicas, sampling datasets for smaller replicas, etc. Plenty of organizations do it, so it's not really an excuse, imo.