Oh? I've had great luck with LLMs and homemade ILs. It has become my favourite trick to get LLMs to do complex things without overly complicating my side of the equation (i.e. parsing, sandboxing, etc. that is much harder to deal with if you have it hand you the code of a general purpose language meant for humans to read).
There is probably some point where you can go so wild and crazy with ideas never seen before that it starts to break down, but if it remains within the realm of what the LLM can deal with in most common languages, my experience says it is able to pick up and apply the same ideas in the IL quite well.
People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.
Logic errors always stems from lack of understanding and inattention. The former is resolved by good communication and analytical skills. The other is just human nature, but we do have guardrails to help, like static analysis and tests. If used correctly.
There are static tools available for C as well. What you get from Rust mostly is that the check is part of the syntax of the language as well and escaping from it is very visible. You get safety, but you give up flexibility and speed.
A plugin that does what exactly? A lot of comments here and under other posts are just declaring things with the following template: "I wanted to do X, but before it would took me N amount of hours, but now with LLM tool L, it has taken me way less time. I can't share anything about X, but LLM tool L is very useful. Just trust me, bro"
My favorite is this advert I keep getting that says "Imagine being able to build an app with your name on it!" I'm like... if you're struggling with the part where you put your name on it... and that's the priority.. I don't know what to tell you.
Everything in Emacs exists under the “M-x” keybind (M stands for Meta which is usually Alt on linux and Option on macOS). Because everything you can do is a command (which are just normal functions that have been annotated). Then you have bindings to directly execute those functions instead of going through a prompt.
There’s some terminology to learn to make sense of the commands. And the default keybindings are also useful to learn (and you can find them in anything that uses the readline library and equivalent: Bash, zsh, psql,…. You can also find them in macOS text widgets).
But the thing is that Emacs have a lot of commands. They are assembled into packages and due to the nature of Elisp, can be edited and patched live. While it easy to get started (videos on youtube, the emacs documentation, the “Mastering Emacs” book), After a while, you config can become alien to anyone else. But it will stay discoverable as Emacs have a great help system.
"and you can find them in anything that uses the readline library and equivalent: Bash, zsh, psql,…. You can also find them in macOS text widgets"
If anything, this is what pushed me towards emacs vs having to learn separate keybinds for vim/neovim. I wanted a terminal based TUI text editor that followed the conventions of keybinds I already understood. I switch from Mac to Windows to Linux quite often, and I am constantly hitting ^+a to get to the front of the line and constantly frustrated when it doesn't work on some OS or only works in some context. It's fantastic on macOS, ^+w does the same thing in my terminal that it does in my text editor that it does in my web browser that it does in my slide deck. It also works because macOS moved the common "CUA" shortcuts for the GUI apps to command/Super, so Ctrl isn't overloaded with shortcuts, leaving things like Ctrl+c to send a SIGTERM and Command+c to copy without fuss. Plug in a keyboard to an iOS device and they work over there most of the time too!
I wish it wasn't such a ballache to replicate this on Linux, even if the various forms of text fields in the GUI frameworks don't respect it.
Giving an estimate is not hard and shouldn't be a pain if if was truly an "estimate" PMs were asking for. But after a while you learn that when they say "What's the estimate for feature F?", they're in fact saying "What deadline you wish to impose on yourself for feature F?". Then the next interaction is most likely to be "Are you done yet?" and not "Is the estimate holding up?".
Take about anything from a standard GUI editor. In a terminal editor, they are also easily accessible. And more easily accessible (if not discoverable). But one of the major gain is how close your shell is. A lot of editors allows to start a cli tool and optionally send a portion of the current buffer as input to it. You may also be able to include the output in some buffer too. Some GUI editors allows that, but it's almost always a config maze and you're never sure of the environment in which it does run the commands.
Also in a terminal environment, all you enter are keyboard keys. If you know how to touch-type, your cognitive load can be greatly reduced (personal feeling). You can also navigate something like sublime with keyboard only. But it's way more tiresome.
CLI usage revolves around text and bash is a meta layer above that. Given curl, jq, and awk, you can create a quick MVP client for almost any api. Doing the same in Python and Go is much more involved.
reply