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.
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.
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?
No so much that YAGNI falls short, but more like “When YAGNI means ‘You Are Gonna Need It’”
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.
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.
But would you pay for it?
My employer’s paying for my access, and I only find it a bit useful here and there
Maybe my company gets a great discount or something, but if they would pay me the subscription cost to give up Copilot, I wouldn’t miss it
One of the best tutorials on really “grokking” git concepts, and it’s online and interactive: https://learngitbranching.js.org
For programming, start with buildings things for yourself. Be practical, start small, and iterate, regardless if you consider the previous iteration was a success or failure. I’ve heard good things about https://automatetheboringstuff.com/ (in Python) in this regard.
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.