Stuck in the plugin development

Off Topic
1

Today I had some thoughts about my hobby, which is plugin development and language learning. And the thing is that I spend most of my time developing plugins, and much less time doing actual things. Ahem, plugins are actual things, but only if you use those, and I… I kinda write plugins to write more plugins, and do not use those for anything besides that. That’s my problem.

I feel like @eraserhd is writing parinfer-rust because he writes a lot of lisp (there are some repos in Clojure and Scheme) and wants a good tool for that language to be available for different editors, and the editor of his choice. Also because making such plugin is good for learning Rust.

I feel like @ulis is writing kak-lsp because he wants to be good at Rust, and because he uses Kakoune and wants that good language servers to be available in it.

I feel like @mawww is writing Kakoune because he wants a better code editor for him to use.

I write my plugins, because I want to write plugins. I don’t even use those as much, as I contribute to. E.g. there’s a lot of functionality in fzf.kak that I do not use at all: fzf-vcs, fzf-search, sk-grep, fzf-tags, fzf-cd, fzf-yank-ring. Even fzf-buffer. I only use fzf-file, and time to time fzf-project. All other modules were written because I thought it would be nice to have those. Like when you’re going through the store, and there’s a thing that you like for no reason, you buy it and it lies unused. And such things are wasting some sort of resources, e.g. in store analogy it wastes money. I feel like writing plugins kinda wastes time.

Sure, there are things that I wrote because I needed those, like plug.kak, or smarttab.kak, but others, like kaktree, tagbar.kak and powerline.kak aren’t really needed things. And I’m not sure if I should spend time on such things.

Several years ago when I was a Vim user, I started thinking about my own plugin for snippets because I wasn’t satisfied with the existing ones. In 2018 I finally wrote my first plugin, which was a snippet engine, that used only vimscript and was fast, but had lots of design issues. Looking on it nowadays it is obvious that the design choices were made were poor, and if I would develop it now I would go entirely different routine from the start, but there’s also another thing that is interesting. I’ve spent so much time and code for such a simple feature that I did not used that much, that I actually spent more time on nothing than on something. Now the pattern continues.

Do you ever feel that way? Perhaps I’ve just encountered another existential crysis of my own, but I feel like I need to create something that is both interesting for me and practical for others. Plugins are kinda fit this category, but I feel like this is self-deception.

And, at the beginning I said that my hobby is, and I quote:

plugin development and language learning

And I actually do so much plugin development and so little language learning, that it is another self-deception here. I’ve learned some sh and perl for sure, but these skills are will not be used anywhere at some serious level, because my skills are not yet good for serious type of work, but I can’t go further in skill development by developing plugins. That bothers me as well.

I also tweak my editor configurations a lot which is also time consuming, and some times I feel that I could just use some editor that is preconfigured, like VSCode, and be as productive as with all those plugins and configurations I have made. Fun fact, that I’ve noticed the pattern, that when I’m semi-satisfied with the environment I have I want to start tinkering with another one because it is a matter of habit now.

Sorry for such a self-blog-posting (I do not have a blog, because I would continuously tweak it instead of writing for it) but I kinda interested in thoughts of other plugin authors here. Why do you make plugins? And how do you feel about it. What are your other hobbies?

3 Likes
2

I feel like @ulis is writing kak-lsp because he wants to be good at Rust, and because he uses Kakoune and wants that good language servers to be available in it.

Yes, your guess is pretty accurate. I started kak-lsp as an exercise in Rust, I made it work because I switched to Kakoune as my primary code editor and needed few IDE-like features. I continue to maintain it (including support for other people’s cases) because I want to give back to the community.

When I was reading the rest of your post, I recognised a lot about myself if you replace “writing plugins” with “learning programming languages”. There are multiple ways you can frame this kind of “addictiveness”: having a passion, or the favourite form of procrastination, or just being a manifestation of longing for a free, liberated, utility-free activity. As software engineers, most of us do creative work, but very much subordinated to one or another kind of “business value”.

Now I learned to have a semi-regular dedicated, even when short, time for pure impractical and aimless activities. When I do music synth or do a shallow dive into another programming language I don’t expect from myself anything anymore. Some aspects of this are captured in http://ul.mantike.pro/SoundGardenManifesto.

I don’t know how much those thoughts apply to your situation; please feel free to disregard if they don’t.

Thank you for your plugins and good luck in self-reflection!

3 Likes
3

I feel like @eraserhd is writing parinfer-rust because he writes a lot of lisp (there are some repos in Clojure and Scheme ) and wants a good tool for that language to be available for different editors, and the editor of his choice. Also because making such plugin is good for learning Rust.

The first part is very true, I write a lot of lisp - it is my day job, in fact. I like Clojure and Scheme a lot, but it’s the job part that ensures that I always pull myself out of whatever plugin-writing, environment-hacking hole I’ve gotten myself into to write Clojure code. If I didn’t have the job, I would need a lot more discipline than I have, I’m sure of it.

The idea behind the Rust port of Parinfer, though, was that I wanted a good parinfer for Vim, and NeoVim’s Node.js hosting of the JavaScript version failed me several times, so I needed a binary DLL to load in Vim. It was nice that I had done that bit when I switched to Kakoune. I chose Rust mainly to avoid C, but if I were to do it again, I’d use C. The initial port was easier with Rust, and Rust is a nice language, but the long-term maintenance issues are about interfacing with C programs and the system, and Rust’s WASM stuff is often broken.

On writing plugins: A long time ago I was talking with a colleague and I said something like, “What makes a good programmer is the sheer amount of effort they are willing to invest in preserving their own laziness.” I still think this is true. It is extremely hard to determine which tools will pay off and which tools will not… I have to prioritize because I only have so much time to hack on non-work things, and I’m usually wrong. But I do think it is kind of like startups, where 9 out of 10 will fail miserably, but the 10th will pay for the other 9 easily.

In any case, efficiency isn’t the only pay off, I just plain like when other people use my stuff, especially if they enjoy it.

1 Like
4

While my plugins are not at the same level as the author and respondents, I also use the kakoune platform to explore programming languages and implement daily work efficiencies. Which I then share through plugins.

Currently working on kotlin.kak a language plugin that I have successfully re-implemented in pure OOP, which left me completely unsatisfied as a hobbyist programmer. So I scraped it.

STOP! Pick up a heaver book and remember don’t stop programming. It is my solution to an existential crisis, it seems to work but doesn’t pay the bills.

This idea may interest to you as a proficient plugin writer. So the plan now is not to build another plugin but a library that supports agnostic plugin development.

Thank for all your plugins guys.

Here’s a couple of links @andreyorst that I am using to build a library that will help support the implementation of kotlin.kak via – > category theory <– warning guaranteed to slow you down. The only thing you need is persistence and time.

Fong, Brendan & Spivak, David 2018, ‘Seven Sketches in Compositionality: An Invitation to Applied Category Theory’ arXiv.org, viewed 02 Oct 2019, https://arxiv.org/abs/1803.05316.

Hinze, Ralf & Marsden, Dan 2016, ‘Equational reasoning with lollipops, forks, cups, caps, snakes, and speedometers’ Journal of Logical and Algebraic Methods in Programming, vol. 85, no. 5, pp. 931–951, doi: 10.1016/j.jlamp.2015.12.004, viewed 02 Oct 2019, https://www.sciencedirect.com/science/article/pii/S2352220815001509?via%3Dihub.

Piróg, Maciej & Wu, Nicolas 2016, ‘String diagrams for free monads (functional pearl)’ Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming, vol. 51, no. 9, pp. 490–501, doi: 10.1145/2951913.2951947, viewed 02 Oct 2019, https://dl.acm.org/citation.cfm?id=2951947.

And so it begins…on the Kotlin/JVM framework inspired by Haskell/Category theory and Arrow/Category theory

interface Functor<F> {
    /** fmap ∷ (a → b) → f a → f b */
    fun <A, B> HK<F, A>.fmap(f: (A) -> B): HK<F, B>
}

interface Monad<F> : Applicative<F> {
    /** bind ∷ m a → (a → m b) → m b */
    fun <A, B> HK<F, A>.bind(f: (A) -> HK<F, B>): HK<F, B> = fmap(f).join()

    /** join :: m (m a) -> m a  */
    fun <A> HK<F, HK<F, A>>.join(): HK<F, A> = bind(::identity)
}

Will it work? I have no F’n idea but it sure beats watching TV.

Forgot the “bring it back to simple links” that I find refreshingly helpful when lost in the theory. Seven Sketches in Compositionality is a great starting point into the topic just read its Preface subsection Purpose and audience and feel the relief, PHD is not required, and exercises are included. The other two links are just nice explanations for those repetitive diagrams in this space think UML.

The Science Behind Functional Programming

The category design pattern

If I am not back by xmas bring food to the library :smile: and when in doubt math nerd it out. Mathematics for Computer Science pdf MIT open course ware Go hard or go home lectures not the official title but a great free lecture series. Still learning and still having fun, thanks guys.

1 Like
5

Hi, thanks for sharing this interesting piece of self-reflection.

I’m struggling a bit to form my thoughts around this but here’s a little blurb that might resonate with you at some level:

Where do you get your inspiration from?

I get inspired just by seeing how people use computers - and how they usually struggle (myself included).

When seeing others they usually have interesting data (for instance at my job as research engineer in academia) but they typically don’t have adequate tools to visualize it or interact with it to build an intuition.

When seeing myself I’m often frustrated with how opaque programming is. I’m currently exploring

  1. jupyter notebooks (I have a way to use them with kakoune which is not yet released)
  2. javascript with hot module reloading while keepin state.

The other day I stumbled upon this (via HN) now quite old essay: http://worrydream.com/#!/LearnableProgramming
Although the example programs are at a very basic level I think even experienced programmers would benefit from more exploratory tools of their code, its state, its data, its means of expression.

Seeing that you’re interested in languages maybe you get some inspiration from this.

6

I think that LISP (Common Lisp) might be interesting to you then. If I understand JS feature correctly, though.

Thanks, always appreciate a good reading.

Where do you get your inspiration from?

This is probable the single correct question that I should ask myself.

Actually, I’m inspired by simple-yet-powerful design philosophy, which *NIX systems are filled with. And Kakoune is one of such projects, that, despite being simple, is really powerful. So my source of inspiration usually is my motivation of creating something that would enhance the experience and make already powerful thing more powerful, and Kakoune was something where I could do things that weren’t yet implemented by others, thus also learning new languages and ways to write programs.

7

First of all - this thread has been an absolute joy to read — fantastic feedback from a lot of great folks.

@andreyorst - For context, I have been in this industry for coming on 25 years. I have seen lots of developers hit the same inflection point you are at now, both in open source and in industry. There are two sides to this in my experience.

The bad: action has to be taken, this is not a self-solving problem. The feeling of shallow connection with your work will not go back to being satisfying. This “developer-life-crisis” (DLC?) requires a lot of reflection and thought about what you value. You will need to look at what you work on, and where you invest your time. Your development path will be forever changed from here on out (both professionally and as a hobby). Some who went through this process decided they didn’t want to be developers anymore and transitioned to management or even different industries.

The good: the outcome tends to be a positive realignment of your developer-life to your values. Generally speaking, I think most developers who go through this come out the other side vastly improved. The awareness of where you spend your time, and actively deciding to spend your time where you want to improve is astonishingly powerful. It feels worse short term (less “fun”) but feels massively better long term.

@ulis said, “Now I learned to have a semi-regular dedicated, even when short, time for pure impractical and aimless activities.”. That is a terrific idea, as it gives you a place to do fun, non-growth activities without any guilt for it. I am going to add this to my life as well. I have been focusing too much on deep stuff and lost some of the fun.

@eraserhd said, “If I didn’t have the job, I would need a lot more discipline than I have, I’m sure of it.” which is precisely the type of self-awareness and reflection you have on the other side of a bit of a DLC.
Also, “What makes a good programmer is the sheer amount of effort they are willing to invest in preserving their own laziness.” is astonishingly quotable, and I think I will steal it.

@duncan said, “STOP! Pick up a heaver book and remember don’t stop programming.” which I think is maybe the most critical thing I have seen in this thread. It is precisely, IMHO, the next best step. Dive deeper, hack closer to the root of the problems you encounter or are interested in. Align your time investment to your developer sensibilities and goals.

@danr asked, “Where do you get your inspiration from?” which is vital. Personally, I am not so much inspired as frustrated. My goal is to reduce friction and frustration in development by focusing on data-oriented programming (Mike Acton style) and avoiding doing non-useful work. But everyone has there own things that inspire/frustrate you – invest your time towards this end.

@andreyorst, you are inspired by the “simple-yet-powerful design philosophy.” What can you do to dive deeper on that topic (smaller more stand-alone apps? Apps that play nice with stdin/stdout? Are there ways you could double-down on the Unix Philosophy (https://en.wikipedia.org/wiki/Unix_philosophy) both personally and professionally? Instead of writing plugins would you feel more engaged with writing console tools that could be used anywhere you need them?

2 Likes
8

Thanks for very, very nice reply, @robertmeta.

I’ve thought about that, but the problem is, that on this field everything already exist :). I know things can be improved though

9

Alright buddy I think I hear your pain correctly and I know you are a generous guy with your time so with your quote in mind:

and your love for text editors head over here Hazel. I think it might be the tomorrow for your today, or at least an inspiration. Its a magnificent next gen field of study for text editors. Were is the next step after Scratch for the next generation of programmers. Just look at JavaScript it went from four functions to were it is today, now imagine the kids of tomorrow starting out with well typed programs as their first lesson provided by the text editor WOW!.

These are not the only guys walking the path but they are hard to find so look wide and deep for other implementations if it peeks your interest. I know there is some half attempts in Haskell and Emacs but think institutional funding for research grants. Head to places like this International Conference on Functional Programming. I’ll remember where I saw the content in a couple of days now that I am thinking hard about the topic.

Hazel “Flexible Structure Editing of Well-Typed Expressions”
We are working on a keyboard-driven editing experience that builds on your intuitions from text editing and that supports complex code reorganization patterns. We are doing user studies.

10

In 1889, Charles H. Duell was the Commissioner of US patent office. He is widely quoted as having stated that the patent office would soon shrink in size, and eventually close, because…

“Everything that can be invented has been invented.”

The start can feel a lot like the end! Prior to LSP people talked about something similar for years, but when it got a little momentum (and corporate backing) great things happened. Prior to ripgrep people were not clamoring for a better text search tool, but wow, what an improvement, has completed shifted my workflow.

1 Like
11

That’s entirely true.

Still, I have a long awaiting game project in the back shelf of my mind, so I guess I gonna start going in that direction :slight_smile: I think I can gain a lot of passion from it.

12

Games are amazing in that they are hard and rewarding. I think that is a great place to start and will make you stretch a lot – and you will be so busy writing your game you will tweak you editor a lot less… or maybe just make a full Unity mode for Kakoune. :slight_smile: