Posted by signa11 21 hours ago
You can see the discussion about it here: https://news.ycombinator.com/item?id=39877637
I remember learning a lot of these programming tricks over the years. They would give me happiness: learning something new about nvim, or some new shortcut in the Fish shell, or a new Vim macro, or the difference between 1 bracket or 2 brackets in Bash scripts, etc. But now it seems like all of them are irrelevant, and I wanted to see how others think about the situation.
Also, I'm mostly not very happy with the architectural choices the LLM makes. It can be good at little details, and sometimes I learn about language features or idioms or libraries by reading its code, but I find it often uses wrong patterns. E.g. just this week I saw it creating two huge intermediate data structures for parsing something in a "cleaner" way, completely missing how the library it had suggested actually had something builtin (and prominently featured in the tutorial) that obviated the need for those intermediate structures and was both safer and more readable.
When I've tried full agent coding, I kept getting distracted while waiting. I also have the feeling that my questions to the LLM were getting "dumber" as I lost contact with the code. And I don't have the hardware for local LLM's, so giving full repo access is out of the question for work.
Altogether I feel like I've found a fairly good balance in how to use them in such a way that I can avoid a lot of the downsides and still have a tool that gives me much value that I didn't have before: I check in fewer bugs, I waste less time picking libraries/methods, I have a better rubber duck, I learn little tricks all the time, I never send LLM-generated text to humans.
I write everything myself. After 41 years of coding, I think in code — code flows from my brain through my fingers effortlessly: translating my thoughts to English for an LLM to then translate back to code is much, much slower than me. And once my hyperfocus kicks in, the last thing I need is to be jolted out of it by an LLM prompting loop.
JetBrains Rider has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next. But even the next-word/next-block-of-code prediction seems so hopelessly out of its depth (which is supposed to be LLM’s party piece), it’s genuinely shocking how wrong it is most of the time.
Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.
Then, there's language-ext [1], which is my large open-source functional-programming framework for C#. And although this isn't beyond the realms of an LLM: they know FP and they know C# and even my library has been around for more than a decade, so it'll be in the training data, when it comes to bending C# to my whims or to trying to eek out exceptional performance, they're all at sea.
A good example would be what I am working on at the moment, which I have in a standalone prototyping repo [2]. Basically I have introduced functional traits to C#, like `Functor<F>`, `Applicative<F>`, `Monad<M>`, etc. This brings more rigour to things like LINQ comprehensions and allows for the building of truly generic trait-based behaviours. Something that just doesn't really exist in C#.
In language-ext today I have `Foldable<F>`, which is a little bit like `IEnumerable`, but pure. I want to be able to provide a super efficient set of default implementations for any `Foldable` (or enumerable/iterable). For this I need an efficient lazy-stream or co-routine system. The one built-in to C# (`IEnumerable` and `IEnumerator`) is impure (it mutates as it enumerates), so I am trying to build an efficient iterator/enumerator that:
* Takes around 0.25 nanoseconds per-iteration-step for its housekeeping (this speed is then on a par with the mutable IEnumerators that are a core part of C#).
* Doesn't allocate any memory
* Is immutable
* Is lazy
* Can be stopped at any point and the iterator reference be passed around (because it's immutable)
* Can be composed with standard functional operators (functor map, applicative apply, monad bind, etc.) without performance degradation and without a large memory-allocation cost.
I've been building several prototypes to try different ways of bending C# to my whims. I've managed all but the last item on that list.
Not allocating memory means using value-types (stack allocated types), but that also means the entire state of the co-routine needs to be stored in the value-type as each value is yielded (because control needs to be given back to whatever code is processing the values). To solve it, I'm pretty much building my own runtime, stack-machine, and memory manager on top of the .NET CLR so that I don't have to submit to its rules. I'm trying to apply as many of my old-skool low-level engineering chops as I can (without making it brittle); but to do the last item on that list needs more space in a value-type than would be reasonable (to avoid copying costs), so I'm looking at other pooling strategies and into building lots of bespoke to-the-metal memory managers.
After all of that, it may be a fools errand, and not doable. The LLM wouldn't understand, and that's for just one feature! Also, it must be stated, I just love doing this shit, it's brain fuel. The idea of having this conversation endlessly with an LLM as it continuously gets it wrong is nightmare fuel.
I'm not anti-AI, I love the fact that people who can't, now can. But, at this point in my journey with code, I think quicker and can produce quicker than an LLM. I think it's akin to a virtuoso piano player. If the piano player had to describe what they wanted to an LLM, the magic would go, the enjoyment would go, and potentially the quality would go. It would it also take much longer than if they had just played.
That's how I feel with code. An LLM can maybe churn out more code than me, but I can build more value and I can invent. And when in my flow state, nothing can stop me.
I will certainly keep checking in though, I'm sure there'll be a point where I feel like it augments me rather than hinders. It's just not there for me yet.
Too much information? :D
[1] https://github.com/louthy/language-ext
[2] https://github.com/louthy/iterator-prototype (this is messy prototype code, don't hate me).
I'm fortunate I guess in that most of my work tasks have very loosely defined deadlines, if any at all.
I don’t mean this to brag, mostly to point out that in my line of work, actually writing the code is not the biggest bottleneck.
For context I work on greenfield network security appliances
Analysis and any artifacts are all handcrafted by me. I mean, that is the work. I have never seen papers or code as an outcome. What I want is to learn and enable other to learn. That I can only get from doing the work myself.
That's basically I all do. I might ask a few questions to LLMs here and there like Google/StackOverflow in the days of yore.
Still, every line in all my codebases are still hand-typed. I get everything I need out of the chatbots, and I cannot use any kind of agentic coding tools at work, oddly enough. Trust me, I'd love to have access to something like Codex at work. That way I could save my mental bandwidth for personal projects that I find interesting and enjoying.
So i still get daily use out of these tricks.
Are there people that are literally ONLY interacting with a computer via an LLM? thats crazy if its true
LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.
But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)
Of course shell scripting is programming according to some HN commenters
Perhaps others would call SQL a programming language
For me, I personally use nothing fancy other than normal KDE Kate for backend development.
Function and variable names are chosen after putting a lot of thought into it which also includes being amenable to grep and sed.
In the macOS terminal you can...
Ctrl + Option + -
...and it'll undo your typing.Dunno about other OS keys!
I’ve always used Ctrl+U, it’s an Emacs shortcut, so it works in many shells and other prompts (especially since readline supports it) by default.
(For example Ctrl+Opt+- doesn’t seem to work in the Python REPL whereas Ctrl+U does.)