Follow

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.

Β· Β· Web Β· 1 Β· 4 Β· 5

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.

So at the end of the day, it's not that people are choosing the wrong editor based on what they want, it's that they don't know enough to want the right things.

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.

And that's before we even get to the fact that if you don't use a debugger you probably also don't know how to profile your code.

Before you get offended realize this is coming from a guy who likes BASIC. But if people are arguing about Emacs or Vim they're probably not talking about BASIC.

Also, if one is put off by the syntax or somewhat weird semantics of Emacs's extension language, it's probably not their editor that's limiting them but the fact that they are junior enough programmers to get hung up on things like surface syntax.

Though keep in mind that this is coming from a guy who hates that Rust looks so much like C++. Though that hasn't stopped me from using it.

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.

@jens how can you claim vim is superior when kakoune is so much better?

/me continues the side-track.

@freakazoid many people are happy with time wasted, because it means more coffee breaks. Also graphical IDE's have done a good job over the years providing integration of development tools, to the extent that this becomes more about keyboard use being more efficient that mouse (or touchscreen) use.

@wyatwerp @freakazoid not only, I think. Take typical refactoring tasks as an example, like renaming something. IDEs are great at automating that, and sometimes I miss having the same.

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..

@wyatwerp @freakazoid ... the tangential benefits it brings. It also means I'll think longer about what to name things, because err, naming is hard? πŸ˜‚

@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.

@freakazoid @wyatwerp I think you misunderstood me here slightly on a couple of points.

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.

@freakazoid @wyatwerp My attributing this to the law of the hammer is ... I suppose it's just something I suspect. I can't offer evidence for it.

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 ...

@freakazoid @wyatwerp ... that you can transfer the results from one tool to the other with sufficient ease that using them together is not creating undue friction.

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.

@freakazoid @wyatwerp I'm not even sure it's about *heavy* up-front design/modularization, specifically.

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...

@freakazoid @wyatwerp ... problem oriented bits. These latter tend to be mostly glue, the first category often more hardware- or dependency-specific access functions, etc.

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.

Show newer

@jens @wyatwerp I am unconvinced that one person's simple is another person's complex. I would submit that the people who "prefer mostly linear code in long functions" don't actually know how to program.

Show newer
Show newer

@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.

@M0YNG But the learning never happens if people choose to use a simplistic editor.

@freakazoid @M0YNG I've been a Vim user since I first ran it on my Amiga decades ago. Haven't looked back, and it is still my go-to editor.

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.

@vertigo @M0YNG As I said earlier in the thread (and possibly on another branch), I don't recommend Emacs to people. If Emacs is the right editor for someone, they'll figure that out.

@freakazoid @M0YNG Right; I mentioned it because it was my specific use-case: I needed/wanted org-mode specifically.

But, I've used a ton of other editor environments as well. Atom, Eclipse IDE, etc. Same logic applies for those too.

@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.

@freakazoid I'm offended :) Debuggers and debug prints are complementary, not substitutes.

Sign in to participate in the conversation
R E T R O  S O C I A L

A social network for the 19A0s.