https://f-droid.org/packages/de.t_dankworth.secscanqr/

Also have the option of selectively/strictly enforcing in CI, to get an experience & protections similar to “compile-time type checking”

it lacks clear and enforced type restrictions which help with clear code contracts

Not anymore! Gradual typing is supported by the core language and pyright is a fantastic incremental type checker that you can use both in your editor and in CI.

You cannot, and that’s why that type declaration models a NonEmpty that a type checker can enforce

Hm, that’s kind of interesting

But my first reaction is that optimizations only at the “Python processing level” are going to be pretty limited since it’s not going to have metadata/statistics, and it’d depend heavily on the source data layout, e.g. CSV vs parquet

What’s hard about vanilla Ruby?

What kind of query optimization can it for scanning data that’s already in memory?

No so much that YAGNI falls short, but more like “When YAGNI means ‘You Are Gonna Need It’”

Bad abstraction is worse than no abstraction

If the code is going to poorly organized, I’d prefer it to just be one single gigantic standalone script than some wrong and misleading arrangement of objects or functions that adds more complexity than they solve

absolute beginner? Start at https://www.hedycode.com/

Which will ultimately lead into vanilla Python. This is the creator explaining why Hedy is uniquely designed for learning: https://www.youtube.com/watch?v=fmF7HpU_-9k

inheritance to avoid code duplication

What no, inheritance is not for code sharing

Sound bite aside, inheritance is a higher level concept. That it “shares code” is one of several effects.

The simple, plain, decoupled way to share code is the humble function call, i.e. static method in certain langs.

If you used good objects, you’ll only have to make the change in one place

IMO that’s generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension – even a good one, will limit flexibility in some other dimension.

Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.

Most every other time, you’re better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.

I’ve never seen these “express code/tests in natural language” ever work well. Your non-coders need lawyer-like skills to wield English very precisely, or it falls to coders that would be better off using code directly.

problems only have one answer and often one strategy to get to the answer

Totally disagree

You’re thinking of equations, which only have one answer. There are often many possible ways to solve and tackle problems.

If you’ll permit an analogy, even though there’s “only one way” to use a hammer and nail, the overall problem of joining wood can be solved in a variety of ways.

IMO mathematical/logical/abstract thinking is critical for programming well, but IMO that’s different from “math degree” math.

Software as a means to an end can be used in almost every domain, so proficiency within that applicable domain is often either useful or necessary. That is to say, “math degree” math is likely needed for 3d rendering (certain games), scientific computation (incl machine learning), etc, but maybe not, otherwise. It depends on what software you’re trying to build.

To be more specific, general programming is definitely and specifically different from trig and calc. However, because math is also broad, “mathy” concepts like type theory, relational algebra, set theory are considered important for programming, even if only informally or indirectly so.

I don’t understand, if you’ve got easy to delete copy-pasted code, then delete it. It’ll be a nice and cathartic exercise.

But sounds like what you’re really talking about is code that isn’t easy to delete.

IMO folding to hide is about equivalent to moving all contents to another file/private function:

def bad_function(args):
    return _hide_elsewhere(args)

i.e. does nothing. Real solution to pyramids of doom is to fix the code.

That’s changing the goal posts to “not static”

Sounds easy to simplify:

Use one of: constructor A(d), function a(d), or method d.a() to construct A’s.

B and C never change, so I invoke YAGNI and hardcode them in this one and only place, abstracting them away entirely.

No factories, no dependency injection frameworks.

IMO factory functions are totally fine – I hesitate to even give them a special name b/c functions that can return an object are not special.

However I think good use cases for Factory classes (and long-lived stateful instances of) are scarce, often being better served using other constructs.