In fact if you are familiar with keyboard macros, in both vim and emacs you can do a lot of text heavy lifting tasks.
I don't see these as opposing traits. One can use both the goodness of vim AND LLMs at the same time. Why pick one, when you can pick both?
I mostly use manuals, books, and the occasional forum searches. And the advantage is that you pick surrounding knowledge. And more consistent writing. And today, I know where some of the good stuff are. You're not supposed to learn everything in one go. I built a knowledge map where I can find what I want in a more straightforward manner. No need to enter in a symbiosis with an LLM.
One can do pick and use multiple good things at a time. Using vim doesn't mean, I won't use vscode, or vice versa. Or that if you use vscode code you must not use AI with it.
Having access to a library doesn't mean, one must not use Google. One can use both or many at one time.
There are no rules here, the idea is to build something.
- Poor editor / editing setup
- Poor programming language and knowledge thereof
- Poor APIs and/or knowledge thereof
Mankind has worked for decades to develop elegant and succinct programming languages within which to express problems and solutions, and compilers with deterministic behaviour to "do the work for us".
I am surprised that so many people in the software engineering field are prepared to just throw all of this away (never mind develop it further) in exchange for using a poor "programming language" (say, english) to express problems clumsily in a roudabout way, and then throw away the "source code" (the LLM prompt) entirely such to simply paste the "compiler output" (code the LLM spewed out which may or may not be suitable or correct) into some heterogenous mess of multiple different LLM outputs pasted together in a codebase held together by nothing more than the law of averages, and hope.
Then there's the fun fact that every single LLM prompt interaction consumes a ridiculous amount of energy - I heard figures such as the total amount required to recharge a smartphone battery - in an era where mankind is racing towards an energy cliff. Vast, remote data centres filled with GPUs spewing tonnes of CO₂ and massive amounts of heat to power your "programming experience".
In my opinion, LLMs are a momentous achievement with some very interesting use-cases, but they are just about the most ass-backwards and illogical way of advancing the field of programming possible.
I wonder whether this is because people don't know about it or because they simply don't care...
But I, for one, try to use AI as sparingly as possible for this reason.
Change your search engine to one that doesn't include AI-generated answers. If none exist any more, all of Google's customers could write to them telling them that they don't want this feature and are switching away from them because of it, etc.
I know that internet-scale search is perhaps a bad example because it's so extremely difficult and expensive to build and run, but ultimately the choice is in the consumers' hands.
If the market makes it clear that there is a need for a search engine without LLM-generated answers at the top, somebody will provide one! It's complacency and acceptance that leads apparently-delusional companies to just push features and technologies that nobody wants.
I feel much the same way about the ridiculous things happening with cars and the automotive sector in general.
I'm using Cursor btw. It's almost a different form factor compared to something like GH copilot.
I think it's also worth noting that I'm using TypeScript with a functional programming style. The state of the program is immutable and encoded via strongly typed inputs and outputs. I spend (mental) effort reifying use-cases via enums or string literals, enabling a comprehensive switch over all possible branches as opposed to something like imperative if statements. All this to say, that a lot of the code I write in this type of style can be thought of as a kind of boilerplate. The hard part is deciding what to do; effecting the change through the codebase is more easily ascertained from a small start.
I too love functional programming, and I'm talking about Haskell-levels of programming efficiency and expressiveness here, BTW.
This is quite a different use case than those presented by the post I was replying to though.
The Go programming language has this mantra of "a little bit of copy and paste is better than a little bit of dependency on other code". I find that LLM-derived source code takes this mantra to an absurd extreme, and furthermore that it encourages a though pattern that never leads you to discover, specify, and use adequate abstractions in your code. All higher-level meaning and context is lost in the end product (your committed source code) unless you already think like a programmer _not_ being guided by an LLM ;-)
We do digress though - the original topic is that of LLM-assisted writing, not coding. But much of the same argument probably applies.
I honestly don’t think we’re far out from people being able to write “Write me a todo app” and then telling it what changes to make after.
I recently switched back to software development from professional photography and I’m not sure if that’s a mistake or not.
Well that's not how LLMs work. Don't use an LLM to do thinking for you. You use LLMs to work for you, while you tell(after thinking) it what's to be done.
Basically things like-
. Attach a click handler to this button with x, y, z params and on click route it to the path /a/b/c
. Change the color of this header to purple.
. Parse the json in param 'payload' and pick up the value under this>then>that and return
etc. kind of dictation.
You don't ask big questions like 'Write me a todo app', or 'Write me this dashboard'. Those are too broad questions.
You will still continue to code and work like you always have. Except that you now have a good coding assistant that will do the chore of typing for you.