nickelpro

If you know what sound you want to hear, but don't know the compressor settings to make that sound, that is a taste-skill gap.

If you don't know what sound you want to hear at all, that's undeveloped taste.

If you know what code you want to type, but don't know how to use a keyboard, that would be a taste-skill gap.

If you don't know what code you want to type at all, that's undeveloped taste.

Then your taste hasn't developed. You don't know what good code for the problem even looks like. It's not that your code doesn't resemble what you wanted to make, you don't know what you want to make at all.

There's no meaningful taste-skill gap in programming because programming doesn't involve tacit skills. If you know what you're supposed to do, it is trivial to type that into a keyboard.

The taste-skill gap emerges when you intellectually recognize what a quality creation would be, but are physically unable to produce that creation, and judge the creations you are physically capable of producing as low quality

The oft cited example is drawing a circle. Everyone knows what a perfectly round circle looks like, but drawing one takes practice.

It doesn't take practice to type code. If you know what code you're supposed to write, you write it. The problem is all in the taste step, to know what code to write in the first place.

There are no parts of uv that don't follow standards.

The standards have nothing to do with the last 25 years of Python project management, the most import ones (PEP 517/518) are less than 10 years old.

It matters immensely that it follows PEP 405, it makes uv the implementation detail. You can swap out uv for any other project management tool or build frontend and change nothing needs to change about the development environment.

This is the entire purpose of the standards.

How do you think uv works?

It creates a venv. Note were talking about the concept of a virtual environment here, PEP 405, not the Python module "venv".

uv has both a uv-specific implementation, and support for standard PEP 751 lockfiles

Yes, it's faster and better than pyenv, but the mechanism it's using (virtual environments) is not a uv invention.

uv does the Python ecosystem better than any other tool, but it's still the standard Python ecosystem as defined in the relevant PEPs.

uv is purely a performance improvement, it changes nothing about the mechanics of Python environment management or packaging.

The improvements came from lots of work from the entire python build system ecosystem and consensus building.

This post isn't popular, it has already fallen off the HN frontpage never to be seen again in any context. It did not and will never break into any sort of traditional media.

Not a single Microsoft C-suite exec, or anyone within spitting distance of the C-suite, will ever hear about this. Do not mistake your personal media bubble for the general media ecosystem.

Microsoft has north of 100k SWEs working for them, the idea that corporate management could be personally responsible for the decisions of every single one is absurd.

I don't have a point beyond thinking that this is "Microsoft", the corporate entity, making a strategic decision is wrong. This is Aditya, the random software engineer with 5 years of experience making a decision.

How you reckon with that, what you take away from it, is up to you. If you want to hold MS corporate responsible for every decision Aditya and Piotr and Zhong make, you can feel free to, but it won't help you understand how these decisions are made because it's wrong.

This is not a PR problem, no one cares about this. It's barely a thing on HN, and not something any traditional media cares about.

> or they're not actually running the company at all

Executives are not micro-managing day-to-day implementation decisions of every team, no. They set broad strategic goals, the management layers below them decide how to best operationalize those goals, and the layers below those middle managers make specific implementation decisions to execute those operations.

If you want to think of this as "not actually running the company at all", you're free to. The point is that's how the world works.

A flash in the pan about a random fork they have on Github with <100 stars, and no significant public usage, which fails to correctly follow the reproduction requirement of the MIT license will not generate a C-suite response. It won't get outside the local management of the team responsible for the fork. Maybe a few dozen people at MS will ever know about this, and most of those from seeing it on HN; who have zero connection to the responsible team.

It baffles me that HN has no idea how large organizations work. The boss's boss's boss has no idea what random worker bees are doing.

Flying in the face of convention for no apparent reason. Use the normal FHS/XDG directories, makes everything easier.

`/usr/local` for system level, non-managed packages

`~/.local` for user level, non-managed packages

`/opt` for system level "add-on" packages. Typically proprietary upstreams. Zoom, Discord, the proprietary builds of Chrome or VSC, etc.

Of course not, but I don't rely on the extended file attributes for anything important such that they need to be replicated during copies

I actively do not want this in a file copy utility, relying on extended file attributes is a massive anti-pattern. If you care about time stamps, they go in the file format itself. If you care about permissions, those belong in the provisioning and access systems in front of the file. The web application or other API that is providing the access.

I expect file attributes of the target to be what I say they should be, not copied over from wherever the content happened to live before.

That's objectively worse, there's no way to know what "blue" means in such a context, there are many blues.

"I want things to be worse" is not a compelling argument. Letting developers describe the needs of their applications with a consistent grammar is not unnecessary invention, complexity, or friction.

The grammars of a technology, the set of building blocks with which developers are empowered to create, should balance flexibility with expressive intent. CSS <select> strikes this balance nicely. To decry its inclusion says more about the naysayer than the feature.

Switch to UBL, the manifest v3 successor to UBO, to continue to get updates, the performance is better too.

You are still allowed and able to block advertisements with extensions.

You could do it in 3nm (or any modern, in-demand node) on 300mm wafers. You could not do it in an ancient node where there's no commercial demand, on 200mm wafers the industry is slowly but surely superseding. These old nodes exist because the facilities were built 40+ years ago and there's just barely enough demand to keep them rolling.

The Skywater fab ran its first wafers in 1987. You could not build such a facility today for the same reason you couldn't build a large-scale factory for carbureted automobiles or CRT monitors. People still use these things, there's still a market for them, they're still serviced, but you could never find investors to build new production capacity.

I don't think I would have minded working with you and your workflow!

There's nothing bad about CL interactive development when used responsibly (and this extends to CL generally, nothing wrong with macros when used responsibly). It enables some behaviors that are still totally unavailable in other language environments. The REPL is remains unique to lisp and its descendants.

The problem is it allows irresponsible users the ability to create scenarios that are nightmarish for the technical experts tasked to support them. I've come to realize I care a lot more about it being hard to do bad things than enabling occasional convenience for advanced users.

And for me personally, I've never cared for or used the features of the REPL that are unique to it so I never miss them. My workflow, my editor, UI, keybindings, test reporting, all of it, for C++, Lisp, Python, JS, Fortran, etc, is mostly identical across the board and I find immense value in that consistency.

We can be more precise, I'm talking about declarative build systems and dependency tracking, project-local builds, tight IDE integration with automatic test suite detection, debug adapters, and language servers.

Those are the kinds of things I'm addressing when I say "modern". I'm not talking about Jupyter Notebooks. Notebooks are as bad or worse than anything I'm whinging about in the CL ecosystem.

Ya, this is the core of the disagreement that I would run into with the old school lispers.

I see it, I do, my third eye is open. I get the entire flow that the interactive development environment brings to the table and how it is infinitely superior than what existed in every other language for decades.

But I don't like it more than the modern tooling. That's pure personal preference. I don't like this weird stateful thing hanging out in the background of my dev environment. I don't find value in sending random expressions into the weird stateful blob. If I wanted to drop into a debugger, I'll ask, don't hijack my stacktraces.

I write tight test loops, modify my code, run the tests from scratch in the same one-key press the lispers use to evaluate their s-expressions. I don't need to go back and verify my build or application works from scratch, it never breaks, I'm constantly rebuilding.

I would run into situations not infrequently where some post-doc wasn't quite sure how they achieved the state they did in the image, had a bug, but no tests to reproduce the bug or anything else. Maddening. An anti-pattern I never saw accomplished to the same degree with the Python boys (not to say Jupyter Notebooks aren't their own stateful fucking mad house of bad software engineering).

It's ~$20k to get on an MPW, for 65 you can double that.

If you're talking about how much it takes to build the fab: infinity dollars, nobody builds new fabs in these nodes anymore. Skywater is barely keeping its head above water as-is and that's mostly wafer services, not tapeouts.

The Sky130 IO pads can't go faster than 33Mhz (at least the ones in the open source PDK), and the OpenLane flow isn't yet timing driven, so anything internal isn't going to break more than 100Mhz. These aren't fast chips or fast processes, Skywater is mostly for pedagogical and niche military and research tapeouts.

I despise SLIME. It made perfect sense in 2003 and was way ahead of the game compared to every other language for decades, but today we have the language server protocol and every effort should be made to support that instead.

Anecdotally, the AliveLSP works fine although it suffers from the same "Why would you want a standalone program? Load it into the REPL" problems I derided in response to the parent.

Do it the same way every language environment not named Common Lisp does?

I could very well be unlucky, and my experience is mostly with academics (not much industry usage of CL anymore).

But if I had a nickel for everytime I got emailed a core file I would not have had to be working in academia.