reuven

I didn't mean that AI is an abstraction. (Hmm, I should change the headline.)

I meant that every time our programming has taken place further away from the raw hardware, we've created abstractions that allow us to think at a higher level, allowing us to build larger and more complex systems. That also let more people write code.

I believe that programming with AI means no longer thinking in terms of strings, lists, and dicts, even though they're clearly being used by a lower level (assuming that AI is writing Python). This is similar to how we don't think in terms of bits and registers, even though those are still being used at the even-lower level.

I'm starting to think about what abstractions we'll want to create and use at this higher level.

MIT's report on AI and education is one of the smartest and deepest takes I've seen to date on the subject. But it's not a "we'll allow X and we'll forbid Y" report. Rather, it's saying that AI can and should profoundly change how we teach and learn, and that the sooner we start to experiment, always keeping people as our central focus, the better.

A very interesting point. Coding with AI definitely requires tight, fast loops. I don't have much experience with Rust, but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).

I'm OK with Lisp output, but maybe that just shows how old I am. :-)

I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.

I've been taking Chinese lessons for a number of years, and my teacher described her son as learning characters via pinyin. But it's quite possible (even likely) that the common ones don't require pinyin, and/or that I misunderstood how it's used. Nevertheless, even if I pushed the analogy a bit, I still think this might happen as a bridge between learning to code and agentic coding.

I can see Rust (and to some degree, Go) as the modern outputs from AI. My point about Python being Pinyin is that both of these languages have a relatively steep learning curve for someone without programming experience, and that it might be worth learning Python before doing agentic coding in Rust, much as children in China learn Latin characters before they learn characters.

I don't know if it's that hard for people to go from Python (where whitespace is significant) to languages that use {} and the like. But hey, people only hire me when they want people to learn Python, not when they're moving away from it. :-)

Interesting -- I still think that Python is an easier onramp than TypeScript for new developers. But given the popularity and depth of JavaScript, and the clear advantages (and popularity) of TypeScript in serious development, that's not a bad prediction.

While working on a PhD in technology and education, I thought that it might be worth creating a SaaS for people to teach whatever they want. This was back in early 2008, when such sites didn't exist. I assembled a team, and we made some progress, and even got a commitment from one funder. But I didn't really understand how to manage the team, and everyone was working very part-time on the project, and we didn't really have anything serious we could show, even after a few months. And the funder was only willing to invest if we found a second investor, which we didn't. So we ended up abandoning the project.

I think that we had some great ideas, including guiding instructors in the creation of online classes using the best proven pedagogical tools and theories. You could connect lessons to standards (if you were in a school, or wanted to be associated with one), or could do it free-form, or could use templates of various sorts.

I ended up finishing the PhD, so I can't complain too much! And as I wrote, I was probalby not a good person to run a startup; I'm much happier with my life as a bootstrapped freelancer. But it was hard to realize that I spent a year or so working on this with very little to show for it -- especially knowing that it might have thrived under a more experienced leader.

A lot of people I know, including many of my students, first heard about uv as a lightning-fast replacement for pip. That's what piqued their interest, and that's also more or less where they stopped. Just yesterday, someone was asking me about whether uv knows about handling different versions of Python, or if it only installs packages.

So your points are all valid -- but I'm trying to address pain points people have repeatedly raised, and that I myself experienced, and flatten the learning curve for as many people as possible.

I dunno, every single conference I've attended over the years had at least one talk trying to make sense of packaging -- downloading, installing, venvs, creating wheelfiles, and distributing to PyPI. It was nice to say that you could choose your own tools, but it was a huge, confusing, daunting mess for many people.

I had some thoughts about how things could improve, but the core developers said that anyone with their own ideas had better think through all of the implications, because packaging is super hairy.

The uv folks basically took that as a challenge, and said, "What if we have one package manager that replaces literally everything else in the packaging ecosystem, hiding the stuff that people find confusing or annoying?" Color me impressed; they really did it.

Sorry to disappoint! I can tell you that many people I've met, including those who have read the documentation, kept asking questions about how to use uv. This article is a summary that I came up with, based on my experience and theirs.

System-wide package installs are a weird quirk of my own work, since I'm doing very little product development and lots of one-off classes. I'm not at all recommending that "normal" developers do this, and I make sure to say that in all of the courses I teach.

I teach Python professionally, and constantly get questions from my students about how they should be using uv, and how to integrate it with pip, pyenv, venvs, and the like.

When I shared this post with them, my students said that it clarified things they didn't previously understand, even after reading the documentation. Part of the problem is that the documentation describes lots of options, rather than explicitly encouraging one particular path and model.

So I don't think it's just me; people are excited about uv, but aren't quite sure how to use it. But hey, I could be wrong!

As for your comment about venvs -- I teach them, I demonstrate them, and I use them when I work on programming projects.

I mostly create one-off Jupyter notebooks, which don't (in my opinion) merit their own venvs, because I don't care about locking versions. That said, I'm switching everything such that every class I teach will have not only a GitHub repo, but also a uv project, and thus an implicit venv behind the scenes. I still don't have to worry about package conflicts, but I want to be more in line with community conventions.