A tutor that can guide you through jargon and give you references. If "skepticism" is even something you have to think about, you are already outside of the optimum path.
GP is saying that the LLM of choice is not necessarily able to translate the jargon, or establishes itself to be an expert at the concept(s) to employ the jargon compatible with the user.
I don't know what to say. You seem to be implying that the jargon if fundamentally unlearnable, and not amount of subsidiary text or help can help anybody.
That flag won't stick. Flagging someone just because you disagree with them is abusing the system. It adds noise and more work for the moderators to actually remove spam and troll comments. There's a downvote button. If you flagged it, then should be obvious to you after a decade of having an account on this site. If you still don't get it, then I can only assume that you're trolling (good luck with that). Also, fix your browser or whatever you use to read hn. Good day. lol
You tried to make a point that flagging was an appropriate response. Obviously I made it a conditional whether you did it or not, because I can't know. But you obviously did not understand that flagging is a tool for moderation, not a tool to prove a point.
Learn to consider whether you are mis-intepreting the person or there's something you don't know and ask questions. You literally wrote that you had an issue reading the whole comment, and dialogue would have resolved that specific misunderstanding instead of your antagonistic comment. I literally wrote "in jest" for a reason and you conveniently continue to miss it even after resolving your rendering issues. Jokes and tongue in cheeks are ways to open a conversation, not to invite lazy or stupid comments.
It's not my problem that you can't do these simple things like asking questions or reading/listening closely. And when you decide to be antagonistic about it, then you're just digging yourself into a hole (your loss and I don't feel sorry for you). Still, I don't think you understand what I was saying, but that doesn't matter because you seem to only care to vent.
You haven't contributed anything interesting to this thread. Just stop. You want to argue? Use your head, for your own sake.
Are these the same people who say it doesn't work well? I've been experimenting with writing what I actually mean by that (with the help of an LLM, funny enough), and it seems to be giving me much better code than the typical AI soup. e.g.
- functional core, imperative shell. prefer pure helpers.
- avoid methods when a standalone function suffices
- use typed errors. avoid stringly errors.
- when writing functions, create a "spine" for orchestration
- spine rules: one dominant narrative, one concept per line, named values.
- orchestration states what happens and in what order
- implementation handles branching, retries, parsing, loops, concurrency, etc.
- apply recursively: each function stays at one abstraction level
- names describe why something exists, not how it is computed
etc.
This is no different from writing a style guide for your team/org. You don't just say "write clean code" and expect that you'll get something you like.
To play devils advocate, why do we have to layout a simple task in PAINSTAKING DETAIL to an AI model which is "PHD LEVEL" and going to take our jobs in 6-12 months?
Why am I still holding its hand like it has the intellect and experience of a new-hire intern that's coded one project in college?
I would never expect to have to layout every detail about "how to write code" to someone I hired to code on my team, at the SWEII and above level. (I.e, sub-senior but beyond junior)
In fact, often times backlog items are "fix bug in x where y is happening" or "add instrumentation to X so that we can see why it's crashing at runtime".
I find that generally it does alright picking up the style of what exists on its own, so this is more important if it's writing something completely from scratch.
I think also "how to write code" is a matter of taste. e.g. in many ways I think I and a Laravel or Rails developer would each think that the other person's code is bad. e.g. as a small-ish thing, I think test-driven development sounds like a massive waste of time, but type-driven development is a huge productivity multiplier and makes the code a lot clearer. I'm sure that I have massive disagreements with e.g. the Go maintainers about what is straightforward.
Don't worry about devil's advocate, if < 100 words feels like a gargantuan amount of documentation effort ("PAINSTAKING DETAIL"), well, there are certain stereotypes about developers (not) writing comments or documentation that come to mind. Whoever coined the term "prompt engineering" may have the last laugh (before the robots take over) after all.
I hate that it's true, but things like this make outputs night-and-day for me. This is the difference e.g. of a model writing appropriate test harnesses, or pushing back on requirements, vs writing the most absolute horrible code and test/dependency injection I've ever seen in pursuit of the listed goals.
Similar to adjacent commentors I've tried to be better at enumerating what I consider to be best practice, but I couldn't argue in good faith that instructions like these produce no noticible improvment.
(As with all things AI, it could all be percepion on my end, so YMMV, wish there was a better way to concretely evaluate effects on outcomes of different rule sets / instructions / ...)
That's the thing about scammers, they operate in plausibly deniable ways, like covering up malice with incompetence. They make taking things at face value increasingly costly for the aggrieved.
I think in this case itemCount had application in a couple of conditions later in the function, so there was value in extracting the count. In my recollection I might be missing some nuance, lets say for the sake of argument it was:
var relevantCount = items.Where(x => x.SomeValue > 5);
vs
var numberOfRelevantItems = items.Where(x => x.SomeValue > 5);
so it wasn't necessarily cheap enough to want to repeat.
Almost. I think you're reflexively doing the same thing GP was questioning (which I agree with; in the original example the new variable was just straight duplication of knowledge and is as likely to be the source of bugs as anything else (like if items were added or removed, it's now out of date)).
Here though you're missing the ".Count", so
var relevantItems = items.Where(x => x.SomeValue > 5);
relevantItems.Count
As long as it's not a property that's calculated every time it's accessed, this still seems better than pulling the count into its own variable to me.
reply