I agree, I think there is such a thing as AI overuse, but I would rather someone uses AI to form their points more succinctly than for them to write something that I can't understand.
To be fair, you are assuming that the input wasn't garbage to begin with. Maybe you only notice it because it is obvious. Just like someone would only notice machine translation if it is obvious.
The author posted their input to the LLM in the comments after receiving critcism, and that input was much better than their actual post.
In this thread I'm less sure: https://news.ycombinator.com/item?id=45713835 - it DOES look like there was something interesting thrown into the LLM that then put garbage out. It's more of an informed guess than an assumption, you can tell the author did have an experience to share, but you can't really figure out what's what because of all the slop. In this case the author redid their post in response to criticism and it's still pretty bad to me, and then they kept using an LLM to post comments in the thread, I can't really tell how much non-garbage was going in.
What's really sad here is that it is all form over function. The original got the point across, didn't waste words and managed to be mostly coherent. The result, after spending a lot of time on coaxing the AI through the various rewrites (11!) was utter garbage. You'd hope that we somehow reach a stage where people realize that what you think is what matters and not how pretty the packaging is. But with middle management usually clueless we've conditioned people to having an audience that doesn't care either, they go by word count rather than by signal:noise ratio, clarity and correctness.
This whole AI thing is rapidly becoming very tiresome. But the trend seems to be to push it everywhere, regardless of merit.
I'm currently learning vim and usign neovim, coming from VScode, wondering how y'all learned it if you made a similar switch, how long it took to learn and your opinions on purely text based editors vs smth like VScode that has a ton of features and plugins.
The journey starts by running the following command:
$ vimutor
in your shell to learn the absolute basics in about 20 minutes, which is largely enough to be able to perform quick edits on config files. If it didn't stick the first time, then try again. If it didn't stick the second time, then don't bother: Vim is not for you and that's 100% OK.
At the end of vimtutor there is a strong hint that there is a lot more to learn. If you are still interested at this point, then run the following command in a Vim session to access the user manual:
:help user-manual
An _active_ reading of chapters 1-12 and 20-32 is pretty much required if you really want Vim to disappear. Skipping this step will make everything worse down the line. It may take something like a month or two if you only do that, and probably a couple more if you do that on the side.
Now, a few recommendations…
Yes, you _need_ to read a lot and experiment a lot if you ever hope to become proficient with Vim. Just like with any "pro" app. It takes time and practice to become a pro at anything. That's life. Luckily, no one is expecting you to be a "pro" vimmer, now or ever, so you can do the learning at your leisure and even drop out if you have to. It's just a weird text editor after all and you still have VSCode.
Each chapter of the user manual builds up on the previous ones so you actually get a very gentle and progression curve. The wording is also very approachable so you don't have to be a CS major to understand it.
Don't go in with the project of replacing your current editor. This would be an absolute waste of time as it would give you false expectations AND a strong incentive to cut corners. Just… look at it. Poke at it. See if you like it and, eventually, dive in. Maybe you will end up replacing VSCode with it. Maybe not. Who cares?
---
As a programer, I have been using Vim as main text editor since 2010. I love it and I'm pretty good at it, active in the community and all, but I also use other editors and IDEs when doing so makes more sense and I'm not here to evangelize the masses. Vim is old and weird and powerful but a) that power comes at a (rather low, IMO) price and b) it won't solve all your problems so don't invest too much, emotionally, into that learning.
I did the neovim tutorial which I accessed via :Tutor, I see now that vimtutor has some divergences, I will do that tutorial also, to improve my muscle memory and knowledge.
Thanks for your other tips as well. I'll try and approach it that way, just doing it little by little, I don't always need VSCode and for simple edits its already way better than nano, although tbf I didn't take the time to learn all of nanos functionality.
It probably is best to take it slow and not cut corners. Play some vimgolf and take it slow, try to get the base stuff like regex search and replace down. Learning regex well can be applied to other things as well, so it is worth it to practice it in the context of vim.
I would stay away from vimgolf if I were you because it focuses too heavily on a useless metric, number of keystrokes. The so-called "Vim language" is about expressiveness, intuitiveness, composability, etc., so performing a task in 20 keystrokes is meaningless if it took two minutes to figure out each of them. 40 or 50 keystrokes that flowed without thinking are always better.
Also I must say that my regex-fu improved dramatically after I picked Vim.
It seems obvious, but I hadn't thought about it like that yet, I just assumed that the LLM was finetuned to be overly optimistic about any user input. Very elucidating.
The self-selection bias is definitely something to consider. I’d guess people who feel relatively confident in their intelligence are more likely to take the test.
I am not an experienced programmer, but I liked python because of the dynamic typing, but tbh no type hints are a nightmare (as I used to use python). These days I gravitate towards using type hints unless I am using an ipynb because it looks clean, but it can be a little much, it can look quite ugly. Not every usecase needs type hints is what I've learned.
A good compromise can be for example: Have your type annotations in the head of the procedure you are writing. That includes types of arguments and return type. You write it once at the head, and when you need to know you can look it up there, but you don't need to clutter the whole rest of the code. If you write well composing functions, then this will be all you ever need. If you write procedures 300 LoC, then well ... you shot yourself in the foot.
There definitely is an element of shooting oneself in ones own foot, but sometimes it seems unavoidable to me, or the effort just isn't worth it e.g. if I am using sklearn or numpy and the return types are ambiguous, then I'd have to overload each function at the head of the file or wrap it although it is clear what it does. What do you think? I think that if it's only my own code, then yes this is certainly avoidable with good composing functions.
