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.
- Artists (still or motion)
- Writing (or related tasks like Editing)
- Mobile roles (sales, aspects of healthcare such as patient record accessibility, etc)
But, even in these cases with there is good alignment, you still lose productivity over a more traditional setup, usually due to restrictions around file management, keyboard shortcuts (usually due to “less than” applications not that the machine is incapable), security (what happens to data on the device if it’s lost or stolen), and window management (if you end up needing multiple monitors for your iPad is that really the best tool?)
I wish and want the iPad to be a true professional machine, but it’s not. It’s an amazing supplementary machine though as a reference screen, drawing pad, media consumption (e.g., tutorials), etc.
I guess I don’t understand how you end up believing it’ll be the best fit if you’ve used one in the past 3-5 years.
I just want to add if you do try external monitors, the experience is subpar.
You can't select which audio output to use, there's no clamshell mode, there are no real mouse settings for scrolling or secondary buttons, and some apps don't allow you to go full screen on a larger display.
Even apps you'd expect to work great like the Affinity suite just sort of don't function on a monitor.
Do you believe given Docker’s history of poor strategy (e.g., monetizing late requiring changes that negatively impact reputation such as docker desktop and hub), communication (e.g., the short notice changes a couple of months ago around free groups resulting in backlash) and in some cases destruction of successful businesses (see other comments in this thread) that this will result in a positive result for end users?
I hope you made bank while the ship continues to sink.
Mutagen's core users are primarily Docker users, and I honestly think they'll be much better served by the tighter integrations that we'll be able to offer now. If I didn't think that were the case, and I didn't think there were a net win (for Docker, Mutagen, and their users), then I wouldn't have joined.
Fair, I appreciate the answer. I guess I’ve just seen enough purchases where it’s just for the payday that I’m a bit cynical. Thanks again for taking the time to read and answer, wishing you the best
Thanks! I totally get it — I think a lot of time with acquisitions in general there's also a lot of good faith intentions that never manifest for whatever practical reason(s), so I can totally understand why the cynicism arises. I appreciate the positive wishes and I will do my best to convert those into positive outcomes!
> there's also a lot of good faith intentions that never manifest for whatever practical reason(s)
This is the risk blindness that exists in people that find success.
No one will perceive risk correctly. They will either over or under estimate. Those there's a huge amount of survivorship bias and those who underestimate risk and get lucky will be those who experience the most outsized success.
This isn't to say the cynical "I told you so"s are right, they're blind to the benefits. It's just that it's easy to say you can see the win-win. From the outside it's easy to see that the underlying benefit for Docker is reducing the power and input of other sources of influence in their technology, and that's a greater benefit to them than any benefit that this move could possibly provide to the users. But if anyone could make it work it's you.
