It blows my mind that there's so much devotion to the tool first, problems second, which must be mashed into a shape that fits my tool.
I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
> I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
According to the Zen master Dogen:
“Before one studies Zen, mountains are mountains and waters are waters; after a first glimpse into the truth of Zen, mountains are no longer mountains and waters are no longer waters; after enlightenment, mountains are once again mountains and waters once again waters.”
Like a lot of Zen things, this sounds like someone 'trying to sound deep'. But I'll try my best to interpret it charitably and maybe others can chime in with their interpretations.
It's safe to say most people see mountains as mountains etc. When you start practicing Zen, you glimpse into the inseparability of things: there is really no defined boundary between the 'atoms of the mountain' and the 'atoms of the water'. (Also the atoms themselves are mostly empty space with a probability distribution of where the 'stuff' 'is'). Things like 'mountains' are really illusory abstractions that humans build on top of the underlying reality of the swirling wave patterns of the universe. 'Existence precedes essence', as the existentialists say.
Still in this second phase, you notice things like when you have a conversation with another, the conversation is not really being generated by either brain, it is being generated by the system that includes both brains (and nerves, muscles, vocal cords, the air between them, eardrums, etc.)
However, after enlightenment, you realize that the underlying physics is no more 'real' than the abstractions, as the abstractions are what really has an effect on the universe. As Zizek might say, the distortion itself is the real. When I see a mountain, the way that my brain interprets it as a mountain, in effect makes it a mountain, because the symbol itself manifests itself in my thoughts and actions.
Note that if you are reading this, you probably shouldn't listen to my interpretations of what Dogen, Sartre, or Zizek are trying to say. These are my own, very flawed interpretations of their words.
It’s following the tao of the ox. That’s why he didn’t need to sharpen his cleaver for a decade or something, it just “naturally” went into the empty spaces, rather than stumble against bones and sinews.
(If I remember correctly; my old Burton Watson copy is now sadly long lost.)
You use a tool enough and it shapes your way of thinking. It's like touch typing, you don't think about the individual keys you press. Instead you think about what you're trying to say/code and muscle memory takes over.
It's the same with vim. You start thinking "delete that word", or change everything until the '(' character. When you start thinking that way, changing the way you think becomes distracting.
> It blows my mind that there's so much devotion to the tool first, problems second, which must be mashed into a shape that fits my tool.
I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
I don't think there's necessarily a right or wrong answer, at some point I changed the way I think to match the vim model. Now I change things to match the vim model rather than change the way I think.
> You use a tool enough and it shapes your way of thinking.
Yes, that's true. I can't fathom writing Java in anything other than Intellij because it's shaped my thinking to "my tool should already know what this symbol is, where it is, and what arguments it might take". I guess it's shaped my expectations more than my thinking, but I hope you see what I mean.
> I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
Fair question. I guess my response is that one of the lessons I've learned the hard way in life is that my way of thinking can be wrong.
And while I enjoy a tool you can tweak to your desired tolerances, I prefer to use the tool that is most closely aligned to the task at hand.
You can get a nice even surface on a piece of timber using a chisel very carefully. Or, you can use a plane.
You can cut down a tree with a stone lashed to a branch, or you can use an axe with a metal head. Or, a chainsaw.
Changing between any of them requires a revision of how you think about the process, but it seems obvious that the cost of doing so might be worth it, even if the chainsaw requires changing how you think to incorporate concepts like kickback.
Isn't the whole article about how the author made his tool "most closely aligned to the task at hand"? Bonus points, since it's a flexible tool that can be aligned to most tasks, he is able to bring his specialized knowledge and experience of the tool to this specific task at hand as well.
It is not clear to me, why people try to make an exception of an extremely IDE-centric language/tooling, such as java is, to an advantage of IDEs in general.
There are other languages besides java and C#, where advantages of IDEA are small to none. For them, you have to accept a bloated project-based resource-consuming monster. Or you do not and just write rust in vim or emacs. In times of LSP and DAP the gap is getting smaller each day. But IDEA is not getting faster, and never will.
i can't not explain in words what it's like to use vim for 20+ years, esp to someone thinking an editor is "just" a tool. my vim config changes with me...
i was trying to make a point that it's a tool with a very long history and all the time i "wasted" (and still waste) on learning it was well invested, as it's going nowhere and i spend 8-9h in it a working day.
i think i've been using only a shell longer than vim.
> It blows my mind that there's so much devotion to the tool first, problems second
What made you think that their devotion to the tool indicates that they care less about the problem? I wonder what you might think about me then in that I have vim integrated with mutt for composing emails, git, my password manager, code editor, text pager, etc land me in vim. I choose most my apps so that I can use vim for text editing. It gives me uniformity. It saves me time.
More importantly, I do not get a negative reaction from people that use different text editors for different text editing tasks looking for buttons to click, shortcuts to press in different places.
Especially nowadays, when tech is converging, getting locked down, and we are being told what and how to do things by a few companies, we must appreciate and encourage diversity of tools (except for emacs obviously:) that empower their users. Not be dismissive and judge them for using a tool that we don't use.
It's okay for people to master tools they find valuable, and use that mastery to do good things even if they're off-road tools (by today's standards) such as vim.
I find that some people really care about the work and that the tools are just a means to an end.
Other people love certain tools so much that "the work" is actually just an excuse to use their favorite tool in more elaborate and challenging ways. Their attitude is something like "and now for my next trick..."
The funny part, to me is that I've never been able to see one method as producing better results than another. I've seen work focused folks produce bad output and I've seen tool focused folks get caught up in their tools and never produce anything at all.
But I've also seen both types produce masterpieces.
Just different approaches and personalities I think.
I think a big part of it is just enjoying your time.
We're both driving cross country, following the speed limits. We'll both arrive at roughly the same time but maybe I'll enjoy my time more if I'm driving a stick shift.
This is in general of course. Me personally, I save tens of minutes a year by using vim.
Probably more. It’s not only the speed of typing and editing that matters, but also the time you spend on context switching. When your hands don’t leave the home row you don’t leave the current context.
I partly agree that it is a matter of personality, and that both can produce good results. But in my experience junior devs care more about the tools than seniors.
This sounds like a knee-jerk reaction that results from not having taken the time to make sure that the criticism lines up with the thing being criticised.
> It blows my mind that there's so much devotion to the tool first, problems second
The problem is clearly outlined here: "Manipulating raw ipynb files is difficult and unergonomic."
OP is not fiddling with his or her editor configuration because of any undue focus/deficiency regarding Neovim. The deficiency is in the Jupyter notebooks editors. In other words...
Problem: Jupyter sucks; my thoughts are always slowed down by having to squeeze them through a low-bandwidth link and the ergonomics hurdles that comprise basic text inputs--I want to go fast, but with Jupyter, I can't.
You seem (and seemed) to be unaware how dismissive your original comment was. In fact that was the entire point of the response. To take issue with that response on the grounds it itself is "unhelpfully dismissive" involves layers of irony.
1. You’re talking about an editor that has been popular across multiple decades and across many many generations of technologies.
2. The editor they’re already using obviously already does things in ways they like. That’s why they are using it. So the odds that their editor will perform the job well for them is also pretty high.
Conveniently, the solution is the editor that thousands of developers have taken time to improve over decades so that the author didn't have to start from scratch.
What are the odds that the solution involved a popular, mature tool that the developer could leverage?
I mean, in mathematics a lot of problems are solved by realizing they can be turned into another tupe of problem that we already know how to solve.
If you know a text editor like the back of your hand, why would you learn another tool when you can take a different approach and be even more effective?
How many hours am I going to spend making my text editor work with this new problem? How long would it take to learn the new tool sufficiently to be reasonably effective?
I always remember a coworker who was determined to use Emacs on our Java codebase. He spent three months trying to get functionality equivalent to 2010 Eclipse (I was one of the IDEA hipsters in the company back then), and failed. Hard.
I always thought that in 3 months,n if he'd applied that effort to Eclipse, he'd probably be contributing patches to it.
If you swing a steel head framing hammer for 20 years, and then discover the lighter titanium one, I guarantee it will feel like nirvana. Tools matter.
I don't disagree that using the right tool for the job is important. In fact, that's kinda what I was going for - don't try to make the problem fit your preferred tool, rather, use the right tool.
I was curious how F = mv/t relates. TIL a steel hammer reverberates 30% of the energy back into the arm. Titanium is only 3%. I imagine it feels a lot better after a day of work.
Yesterday, I bought some nuts and wondered if I needed a nutcracker. I kinda dislike specialist tools. I prefer versatile ones. I found that I could just hold it in my hand and hit the nut with the blunt side of a chef's knife, turning the nut around and cracking all sides with precision. I could reliably extract the eatable inside part completely intact, not even split in halves. A specialist nutcracker tool is pointless to me now.
Because there’s a tool and there are (current and future) problems that can be solved with this tool. It’s an one time investment into a tool and it helps to solve multiple future problems more efficiently. Especially with vim or rather modal editing - this skill can be applied everywhere, including your favorite IDE. Though, it may be unrelated to the problem that OP was solving.
I've used Vim since I first managed to figure out a way to get a shell on the heavily controlled school Unix network. (Well, it was Vi initially).
It was always my editor of choice when SSHing into a box over dodgy dial-up for the very obvious reasons, a few keystrokes could be immensely powerful, and they're easy to transmit.
But I've never felt the urge to run Vim bindings in my IDE, or my browser. But for working on a file over SSH? Vim all the way.
It is good to have at least a basic understanding of a common terminal based editor. Otherwise it is very cumbersome to work with files on a remote server / ssh.
I find it fascinating that people think that optimizing a tool doesn't matter when they will be spending over 50% of their actual productive professional time in that tool. At least.
I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.