[HN Gopher] Does Visual Studio rot the mind? (2005)
___________________________________________________________________
Does Visual Studio rot the mind? (2005)
Author : inerte
Score : 92 points
Date : 2025-03-10 16:56 UTC (6 hours ago)
(HTM) web link (charlespetzold.com)
(TXT) w3m dump (charlespetzold.com)
| inerte wrote:
| The excitement about AI and Vibe Coding made me think about this
| (somewhat old) article.
| voidfunc wrote:
| Vibe... coding... I'm getting old, what is this?
| shmoogy wrote:
| Letting ai write most of the code (using cursor, windsurf,
| aider, or any similar solution).
|
| You go back and forth with the ai (or let the agent mode and
| MCP interactions) figure out any build errors / exceptions
| and resolve them.
| jadbox wrote:
| Throwing user stories at an LLM and hope it builds the right
| thing. It's like letting a product manager try to generate
| code without paying attention to the details. It's as
| terrible as it sounds, but debatably okay for fast
| prototypes.
| qingcharles wrote:
| I think this is what they're referring to -- see this video:
|
| https://www.tiktok.com/@rileybrown.ai/video/7473731306845768.
| ..
| colonCapitalDee wrote:
| A term coined by Andrej Karpathy.
|
| "There's a new kind of coding I call "vibe coding", where you
| fully give in to the vibes, embrace exponentials, and forget
| that the code even exists. It's possible because the LLMs
| (e.g. Cursor Composer w Sonnet) are getting too good. Also I
| just talk to Composer with SuperWhisper so I barely even
| touch the keyboard. I ask for the dumbest things like
| "decrease the padding on the sidebar by half" because I'm too
| lazy to find it. I "Accept All" always, I don't read the
| diffs anymore. When I get error messages I just copy paste
| them in with no comment, usually that fixes it. The code
| grows beyond my usual comprehension, I'd have to really read
| through it for a while. Sometimes the LLMs can't fix a bug so
| I just work around it or ask for random changes until it goes
| away. It's not too bad for throwaway weekend projects, but
| still quite amusing. I'm building a project or webapp, but
| it's not really coding - I just see stuff, say stuff, run
| stuff, and copy paste stuff, and it mostly works."
|
| https://x.com/karpathy/status/1886192184808149383
| kelseyfrog wrote:
| Absolutely it does. In the same way Socrates warned us about
| books, VS externalizes our memory and ability. and makes us
| reliant on a tool to accomplish something we have the ability to
| do without. This reliance goes even further to make us dependent
| on it as our natural ability withers from neglect.
|
| I cannot put it more plainly that it incentives us to make a part
| of us atrophy. It would be like us giving up the ability to run a
| mile because our reliance on cars weakened our legs and de-
| conditioned us to the point of making it physically impossible.
| tomlue wrote:
| Completely agree. Though I think this statement could benefit
| from pointing out that cars also help people go much faster,
| and do things they otherwise couldn't.
| dartos wrote:
| Besides going fast, what does a car allow people to do that
| they couldn't before?
| jason_zig wrote:
| are you serious?
| dartos wrote:
| Yea
| DontBreakAlex wrote:
| Reach farther places? Move around heavy loads?
| dartos wrote:
| People traveled almost the entire world and built
| pyramids before cars were invented.
|
| They make it easier and faster, but don't add new
| capabilities
| sunshowers wrote:
| I think "carrying something heavy without slavery being
| involved" is a new capability compared to "enslaving
| people and making them carry something heavy".
| kelseyfrog wrote:
| Go through drive-thrus.
| dartos wrote:
| Shit, you right.
| jermaustin1 wrote:
| I got yelled at once at the bank in my office's parking
| lot for going to the drive up ATM instead of going inside
| to a teller. So they definitely agree with that. Not
| allowed to walk through a drive through.
| mikedelfino wrote:
| Cars allow people to travel longer distances more
| conveniently, access remote areas, transport goods
| efficiently, and have greater independence in their daily
| lives. They also enable emergency services to respond
| quickly, support economic growth by facilitating trade, and
| provide opportunities for leisure travel that were
| previously impractical.
| dartos wrote:
| Yes, they make things faster and easier.
|
| My question was what do cars let us do now that we
| couldn't before.
|
| We moved heavy objects and traveled long distances long
| before cars.
| itishappy wrote:
| They let us do things efficiently. Sure, you could have
| moved a truckload of goods up the coast using 20 wagons,
| 40 mules, 20 drivers, 10 security, and a week's time.
| Today, one dude can move a truckload of goods up the
| coast same day.
|
| (Numbers have been entirely fabricated, feel free to send
| adjustments.)
| recursive wrote:
| Going faster and carrying more is enough to enable things
| that aren't otherwise possible.
|
| For example, I can take my kids to visit their cousins
| for the day and make it home by bedtime.
| kelseyfrog wrote:
| Utilize car washes.
| daedrdev wrote:
| In a day I can travel many times farther than I can walk,
| carrying hundreds or thousands of pounds of stuff with me
| if needed.
| hooverd wrote:
| The ICE and more generally the automobile has been a great
| technology and has lots of benefits. But we did all huff
| alarming amounts of lead for a generation and built our
| cities around them to our detriment.
| fransje26 wrote:
| > But we did all huff alarming amounts of lead for a
| generation and built our cities around them to our
| detriment.
|
| And yet, this has nothing to do with the ICE itself, and
| everything to do with the greed of the Ethyl Corporation
| and the generation of corrupted minions that knowingly
| enabled their disastrous scheme.
| wahern wrote:
| Relatedly, people who rely too much on GPS for navigation
| (i.e. online automated route planning), especially real-time,
| turn-by-turn instruction, seem to have poor spatial
| awareness, at least at the local geographic level. I doubt
| the loss of that skill is a meaningful impediment in modern
| life[1], but I personally would not want to lose it. Tools
| like Google Maps are extremely useful, but I use them to
| augment my own navigation and driving skills. I'll briefly
| study the route before departing, choose major thoroughfares
| to minimize complexity, and try to memorize the last few
| turns (signage and a practiced understanding of how highways
| and roads are laid out is sufficient for getting close
| enough).
|
| [1] No impediment for _them_. It 's an impediment for me when
| the car in front of me is clearly being driven by somebody
| blithely following the computer's instructions, with little
| if any anticipation of successive turns, and so driving
| slowly and even erratically.
| aaronbaugher wrote:
| Yes. You can see a difference between the person who
| learned to do a process "by hand" and then uses technology
| to make it faster or easier, versus the person who never
| learned to do it without the tech at all.
| hooverd wrote:
| Being an active transit crank, I'd like to put out that if
| computers are a "bicycle for the mind", LLMs are an SUV.
| QuercusMax wrote:
| An SUV? Unnecessary for most people, a huge waste of power,
| and bad for the environment? Dangerous to bystanders?
| fragmede wrote:
| but great for the occupants
| QuercusMax wrote:
| Only in moderation; spending all day sitting in a vehicle
| is bad for you. Gotta still get your exercise.
| sbuttgereit wrote:
| But also gives us back time and mental capacity to do other
| things which were previously out of reach because of what we
| had to focus our minds and time on.
|
| In some cases, maybe even many or the majority of cases, that
| trade isn't a bad one. It really depends on how you use it.
| snarfy wrote:
| If your job for 30 years is to move bags of cement 50 miles
| each day, is it not more productive to use a truck than your
| legs? Even if you use the truck so much you could not move a
| bag of cement with your legs anymore due to atrophy?
|
| You could make the same argument about most tools. Do
| calculators rot the brain?
| yoyohello13 wrote:
| > Do calculators rot the brain?
|
| Yes, they unequivocally make people worse at mental math. Now
| whether that's bad or not is debatable. Same with any tool,
| it's about tradeoffs and only you can determine whether the
| tradeoffs make sense for you.
| BuckRogers wrote:
| > _they unequivocally make people worse at mental math. Now
| whether that 's bad or not is debatable._
|
| Not debatable because as long as calculators exist and are
| available, nothing is lost. You can put that mental energy
| towards whatever is relevant. There's nothing special about
| math that elevates doing it in your own mind more valuable
| than other tasks. Any of us that do software for a living
| understand that mental work is real work and you are
| limited in your capacity per day. If your boss wants to pay
| you to do longhand division instead of getting projects
| done, I'd call that man a liar.
|
| The people that make these arguments that we "lose"
| something are usually academics or others that aren't
| actually in the trenches getting things done. They think
| we're getting weaker mentally or as a society. I'm
| physically tired at the end of the day, and I sit at a
| desk. I'll do math when the calculators are gone, I have a
| lot of tasks and responsibilities otherwise.
| bigstrat2003 wrote:
| > Not debatable because as long as calculators exist and
| are available, nothing is lost.
|
| This is a vacuous argument. Of course nothing is lost if
| we are never in the situation where the downsides of
| calculator reliance are apparent. Nobody said otherwise.
| The point is that people _do_ find themselves in those
| situations, and then struggle to do math because they 've
| never developed the skill.
| jchw wrote:
| > Do calculators rot the brain?
|
| I don't know if I'd agree with the phrasing that it rots the
| brain, but broadly I would expect that if you rely on it for
| arithmetic your mental arithmetic will atrophy over time.
|
| Unfortunately though it may not be such an exaggeration after
| all. It's probably too early to say, but there is definitely
| mounting evidence that some of these useful tools are
| literally, genuinely rotting our brains.
|
| https://www.fatherly.com/news/gps-google-maps-cognitive-
| decl...
|
| Even if we just take this at face value and assume it's
| accurate though, it's still not immediately clear what to
| actually _do_ with this knowledge.
| gspencley wrote:
| > Unfortunately though it may not be such an exaggeration
| after all. It's probably too early to say, but there is
| definitely mounting evidence that some of these useful
| tools are literally, genuinely rotting our brains.
|
| > https://www.fatherly.com/news/gps-google-maps-cognitive-
| decl...
|
| I think you may have fallen into a bit of confirmation bias
| there. The article you linked to words itself like so:
|
| "According to research published in the journal PLOS One,
| navigating with a map and compass might help stave off
| cognitive decline and symptoms associated with Alzheimer's
| Disease."
|
| This means that the study found that there may be positive
| benefits to cognitive health when one routinely engages in
| navigation related activities using a compass and a map.
|
| That is a very very VERY different statement than: "Using
| Google Maps causes cognitive decline."
|
| In order to demonstrate any kind of causality between using
| Maps and cognitive decline, you would have to start with an
| additional premise that everyone engaged in navigation
| using a compass and map on such a regular basis that the
| switch represents a switch to a less healthy lifestyle.
|
| I think that statement is specious at best.
|
| I'm old enough to remember living without Google Maps. And
| the amount of time that I reached for a paper map and a
| compass was so infrequent that Google Maps represented
| something new for me more than it represented something
| different. That is to say, it wasn't replacing something I
| did regularly so much as it gave me a reason to start using
| any kind of a "map" in the first place.
|
| Most people I know would say the same thing. We had some
| maps skills when we needed them ... but we tried to avoid
| needing them more often than not.
|
| So yeah, the study might have merit. But I don't think it
| suggests what you think it suggests.
| jchw wrote:
| > I think you may have fallen into a bit of confirmation
| bias there. The article you linked to words itself like
| so:
|
| > This means that the study found that there may be
| positive benefits to cognitive health when one routinely
| engages in navigation related activities using a compass
| and a map.
|
| > That is a very very VERY different statement than:
| "Using Google Maps causes cognitive decline."
|
| It is a different statement, but it is not a giant
| logical leap. The two statements are connected by a
| pretty rational extrapolation. That said, I'm not
| suggesting this study is claiming anything like that,
| just that there is growing evidence that these things
| might be bad for our brain health, and studies like this
| are part of it.
|
| However, it's going to be _really, really hard_ to
| _prove_ that something like Google Maps is ultimately
| responsible for cognitive decline. In fact, I think
| saying that would be a step too far. However, when you
| combine many of these tools, like calculators, AI
| autocomplete, and GPS navigation together, I _definitely_
| think there is a stronger case that it is not good for
| our brain health, but I doubt it 'll be easy to make a
| case for that using actual data, and I don't expect such
| a study to come around soon (and even if it did, I'm not
| sure people would feel enticed to trust it anyways.)
|
| > I'm old enough to remember living without Google Maps.
| And the amount of time that I reached for a paper map and
| a compass was so infrequent that Google Maps represented
| something new for me more than it represented something
| different. That is to say, it wasn't replacing something
| I did regularly so much as it gave me a reason to start
| using any kind of a "map" in the first place.
|
| I'm surprised. I thought all of us who lived before
| Google Maps were using Map Quest, at least for a few
| years. That's what I was doing. Before Map Quest, when I
| was growing up, we definitely did try to avoid paper maps
| as much as possible, but it was frequently necessary to
| go somewhere we didn't already know how to get to, so it
| wasn't unusual to have to get directions and navigate
| using a map.
|
| Anyhow, I'm sure everyone experiences life differently
| here, but I think not needing to navigate very often is
| definitely something I would've considered a luxury.
| justtinker wrote:
| I am the MapGuy(TM). I had paper maps of every
| destination and triptix from AAA. I would fly with a
| pocket Rand McNally Road Atlas and be able to identify
| where we were from features on the ground. I still do it
| but I use a GPS. I don't trust them so I still check maps
| before I use a GPS in unfamiliar areas. I find badly
| optimized routes 5% of the time and outright mistakes 1%.
|
| I was the one who got people unlost when they got them
| selves lost because they did not listen to the map geek.
|
| I hope this gives me at least 30 more years before mental
| decline starts. That will get me to my late 90's.
| w0m wrote:
| > Do calculators rot the brain?
|
| According to my math teachers in high school - yes.
| trelane wrote:
| Relevant to this topic:
| https://en.wikipedia.org/wiki/The_Feeling_of_Power
|
| PDF of the story: https://archive.org/download/TheFeelingOfPo
| wer/The%20Feeling...
| vunderba wrote:
| This is a poor analogy.
|
| The real danger of LLMs lie in their seductive nature - over
| how tempting it becomes to immediately reach for the nearest
| LLM to provide an answer, rather than taking even the
| briefest of moments to quietly ponder the problem on your
| own.
|
| That act of manipulating the problem in your head--critical
| thinking--is ultimately a _CRAFT_. The only way to become
| better at it is by practicing it in a deliberate, disciplined
| fashion.
|
| However if you ultimately believe that critical reasoning
| isn't worth cultivating, then I suppose we're at an impasse.
| sunshowers wrote:
| How different is this argument from "does Rust rot the mind"?
| After all, Rust means that the part of the brain that is
| paranoid about careful memory safety issues no longer has to be
| engaged.
|
| Like most things, the answer is that it depends. I think
| autocomplete is great, and I've come to appreciate LLMs doing
| boilerplate editing, but I'm quite worried about people using
| LLMs to do everything and pumping out garbage.
| bongodongobob wrote:
| Socrates just argued about semantics. If you take anything away
| from those dialogues it should be that they were confused and
| didn't really have many good ideas.
| tarunkotia wrote:
| Great point, to me it feels more like running barefoot versus
| with padded shoes. Barefoot running will build your foot muscle
| based on your natural form over time, whereas padded shoes may
| interfere with your natural form and at worst encourage bad
| form which may lead to injuries as your mileage increases.
|
| Over the years in building software, I tend to spend more time
| thinking about how all the pieces (i.e. from package manager)
| fit together rather than building them from scratch and fitting
| two pieces together require deeper understanding of both the
| pieces and how the combination of the two behaves in the
| environment.
| asdfman123 wrote:
| This article is so well written and more relevant than ever.
| hooverd wrote:
| Yes. Intellisense is great for discovery and terrible for recall.
| I think it comes out ahead though. Why remember things when I can
| CTRL+SPACE and search?
| rqtwteye wrote:
| I think with the number of libraries today you can't really
| remember everything. It's just not possible anymore.
| bluedino wrote:
| There should be an updated article, "Does _Visual Studio Code_
| Rot the Mind? "
|
| _In the old days_ , when we set our development environments up
| _by hand_ , you usually ended up learning quite a bit about your
| setup. Or you at least had to know things like what's installed,
| what paths are where, blah blah.[1]
|
| With Visual Studio Code being what almost everyone uses these
| days, everything is a click-to-install plugin. People don't
| realize Python isn't part of Visual Studio Code. The same for
| gcc, ssh, etc. You end up with tickets like "Can't run Python",
| or "Can't connect to the server", but it's all Visual Studio Code
| issues.
|
| [1]: And yes, I realize a lot of us didn't know what we were
| doing back then, and the shotgun approach of "`apt-get install
| foobar` fixed this for me!" was a standard 'solution'
| Conscat wrote:
| My background is heavily biased towards C++ but I don't really
| feel like you can make it work in VS Code without
| understanding, at minimum, where your clangd is actually
| located. The C++ plugins don't install what you need where you
| need them, and the launch.json really does not just work. My ex
| was unable to set up a C++26 toolchain for VS Code because
| without my help he couldn't configure the settings to connect
| to the right version of clang tools, and I don't think he ever
| got the GDB debug adapter working at all.
| mattmanser wrote:
| One of the definite positives of AI is that kind of stuff is
| now fairly easy to solve.
|
| It surfaces a lot of the ways people found to fix those
| problems in forums/git issues/random blogs that were hard to
| track down past google spam.
|
| And it tends to list the possible fixes in a nice little
| bullet point list of things to try to get everything working.
| bluedino wrote:
| > One of the definite positives of AI is that kind of stuff
| is now fairly easy to solve.
|
| I agree that 'AI' feels like a fancier/faster 'Google'
| (I've done the thing where I find a Github issue from 4
| years ago that explains the problem), but when we will see
| a local AI agent that looks at your current
| configuration/issue and solves the problem for you, and
| then gives you a summary of what it did?
| fragmede wrote:
| open-interpreter has been around for a while by this
| point.
| yoyohello13 wrote:
| The number of times I've had to help a colleague troubleshoot
| some VSCode thing seems to bear this out. I'm regarded as a
| 'wizard' because I actually know how to use git/build tools
| without a gui. It's kind of shocking to me how many developers'
| knowledge ends at the run button.
|
| It doesn't bother me too much, because I like being needed,
| lol. But it would probably make our team more productive if
| people bothered to learn how our tooling works.
| woodrowbarlow wrote:
| my version of this was "do convenient linux distros and binary
| package managers rot the mind?" after setting up a freebsd box
| with everything built from source and everything configured by
| hand. then again from building an arch-based Linux system from
| the wiki. you learn a lot from doing things by hand... but
| eventually you need to get stuff done.
| indigovole wrote:
| It's a really interesting question.
|
| I'm sure you could go back 40 years earlier and find programmers
| complaining about using FORTRAN and COBOL compilers instead
| writing the assembly by hand.
|
| I think that the assembler->compiler transition is a better
| metaphor for the brain->brain+AI transition than Visual Studio's
| old-hat autocomplete etc.
|
| After working with Cursor for a couple of hours, I had a bunch of
| code that was working according to my tests, but when I
| integrated it, I found that Claude had inferred a completely
| different protocol for interacting with data structure than the
| rest of my code was using. Yeah, write better tests... but I then
| found that I did not really understand most of the code Claude
| had written, even though I'd approved every change on a granular
| level. Worked manually through an solid hour of wtf before I
| figured out the root cause, then Clauded my way through the fix.
|
| I can picture an assembly developer having a similar experience
| trying to figure out why the compiler generated _this_ instead of
| _that_ in the decade where every byte of memory mattered.
|
| Having lived through the dumb editor->IDE transition, though, I
| _never_ had anything like that experience of not understanding
| what I'd done in hours 1 and 2 at the very beginning of hour 3.
| jgrahamc wrote:
| I was programming 40 years ago and was very happy to be able to
| use "high-level languages" and not write everything in
| assembly. The high-level languages enabled expressiveness that
| was hard with lower levels.
| scarface_74 wrote:
| In 1985, any time I needed any level of performance on my
| 1Mhz Apple //e, I still had to use assembly or when BASIC
| didn't expose the functionality I needed. Mostly around
| double hires graphics and sound.
| jgrahamc wrote:
| Yep. That stuff was necessary then and still is today. Just
| look at DeepSeek doing low(er) level NVIDIA stuff and
| making the GPUs work hard.
| yoyohello13 wrote:
| This feels very similar to me as the "Tutorial Hell" effect.
| Where I can watch videos/read books, and fully feel like I
| understand everything. However, when hand touches keyboard I
| realize I didn't really retain any of it. I think that's
| something that makes AI code gen so dangerous. Even if you
| think you understand and can troubleshoot the output. Is your
| perception accurate?
| cassepipe wrote:
| I have done that too much. When learning now, when I read the
| solution, I always make sure that I am able to implement
| myself, else I don't consider I learned it. I apply the same
| for LLM code.
| irishloop wrote:
| Yeah I never really learn something until I actually hack
| away at it, and even then I need to really understand things
| on a granular level.
| ashoeafoot wrote:
| The Torturial
| golergka wrote:
| > Where I can watch videos/read books, and fully feel like I
| understand everything. However, when hand touches keyboard I
| realize I didn't really retain any of it.
|
| Always type everything down from a tutorial when you follow
| it. Don't even copy and paste, literally type it down. And
| make small adjustments here and there, according your
| personal taste and experience.
| vunderba wrote:
| I've called this out before around LLMs - when the act of
| development becomes passive (versus active) - there is a
| significant risk around not fully being cognizant of the
| code.
|
| Even copy pasta from Stack Overflow would require more active
| effort around grabbing exactly what you need, replacing
| variable names, etc. to integrate the solution into your
| project.
| mystified5016 wrote:
| Embedded programming is _still_ like this. Most people just don
| 't inspect the assembly produced by their compiler. Unless
| you're working on an _extremely_ mainstream chip with a
| bleeding edge compiler, your assembly is going to be absolutely
| full of complete nonsense.
|
| For instance, if you aren't aware, AVR and most other uCs have
| special registers and instructions for pointers. Say you put a
| pointer to an array in Z. You can load the value at Z and
| increment or decrement the pointer as a single instruction in a
| single cycle.
|
| GCC triples the cost of this operation with some extremely
| naive implementations.
|
| Instead of doing 'LD Z+' GCC gives you ``` inc Z ld Z dec Z ```
|
| Among other similar annoyances. You _can_ carefully massage the
| C++ code to get better assembly, but that can take many hours
| of crazy-making debugging. Sometimes it 's best to just write
| the damn assembly by hand.
|
| In this same project, I had to implement Morton ordering on a
| 3D bit field (don't ask). The C implementation was well over
| 200 instructions but by utilizing CPU features GCC doesn't know
| about, my optimized assembly is under 30 instructions.
|
| Modern sky-high abstracted languages are the source of brain
| rot, not compilers or IDEs in general. Most programmers are
| completely and utterly detached from the system they're
| programming. I can't see how one could ever make any meaningful
| progress or optimization without _any_ understanding of what
| the CPU actually does.
|
| And this is why I like embedded. It's very firmly grounded in
| physical reality. My code is only slightly abstracted away from
| the machine itself. If I can understand the code, I understand
| the machine.
| lukev wrote:
| And this is appropriate for your domain and the jobs you work
| on.
|
| If your job was to build websites, this would drive you
| insane.
|
| I think I'm coming around to a similar position on AI dev
| tools: it just matters what you're trying to do. If it's a
| well known problem that's been done before, by all means.
| Claude Code is the new Ruby on Rails.
|
| But if I need to do some big boy engineering to actually
| solve new problems, it's time to break out Emacs and get to
| work.
| larve wrote:
| As a long time embedded programmer, I don't understand this.
| Even 20 years ago, there is no way I really understood the
| machine, despite writing assembly and looking at compiler
| output.
|
| 10 years ago, running an arm core at 40 Mhz, I barely had the
| need to inspect my compiler's assembly. I still could roughly
| read things when I needed to (since embedded compilers tend
| to have bugs more regularly), but there's no way I could
| write assembly anymore. I had no qualms at the time using a
| massively inefficient library like arduino to try things out.
| If it works and the timing is correct, it works.
|
| These days where I don't do embedded for work, I have no
| qualms writing my embedded projects in micropython. I want to
| build things, not micro optimize assembly.
| nosianu wrote:
| > _As a long time embedded programmer, I don 't understand
| this_
|
| I think you both should define what your embedded systems
| look like. The range is _vast_ after all. It ranges from 8
| bit CPU [0] with a few dozen kilobytes of RAM to what
| almost is a full modern PC. Naturally, the incentives to
| program at a low level are very different across the
| embedded systems range.
|
| [0] https://www.silabs.com/mcu/8-bit-
| microcontrollers/why-8-bit-...
| iuvcaw wrote:
| The vast majority of time spent building software has little
| to do with optimization. Sky-high abstracted brain rot
| languages are useful precisely because usually you don't need
| to worry about the type of details that you would if you were
| optimizing performance
|
| And then if you are optimizing for performance, you can make
| an incredible amount of progress just fixing the crappy Java
| etc code before you need to drop down a layer of abstraction
|
| Even hedge funds, which make money executing trades fractions
| of milliseconds quicker than others, use higher level
| languages and fix performance issues within those languages
| if needed
| phyllistine wrote:
| If you're active on social media (twitter), you will still see
| people, like the FFmpeg account, still bashing higher level
| languages (C) and praising hand written assembly.
| the__alchemist wrote:
| This is a tangent, but perhaps relevant:
|
| I think sending your LLM all relevant data structures (structs,
| enums, function signatures etc) is mandatory for any code-
| related queries. It will avoid problems like this; it seems
| required in many cases to get integratable results.
| OulaX wrote:
| Wow! That page has the best styling ever! No fuff, no SPA, no
| colors, nothing! Just text and straight to the point!
| yupyupyups wrote:
| Still rough around the edges on mobile. Too much margin on the
| right, and code blocks appear tiny.
| tra3 wrote:
| I see where this is going in the context of tools like Cursor.
| The common wisdom is that if you don't use it, you lose it.
| Muscles atrophy without stimulus (regular exercise).
|
| On the other hand, this seems to echo the transition from
| assembly -> higher level languages. The complaint was that we
| lose the skill or the context to understand what the machine is
| really doing.
|
| I've written a whole bunch of LLM-assisted code in the past few
| weeks so I sympathize. If I'm generous, I have a high level
| understanding of the generated code. If I have to troubleshoot
| it, I'm basically diving into an unknown code base.
|
| Anyway, I'm just rambling here. More tools is better, it gives
| everyone an opportunity to work the way they want to.
| _fat_santa wrote:
| I feel like with tools like cursor, while you may be able to
| cobble together a todo app or something else simple without any
| programming knowledge, for anything bigger you will still need
| to know how the underlying thing works.
|
| With everyone now using LLM's, the question goes form "who can
| code the best" to "who can prompt the best" but that still
| comes down to who knows more about the underlying code.
| larve wrote:
| Yes, better understanding of the stack makes you a more
| efficient prompt engineer. and yes I don't say this
| ironically, prompt engineering / vibe coding is not easy, as
| evidenced by the amount of people who think it's only good
| greenfield yeet prototypes.
|
| A lot of my programming skills have atrophied over the last
| two years, and a lot of skills have become that much sharper
| (architecture, algorithm and design pattern knowledge,
| designing user facing tools and dev tools, setting up complex
| infrastructures, frontend design, ...) because they are what
| allow me to fly with LLMs.
| rednafi wrote:
| This could be extrapolated to "does Cursor rot the mind?" Maybe.
| But programmers' obsession with minutiae is a massive waste of
| time.
|
| People try to dress it up as "attention to detail" or "caring
| about the craft" when it's just unnecessary bikeshedding most of
| the time.
|
| Hemingway didn't need some bullshit Hemingway Writer to craft his
| style. Michelangelo wasn't posting meta takes on Hacker News
| about the tools he used to carve David. Dante didn't waste time
| blogging about the ink he used to write Inferno.
|
| All this tabs vs. spaces, Vim vs. Emacs, Java vs. Go nonsense--
| it's just another way people trick themselves into feeling
| productive. If some Gen Z dev wants to use Cursor or Vibe CoPilot
| to get shit done, more power to them.
| dokyun wrote:
| Seems like Visual Studio rots the mind so bad nowadays that
| people would rather clamor support for useless garbage like LSP
| in their editors, and if it can't be supported very well it's
| foremost the editor's fault, not the fault of the crap they want
| to tack on to an otherwise fine product. People have been doing
| this with Emacs, saying Emacs is slow because its LSP
| implementations are slow and unresponsive, not that LSP is badly
| designed, or that an editor shouldn't need an asynchronous
| network protocol to provide IDE features. It also demonstrates
| the mentality that people find it increasingly preferable to have
| their computing served to them on a silver platter by a third
| party than being able to control it locally.
| seltzered_ wrote:
| For those trying to remember, microsoft intellisense
| (autocompletion within the IDE) was a big subject of debate going
| back to ~1999 on whether it'll make programmers lazier or more
| productive.
|
| Some of this stuff would be found in old slashdot discussions but
| it seems harder to find, im finding an old John Carmack interview
| as one mention: https://m.slashdot.org/story/7828
|
| Here might be the original slashdot discussion of "Does visual
| studio rot the brain?" (2005)
| https://tech.slashdot.org/story/05/10/26/1935250/does-visual...
| ferguess_k wrote:
| I don't think Intellisense and autocomplete bring brain-rot. AI
| could, because it tries to solve the problem FOR you, while
| intellisense and autocomplete merely help you find stuffs. These
| two are completely different.
|
| As much as I look up to Charles Petzold, I believe one of the
| best qualities of an engineer is to know how to prioritize things
| in life. We only have limited brain power, so it's best to use it
| in areas that we do care about, and keep the others to the lowest
| standard the customer can accept as possible. I'd argue that as
| long as you don't care about memorizing class names or variable
| names or API details, and as long as you don't become a slave of
| intellisense and auto-complete, you are perfectly fine.
|
| I'd argue that this is even fine if you only use AI to bootstrap
| yourself or "discuss" with it as with a rubber duck.
| 12_throw_away wrote:
| Huh, I've honestly never felt that autocomplete was an impediment
| to top-down coding like the author describes (and I also did my
| first few years of coding in feature-free text editors).
|
| It seems like part of the problem here, is that Microsoft chose
| aggressive settings to force users to use their new tool as often
| as possible. Sounds familiar ...
| immibis wrote:
| Every time I write something without an IDE - which is very often
| - I'm reminded how much more convenient they are. And limiting.
| And the limiting _is_ convenient. And I feel less productive
| because I don 't have it.
|
| Consider a typical blank IDE project (any IDE): you select File >
| New Project, you enter a name, you create some source files
| according to the language and then you press "compile and run" or
| Ctrl+F5 and it runs. If I want some obscure feature, I have to go
| three levels deep in an options menu or maybe I just can't have
| the feature at all. But if what I want is very typical (as it
| usually is), it's extremely convenient.
|
| Now consider a typical Makefile project (which is really a lot
| like compiling your project with a shell script with some
| optimizations). You can compile anything you like, any way you
| like. It's extremely flexible. You can compile a domain-specific
| compiler, that you wrote, and then use that to compile the rest
| of your code. You can walk over all your files, extract certain
| comments and generate a data file to be #included into another
| file. You can mix and match languages. You can compile the same
| file several times with different options. You can compile
| anything any way anywhen anywhere.
|
| But you can't load it into an IDE, because the IDE has no way to
| represent that.
|
| At best, you can load it as a "makefile project", where the build
| process is completely opaque to the IDE, and autocomplete won't
| work right because it doesn't know all your custom -I and -D
| flags. If your IDE is _really really_ smart, it 'll attempt to
| dry-run the makefile, determine the flags, and still get them
| wrong. If _your makefile_ is really really smart, it can 't be
| dry-run. And it still won't be able to see your generated header
| files until you build them. Nor can it syntax-highlight or
| autocomplete your custom DSL (obviously).
|
| The design of any language or protocol involves a tradeoff: how
| much you can do _in_ the language, versus how much you can do
| _with_ the language. Some configuration files are simple static
| data. Easy to load and process, but there are no shortcuts to
| repeat values or generate them from a template. Other
| configuration files are Turing-complete. You can write the
| configuration concisely concise, but good luck manipulating it
| programmatically and saving it back to the file, without ruining
| it. Project files are no exception to this rule.
|
| IDEs, like Visual Studio, Netbeans, Eclipse (you can tell I
| haven't used IDEs a lot recently) tend to fall on the fixed-
| function, easy-to-manipulate end of the spectrum - although
| Netbeans writes and executes an Ant build file. Command-line
| build tools like Make, CMake, Ant, autoconf (you can tell I do
| not do web dev) tend to fall on the fully-flexible end of the
| spectrum. There are exceptions: command-line package managers
| like Cabal and NPM seem to provide the worst of both worlds, as
| I'm locked into a rigid project structure, but I don't get
| autocomplete either. And then there's Gradle which provides the
| worst of both worlds in the opposite way: the project structure
| is so flexible, but also so opaque that unless I've spent a year
| studying Gradle I'm still locked into the default - I'm the one
| who has to parse and modify the Turing-complete configuration
| that someone else wrote (and I still don't get autocomplete).
| (I'm aware that Android Studio writes and executes Gradle files
| just like Netbeans writes and executes Ant files; the IDE's
| project structure is supreme in these cases.)
|
| ---
|
| Another thing the article talks about is that GUI designers
| generate ugly code. With GUI designers, the graphical design _is_
| the code - reading the textual code generated by a GUI designer
| is like reading an RTF file (formatted text) directly instead of
| reading it in Wordpad. Use the right tool for the job, and the
| job will be easier.
|
| However, GUI designers suffer from the same power dilemma. If you
| want some type of dynamically generated GUI layout, you won't
| find it in a GUI designer. You may be able to copy the code
| generated by the GUI designer, or edit it directly, and then
| you'll be legitimately annoyed by the ugly code. And if you edit
| it directly and then reopen the file in the GUI designer tool,
| _it_ will be annoyed at having to process your non-conforming
| code! (Looking at you, Eclipse WindowBuilder.) There 's just
| something fundamental here, where you can't use the really nice
| and convenient tool if you want to do the complicated thing.
|
| In Visual Basic (pre-.NET), there was no GUI code at all. There
| was just the GUI, and the code. You could refer to things in the
| GUI by name in the code, but they weren't declared as fields or
| anything. Of course, in this case you _can 't_ make a dynamic
| layout by using what the GUI builder generated as a template. All
| layouts are static - strictly how they looked on the designer's
| screen.
|
| ---
|
| Although writing pure C code in the command line is educational
| and more flexible and so on, it's strictly less productive. It's
| like planting a field by hand so you can see what the machine is
| giving you. It's better at making you gain understanding of the
| process, and appreciation for the machine - both of which are
| very valuable - than it is at actually planting the field.
| (Codeless Code 122)
|
| ---
|
| This message was delayed by the Hacker News rate limit.
| dang wrote:
| Related. Others?
|
| _Does Visual Studio rot the mind? (2005)_ -
| https://news.ycombinator.com/item?id=29760171 - Jan 2022 (143
| comments)
|
| _Does Visual Studio Rot the Mind? (2005)_ -
| https://news.ycombinator.com/item?id=22258198 - Feb 2020 (118
| comments)
|
| _Does Visual Studio rot the mind?_ -
| https://news.ycombinator.com/item?id=3386102 - Dec 2011 (2
| comments)
|
| _Do modern IDEs make us dumber?_ -
| https://news.ycombinator.com/item?id=387495 - Dec 2008 (37
| comments)
| korse wrote:
| Required supplementary reading?!?
|
| I like the verse form.
|
| https://users.cs.utah.edu/~elb/folklore/mel.html
| snovymgodym wrote:
| This was written by the author of Code:
|
| https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_C...
___________________________________________________________________
(page generated 2025-03-10 23:02 UTC)