On Java LSP support and editor¹

A note on IDE. I use neovim btw but that was until God blessed me with Java. Is what you probably expect me to say. And indeed setting up a Java LSP for neovim turned out as difficult as they say. I abondoned my beloved code editor and asked daddy aka my employer for a premium license for IntelliJ. I spent a bit of time rewriting some of the most basic functionality from neovim config in Lua to Vim script to still benefit from Vim motions in the IntelliJ IDE. I have to admit the IDE made many things easier but after a while I still turned back to neovim. Buckled up and divided into the LSP setup once again. I ended up with java-language-server (as opposed to the more popular jdtls but it gave me the most basic things I needed: code diagnostics and quick remedy strategies (hashtag lsp_code_actions), signature help, autocomplete suggestions, etc. Although granted, there’re still many things I’m unhappy about (e.g. symbol signature and third-party code, more stable cross-project referencing) but this is most likely due to a skill issue.

On input validation and error handling¹

• Always validate your inputs. And by that I mean ALWAYS. This will spare you hours of running simulations only to find out that something went wrong and changed the behaviour of the entire system

• Confirm your expectation of the system behaviour. Especially in a non-deterministic aka asynchronous context. ESPECIALLY in a distributed setting with a high data transmission ratio. There’s no humanly possible way to prune gigabytes of log files to verify your assumptions.

On abstraction and ugly code¹

• DO NOT ABSTRACT UNLESS ABSOLUTELY NECESSARY! Yep, I said it. Abstractions are beautiful in theory and Java makes it so tempting to start with an abstraction and work your way down to specifics. Fight the urge to abstract early, you’ll thank me later.

• This goes in hand with the above but I’ll make a separate point out of it. Do not try to be a smart-ass. Clean code, modularisation - out of the window. This is unimportant in the POC stage. Hack it out as fast as possible to get a working solution. I’d go even further than that. Make it your goal to make it as ugly as possible. Avoid early optimisation and getting stuck on splitting your code into functions 4 lines of code each (I’m sorry, Uncle Bob). Raw dawg 50 line-functions all the way, embrace code duplication. Embrace chaos. Only when it starts getting really uncomfortable for you (and by that I don’t mean your perfectionism), only then do some refactoring. Don’t let some abstract principle guide your hand. Make it dirty and functional because you learn so SO many things about the process.

The power of positive mindset (even if it’s java).¹

Curiosity and a positive mindset go a long way. They will give you a good head start on the most challenging part of solving a difficult problem with a language you hate slightly dislike. Keeping an open mind helped me push through the initial learning curve (especially the part with functional Java) and shape my thinking to focus on the things that I do find enjoyable. For example, I hadn’t dealt so much with threads before and the standard Java library provides extensive functionality to make threads realively comfortable. Suddenly, the bloated world of alien Java modifiers (like volitile and synchronised) starts slowly to make sense. After building a a few simple TCP servers you feel slightly more confident and optimistic.

Ever since I was a child, I have always felt the need to document my thoughts and capture fleeting moments of my life. It started as a diary which served the purpose of retrospection (however much is imagineable in the life of a kid) which was of course naive but it helped me develop my writing and formulation skills. In high school, when I decided to go down the path of linguistics, I was required to pass a state examination on literature so there I was consuming the classics of literature and writing god knows how many literary analyses. I was compelled by the literary world and was blessed with a teacher who took my pursuits seriously and indulged me in lengthy discussions on the motives of literary heroes. As I moved into the depth of linguistic academia, fiction literature was more and more replaced by scientific articles and empirical studies while the writing migrated to personal notes on my IPhone. In both my linguistic and programming journeys, I was genuinely passionate about the discoveries I was making along the way and always tried to relate them to the modern world and my own experiences. I felt the need to share.