space_comrade [he/him]

  • 0 Posts
  • 20 Comments
Joined 4 years ago
cake
Cake day: November 11th, 2020

help-circle


  • space_comrade [he/him]@hexbear.nettoLinux@lemmy.mlHow to quit VIM?
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 months ago

    Just switch to VSCode or something similar, it has enough features and shortcuts that will quickly make you like at least 80% as productive as you were in Vim. It even has a Vim mode so you can wean yourself off of it more easily.

    Honestly never got the appeal of Vim, you need to spend so much time learning and configuring it only to squeeze out a little bit of extra productivity out of it when compared to a “normal” editor/IDE. I don’t see why it’s so important to be able to edit and write code as quickly as possible since most of the time you’re going to be debugging or looking at the code or reading docs.

    EDIT: Just noticed you said you don’t code a lot. I think most of what I said still applies, I imagine you don’t spend 99% of the time in the editor typing away.






  • I don’t like VMs because I need to allocate memory upfront for it, and considering it’s a Windows VM and depending on the dev work you’re doing on it you might need to give it 10Gb+.

    If it’s at all possible for OP I’d recommend getting a separate physical workstation and then just remoting into it with your Linux machine, if you use VSCode the process is pretty much seamless, you use VSCode from your Linux machine normally while all the work is being done on the remote machine.










  • Most types force premature design/optimization.

    I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good, easy to understand abstractions. Types are way more elegant in functional or functional-inspired languages.

    Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.

    Agreed, unit tests are useless in most cases, they mostly test the bullshit abstractions you built for the unit tests themselves.


  • Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.

    “Easy to learn” and “good type system” will by necessity be opposing forces IMO. If you want to work with a good type system you’re gonna have to put in the effort to learn it, I’m not sure there’s this magical formulation of a good type system that’s also intuitive for most new developers. Hope to be proven wrong one day tho but so far no dice.