I've been coding in Python for 10+ years but I can never really get python's tooling ecosystem. It seems that there's always a newer shiny choice. easy_install, pip, conda, virtualenv, pipenv, setup_tools, hatchling, setuptools-scm, uv, requirements.txt, pyproject.toml...
I wish python can provide an "official" solution to each problem (like in rust, there's cargo, end of story), or at lease, an official document describing the current best practice to do things.
For the last year or so, I've been trying to provide an alternative guide that stays abreast the best options and provides simple guides: https://pydevtools.com/.
Apparently Kagi has been down globally for >10 minutes now. I cannot believe such maintenance is allowed for a service that want to convince people as a Google replacement.
Asking it to explain rust borrow checker is one of the worst examples to demonstrate its ability to read code. There are piles of that in its training data.
Agreed, ask it to explain how exceptions are handled in python asyncio tasks, even given all the code, and it will vacillate like the worst intern in the world. What's more, there's no way to "teach" it, and even if there was, it would not last beyond the current context.
A complete waste of time for important but relatively simple tasks.
Such a weird complaint. If you were to explain the rust borrow checker to me, should I complain that it doesn't count because you had read explanations of the borrow checker? That it was "in your training data"? I mean, do you think you just understand the borrow checker without being taught about it in some form?
I mean, I get what you are kind of saying, that there isn't much evidence that they tools are able to generate new ideas, and that the sheer amount of knowledge it has obscures the detection of that phenomenon, but practically speaking I don't care because it is useful and helpful (within its hallucinatory framework).
I’ve been using vim for 10+ years. However I honestly don’t see the downside of repeating h or j to move up/down (with the key repeat delay adjusted to a small value). It’s more intuitive than using say 15j, which involves recognizing some number in the screen and then look at the keyboard to type because the upper number row cannot be easily touch typed
I was the exact same until I started using relative line numbers. Then I can just look at a line and see that it's N lines down and jump there immediately. With j or k repeat I'll often over shoot and then have to go back which is kind of annoying.
The information is also more relevant. How many lines a function or block has might make a difference, but the absolute file position is, more often than not, irrelevant.
Funny, I was thinking exactly the opposite. Stack traces, logs, test failures, warning, etc will always reference an absolute number. If you want to tell a coworker where to find a section of code, you use the absolute number.
Relative numbers are useful to save a few keystrokes. But in every other context, absolute numbers are what's relevant.
Exactly. h or j repeated is widely dismissed as inefficient. But that ignores two important things:
First, you can hold down h or j and use visual clues to know when to stop. It's one keypress on the homerow, no reason to even glance at the keyboard. Eyes on the monitor = better focus. One keystroke.
Second, thinking in line numbers is one more piece of context to load up into your brain (find the line number), then act on (type out incantation), then context switch back to whatever you were doing before. By contrast, holding j until you're in the spot takes up almost zero working memory. You can think while it's happening! It's a small and subtle difference but that 200ms pause in thought process really does add up - not in wall time (jumping by line is probably "faster") but in contiguous focus time. Having to invoke any multi-part command is a distraction from your core work. Again, one lazy keystroke with immediate visual feedback > some complex combination of keystrokes.
An one small pitch for treesitter - rather than use j/k to navigate by line, set up some keybindings to jump by treesitter element (functions, methods, etc). I've got mine set to +/-. This lets you move in the same "dumb scrolling" way but by jumping to semantically-relevant parts automatically rather than line by line.
Agreed. I wonder if this is somewhat revealing of the mental processes of the creators.
To me, if my cursor is a few lines away from another line, the easiest way for me to get there is by either using h/j a few times, or looking at the absolute line number and doing that with gg.
Relative jumps are only useful to me in macros. Calculating a relative jump myself would 100% pull me out of the flow state where I just want to go up/down a few rows.
I have no proof of this, but I’d guess that the creator of this pattern didn’t feel the same way.
The best tip I got, was to rely more on search instead of other kind of movement. Especially when doing a bunch of editing. Things like easymotion/sneak/avy works best when reading/reviewing.
While I loved multi cursor with sublime. After I moved to Vim, I’ve never needed it. It’s either search~repeat or a macro. Now I’m using emacs, and it’s mostly occur-mode and macro. Grep edit is nice for bigger refactoring.
I really, really like flash/easymotion/etc because I effectively also use the same jump motions all the time in my browser (with vimium/tridactyl). So I have double the muscle memory, and I context-switch less between my browser and neovim, compared to if I was primarily using relative line jumps in neovim
Vim is a fine editor, but emacs has better tooling. I got in touch with Emacs while learning Common Lisp, and I got hooked by the extensive capabilities and customization available. Vim is fine for extension, but you have to build most of them yourself.
I tried evil mode, but it clashes with other keybinding in some places and I got unhappy with it. There's a philosophy conflict there. With vim, you're expected to have a command for an action and then bind it to a key. Your editing workflow is to compose those keys.
But with emacs, you're more expected to have a view and then a set of actions for that view. The power of emacs comes with how easy it is to integrate all those views together. For a programming workflow, you have the file explorer, the symbol explorer, the search result (single file and all files), the version control, the docs, the compilation|build window, the shell, the project tasks,... all together in the same place and linked to each other. With vim, you have to compose all those with a multiplexer and other tools (with conflicting bindings) to get there. Vim is still better for editing, but Emacs is better for workflows.
Getting used to thinking about multi-line motions via 5j helped me train to visualise lines that way.
Over time, I started using things like 13dd or 7yy with more ease.
Of course, `set relativenumber` is always recommended.
> Calculating a relative jump myself would 100% pull me out of the flow state where I just want to go up/down a few rows.
Yeah, you can't be a purist about it. If you're hard-focused and jjjjj is the first thing that comes to mind, then that's fine. When you're doing lighter work is when you have the spare mental capacity to train and improve on your workflow.
It's nice to have good tools that are practical for navigating around the text.
For jumping around what's on screen, I think 'easymotion' ("jump anywhere on screen by pressing two characters") & variations are best in terms of how quickly they let you navigate for how easy it is to use.
There are countless more convenient keys that you can use to navigate up and down without counting. Basic ones are /, *, n, N, H, M, L, {, }, %, ctrl-]. ]c, [c when you're in a diff buffer or have a Git plugin that offers this key. ]d, [d, [q, ]q, ]l, [l if you use Neovim.
C-d, C-u, {}, () and searches are better anyway. You should also be using g, so say you are defining a function and need to check where it's going to be used on main. For optimal usage you should always have main marked as something, so you would exit insert mode, gm, look around in main, gi to go back to where you were typing last
You don't need to use the upper row, bind numbers to right thumb modifier + numpad-like uio jkl m,.
Or instead of 15j use another jump to command that accepts those letters as numbers
Or have some jump type of command that displays a-z labels 1 per row in the middle and you can jump without numbers and without shifting focus to the gutter
But yes, the most basic motion will still be more "intuitive"
I've pretty much always struggled with this too. I have a numpad that I can touchtype easily but if I'm taking my hands off homerow I may as well use a mouse at that point.
I think it's more common because one doing only coding can get paid reasonably. On the contrary, few people who "bake cakes for fun, make music for fun, write poems, novels, play chess for fun, practice sports, grow potatos" can get paid enough for a living, so that's usually not an option to consider. (Which is the reason that I find us coding people very lucky.)
If you happen to work for a company that's big enough to pay reasonably. And even that is still a very temporary accident of times.
There was a time with plenty (comparatively to today) of tailors, living very reasonably, because there was a demand, and the means.
Today, you're lucky if you manage to find one that's in your city, and even more if he/she's not too expensive (that is, compared to ready-made stuff).
Like you almost spelled out, tailors were never competing with ready-made. Clothing used to be expensive, until people (sometimes children) working for pennies were able to send to you across long distances something good enough to wear.
Come on, coding is universally at a premium compared to other trades. Naturally you wouldn't have a FAANG salary at an outsourcing farm overseas but it'll certainly provide you with comfortable living by local standards.
> coding is universally at a premium compared to other trades
It has been and it still is at this time. Just saying that it won't last.
The existential threat, and perpetual adaptation to technology musicians (classical as well as contemporary) have met since the invention of sound recording and its developments, is coming for software developers too.
I'm not sure that is actually true about tailors. My understanding is that most clothing was homemade. I assume people didnt generally make their own shoes but they made their own textiles and basic garments and most people didnt have many garments.
Maybe there is a specific time period you are referring to where this was common but as I understand it, pre-industrially there were very few artisans selling products for money. Clothes were made largely by women and girls for their families.
Presumably he is referring to the industrialization period when suits were the everyday fashion. Once we moved on to baggy jeans and sweatpants, where the fit doesn't matter much, then the tailor was no longer relevant.
Yes, I'm referring to what we could call the golden age of tailoring, around 1800-1970.
You could say it was brief, relative to humanity history, indeed, as a transition period between cottage/home textile manufacturing as well as sewing, and high (and accelerating) automation managed by fewer people and lots of low-paid workers (as it is today).
And such is the trajectory for software development, a brief golden age, between the moment where computers barely existed, and the moment where automation/acceleration takes over.
It won't eliminate software development, but it won't require as many people as it does today. Some "local" artisan shops, highly skilled, and more expensive, may still exist.
But the capital currently feeling high tech salaries will inevitably seek new/other growth opportunities, as it has always done with other growth drivers.
I code at work so they can give me money so I can buy the stuff I need to carry on living. I have very generous employers who pay me a lot more money than I need to live on. The code I write at work is not very creative code - I contribute bugfixes and incremental improvements; I advocate for better accessibility of our products; I spend time code reviewing for colleagues. Standard work.
When the working day ends I switch from my work laptop to my personal laptop and start doing fun stuff: creative coding; curious-itch-scratch coding; etc. I'll also spend time doing the other fun stuff like writing poems, inventing languages, drawing maps, watching reaction videos - there's all that family and friend stuff too which can (often) be fun.
It's a choice: "live-to-work", or "work-to-live". I choose living. Recently my employers had a promotion round (the first in a few years) and I told my manager not to put my name forward for consideration. I'm comfortable at my current level and don't need the worries and stresses that come with increased work responsibilities - that would just get in the way of the fun stuff!
It's not that work is meant to be miserable, it's that if work wasn't in some ways miserable/frustrating/unrewarding/etc, more people would be doing it for free.
Or rather, you wouldn't need to pay people to do things they already enjoy doing. So, the things you need to pay people to do must contain some things that people don't want to do for free.
This is so much cheaper than re-prompting each tool use.
I wish this was extended to things like: you could give the model an API endpoint that it can call to execute JS code, and the only requirement is that your API has to respond within 5 seconds (maybe less actually).
I wonder if this is what OpenAI is planning to do in the upcoming API update to support tools in o3.
I imagine there wouldn’t bd much of a cost to the provider on the API call there so much longer times may be possible. It’s not like this would hold up the LLM in any way, execution would get suspended while the call is made and the TPU/GPU will serve another request.
They need to keep KV cache to avoid prompt reprocessing, so they would need to move it to ram/nvme during longer api calls to use gpu for another request
This common feature requires the user of the API to implement the tool, in this case, the user is responsible to run the code the API outputs. The post you replied suggests that Gemini will run the code for the user behind the API call.
It's also true for human. But then we invented functions / libraries / modules
reply