From my brief time in Clojure: Rainbow parentheses coloring is a must.
Rainbow parens are a lot like training wheels; they make it seem easier for beginners by helping you out when counting and balancing parens, but the trick for actually reaching mastery is to have the computer balance parens for you and for you to ignore them.
I used the paren shortcuts in Cursive, so I seldom used them for counting/balancing parens. Rainbow parens were helpful to visually break up the horribly nested expressions I was forced to deal with.
Yeah, I too was hoping for some substance to go with the title.
I didn’t mean it to be sarcasm since he didn’t actually mention rainbow brackets, but understand where your point lies. The post could read like “it took me 3 months to make Vim a decent Clojure editor.” Personally, I’m a little tired of making Vim a decent editor in whatever environment I’m thrown into and some businesses are very touchy about bringing in plugins. I mainly just use IDEs now and them whip out my Vim mastery only when it’s needed.
I wish he’d talk more about Spec or other Clojure specifics. Maybe a followup article is in the works?
I wrote about my environment setup because I’d only managed to find a couple of decent posts about it that helped me.
I’ll definitely post a follow up, but I decided 3 months wasn’t enough time to really form much of a deep opinion about a language, and there are already tons of “first impression” posts.
And things change so quickly too. I’m at 5 months now, and what I knew about Clojure when I actually wrote this post as opposed to now is pretty different; useful functional patterns keep emerging, more exposure to popular or commonly used libraries, Java interop vs Clojure-y layers, etc. So I’m glad I didn’t try to tackle that in this post.
Just as an additional example, I switched to using JetBrains IntelliJ IDEA a few years ago and was happily working in that application for a few years for a variety of languages and project types. But it got to the point where typing was just painful. On a fairly high end desktop at the time, my typing would lag and I could watch the cursor try and catch up. It drove me insane, I tried all the recommended tweaks and changes, but ultimately I abandoned IntelliJ and went back to vim and haven’t gone back since. I was willing to give up all the bells and whistles of IntelliJ, the project view, refactor tools, debugger, etc… purely because the typing was just so bad, it just couldn’t keep up with my typing speed at all even with a minimal footprint of plugins installed. Maybe they’ve since fixed it, but it was frustrating enough that I haven’t really gone back to check.
I use CLion every day for $WORK. It doesn’t get in the way of typing much. When I’m on the go, I put power save mode, which disables all of the semantic analysis that can eat battery.
I prefer lighter weight editors for projects at lower levels of complexity. There, I tend to build by writing some code, running it, and tweaking. As projects grow larger, so do your needs, and integrating things like type checking, linting, and automated refactoring start to become worth something. A specific example: I often don’t discover the real name of a module until some time after I’ve implemented a majority of it. However, you usually need to specify said name at least once, if not multiple times (file name). So, it imposes a cost to choosing said name, and makes it more onerous to change it. Having a tool do that for you safely and quickly is a great asset to evolving a codebase.
There definitely isn’t a perfect editor. Whenever I use vim, I want more semantic information available. Whenever I use an IDE, I wish they prioritized the typing experience to the same extent that vim does.
That’s a good point about the power-saving mode actually, I might try that if I come back to IntelliJ again at some point.
In the cases where I got fed up it was a fairly sizeable monorepo python/react application and I just found it easier (for me) to use tmux and vim at a given point. I started to feel like the IDE was getting in my way a lot and I was under such severe time crunches that the typing lag was getting to the point at times where I wanted to throw a keyboard. For instance, debugging something, finding the issue, quickly swapping to the editor, typing to fix… wait for typing to catch up, ah type, backspace lag, fix, restart debugger. It was a loop where the editor was dragging me down quite badly and it was getting really frustrating.
I have a variety of ways that I get around the lack of the features in the IDE and in some cases I just realized I didn’t need something I was using, I mostly use command-line utilities and debuggers, etc…
I honestly have nothing against the IDEs either, I loved using them and I use DataGrip religiously, it was literall just down to typing lag and the frustration it was causing that got me.
I’ve heard the same thing from other folks who’ve used it in the past. I’ve been using CLion and other IDEs for the last two years with no issues. It’ll eat processor time when it’s indexing a project for the first time though.
I could handle the indexing, that was sort of inevitable for an IDE that does the fairly advanced things it does, but the indexing was predictable to an extent. You could sit there and go “well I’m going to go make a coffee while this runs”. It’s worth saying I didn’t get the typing lag as much (or at all) in the individual IDEs like CLion, PyCharm and DataGrip, it was mainly in IntelliJ with support plugins installed when I was working on a large monorepo project with multiple build configs, etc… I also found myself hopping to other editors a lot or to vim for quick edits and then just one day I went to edit something with vim, and just, didn’t go back to intellij.
I’m taking my daughter to my town’s huge ladybug release at a local garden.
I use this trick with my local GoCD hosting, since it doesn’t allow you to configure which ssh key you want to use for a version control checkout. Though it looks like I might swap to wbolster’s trick.
I’ve had to write code on Windows to pay bills too, here’s what I did. The biggest conceptual change I had to make was to leverage my IDEs/environment for help instead of trying to use GNU tools for everything. Keep in mind there might also be hosted tools to use, for things like code search.
Visual Studio. You have to explicitly disable telemetry, but after that it’s pretty tolerable. Learning it is an absolute pain, as a bunch of useful shortcuts in it are exceptionally well hidden. The debugger is what really sold me on using this. I have never succeeded in making it not look ugly.
Visual Studio Code. This is more and more becoming the go-to IDE on Windows. There are enough plugins to make it feel like home.
A Jetbrains subscription. Their license allows you to use your personal subscription for your professional work, so this is my preferred tool now. The MSVC debugger is now experimental for CLion. Jetbrains IDEs works on Linux too, so I swapped to using it for home work so professional work on Windows doesn’t seem as weird.
For terminals, there’s WSL, cygwin, msys2, Cmdr. I’ve always run into weird quirks with all of these in terms of automation dealing with passing paths to/from native Windows programs. With WSL you can install Ubuntu straight from the Windows store and then use apt to grab a lot of things. This gives me GNU tools for examining logs.
For simple automation: use the Powershell ISE. Powershell misses the terseness of commands of the GNU tools, but the ISE is kind of an IDE for writing scripts with decent built-in docs and autocomplete. It should also be installed by default.
Python also typically comes installed, so use it for more in-depth automation tasks.
+1 to using Visual Studio, getting a better terminal (anything’s better than the default console), and installing Python.
Perhaps use Ninite to setup a machine easily.
It can be helpful to install basic unix tools like cd, ls, etc to make it easy to transition. At the end of the day, you will be better off learning windows commands.