A language is not functional just because it supports higher order functions. Technically C even supports them (even though the ergonomics and safety of them are terrible). Would you call C a functional programming language? Obviously not. Rust is also not a functional language, even though it comes closer than most OO/imperative languages.

Kotlin and plenty of other OO languages have borrowed some ideas from functional languages in recent years because those ideas are useful. That doesn’t make them functional languages. If Kotlin were a functional language, then it wouldn’t need libraries like arrow to try to make doing FP in Kotlin even (kind of) possible.

Hallmarks of FP (beyond higher-order functions), in no particular order:

• Organization around functions as the fundamental unit of code
• Code primarily defined in terms of expressions and data transformations rather than statements manipulating object state (so languages that have big blocks of imperative statements like Kotlin don’t count)
• A general orientation around pure functions, even if they vary on the degree to which they enforce purity
• Explicit parameter passing being the standard and preferred way of providing data to functions, rather than methods operating on implicit state
• First class support for function composition (method chaining doesn’t count)
• Pattern matching and destructuring as a first-class and ubiquitous concept (what Kotlin does have is a joke comparatively and no one would actually call it that)
• For statically-typed functional languages, first class support for algebraic data types (Kotlin has sealed classes which can kind of be used to try to emulate it, but it’s pretty awkward in comparison and requires you to write very OO-ish code to use)

There are some minor exceptions, such as Clojure lacking pattern matching, but on the whole functional languages generally fit these descriptions.

That list also counts Java and C# as “functional languages”. I wouldn’t take it too seriously. Ocaml, Scala, F#, etc. are impure functional languages. Kotlin absolutely is not. Having a couple of features you might find in functional languages does not make a language functional. Kotlin is still very much an OOP-based language. It’s basically a somewhat nicer Java.

Minor nit: Kotlin is decidedly not a functional language.

Design patterns in OOP exist purely to solve the problems created by OOP itself. If you have a language with proper ADTs and higher order functions, the need for traditional design patterns disappear since the problems they solve are first-class features baked into the language.

The first-class replacement for the Strategy pattern (and many other patterns such as the Visitor pattern) is sum types (called enums in Rust).

All it means is if you were to reverse the order of the characters, you’d get the same string you started with. So “dog” isn’t a palindrome because when you reverse it, you get “god”. “dog god” is a palindrome, though, because if you read it backwards, it’s also “dog god”.

It’s not complicated at all: https://en.m.wikipedia.org/wiki/Palindrome. Not really something that’s education-specific, in this instance (though I suppose it’s commonly used in entry-level programming classes since it’s a simple concept).

No, the legacy of HJKL in modern tools comes from vi, which itself uses them because the original ADM-3A terminal that Bill Joy used when developing it used HJKL in lieu of arrow keys.

vi was hugely influential and its legacy can be found in many tools beloved by software engineers and other tech-minded folks (and vi’s successor, vim, is still widely used to this day).

I was born in '90. Some of my most cherished memories as a kid are playing 90’s video games: Donkey Kong Country 1-3, Super Mario World 1-2, and later, the revelation that was the N64. I didn’t get to watch a lot of TV, but when I did I loved 90’s cartoons like Dexter’s lab and Arthur (and Mobile Suit Gundam Wing whenever I could catch it, though that was exceptionally rare)

I vividly remember people stockpiling for Y2K and my mom turning on a radio to listen to the reports of 9/11.

I’m definitely a 90’s kid, and so is my brother who is a year younger than me ('91).

After working at a company that had Crowdstrike installed on all machines, it is most certainly malware.

It’s definitely not great here at all, though I’d say it’s a bit different for professional software developers (who probably make up the bulk of contributors), since that kind of job tends to give you better benefits. In my experience, it’s typical to either have unlimited PTO (that you may or may not be able to take, admittedly, though I’ve never had an issue with that), or at least a couple weeks of vacation a year. I’ve never worked anywhere as a software engineer where I had to really even account for sick time at all. I just tell my team I’m sick and that’s about it.

Why in the ever-loving fuck would it do that? My hatred of Go only continues to grow.

It has the return type declared to be double.

That’s what the If-Match header is for. It prevents this problem.

That being said, I generally think PUTs are preferable to PATCHes for simplicity.

It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.

But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.

As I already said, it’s very simple with JSON Patch:

[
  { *op": "replace", "path": "/Name™, "value": "otherName"}
]

Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

The semantics of the API contract is distinct from its implementation details (lazy loading).

Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.

As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.

Only if using JSON merge patch, and that’s the only time it’s acceptable. But JSON patch should be preferred over JSON merge patch anyway.

Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.

Pretty dumb, honestly. If anything it just adds a Streisand effect to it as people try to figure out what’s censored.

Not that censoring it has any value whatsoever. Like if a child sees that, so fucking what?

Yeah it’s not all that uncommon in school, just increasingly uncommon in industry.

It sounds funny but it’s not an uncommon phrase.