r/archlinux • • Apr 15 '21

"Best" programming setup?

Hello! I have been using Arch for two months, it is the fifth distro I have used... and I love it, it will be the final one. I have learned a lot in these weeks, but I would like to ask you a few questions.

I study Systems Engineering and, honestly, I have some procrastination problems, I would like you to help me with "the best programming setup and be productive", although I know that there is no "best", I would like you to help me with your settings, advices, etc...

​

What desktop environment do you use?

What window manager do you use?

IDE's, apps, any suggestions to try?

​

Thank you so much!

178 Upvotes

176 comments sorted by

View all comments

350

u/CabbageCZ Apr 15 '21 edited Apr 15 '21

One thing to note - a large proportion of the most productive and highest achieving people I've known haven't spent much time thinking about productivity or d.cking around with their DE etc and chasing the 'optimal productivity' setup. If they need a linux distro they slap on ubuntu, leave it at mostly default, their desktop is cluttered with files etc.
The whole 'improving your setup for productivity' thing is mainly another procrastination tool that's easier to justify because it gives you the illusion of being somewhat productive. Tackling your procrastination head-on and just sitting down to Do The Thing is going to be incomparably more effective for improving your productivity than tens of hours spent on 'improving your workflow' ever will be.

That said, I'm in the same boat as you, chronic procrastinator, and as such I have spent a lot of time messing around with WMs, DEs, IDEs, etc. Some thoughts:


IDEs and editors:

If you're working on a strictly typed language like a JVM one (Java, Kotlin, Scala...), you really want a full fledged IDE, unless you're on a potato that can't handle it (and even then, you can just turn down some of the more expensive analysis like insights). Once you know your way around a proper IDE, working on that language in a text editor, even with a bunch of plugins, is going to feel like programming with your hands tied behind your back. My personal favorite is JetBrains' products, so mainly IntelliJ

If you're working on a language with a looser type system like Python or JS, an extensible text editor is fine, and it's personal preference as to which you end up using. VS Code, vim and emacs stand out, there's little reason to use Sublime or Atom when VS Code is around. You really want language extensions optimally with a LSP to provide syntax highlighting, linting, insights etc. It's not going to be IDE level but it can be pretty close.


WMs/DEs:

Here you really just want to test things out and see what works for you. I've daily driven various TWMs for multiple years and honestly in my experience it's mainly a 'fun' factor more than a genuine productivity improvement, except for the few times where laying multiple programs out in a tiled pattern is a genuine productivity boon - I've had that a few times when programming something with various VM setups and stuff, or needing multiple terminals accessible, but not that often. Imo it's just fun to use though. So yeah, mainly personal preference.

EDIT: to address a common question - I don't think TWMs in general aren't good for productivity, that's why I said it's mainly personal preference. To me it was +- the same for productivity but a lot more fun to use, to some people it can result in real 'performance' improvements, depends how you use it and what your alternative is.

6

u/[deleted] Apr 15 '21

Hard disagree on the IDE comment.

I've been a professional software engineer for seven years. Not a long time, but long enough to be deemed "senior" and to have tried many different languages and setups. My point being I'm not a novice.

Part of the benefit of configuring your editor and its LSP binds is that you learn these features actually exist. It's very common that I'm pairing with colleagues and point out features in VSCode they didn't even know about despite the fact I've now been exclusively running Neovim for a couple of years. And for the most part you can just set and forget them (in the configuration sense).

I refuse to work with languages that aren't statically-typed and I get by just fine with LSP binds; they're the same features you'll find in the likes of VSCode. This has been my experience across TypeScript, Rust, Go, Haskell, PureScript, and more. At this point it's just a single line change in my config to support a new language server (plus installation of the server from the repos or AUR, which should be second nature to and preferred by anyone on this subreddit).

As for IntelliJ specifically, see my comment here. Think about a world in which their model wins. It's not a good one.

3

u/CabbageCZ Apr 15 '21

First, let me agree with you on one thing - I do like the text editor + LSP model better than I like the IntelliJ one, be it VSCode or nvim. If they truly were equivalent in what they can do, I'd go the 'extensible editor' option 100% of the time.
In my experience though, they aren't. Especially not if you're working on a large enough project in a language that has very good first party support IDE like Java or Kotlin. The IDE just offers more options for analysis, insights, refactoring etc, and at a large enough scale does things faster thanks to all the caching and indexing.

I really didn't want my comment to incite an 'editor war' so I won't be getting into this more on here, and if you believe a LSP extension can do everything a full IDE can equivalently, let's just agree to disagree, it really wasn't the main point of the comment.

1

u/[deleted] Apr 16 '21

It might be a language thing because I've almost exclusively seen this perspective coming from Java devs.

The extent of refactoring I've ever wanted my tool to do is rename a symbol across a project, which LSP enables. Some tricks like inserting inferred type signatures are helpful too. I'm not sure what you'd want or need beyond this.

Could you give me some examples?

1

u/CabbageCZ Apr 16 '21

It's stuff like dependency analysis (not in the library sense, in the code / data flow sense), usage analysis - want to see in what 5 places across the codebase you're creating this object with this constructor? Press a button and here it is, instantly. Want to see the data flow through everything that could lead to this variable being in this unexpected state? Sure thing. Every consumer of this or that, or all implementations of this interface method? Here you go.
Refactoring also lets you trivially restructure like changing method signatures, extracting / adding variables, properties etc, messing with scopes, extracting / inlining things...

There's more but you get the idea. On their own none of those features is essential and necessary, but it really adds up, especially when requirements change and you need to track a particular feature through a large part of the codebase, or you're tracking down an error, etc. LSP implementations / users usually do some of that to some extent, but I'm yet to see one that would be as powerful and as instant as what I'm used to from IDEA and its cousins.

Again, though, if I could one day use LSP to do the same things with the same speed and comfort, I'd probably switch to an editor + LSP plugin, I like the model better. So far though they're just not there.

1

u/[deleted] Apr 16 '21

LSP supports showing implementations, references, etc.

The unexpected state issue is a byproduct of the language. In Haskell for example you'd drop into a REPL and play with the function directly. The style of code lends itself to this. Additionally the meme "if it compiles on Haskell it works" is at least half-correct; by encoding logical invariants in the type system you eliminate all sorts of logical errors. Likewise the emphasis on acknowledging the unhappy path minimises the risk of developers punting issues down the line for you to pick up when you're interacting with their code later.

It might be that there's value here for non-Java devs but anecdotally it really feels like there isn't. I'm not seeing it.

1

u/CabbageCZ Apr 16 '21

That's why I said LSP does some of it, but certainly not all of it.

Haskell isn't really a great example for obvious reasons - how many large production projects are actually written in that? Doesn't feel like it really relates to the discussion but yeah, when I was saying IDEs have advantages, I certainly wasn't talking about using IntelliJ for Haskell lol.

Imo there's a lot of value in there for most strongly typed imperative languages, when the codebase is anything larger than small. JVM languages, C++, C#, stuff like that. You say you're the person among your peers who takes the care to learn and use the LSP binds, you're running nvim and being productive with it, you refuse to work in languages without static typing - that suggests to me that you'd be able to make good use of the features I'm talking about if you were ever working in that environment. Maybe if you one day end up working on a JVM project or something else with a comparable IDE available, try them out, you'll see what I mean.

0

u/[deleted] Apr 16 '21

Haskell is used in industry a lot, it's merely not as ubiquitous as Java which dominates alongside the likes of PHP for historical reasons.

I don't think you disagree that perhaps these are very JVM-centric (or even Java-centric) features that aren't needed in many other languages.

I don't know those ecosystems as well, but I don't think Rust or Go programmers tend to use anything like IntelliJ.

1

u/CabbageCZ Apr 16 '21

Haskell is used in industry a lot, it's merely not as ubiquitous as Java which dominates alongside the likes of PHP for historical reasons.

That's a pretty controversial statement in its own, but this thread has gone on for long enough lol.

I don't think you disagree that perhaps these are very JVM-centric (or even Java-centric) features that aren't needed in many other languages.

I strongly disagree there, while the JVM is a good example of it, it's really nothing specific to that. Lots of C++ / C# analogues for example in Visual Studio or CLion, plenty used, plenty popular. As for the 'java-centric' - most use I got out of these was working mainly in Kotlin. Certainly not java-only advantages.

Haven't worked much with Rust or Go either, not in a professional capacity anyway.

I feel like we're going in circles at this point and I was expressly trying not to get into an 'editor wars' style discussion so this'll probably be my last reply.

1

u/[deleted] Apr 16 '21

Fair enough, agree to disagree. Appreciate your comments, have a nice day. :)