What was the last breakthrough in computer programming? (2019)

Surely you can, with a huge amount of inconvenience, achieve in Pascal what you routinely do in C++, by passing "self" into function calls and manually implementing vtable lookups? :)

(You might have a point with C++ templates but that's just saving yourself the trouble of a bunch of copy and pasta....)

Similarly, the "2GL" to "3GL" transition merely gives you the convenience of not having to maintain a call stack. There's no magic, you just save yourself trouble of writing boilerplate code with pushing and popping pointers and stack variables.

I would argue that the only reason it's considered a "paradigm shift" is merely because you were "indoctrinated" into thinking those advancements were so great that they were "more than" mere convenience. But, at least in retrospect, they are _trivial_ when compared with the advancements made in recent years (eg. Garbage Collection, Rust's safe memory management, import tensorflow, etc.). And while the old school programming language advancements surely boost programmer productivity and accuracy, I don't think it's fair to say they're more important than say the convenience of an "import fancypackage" that does 90% of the work for you.

Perhaps the form of improvement is often not in a new programming language (because perhaps classical languages are "good enough" for most cases), but I know I wouldn't enjoy programming with the tools available 20 years ago.

PS: I suspect your C++ perspective might also have tinted your perspective a bit. For the examples I gave as more recent advancements (i.e. GC, Rust, TF), they aren't (readily) available in C++. Sure you can say you prefer the speed of C++ which is entirely fair, but you might be pleasantly surprised if you looked outside.

I didn't say it was or it could.

> Funny enough the problem you raised was trivially solvable by creating a BNF-like checker based on the spec for "THEIR" API response data. > > YOU just didn't want to do it.

I didn't write the code, but if I did, I WOULD have used a NonEmptyString type for the deserialized result of the response body. That's... pretty much my whole freaking point here.

The "problem" is that my colleagues, as well as many, many, devs, including the ones at the company in question, are going to do the easiest thing they can. If your language provides String, and writing your own NonEmptyString type would require a bunch of boilerplate, most devs are just not gonna do it. "We'll never have an empty string here, anyway" they'll say. Until they do.

And, as I pointed out in another comment, I DO write these types in languages like Java. It's a ton of boilerplate and the language fights you at every turn. In Java, most texty APIs expect a String instance, which is a final class. So I have to wrap String with my class and convert to-and-from explicitly all over my code. Not to mention the performance overhead and optimization loss from wrapping a primitive type.

So, thanks for the condescending attitude, but I DO put my money where my mouth is and I still feel completely justified in criticizing the current state of software development tools.

If our tools and "best practices" are adequate, then how in the hell did Apple, a trillion dollar company, just release a version of macOS a year ago that literally had a calculator app that gave the wrong arithmetic answer if you used it too quickly?!

Every time I criticize software dev stuff and someone replies and tells me everything is totally fine, it only makes me stronger.

For example, what if I don't like data class's stupid copy() method? How do I opt out? You can't.

Value classes can't be used as varargs, can't implement an interface by delegating to the wrapped value. (Forgetting the fact that they're just buggy as all hell and I keep getting runtime crashes from them being overly aggressively optimized away)

And it, of course, inherits a ton of badness from Java. Like the crappy type-erased generics, lack of type classes, etc. It chose to just use Java's standard collection types and encourage copies instead of using persistent collections by default. It hides the mutability under "read only" interfaces, but that's not at all concurrency-safe. Map is not a Collection or an Iterable, which is dumb. Map's type parameters are also allowed to be nullable types, which means that Map.getOrElse{} is actually wrong in the standard library.

Since Kotlin chose nullable types instead of Option, you can't express "nested" emptiness. This means that the Map API is janky if you need to store nullable types. Map.get returns null if there was no value stored, but what if the value stored IS null? Then you have to call Map.contains(key), which means you have to hash the key twice to reliably pull out values.

There's just a lot of papercuts.

Huh, you rambled about not being able to do so. But now you claim it's totally feasible if you wrote it?

It seems you're just ranting against bad programmers instead of missing language features then.

I'm rambling because our programming languages make it awkward, difficult, and performance-sub-optimal to do such things.

If you do what I often do, you have to wrap and unwrap your primitives explicitly so that you can use APIs that others have written.

You take a performance hit with all of the boxing and unboxing.

It's absolutely still a missing language feature if the language doesn't have ergonomic "newtypes". Just because it's possible to write a ton of poorly performing boilerplate to accomplish my goal of type safety, doesn't mean that I think we're done. You can do these things with essential zero runtime overhead and almost no boilerplate and friction in the code. It's entirely possible to do newtypes and refinement types in Rust, Haskell, D, Scala, even TypeScript. It's just that most of those languages are not very popular. TypeScript is the most mainstream of the lot.

I think "good programmers" are more of the problem than bad programmers. Good programmers are so used to these shit languages and all of their workarounds (excuse me: "design patterns") that they can't even see the forest for the trees and realize how tedious and stupid most of our work actually is. There's no Earthly reason it should take a million lines of code to write a CRUD app (I'm counting dependencies).