Comment by asa400

Comment by asa400 2 days ago

Abstraction. Not having to know all the innards (or even names) of each until you want to. It's all there if you want to, but stuff like uv (or cargo, or go's toolset) greatly simplifies 3 scenarios in particular: starting a new project, joining an existing project, and learning Python for the first time.

All 3 scenarios benefit from removing the choice of build tool, package manager, venv manager, formatter, linter, etc., and saying, "here, use this and get on with your life".

zahlman 2 days ago

How is "uv format" a better name, or more "abstract", etc. etc., than "ruff check"? Why is it easier to think of my formatter and package manager (or whatever other pieces) as being conceptually the same tool, given that they are doing clearly different, independent and unrelated things?

And why is any of this relevant to first-time Python learners? (It's already a lot to ask that they have to understand version control at the same time that they're learning specific language syntax along with the general concept of a programming language....)

Reply View 4 replies

asa400 2 days ago

It’s an abstraction because it literally hides knowledge in service of presenting a more a more cohesive API to the human.
It requires less knowledge at the front end, which is when people are being bombarded with a ton of new things to learn.
Learners don’t have to even know what ruff is immediately. They just know that when they add “format” to the command they already know, uv, their code is formatted. At some later date when they know Python better and have more opinions, they can look into how and why that’s accomplished, but until then they can focus on learning Python.
uv isn’t a package manager only, its best thought of as a project manager, just like go or cargo. Its “one thing” is managing your Python project.

Reply View | 2 replies
- zahlman 2 days ago
  
  Would Linux similarly be better if we wrote e.g. "cu list" instead of "ls", "cu change" instead of "cd", etc.? (The "cu" stands for "coreutils", of course.) Because it seems to me like the same arguments apply. I was already thinking of uv as a "project manager" and I understand that intended scope, and even respect the undertaking. My point is that I don't believe that labeling all the tasks under that scope like this actually improves the UX.
  Maybe I'm wrong about that. But I don't know that it can actually be A/B tested fairly, given network effects (people teaching each other or proselytizing to each other about the new way).
  
  Reply View | 1 reply
  
  woodruffw 2 days ago
  
  I don't think Linux would be better with a `cu` prefix for coreutils, but I do think git would be worse without a `git` prefix. I think it's ultimately a question of user expectations, and I think user expectations around packaging tooling in particular have shifted towards the Go and Rust styles of providing a "namespace" tool that provides a single verb-style interface for developer actions.
  
  Reply View | 0 replies
ChadNauseam 2 days ago
the meaning of the word "ruff" has nothing to do with formatting. Therefore it's harder to remember than "format". if they could just call the formatter "format", that would be best, but obviously that name is too overloaded. So they namespace it under a tool people already know, "uv".
Let's imagine you're learning a new language, which has tools with names that I just made up. Which has a clearer pattern to you?
1. Check code with `blargle check` 2. Format code with `blargle format` 3. Run code with `blargle run`
Or
1. Check code with `zoop` 2. Format code with `chungus` 3. Run code with `kachow`
Clearly, the first is easier to remember. The benefit of namespacing is that you only need to remember one weird/unique name, and then everything under that can have normal names. If you don't have namespacing, you need weird/unique names for every different tool.
Reply View | 0 replies