Nice reference — Ideaverse is a good reminder that capture should create lift, not just storage.
My only nuance is: “sparks ideas” is one slice. A lot of what we stash isn’t inspirational at all — it’s obligations, decisions, constraints, receipts, meeting notes, “I’ll need this later” references. So the goal (for what I’m exploring) isn’t only to spark, but to make the right thing reappear at the right moment: sometimes that’s an idea, sometimes it’s a decision you already made, sometimes it’s the one constraint that prevents rework.
Curious: in your own system, what kind of captured info most often pays off later — inspiration/ideas, or concrete reference (decisions, specs, links, context)?
People might have envy for others success which would hurt their ego, but they are greedy enough to stroke someone else's ego, just so that they can get internet points or some "value creation" so that one day others can stroke their egos too.
I wish people would stop holding onto compatibility as if it is some amazing feature. It has benefits, but also comes with many drawbacks to innovation and improvement in established ecosystems
I love their software and am happy for the humans behind it all. As a customer who doesn’t believe they won’t force a subscription on me, I wish I had never supported them
Many large companies suffer from the concept of shadow IT. The use of software and services that aren’t blessed by the company to accomplish tasks that are blessed. As someone in security at a large company, I expect this is a matter of not every company has people who follows rules. I know I’ve seen and know, even within security orgs, plenty of people who don’t follow the rules because a few bad rules makes them feel that other important rules are also bad. It’s pretty simple to bypass the software companies use to “enforce” the rules
Broadly speaking, yes, but for some situations like database models with bi-directional relationships that can cause unnecessary maintenance burden simply for the benefit of type checking which this allows you to work around since the cyclical nature is only caused by typing not runtime semantics
It’s a good introduction but it’s review in my case - I know how enums work in TS.
But the end conclusion
> Enums in TypeScript are a very useful addition to the JavaScript language when used properly.
> They can help make it clear the intent of normally “magic values” (strings or numbers) that may exist in an application and give a type-safe view of them.
> But like any tool in one’s toolbox, if they are used incorrectly, it can become unclear what they represent and how they should be used.
Doesn’t really support the original post’s premise that prefers not to use enums.
This. Also huge on enums elsewhere, just not in typescript.
I think this could be the reason devs first reach out to enums, since familiarity from other languages.
Seeing so many comments about how hard it is to just break compatibility and upgrade is sad. Instead of just throwing our hands up and saying it’s too hard, we could adopt the model the JavaScript ecosystem has seen more of which is codemods that upgrade the code for us.
If as a community we invest in those tools and make them easier to build, the cost of upgrading goes down and the velocity of high-impact changes can increase.
TC39 has a famous "don't break the internet" mantra. Even the leeway that Python has with deprecations/features JavaScript doesn't. It's versionless, code automatically gets updated to whatever the browser is using.
JavaScript evolves quickly but so does Python!
(Note that your approach is exactly what they said in the 2 to 3 transiton btw with a special tool that didn't work too well)
That’s not what that library was in my opinion, it was a compatibility layer not a rewriting tool which is what I referenced. Having a layer in between simply prolongs the issue and creates many types of problems based on adoption or not. On the other hand, when rewriting you can apply that either as an author or as an end user depending on the quality which meaningfully allows for different results.
codemod is a syntax conversion tool, using regexes. Thread-safety isn't even semantic--it's an emergent behavior question, the same as "does this code halt?" There is no general solution.
For example, is this code thread-safe?
foo(int* x) {
int z;
for (int* y = x + 1; y != 0 && *y < *(y - 1); ++y) {
z = *y;
}
return z;
}
You can't tell from static analysis of the function. It depends upon what guarentees are imposed upon the passed-in "x" value. For example, if "foo" is only referenced as a function pointer passed to "baz" (also in the library), and "baz" creates "x" and uses it in a thread-safe manner, then there's no problem. But there's no guarenteed mechanical way to determine if "baz" is indeed doing the right thing, or what changes should be made to make it so.
A fully general transformation from naive to thread-safe code seems like it would make you one of the giants of computer science alongside Knuth and Dijkstra.
I think this is where concepts from Rust and Go could come in handy. Things like Go’s race condition detection and rust’s compiler validation approaches can be used to statically analyze code. Sure, it’s a meaningful change from how many Python devs approach the language and challenging problem but not insurmountable given the existing work in the field.
I'm not sure what "codemods" means. Just static analysis code changer? Python is so highly runtime dynamic I'm not sure a tool is even possible to upgrade behavior, preserving correctness and intent (bugs and all).
But I think they're referencing the litany of transpilers and repackagers which exist for js. So you can add new features and then still have it run on really old systems like internet explorer 9 if you need to.
This has problems obviously and in my opinion for python it would be preferable.
My reasoning being that if you need your code to work on an older system being able to write and use current syntax is preferable to not, and the hard bifurcation that python did with 2 to 3 and now potentially with 3 to nogil seems to me just to break apart the ecosystem more.
That differs but is a reasonable understanding. I’m instead referring to automations that perform large scale refactoring as handled by Facebook, who would be contributing to this effort.
It sounds like what you are describing is what’s known as poly fills which convert code into a variant that maximizes function across implementations which isn’t really applicable here.
reply