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

Ultimately Turing-completeness means there is no difference in what you can achieve with various languages. What matters are other things: the convenience of getting the work done, performance, etc. In my experience Pascal and C++ really do differ significantly, with C++ allowing you to automate a hell of a lot more than Pascal would.

I disagree that GC is a more meaningful step forwards than, say, structured programming - this is something that is now so pervasive that it is no longer recognized for the revolution that it really was. GC is just one method of freeing memory, but it's not the only one; C++'s RAII does the same, and tracks any resource you care for, not just memory. I totally agree on the importing though. Arguably vcpkg has been a game changer in that sense.

Programming 20 years ago wasn't all that bad, really. Figuring something out usually meant reading a book. There were fewer useful libraries around and they were less capable, but on the other hand, they also weren't as ridiculously complex as today's libraries sometimes are.

And I'll readily admit that C++ informs my comments ;-) I mean, I've been writing C++ since 1996 or so, and for most of that, pretty much full time...

@JvmInline value class NotBlankString private constructor(private val value: String) : CharSequence {

    override val length: Int
        get() = value.length

    override fun get(index: Int): Char = value[index]

    override fun subSequence(startIndex: Int, endIndex: Int): CharSequence = value.subSequence(startIndex, endIndex)

    override fun toString(): String = value

    companion object {
        fun of(value: CharSequence): NotBlankString? = if (value.isBlank()) null else NotBlankString(value.toString())
    }

The problem is that most APIs in Kotlin and Java (including the standard library as well as almost all third party libraries) work specifically with String, which is a final class. So, using my NotBlankString is a pain in the ass because I have to explicitly call toString() for most APIs.

Also, I do implement CharSequence, because String does. But CharSequence is a terrible interface and we should probably just pretend it doesn't exist. I somewhat regret even acknowledging its presence.

One of the limitations of value classes is that they cannot implement an interface by delegation, either. So I have to implement CharSequence by hand, instead of writing `: CharSequence by value`.

If you define a "newtype" in Kotlin by using a value class, don't forget to override toString to call value.toString(). By default, it's going to print like a data class format: "NotBlankString(value=foo)"

But, overall, this is a much better than the situation in many languages. But it's still just awkward enough that I think a lot of people don't bother.

In my opinion, a statically typed language should HIGHLY prioritize the ergonomics of defining and using custom defined types. Ideally, I would be able to declare somehow that NotBlankString can do everything a String can do, and therefore be able to pass my NotBlankString type into any function that asks for a String. It would also be better for ergonomics if I could define my own type refinement, instead of needing to call a constructor- kind of like how Kotlin does "smart casting" with null and sealed types:

    val s: String = getSomeString()
    if (s is NotBlankString) {
        doStuff(s) // takes a NotBlankString
    } else {
        doOtherStuff()
    }

I did understand the situation I was in, and I do see that the world has changed.

Arguments against passionately held positions are usually fruitless, and I don't like debate as a form. I will point out e.g. that there was nothing at all "top down" about the Xerox Parc process (that can be easily checked).

Leaving out the "anti-elite anger", I think that another round of the ARPA-IPTO type funding and research community (of which Parc was a part in the 70s) would make an enormous difference in the richness and levels of ideas and technologies available for computing to choose from. But let me note that the uptake of the 60s and 70s inventions by the larger field was a bit spotty and introduced a fair amount of noise when something was adopted at all. This would likely be the fate of many of newer better inventions than we were able to do 40 and more years ago.

The writer says: "For most of the rest of us, we have to get by with minimal funding and try to push ideas to an over saturated market." There's no question that the current side-conditions in commercial computing are stifling (and they were when I was a journeyman programmer in the early 60s: every important choice -- of problem, HW, tools, etc was already made and stipulated).

It's worth pointing out here that e.g. many of the most important inventions at Xerox Parc were done by a grand total of 25 researchers plus about an equal number of support folks. That represents a tiny percentage of "mad money" that most Fortune 500 companies would regard as "nothing". The cost in dollars is not the reason they don't invest in new inventions in computing, especially software.

One observation that I think obtains here, is that a very large percentage of computer people take much more joy in "devising" than "learning" -- and haven't tackled the idea that "lots of learning" will greatly uplift "devising".

I found the list above very illuminating in understanding where the author might be coming from. What's interesting is that it does represent "new things" that have appeared in the general world of computing -- and have happened after many of the ARPA/PARC etc. inventions.

I think that anyone who can find the perspectives to be able to criticize this list will also be able to see some of what has happened. What does it mean in the large that these are the solutions endorsed in the current day?

Something not on the list per se is the web and especially the web browser. Most computerists I talk to are unable to really criticize these, especially the latter. (The "new normal" seems to be inescapable "reality".)

I think a good one to pick on the list here would be "Docker" and "containers". There is a lot to be learned here, both about computing and people who do computing if this could be criticized deeply, and alternatives identified.

I find it interesting that the author purports to read my mind. This doesn't seem to be working.