Not very long at all ago, people waged war over dynamic vs lexical function scoping.

These days you are hard pressed to find a language that uses dynamic scoping as the default.

The needle likes to swing back and forth between dynamic be static typing but we definitely seem to be coming back to static typing again

It was somewhat common in the 1970s and before for programming languages to support abbreviating variable names when you referenced them. So for example, you could say

    patients = 400
    x = pat / 2

And x would be 200. This seems like an obvious footgun today and I don't think any language designer would even consider it, but it seemed to make sense for a while.

Were they actually supporting abbreviating or just doing something like only storing the first 3 characters of the name? That feels more like something a compiler trying to fit in 8k of RAM or whatever would do.

Is there a difference between doing something and supporting something?

This joke is like a decade old at this point https://xkcd.com/1172/

Well, yes.

Namely, what does the following code do?

    patients = 400
    patents = 20
    x = patients / 10

If the compiler truncates, x will be 2 (assuming it allows variable reassignment), and you've probably introduced at least two bugs. It's doing some sort of lookup against the source, well, all bets are really off.

You have ignored my question

“Doing something” is the beginning of how to describe the actual truth of what some actions causes in relation to its affect on reality.

“Supporting something” has literally nothing to do with reality beyond what’s necessary to support a brain that can _intend_ a result or action regardless of what actually happens.

I linked the xkcd comic because the behavior described by the developer in the comic met the criteria for “doing something” but it didn’t meet the criteria for “supporting something” because the behavior of the software was not what the developer intended.

TDD. Agile.

I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).

Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?

Yes, exactly this. I never bought into TDD, but I can understand that it brings comfort for many normie enterprise CRUD developers... of which I am one myself!

I despise it because I've seen some absolutely HORRIBLE designs that excessively separate concerns (that are actually linked and shouldn't be) in the name of "testability". I would rather maintain 50 lines of clear idiomatic code than 1000 lines of TDD code salad full of 3 line functions that each take a bunch of fragile mocks.

It's also my experience that a few well written integration tests are more useful and catch more actual bugs than a million unit tests. This is especially true of web apps which are inherently highly stateful.

The most powerful design paradigm I have ever found is to spend the first, say, 10-20% of my time making a rough prototype. Not with an eye of actually using a single line of it (although it happens) but just to do the quickest and dirtiest possible exploration of what the actual problem is.

> excessively separate concerns (that are actually linked and shouldn't be)

you mean concerns that should be seperated but they did it in a wrong way?

When you say TDD do you meant test driven design or the test first design actually practice when “doing TDD”