Is that the part of programming that you enjoy? Remembering logger vs logging?
For me I enjoyed the technical chalenges, the design, solving customer problems all of that.
But in the end, focus on the parts you love.
The user, infact, has setup a tool for the task - an "AI model", unless you're saying one tool is better than others.
Of course LLMs can do a lot more than variable autocomplete. But all of the examples given are things that are removing cognitive overhead that probably won't exist after a little practice doing it yourself.
- Your hot path functions get optimized, probabilistically
- Your requests to a webserver are probabilistic, and most of the systems have retries built in.
- Heck, 1s and 0s operate in a range, with error bars built in. It isnt really 5V = 1 and 0V = 0.
Just because YOU dont deal with probabilistic events while programming in rust, or python doesnt mean it is inherently bad. Embrace it.
> Just because YOU dont deal with probabilistic events while programming in ...
Runtime events such as what you enumerate are unrelated to "probabilistic codegen" the GP references, as "codegen" is short for "code generation" and in this context identifies an implementation activity.
Again, the post to which you originally replied was about code generation when authoring solution source code.
This has nothing to do with Linux, Linux process scheduling, RTOS[0], or any other runtime concern, be it operating system or otherwise.
0 - https://en.wikipedia.org/wiki/Real-time_operating_system
Apples and oranges. It's frankly nonsense to tell me to "embrace it" as a phantom / strawman rebuttal about a broader concept I never said was inherently bad or even avoidable. I was talking much more specifically about non-deterministic code generation during implementation / authoring phase.
Old heads cling to their tools and yell at kids walking on lawns, completely unaware that the world already changed right under their noses.
This change is good for some people, but it isn't good for us – and I suspect the problems we're raising the alarm about also affect you.
Still prefer my neovim, but it really made me realize how much cognitive load all the keyboard shortcuts and other features add, even if they feel like muscle memory at this point.
I mean, sure, yes, it can. But drastically less efficiently, and with the possibility of errors. Where the problem can be easily soluble, why not pick the solution that's just...right?
I think you're clinging onto low-level thinking, whereas today you have tools at your disposal that allow you to easily focus on higher level details while eliminating the repetitive work required by, say, the shotgun surgery of adding individual log statements to a chain of function calls.
> Of course LLMs can do a lot more than variable autocomplete.
Yes, they can.
Managing log calls is just one of them. LLMs are a tool that you can use in many, many applications. And it's faster and more efficient than LSPs in accomplishing higher level tasks such as "add logs to this method/methods in this class/module". Why would anyone avoid using something that is just there?
You are commenting a blog post on how a user set up his tools. It's just that it's not your tool that is being showcased.
> You should be able to type log and have it tab complete because your editor should be aware of the context you're in.
...or, hear me out, you don't have to. Think about it. If you have a tool that you type "add logs" and it's aware of best practices, context, and your own internal usage... I mean, why are you bothering with typing "log" at all?
I’m not saying not to use them, but you putting it like that is very dishonest and doesn’t represent the actual reality of it. It doesn’t serve anyone but the vendors to be a shill about LLMs.
There are many people out there that have absolutely no idea how horrible or great they have it.
It can infer the correct logging setup from the rest of the project and add the most logical values to it automatically
If you're proficient in a programming language then you don't need to remember these things, you just do it, much like spoken language.
I am using a much wider range of languages now that I have LLM assistance, because I am no longer incentivized to stick to a small number that are warm in my mental cache.
Granted, AI can definitely ease that ramp-up time at the cost of lengthening it.
Thank you for this analogy.
It's not the ramp up time. There's no problem with learning yet another one. There's a problem with remembering them all as you switch between the projects. Most of the time LLM will know exactly what to use, how, and what data I want to log. Which will take way less time than me rediscovering how a specific project I haven't seen in weeks does things.
I can reasonably expect Python to be installed on every Linux system, the debugging experience is amazing (e.g. runtime evaluation of anything), there's a vast amount of libraries and bindings available, the amount of documentation is huge and it's probably the language LLMs know best.
If there were two languages I would suggest anyone to start with, it would be C and Python. One gives a comprehensive overview of low-level stuff, the other gives you actual power to do stuff. From there on you can get fancy and upgrade to more advanced languages.
It's still important to know both, and especially when I began working on aspects like multithreading I found my basis in C helped me learn far easier, but i'm definitely more supportive of the ship it mindset.
It's better to have a bad side project online than have none - you learn far more creating things then never making things, and if you need LLMs and Python to do that, fine!
I think it depends on how you approach these tools, personally I still quite focus on learning general, repeatable concepts from LLMs as i'm an idiot who needs different terms repeated 50 times in similar ways to understand them properly!
In many many cases Python will be perfectly fine until you hit absolutely massive loads, and even then you can optimise the hot path with something else while keeping the rest as is.
No but genuinely like writing informative logs. I have been in production support roles and boy does the lack of good logging (or barely any logs at all!) suck. I prefer print style debugging and want my colleagues on the support side to have the same level of convenience.
Not to mention the advantages of being able to search through past logs for troubleshooting and analysis.
> Is that the part of programming that you enjoy? Remembering logger vs logging?
If a person cannot remember what to use in order to define their desired solution logic (how do I make a log statement again?), then they are unqualified to implement same.
> But in the end, focus on the parts you love.
Speaking only for myself, I love working with people who understand what they are doing when they do it.
You make my point for me.
When I wrote:
... I love working with people who understand what they
are doing when they do it.