It mystifies me that people aren't willing to spend tens of hours learning to use something that they will spend tens of thousands of hours using over their lifetime. Talk about hyperbolic discounting.
I think the problem is that people don't actually understand the payoff, and therefore they don't realize the cost they're paying every day by using a simple text editor.
In which case, they probably wouldn't even know what they should be learning about a more powerful programming environment, and they'd try to use it as a simplistic editor. In which case, they're better off sticking with their original editor.
Which, incidentally, makes the "my editor is better than yours" approach a complete waste of time. You are not helping someone if you convince them to use Emacs or Vim (or whatever). You need to convince them that they're wasting tremendous amounts of time and energy by performing an order of magnitude more edit/compile/run or edit/run cycles than they'd otherwise need. An order of magnitude because I'm including the addition of debug prints that they wouldn't need with a debugger.
This becomes really apparent when I try to explain to people what's so awesome about Magit when they still blow away their local repo and re-clone every time anything goes wrong.
At any given time, it will be faster to use the easiest tool available and to learn as little about it as you need to accomplish whatever you're trying to do. But it doesn't take long before the additional time that takes far exceeds the time it would have taken to learn to use your tools from the beginning.
@freakazoid yes, but why are you making this about Emacs when vim is clearly superior?
/me grabs popcorn
@jens Emacs is the one I happen to use, and I know it far better, though I did use Vim for a long time. And while people keep telling me vim *can* integrate with various programing tools as deeply as Emacs can, for some reason I've never actually spoken to anyone who claimed to have actually done that; I've always heard it secondhand.
I think Emacs also benefits a lot from the fact that it's mostly written in the same language that people write packages in.
@jens In any case, I don't actually recommend Emacs to anyone. If Emacs is the right editor for someone, they'll figure that out on their own.
@freakazoid Oh, I'm just teasing. It's the same for me, I just happen to use vim.
And no, I don't integrate vim with many tools. I've tried various setups like that, and never liked them much. In the end, my IDE is the shell, and the editor component tends to be the one that's mostly open.
I think I just don't like IDEs.
But on the other hand, I've lost count of the number of drive-by improvements I've made when revisiting code just for the purpose of changing a name. I'd go so far as to say IDEs contribute to code rot.
If course, this is a personal thing as well. I, for one, prefer this discomfort for..
@jens @wyatwerp I think that if the only reason you're touching a given piece of code is to rename functions, you have a bigger problem. To avoid code rot, you need to adopt a practice of regularly touching every piece of code. You definitely won't increase the overall amount of refactoring that happens by denying yourself decent refactoring tools.
I will grant that IDEs can support bad software engineering practices, but you can't achieve good software engineering practices by avoiding them.
Agreed that if the only reason you're touching a piece of code is to rename a function, you have a problem. It's also a very common problem I see across a number of businesses, which is why I bring it up.
You definitely need to adopt a practice of regularly touching every piece of code.
@freakazoid @wyatwerp I do see a correlation between teams relying on IDEs - especially when the IDE is standardized within the team - and an increase of refactoring. But it isn't necessarily a direct consequence. I'm not saying that, either.
What I *am* saying is that I have the anecdotal evidence of not using an IDE and refactoring a lot less. Again, one doesn't have to be a consequence of the other, but I have some insight into this anecdote because it's about me. And I notice that...
@freakazoid @wyatwerp ... I put a lot more effort into up-front design than most of my peers. Further, I tend to see that those who prefer that often (with notable exceptions) don't rely on IDE features as much.
Now it's entirely unclear which one is a consequence of the other, if any. It might be that preferring up-front design means less need for refactoring, and consequently less need for IDE features.
On the other hand, the tools we use also shape our thinking. Remember Maslov's hammer.
The only thing I disagree with is that you absolutely can achieve good software engineering practices by avoiding IDEs.
Again, it's about tools. You do need to pick the right tools for the job, but that doesn't imply that these tools must be integrated in one way over another. The important part is ...
That's a bit personal what "undue" means for you; in my case, since I do a fair bit of up-front design, refactoring happens rarely enough that I'm more than happy with a shell, grep and vim's search-and-replace.
It has the benefit that if it happens often enough, I get annoyed and rethink my approach :)
@jens @wyatwerp Heavy up-front design and heavy modularization can reduce the utility of an IDE when you're working on the section that's been assigned to you. I wonder if that contributes to Conway's Law for bigger projects? Or to put it another way, is it possible to overcome Conway's Law by using languages and tools that help to produce an easier-to-understand codebase and to comprehend that codebase by navigating the code?
I guess at the very least better tools can lead to smaller teams.
I just see people treat code as, at one extreme end, infinitely malleable to the problems of today vs at the extreme other end to provide a structure that must overcome the next decades and a nuclear winter.
I'm not a big fan of either, so I spend a fair bit of effort on decomposition into bits that must be relatively fixed, bits that can see some generic re-use, and very...
This isn't really about communication with the team (though I suppose that's a side-effect) as about keeping complexity under control.
A friend of mine (quite rightly) states that programming is just an exercise in managing complexity. What I'm saying is that one person's simple is another person's complex.
@freakazoid @wyatwerp I'm rubbish at keeping everything in my head, so I need decomposition as I outlined above so I can focus on each bit separately. That's it, really. I'm just overcoming a weakness of my mind, if you will.
I know people who find that complex and prefer very, very linear code - a couple of thousand lines with only few branches in a single function is easier for them to grok. It definitely isn't for me.
@freakazoid I think you have disproven your own point here. People will always take the easiest option, and that is often to learn a little as they go. The learning is also likely to stick better than if you have to learn lots up front and then try to remember it later when stressed.
But, I managed to learn Emacs not too long ago, in part because of two things: (1) I had an overt need to do so, as I strongly desired the functionality of org-mode that was lacking in other solutions, and (2) for some reason, my brain was finally ready and open to the idea.
I would argue that having an external motivation would be a strong influence on learning more complicated editors. Also, external motivation isn't "because my boss told me so." That's just duress, and in my experience, can actually work against developing the desire to learn something. A genuine external motivation is the user recognizing that he has a need (or at least a strong enough desire) for some functionality that his current environment isn't able to satisfy.
If someone doesn't recognize the need, and they're comfortable working with the environment they're currently with, they're probably not going to be bothered learning.
@freakazoid there are places where debugger is unavailable, and there are places where your vimrc is unavailable. Optomizing your environment to better suit you is nice, but if you know you'll need to go into a wilderness, it's better to practice for it
@wolf480pl That's only in dysfunctional environments. In non-dysfunctional environments you have sshfs or some other means of getting to files from a system with a decent editor setup.
@freakazoid I vaguely remember having issues with sshfs to a local VM, let alone to a remote server. It worked, but it wasn't very comfortable.
Also, it's not worth it for small edits.
And then that only solves the editor problem. There are plenty of situations where you have no debugger and there is no debugger, or a debugger would be uselesa, and I wouldn't call them dysfunctional environments.
@wolf480pl FWIW I use nano for small edits even to local files. I have no issues switching among vim, nvi, Emacs, and nano.
@wolf480pl It doesn't really make any sense at all to spend a lot of time practicing for something that is relatively rare and for which moving faster doesn't really matter.
An exception is emergency training, but IMO if you're doing "emergency nano" where seconds count, your overall approach to incident response is probably broken.
@freakazoid As someone who hasn't used a debugger in over 20 years (for his own projects; I'm forced to use one for my day-gig work, and it drives me up the fucking wall), I feel attacked. ;)
@vertigo Well there's something to be said for keeping things simple enough that it's rarely worth it to fire one up.
I should really learn how to use a remote debugger over JTAG.
@freakazoid I agree; I'd advocate learning how that stuff works, so you have the experience for when it's really needed.
Afterwords, though, I'd recommend building your circuits so that you don't need it. Speaking as someone who's forced to use this configuration professionally to the exclusion of all other methods, I can't help but feel utterly hamstrung by it.
@vertigo Isn't it possible that you feel hamstrung by it because you don't have much experience with it?
A debugger is not just a tool for finding bugs. It's a tool for understanding systems.
There's a (rude, like most of them) Perlisism about this: "It is easier to write an incorrect program than to understand a correct one." Ignoring the question of correctness for the moment, writing code from scratch is easier than reading someone else's code, but readingsomeone else's code can be better.
@vertigo In your case, though, the systems you're looking at presumably suffer from Conway's Law and have a lot of incidental complexity, which may be the source of a lot of your pain.
@freakazoid Not in my situation.
The problem is that our JTAG interface is limited to about 10kHz in practice (you can sometimes push it to 20kHz), which means GDB has to serialize the chip's active state through that narrow bandwidth link. Each instruction it performs has to be mitigated through a 10kHz link. So, imagine running code at 0.01 MIPS, and you can imagine one source of our frustration.
The other cause for frustration is that a debugger is simply not repeatable. I prefer to write test-cases and run them; that way, I can reason about them and even have working examples committed to a revision control system.
I'm not saying never to use a debugger; they have their place, especially in early hardware bring-up. But, for the stuff we're doing, we've already solved the early part of the bring-up process, and we've enough of a runtime environment on it that we could (if we had the I/O for it) run proper testing routines and spit out logs of issues detected. The debugger would just be operational overhead for us at this point.
Alas, no such outlet for that information exists, so we're forced to run everything via the remote debugger.
We literally only use the debugger as a means of uploading code into the bootstrap RAM of the module, then click on "Resume" to kick the processor off. We then wait some minutes to hours for the results of a test run.
@vertigo Ugh. Yeah, I see your point. It seems like you should have a complete suite of fully automated tests that run on the device for every build.
A social network for the 19A0s.