Perhaps open federated systems should have recommendation algos too, just optional and open

Bravo, a proper application of https://en.m.wikipedia.org/wiki/Paradox_of_tolerance

For me, the more relevant adage here is “a bad abstraction is worse than no abstraction”.

IMO many abstractions in Java are terrible in this regard, either via commonly proliferated patterns or via language design issues. Abstractions large and small are all forcibly locked into place very early on in the name of formalism and safety, ultimately leaving us with poor versions of the former and weakened versions of the latter. Where is “encapsulation” when certain classes only work when hooked up in very particular ways to other distant classes? Where is “type safety” when certain methods simply raise “not implemented for this sub/super-type”?

These faults are often hand-waved as “all ecosystems have rough patches”, but my point is that Java’s bad abstractions in particular are supremely more stubborn and persistent in comparison with other ecosystems. I understand many consider this a strength aka stability, but IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality, but I’ve already moved on – it’s just not for me.

Maybe their communities are blank slates where innovations in “distributed power grid” systems can happen? Have heard that traditional power grids are “unidirectional” and have had some trouble with solar installations popping up.

Python deps can be dynamic, so it can be necessary to download the package and execute code just to find out.

Would be nice to see a resource that lists out the statically defined ones, though. Perhaps that’d pressure the dynamic ones to change – it’s a cause for some of the notorious pain of Python packaging.

IMO it will “succeed” in the early phase. Pre-seed startups will be able demo and get investors more easily, which I hear is already happening.

However, it’s not sustainable, and either somebody figures out a practical transition/rewrite strategy as they try to go to market, or the startup dies while trying to scale up.

We’ll see a lower success rate from these companies, in a bit of an I-told-you-so-moment, which reduces over-investment in the practice. Under a new equilibrium, vibe coding remains useful for super early demos, hackathons, and throwaway explorations, and people learn to do the transition/rewrite either earlier or not at all for core systems, depending on the resources founders have available at such an early stage.

First suggestion is impractical. Not going to be able to memorize 100 names to look up and research later

Second suggestion should already be happening, but doesn’t capture the desired use case.

The use case is this: in physical life, there is a gradient of “boundaries/leashes” to match maturity and development. For example, the gradient of movie ratings, or:

• Very young - stay within arms reach/sight
• Young - stay in the yard/park/neighborhood
• Child - stick with what’s familiar, I’ll be nearby
• Pre-teen - go and try it, I can be right there
• Teen - go and try it yourself, call me if needed

We could argue about whether a gradient is too steep or shallow, but the point is that one exists.

In contrast, digital in many ways is very often all-or-nothing

Not saying digital should be “gradient-ed” in all cases, that leads to tone-deaf rules and bad security practices. Just trying to show what the problem is

I think there is a difference. Because software is so flexible and quick to build, it’s orders of magnitude easier to build something known and understood.

A promising startup with its systems in a knot, but their initial team is still on retainer? Brains can be picked, abstraction boundaries placed, surgical rewrites deployed. Despite the mess, they still understand it, and development can expand.

It remains to be seen if AI-generated code is recoverable, if any existing strategies can be applied so humans can contribute, or if the company is forever beholden to AI providers to release a better AI to manage/improve what they’ve already got.

Highly recommend having some scripting/interpreted language in your stack – in fact you likely already do (consider how shell scripting makes up a significant part of Dockerfiles)

It’s an incredibly useful intermediate between freeform-but-non-executable text/docs/wikis and “industrial-grade”-but-inflexible tooling

In other words, a great fit for capturing this partial/incomplete/tribal knowledge space the post is talking about. I personally even go a bit further and actively advocate for converting “onboarding/operational docs” from wikis into scripts that print out the equivalent text that can be committed and incrementally automated.

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

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 kind of query optimization can it for scanning data that’s already in memory?

What did you go over?

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

“never see addressed”? What do you think currently happens in (real, non-hypothetical) cities with good bike infrastructure?

https://www.youtube.com/watch?v=j2dHFC31VtQ&t=365

Oh look, emergency vehicles work even better on bike infrastructure than on car infrastructure

Bicylists and pedestrians can’t hard block a firetruck the way car traffic can

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

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.