4 ms·
It's interesting because I come from the exact opposite direction. I started with IDEs, then Emacs for almost 15 years, and last year I switched to Vim. Ecosys
by simias 5y ago
It's interesting because I come from the exact opposite direction. I started with IDEs, then Emacs for almost 15 years, and last year I switched to Vim.
Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
- majkinetor 5y agoYeah, give me generics and a language to pipeline them into anything I want. Full stop. Let Harry Potter and his friends play with magic.
- zozbot234 5y agoLSP and Tree-sitter seem to have the right approach, aiming to provide a standard layer that can support a wide variety of languages and ecosystems throughout. Language-agnostic tools can interoperate with this approach too but they only provide very basic features, not really enough to compare well with existing workflows.
- rodgerd 5y agoLSP seems like a real blessing for editor authors, since "it can't do anything useful with my preferred programming language" has been a big lock-in.
- xpe 5y ago?. This is a back handed compliment? Can you explain?
- rob74 5y agoI guess he means that LSP (at least in theory) enables "simple" editors to offer features which in the past have been the domain of IDEs (code completion etc.), and for editors supporting LSP, the support for a given language will (again in theory) be as good in one editor as in the next one you might want to try out...
- rodgerd 5y agoIf you're trying to get people to try your new editor, no matter how awesome the ideas that you're trying, you're going to lose a chunk of your audience if it doesn't support C syntax highlighting, a chunk if it doesn't support Python intellisense, and so on and so forth. You can have the best idea in the world, but people will play with it, and decide that they love it but can't use it for "real work" unless you slog through adding native support for a bunch of languages and runtimes/compiler suites. That's a huge burden. Now, if you implement LSP, you get "for free" support for C#, C, Python, Rust, etc etc. People can evaluate your editor on its merits as a text editor, not on whether you had the time and energy to add support for their favourite language.
- linsomniac 5y agoJust this morning I upgraded to NeoVim 0.5 and set up TreeSitter and LSP with Lunar. I haven't had much time to play with it today, but it's looking good so far. https://github.com/ChristianChiarulli/LunarVim https://github.com/ChristianChiarulli/LunarVim
- Scarbutt 5y agoSeems you are agreeing with GP.
- mraza007 5y agoI totally agree with you !!! I think using visual studio code gives you everything out of the box like all these extensions just makes things very easier for you. But learning tools such as vim and learning how to configure those really helps you get out of the comfort zone I was a regular vscode user but after using vim my workflow really improved I have nothing against vscode users but sometimes getting out of comfort zone really helps you
- pjmlp 5y agoThe 10 line Makefile doesn't do Smalltalk like development experience, nor is able to single step GPGPU shaders, do live editing of GUIs, graphical visualization of running tasks and threads, provide graphical architecture diagrams, correlate lines of code with the people that edited it and to which tickets the PR were made to.
- MisterTea 5y agoThose are called tools. They can be separated. Not everything has to be a multi gigabyte monstrosity swiss army knife. You can think microsoft for gas lighting you into that line of thinking.
- pjmlp 5y agoTools work best when they are designed to work together. Anything else is a klundge. If I have to thank anyone, it is Xerox PARC, TI, Genera, Apple and Borland, long before Microsoft mattered at all.
- jcranmer 5y agoThe problem with separating out tools is that the resulting tools tend not to work very well with each other and suffer as a result. I'll use gdb as an example: using it standalone means I can use whatever text editor I prefer to read the code, but now I'm forced to manually schlep between the debugger and the editor to do debugging: let me figure out what file I need to look at for this current function, and manually open it in the editor. Okay, now let me copy-paste this function name to break on. Oh, here's a value I want to inspect, let me go manually type this in. And constantly back and forth between the editor and the debugger. Having the tools all work together in one environment is honestly a far superior experience than having each tool live in its own bubble and requiring you to do all the coordination work yourself, with all of the repetition and scope for mistypes in the process.
- HeavyStorm 5y agoI thank Microsoft for building tools that make my life easier and my work a delight. Yours was a very ungrounded commentary.