No snippets, no LLMs, no autocomplete.
This is the way!
Ask HN: Does anyone still use code snippets?
51–60 of 61 posts
Re: Ask HN: Does anyone still use code snippets?
#52Earlier quoted context omitted.
> Around 85% of the time, it seems like it takes me more time to write what I want to code in natural language to an AI prompt (and then correct it) than it would to actually code what I want. That's how it should be, actually 100%. If you need scaffolding (and snippets) it means your language doesn't have (or worse, can't have) the right abstractions in its library.
You're correct it could mean that, but alternatively: - the use cases covered by the language could be so varied that it would be misguided to expect special functions for each of those cases - what one programmer describes as scaffolding could be seen as essential part of the setup for others. I have seen essential parts been called "scaffolding" by beginners who had no idea this was not just "text that needs to be…
> have seen essential parts been called "scaffolding" by beginners who had no idea this was not just "text that needs to be there"
https://en.wikipedia.org/wiki/Scaffold_(programming)
Nothing about scaffolding pertains to how important it is.
Re: Ask HN: Does anyone still use code snippets?
#53I use only one snippet both before and after integrating copilot (provided by my employer) into my workflow, which is for creating a empty arrow function (in JavaScript / TypeScript.) Copilot have not been able to generate arrow functions when I intend to, in my experience. I found it pretty incompetent, and unable to provide relevant assistance if there is any bit of abstraction. YMMV. I reckon my need for this spec…
This puzzles me. `arg => expression`, `(args, …) => expression`, `arg => { block }`, `(args, …) => { block }`… they’re not hard or long to type, and there are the different forms of argument list and body, so that I imagine you’d want more than one snippet (at least for expression versus block, considering some style guides say “always parenthesise argument lists”), and the entire thing seems not at all worth it.
Re: Ask HN: Does anyone still use code snippets?
#54Earlier quoted context omitted.
> Around 85% of the time, it seems like it takes me more time to write what I want to code in natural language to an AI prompt (and then correct it) than it would to actually code what I want. That's how it should be, actually 100%. If you need scaffolding (and snippets) it means your language doesn't have (or worse, can't have) the right abstractions in its library.
I am generally fine with duplicating some of the "scaffolding" between projects to aid with readability and have less magic when trying to understand the code. Eg. most languages would enable you to build a custom library, but then it becomes non-obvious what's exactly happening to someone diving into the project, a most engineers never bother fixing/improving the original library, and you end up with crap on top to…
IMHO What you describe is mostly a tooling problem. Current tooling doesn't let users to see the referenced/abstracted code as simply as the local code (for example, expand function definitions). So people tend to avoid abstracting it.
Re: Ask HN: Does anyone still use code snippets?
#55Nothing bigger than a foreach/switch snippet that's built in to in Rider.
The rest I can just do with whatever AI I'm currently using, they'll usually guess the variables right the first time too.
Re: Ask HN: Does anyone still use code snippets?
#56I tried using Copilot a bit, but I found it tried to do too much. As often as it got things right it got them irritatingly wrong. Something pared back giving context sensitive snippets would do fine.
You can swap it to only run on shortcut. You get used to when it will save you time / be accurate relatively quickly. It's a nice little autocomplete that saves me time- but I couldn't stand the automatic mode.
Ah, thanks. I will look for that.
Re: Ask HN: Does anyone still use code snippets?
#57Earlier quoted context omitted.
I am generally fine with duplicating some of the "scaffolding" between projects to aid with readability and have less magic when trying to understand the code. Eg. most languages would enable you to build a custom library, but then it becomes non-obvious what's exactly happening to someone diving into the project, a most engineers never bother fixing/improving the original library, and you end up with crap on top to…
IMHO What you describe is mostly a tooling problem. Current tooling doesn't let users to see the referenced/abstracted code as simply as the local code (for example, expand function definitions). So people tend to avoid abstracting it.
Yeah, that's a great point!
But solving that tooling issue is hard (or we'd have a great solution already), and we choose our compromises based on the reality we live in. Neither is perfect, and we should continue thinking how we can improve the situation from all angles, including improving the tooling as you suggest.
Re: Ask HN: Does anyone still use code snippets?
#58Earlier quoted context omitted.
> Around 85% of the time, it seems like it takes me more time to write what I want to code in natural language to an AI prompt (and then correct it) than it would to actually code what I want. That's how it should be, actually 100%. If you need scaffolding (and snippets) it means your language doesn't have (or worse, can't have) the right abstractions in its library.
I am generally fine with duplicating some of the "scaffolding" between projects to aid with readability and have less magic when trying to understand the code. Eg. most languages would enable you to build a custom library, but then it becomes non-obvious what's exactly happening to someone diving into the project, a most engineers never bother fixing/improving the original library, and you end up with crap on top to…
> ...abuse of @decorators in Python, which are side-effect pits of hell.
And just as I posted this, an articles shows up on the front page (https://www.dbos.dev/blog/what-is-lightweight-durable-execut...) claiming this:
> So how does this work? The key is in those decorators, DBOS.workflow() and DBOS.step(). They wrap your functions with the code that durably executes them. At a high level, they persist your program’s execution state–which workflows are currently executing and which steps they’ve completed–in a Postgres database.
Ouch! Those innocent looking lines of @DBOS.workflow or @DBOS.step make decorated functions actually connect to a Postgres database somewhere, and you can't be certain if you can test those functions without Postgres anymore. Ouch, ouch, ouch!
So, developers, please, remember the implicit vs explicit rule of thumb.
Re: Ask HN: Does anyone still use code snippets?
#59No snippets, no LLMs, no autocomplete.
Eep on the autocomplete. For me that's a must-have to enable clear code. Calling SomeFunctionWithAReallyDescriptiveName would get pretty painful pretty quickly if I had to type it out every time. No clue if it's true, but this is why I assumed a lot of older computing stuff is often abbreviated to the point of obfuscation.
How frequently do you actually have to type it out though?
You can always copy-paste from nearby code that also calls it.
Re: Ask HN: Does anyone still use code snippets?
#60No snippets, no LLMs, no autocomplete.
For things you write a lot, learning how to quickly autocomplete them can pay off. I don't autocomplete everything, as picking things from a list is if not slower then at least more annoying than just typing that thing, but for common things it's helpful. For instance I type "game.ReplicatedStorage" all the time, so taking a few moments to learn that "game.reso " is the same has saved time. What upped my motivation t…
Maybe you should brush up on your typing proficiency.