5 ms·

Does Visual Studio rot the mind? (2005)

105 points by inerte 2y ago

inerte 2y ago
The excitement about AI and Vibe Coding made me think about this (somewhat old) article.
- voidfunc 2y ago
  Vibe... coding... I'm getting old, what is this?
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - shmoogy 2y ago
    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 2y ago
    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 2y ago
    I think this is what they're referring to -- see this video: https://www.tiktok.com/@rileybrown.ai/video/7473731306845768990 https://www.tiktok.com/@rileybrown.ai/video/7473731306845768...
    - urbandw311er 2y ago
      I lasted about 10 seconds of that video before I had to stop it as I was beginning to develop a very unhealthy urge to inflect violence on the presenter and his whiny overly performative voice.
  - colonCapitalDee 2y ago
    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 https://x.com/karpathy/status/1886192184808149383
kelseyfrog 2y ago
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.
- hooverd 2y ago
  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 2y ago
    An SUV? Unnecessary for most people, a huge waste of power, and bad for the environment? Dangerous to bystanders?
    - fragmede 2y ago
      but great for the occupants
      - QuercusMax 2y ago
        Only in moderation; spending all day sitting in a vehicle is bad for you. Gotta still get your exercise.
- tomlue 2y ago
  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 2y ago
asdfman123 2y ago
This article is so well written and more relevant than ever.
hooverd 2y ago
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 2y ago
  I think with the number of libraries today you can't really remember everything. It's just not possible anymore.
bluedino 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      > 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?
indigovole 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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.
- 2y ago
OulaX 2y ago
Wow! That page has the best styling ever! No fuff, no SPA, no colors, nothing! Just text and straight to the point!
- yupyupyups 2y ago
  Still rough around the edges on mobile. Too much margin on the right, and code blocks appear tiny.
deleted 2y ago
[deleted]
tra3 2y ago
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 2y ago
  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 2y ago
    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 2y ago
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.
- nirava 2y ago
  > 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. The greats have been as particular and passionate about the tools as the rest of us. Whether this is productive or unnecessary is a different argument. But don't revise history to fit your argument.
dokyun 2y ago
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_ 2y ago
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 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-studio-rot-the-brain https://tech.slashdot.org/story/05/10/26/1935250/does-visual...
ferguess_k 2y ago
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.
- ilrwbwrkhv 2y ago
  So I actually would disagree with this. I think from the time ides have shown up quality has gotten worse. Photoshop 3 used to be much more performant than the modern day Photoshop. Slack is one of the worst performing apps I've ever had the misfortune of using. Overall, I think software quality has definitely declined from the earlier times. The surface area of apis would be limited because you would be constrained by what you can keep in your head, but now you're free to just add hundreds of different methods. One of my theories is that Java actually has so much sprawl is because how good the IDEs were for Java so I think overall, it definitely adds to brain rot.
  - jamesfinlayson 2y ago
    > One of my theories is that Java actually has so much sprawl is because how good the IDEs were for Java Not sure what came first - chicken or the egg - on that one, but I remember years ago discussing vim vs an IDE for writing code with workmates. We were writing PHP and I used a plain text editor at first then moved to an IDE, while the older devs stuck to vim. I pointed out that they probably couldn't do that if we were writing Java.
  - ferguess_k 2y ago
    This should be expected, when computing went from an elite instrument to a common toy. It won't go back.
12_throw_away 2y ago
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 2y ago
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 2y ago
Related. Others? Does Visual Studio rot the mind? (2005) - https://news.ycombinator.com/item?id=29760171 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 https://news.ycombinator.com/item?id=22258198 - Feb 2020 (118 comments) Does Visual Studio rot the mind? - https://news.ycombinator.com/item?id=3386102 https://news.ycombinator.com/item?id=3386102 - Dec 2011 (2 comments) Do modern IDEs make us dumber? - https://news.ycombinator.com/item?id=387495 https://news.ycombinator.com/item?id=387495 - Dec 2008 (37 comments)
eurekabot123 2y ago
[dead]
korse 2y ago
Required supplementary reading?!? I like the verse form. https://users.cs.utah.edu/~elb/folklore/mel.html https://users.cs.utah.edu/~elb/folklore/mel.html
snovymgodym 2y ago
This was written by the author of Code: https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_Computer_Hardware_and_Software https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_C...

105 points by inerte 2y ago

inerte 2y ago

The excitement about AI and Vibe Coding made me think about this (somewhat old) article.

voidfunc 2y ago
Vibe... coding... I'm getting old, what is this?
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- shmoogy 2y ago
  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 2y ago
  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 2y ago
  I think this is what they're referring to -- see this video: https://www.tiktok.com/@rileybrown.ai/video/7473731306845768990 https://www.tiktok.com/@rileybrown.ai/video/7473731306845768...
  - urbandw311er 2y ago
    I lasted about 10 seconds of that video before I had to stop it as I was beginning to develop a very unhealthy urge to inflect violence on the presenter and his whiny overly performative voice.
- colonCapitalDee 2y ago
  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 https://x.com/karpathy/status/1886192184808149383

kelseyfrog 2y ago

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.

hooverd 2y ago
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 2y ago
  An SUV? Unnecessary for most people, a huge waste of power, and bad for the environment? Dangerous to bystanders?
  - fragmede 2y ago
    but great for the occupants
    - QuercusMax 2y ago
      Only in moderation; spending all day sitting in a vehicle is bad for you. Gotta still get your exercise.
tomlue 2y ago
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 2y ago

asdfman123 2y ago

This article is so well written and more relevant than ever.

hooverd 2y ago

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 2y ago
I think with the number of libraries today you can't really remember everything. It's just not possible anymore.

bluedino 2y ago

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 2y ago
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 2y ago
  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 2y ago
    > 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?

indigovole 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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.
2y ago

OulaX 2y ago

Wow! That page has the best styling ever! No fuff, no SPA, no colors, nothing! Just text and straight to the point!

yupyupyups 2y ago
Still rough around the edges on mobile. Too much margin on the right, and code blocks appear tiny.

deleted 2y ago

[deleted]

tra3 2y ago

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 2y ago
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 2y ago
  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 2y ago

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.

nirava 2y ago
> 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. The greats have been as particular and passionate about the tools as the rest of us. Whether this is productive or unnecessary is a different argument. But don't revise history to fit your argument.

dokyun 2y ago

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_ 2y ago

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 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-studio-rot-the-brain https://tech.slashdot.org/story/05/10/26/1935250/does-visual...

ferguess_k 2y ago

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.

ilrwbwrkhv 2y ago
So I actually would disagree with this. I think from the time ides have shown up quality has gotten worse. Photoshop 3 used to be much more performant than the modern day Photoshop. Slack is one of the worst performing apps I've ever had the misfortune of using. Overall, I think software quality has definitely declined from the earlier times. The surface area of apis would be limited because you would be constrained by what you can keep in your head, but now you're free to just add hundreds of different methods. One of my theories is that Java actually has so much sprawl is because how good the IDEs were for Java so I think overall, it definitely adds to brain rot.
- jamesfinlayson 2y ago
  > One of my theories is that Java actually has so much sprawl is because how good the IDEs were for Java Not sure what came first - chicken or the egg - on that one, but I remember years ago discussing vim vs an IDE for writing code with workmates. We were writing PHP and I used a plain text editor at first then moved to an IDE, while the older devs stuck to vim. I pointed out that they probably couldn't do that if we were writing Java.
- ferguess_k 2y ago
  This should be expected, when computing went from an elite instrument to a common toy. It won't go back.

12_throw_away 2y ago

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 2y ago

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 2y ago

Related. Others? Does Visual Studio rot the mind? (2005) - https://news.ycombinator.com/item?id=29760171 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 https://news.ycombinator.com/item?id=22258198 - Feb 2020 (118 comments) Does Visual Studio rot the mind? - https://news.ycombinator.com/item?id=3386102 https://news.ycombinator.com/item?id=3386102 - Dec 2011 (2 comments) Do modern IDEs make us dumber? - https://news.ycombinator.com/item?id=387495 https://news.ycombinator.com/item?id=387495 - Dec 2008 (37 comments)

eurekabot123 2y ago

[dead]

korse 2y ago

Required supplementary reading?!? I like the verse form. https://users.cs.utah.edu/~elb/folklore/mel.html https://users.cs.utah.edu/~elb/folklore/mel.html

snovymgodym 2y ago

This was written by the author of Code: https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_Computer_Hardware_and_Software https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_C...