Why didn't COBOL evolve more successfully?

FORTRAN, OTOH, has survived precisely because it--and more importantly, related tools, esp compilers--has evolved to solve/overcome many (certainly not all!) of the sorts of pain-points you describe, while retaining the significant performance edge that (IMHO, ICBW) prevents challengers …

https://twitter.com/audreywatters/status/1246609613203505152

The tweet has since been deleted. Here's the old text

At this point, we're closing in on 9/13 (70%) of the way through the 2nd edition rewrite.

Important changes.

1. Type Hints
2. Type Hints
3. Type Hints

First.

Every single class, method, or function has to be changed to add hints. Every. Single. One. This is kind of huge. The book …

I made some bad decisions when I wrote this a few years ago: https://github.com/slott56/Stingray-Reader. Really bad. And. Recently, I've burdened myself with conflicting goals. Ugh.

I need to upgrade to Python 3.8, and add type hints. This exposed somes badness.

See Stingray Reader Rewrite for …

This seemed like an interesting problem. I hope this isn't someone's take-home homework or an interview question. It seemed organic enough when I found out about it.

Given a document like this...

doc = {
    "key": "the key",
    "tag1": ["list", "of", "values"],
    "tag2": ["another", "list", "here"],
    "tag3": ["lorem", "ipsum", "dolor"],
}

We want …

Using the clear() method of a dict isn't *wrong*. But. The reasons have to be investigated. I got a question about this code not working "properly." ("Properly"? Seems too vague to be useful.)

Here's a summary of the example.

final_list = []
temp_dict = {}
for obj in some_source:
    cool_function(obj, temp_dict)
    final_list.append …

See {filename}/blog/2020/01/2020_01_26-stingrayreader_upgrade.rst

This drifted into some serious rethinking of bad design decisions. (If someone else did this, I'd call it weak, and suggest improvements. It was me. It was bad. I'm a bad programmer and I feel bad about it.)

An an example, there's this …

some_data = {name: source[name] for name in the_names}
the_object = SomeClass(**some_data)

For the last week I've been working with some legacy code that reveals a kind of problem I hadn't really seen before.

I'm calling it the Wrong Abstraction.

I want to contrast this with the Leaky Abstraction, where implementation details are revealed and raise havoc.

The Wrong Abstraction problem seems …

See "Additional, Related Content". It's one of the posts here: https://www.patreon.com/slott.

I think there's space for a Building Skills in Functional Python title next to the Building Skills in OO Design.