5 ms·

I have used Jetbrains IDEA and Clion extensively to understand the other side. An IDEs heavy introspection isn’t necessary, and perhaps actively harmful towards

I have used Jetbrains IDEA and Clion extensively to understand the other side. An IDEs heavy introspection isn’t necessary, and perhaps actively harmful towards writing and reading code. It’s rigid policy over tools like git is certainly actively harmful. If it takes an IDE to write your code, then it will likely take an IDE to read your code. They are tools that allow you to take shortcuts were you shouldn’t, and rob you of valuable knowledge. Programming is about thinking and continual learning and IDEs sell you the complete opposite. They help you build unsustainable projects where only a computer can understand the binary AND the source code. The other point here is that the gap between IDE and text editor has only gotten smaller over the years and was closed considerably by LSPs. It may not be a perfect match in features, but small niceties are not an excuse for using closed source spyware for your text editor. They also do not make the difference between the success or failure of one’s work.

charcircuit 5y ago
>If it takes an IDE to write your code, then it will likely take an IDE to read your code There is nothing wrong with this. We shouldn't let old text editors hold back the productivity of programmers.
- diffeomorphism 5y ago
  There is lots wrong with this and with this mind set. This is not about "productivity" at all but about being auditable and working in a team.
  - charcircuit 5y ago
    Expecting your teammates to use an IDE does not get it the way of working in a team. In my experience as a team we have a default IDE for everyone to use and a configuration file for it so everyone's is using the same settings. Usually you could use a different IDE if you could configure it to act similar, but making sure everyone uses the same tools doesn't prevent you from working as a team.
- b3morales 5y ago
  It's not "old text editors". There are current tools for viewing source (pull requests/diffs a prime example) that are extremely good at what they do but are language agnostic. As is so often said, code is read more than it's written. If I can't understand the source without pulling it into my IDE, that adds a lot of friction to these reading tasks.
  - charcircuit 5y ago
    Those other tools you work with can become more advanced to in order to keep up with the improvements your IDE offers. You want to inline a diagram to your code? That image should show up both in your editor and in the diff.
criddell 5y ago
You can write shitty code in Emacs as well. I'm certainly guilty of that. Steve Jobs once said that a computer is like a bicycle for your mind. It's an amplifier of sorts and an IDE fits into that metaphor. It will amplify the good and the bad. It's up to you, as a professional, to develop the skills necessary to use the tools in ways that make sense for whatever it is you are working on.
tored 5y ago
As with every tool you should of course have the knowledge to do things properly without the tool, but not using a good tool is like saying we should use old style shovels instead of a modern excavator because the excavator shields us from understanding the back breaking process of the shovel. Now it is true that we programmers could need a good workout but doing things more infectively because of some immeasurable consideration of what is "harmful" is probably the reason we are still stuck in the 70s of tooling in many languages. However what I do think is important is that every project should not actively discriminate against any of the alternative tools, in every project I manage I encourage every programmer to use the editor/IDE, shell or operating system they are most conformable with (but they need of course to manage their environment themselves and deliver the code in time).
adlpz 5y ago
> If it takes an IDE to write your code, then it will likely take an IDE to read your code I can agree with that. However, the real world is filled with random legacy projects, massive enterprise applications where a dozen developers came and went over a decade, quick-and-dirty MVPs and everything in between. If you are paid to write well-crafted code that fits nicely within the limitations of your editor, that's great. But for the rest of us who have to deal with the realities of this industry, a helpful IDE makes it so much bearable.
howinteresting 5y ago
I can write the same code significantly faster with an IDE because of all the autocompletion and code navigation. I don't use the version control features other than the occasional blame, preferring to stick to a command line for that.
- ilovecaching 5y ago
  The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into cheap labor would have been successful, which it wasn't. Software engineering is still part art, part math, and 90% a mental activity and not a physical one.
  - klibertp 5y ago
    > The speed at which you write code is meaningless. That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone. There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point. [1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.
  - howinteresting 5y ago

charcircuit 5y ago

>If it takes an IDE to write your code, then it will likely take an IDE to read your code There is nothing wrong with this. We shouldn't let old text editors hold back the productivity of programmers.

diffeomorphism 5y ago
There is lots wrong with this and with this mind set. This is not about "productivity" at all but about being auditable and working in a team.
- charcircuit 5y ago
  Expecting your teammates to use an IDE does not get it the way of working in a team. In my experience as a team we have a default IDE for everyone to use and a configuration file for it so everyone's is using the same settings. Usually you could use a different IDE if you could configure it to act similar, but making sure everyone uses the same tools doesn't prevent you from working as a team.
b3morales 5y ago
It's not "old text editors". There are current tools for viewing source (pull requests/diffs a prime example) that are extremely good at what they do but are language agnostic. As is so often said, code is read more than it's written. If I can't understand the source without pulling it into my IDE, that adds a lot of friction to these reading tasks.
- charcircuit 5y ago
  Those other tools you work with can become more advanced to in order to keep up with the improvements your IDE offers. You want to inline a diagram to your code? That image should show up both in your editor and in the diff.

criddell 5y ago

You can write shitty code in Emacs as well. I'm certainly guilty of that. Steve Jobs once said that a computer is like a bicycle for your mind. It's an amplifier of sorts and an IDE fits into that metaphor. It will amplify the good and the bad. It's up to you, as a professional, to develop the skills necessary to use the tools in ways that make sense for whatever it is you are working on.

tored 5y ago

As with every tool you should of course have the knowledge to do things properly without the tool, but not using a good tool is like saying we should use old style shovels instead of a modern excavator because the excavator shields us from understanding the back breaking process of the shovel. Now it is true that we programmers could need a good workout but doing things more infectively because of some immeasurable consideration of what is "harmful" is probably the reason we are still stuck in the 70s of tooling in many languages. However what I do think is important is that every project should not actively discriminate against any of the alternative tools, in every project I manage I encourage every programmer to use the editor/IDE, shell or operating system they are most conformable with (but they need of course to manage their environment themselves and deliver the code in time).

adlpz 5y ago

> If it takes an IDE to write your code, then it will likely take an IDE to read your code I can agree with that. However, the real world is filled with random legacy projects, massive enterprise applications where a dozen developers came and went over a decade, quick-and-dirty MVPs and everything in between. If you are paid to write well-crafted code that fits nicely within the limitations of your editor, that's great. But for the rest of us who have to deal with the realities of this industry, a helpful IDE makes it so much bearable.

howinteresting 5y ago

I can write the same code significantly faster with an IDE because of all the autocompletion and code navigation. I don't use the version control features other than the occasional blame, preferring to stick to a command line for that.

ilovecaching 5y ago
The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into cheap labor would have been successful, which it wasn't. Software engineering is still part art, part math, and 90% a mental activity and not a physical one.
- klibertp 5y ago
  > The speed at which you write code is meaningless. That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone. There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point. [1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.
- howinteresting 5y ago