Unfortunately, it ceased being strange a long time ago that people choose to disregard the benefits of simplicity, precision, and ubiquity. What are you going to do when you don't have access to an IDE? If you haven't been in that position, the odds are you are either a specialist, work for a completely siloed company in which you write code and throw it over the wall never to be seen again, or you haven't been a developer very long.
Is EC2 part of your development or production cycle? Goodbye IDE. Have to parse through 200M of logs that can only be viewed on a production server? Use docker? Only have ssh access to the server? Development box only has 8G of ram and the project is large enough that you can't start the IDE because you run out of memory?
No, these are not contrived situations. I have experienced every one of them, as stupid as it sounds, that last one was within the past month. And many people I've work with experienced those situations a lot more often than I have. A lot of devops people I know regularly throw the IDE away for weeks at a time because it's just easier to use vim since can be installed everywhere if it isn't already installed by default.
Just to play devil's advocate for a moment regarding the benefits of an IDE:
I have watched many people over pull out hair trying to figure out why a project doesn't compile when it turned out the IDE wasn't configured properly for that project. If you look at the sheer quantity of configurable options under the IntelliJ preferences menu, I understand why many people spend just as many hours playing with their IDE configurations as I do with my vim. Sure, an IDE works great out of the box, until it doesn't. Vim is no different. It, too, works great out of the box, until it doesn't meet your needs.
Setting aside for a moment that you can get live debugging in vim if you want to work for it, I'll instead point out that, for myself, if I've been forced into using a live debugger, I've probably already gone wrong somewhere. Most likely because I've screwed up my testing, it's too complex to write a test, which usually means I've written too much production code without writing a test for it. My goal is to not need to use a debugger, so not having it? That's not a problem, that's me configuring my environment to encourage outcome I desire.
As far as automatic refactoring tools, I'm kind of in the same boat as with needing a debugger. I like having to refactor by hand, it forces me to pay attention to my code quality. Also, most automated refactorings in an IDE are pretty simple. Simple enough that I don't really need an IDE to do them quickly.
Vim gives me the ability to find class/function definitions out of the box in an uncomplicated way. Check out ctags.
Better is a subjective term, my "better" and your "better" may be different.
Like "better", productive can also be a subjective term unless you're going to attach specific metrics to it. If you can do that, I would honestly like to see the metrics you use and why you chose them. There's a reason that even after decades of trying there is still no way for management to accurately measure developer productivity. This has been a holy grail for them since they hired software developers.
Anyway, vim works most of the time for me but that's just my opinion, I could easily be wrong.
Agree with everything except the live debugger which I use all the time when working on Magento extensions. For me iterating with VdebugEval is the quickest way I've found to code that works. Maybe I should try a more test driven development approach?
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Unfortunately, it ceased being strange a long time ago that people choose to disregard the benefits of simplicity, precision, and ubiquity. What are you going to do when you don't have access to an IDE? If you haven't been in that position, the odds are you are either a specialist, work for a completely siloed company in which you write code and throw it over the wall never to be seen again, or you haven't been a developer very long.
Is EC2 part of your development or production cycle? Goodbye IDE. Have to parse through 200M of logs that can only be viewed on a production server? Use docker? Only have ssh access to the server? Development box only has 8G of ram and the project is large enough that you can't start the IDE because you run out of memory?
No, these are not contrived situations. I have experienced every one of them, as stupid as it sounds, that last one was within the past month. And many people I've work with experienced those situations a lot more often than I have. A lot of devops people I know regularly throw the IDE away for weeks at a time because it's just easier to use vim since can be installed everywhere if it isn't already installed by default.
Just to play devil's advocate for a moment regarding the benefits of an IDE:
I have watched many people over pull out hair trying to figure out why a project doesn't compile when it turned out the IDE wasn't configured properly for that project. If you look at the sheer quantity of configurable options under the IntelliJ preferences menu, I understand why many people spend just as many hours playing with their IDE configurations as I do with my vim. Sure, an IDE works great out of the box, until it doesn't. Vim is no different. It, too, works great out of the box, until it doesn't meet your needs.
Setting aside for a moment that you can get live debugging in vim if you want to work for it, I'll instead point out that, for myself, if I've been forced into using a live debugger, I've probably already gone wrong somewhere. Most likely because I've screwed up my testing, it's too complex to write a test, which usually means I've written too much production code without writing a test for it. My goal is to not need to use a debugger, so not having it? That's not a problem, that's me configuring my environment to encourage outcome I desire.
As far as automatic refactoring tools, I'm kind of in the same boat as with needing a debugger. I like having to refactor by hand, it forces me to pay attention to my code quality. Also, most automated refactorings in an IDE are pretty simple. Simple enough that I don't really need an IDE to do them quickly.
Vim gives me the ability to find class/function definitions out of the box in an uncomplicated way. Check out ctags.
Better is a subjective term, my "better" and your "better" may be different.
Like "better", productive can also be a subjective term unless you're going to attach specific metrics to it. If you can do that, I would honestly like to see the metrics you use and why you chose them. There's a reason that even after decades of trying there is still no way for management to accurately measure developer productivity. This has been a holy grail for them since they hired software developers.
Anyway, vim works most of the time for me but that's just my opinion, I could easily be wrong.
Agree with everything except the live debugger which I use all the time when working on Magento extensions. For me iterating with VdebugEval is the quickest way I've found to code that works. Maybe I should try a more test driven development approach?
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.