> That said I suspect most people would be better off learning a good IDE properly, including but not limited to:
To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?
Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.
I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.
With that said, i'll be quite glad that we're moving towards standardizing (of sorts) a code editor protocol so that new editors don't suffer from lack of tooling. It will be great to see a single set of tooling (formatting, linting, imports, syntax checking, etc) plug into any new editor that might pop up.
Switching editors has enough friction, tooling shouldn't be one.
To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?
Right now, for most people: very much yes.
Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.
Fair point. However: Between the default keybindings of Netbeans on Windows or Linux and the simplicity of customising it to my hearts content I haven't found any reason to abandon it.
I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.
Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years.
> Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years.
Yea, i definitely agree there. It's also that GUI IDEs tend to cater towards.. well, a different crowd. What that means in real world terms in often a product with rough edges, confusing patterns, and a horribly steep learning curve.
I enjoy seeing products and languages (programming) focus on learning as core feature of the product. It really is inherently important to a projects success.
Meanwhile, Git has taken over all source control for development despite being possibly one of the worst applications ever created. (Hell, even Lotus Notes tried to be usable-- it failed, but it tried.)
You spent (likely) years learning Emacs. How much time did you spend learning each of those IDEs you've tried?
You have to realize that psychologically: you like things you're familiar with, and dislike things you're unfamiliar with. That's how top-40 radio works. That's why everybody bitches over every new software update, even when the new version is provably better.
So of course you like the thing you spent years with over the thing you tried to learn for a week and a half then gave up on because Emacs is better. That has nothing to do with UX.
I've spent years in Eclipse as well (and still use it every day at work for Java stuff), and I appreciate a lot of the functionality it offers, but I definitely find the UX lacking. It's klunky. Yes, it's maybe more discoverable (although, at least in the case of Ecipse, that's debatable) and some of the keybindings are probably more familiar to most people, but I find that even though Emacs has a bit of a learning curve, once you've gotten past that, the experience of actually using it is very fluid and productive.
The core "IDE" features you don't normally get with an editor are things like project views, intellisense, code completion as you type, real time parsing and error highlight, code navigation. Sure you can get most all of this by wrangling plugins for vim (or which ever editor you choose) but in an IDE like eclipse, netbeans, intellij, visual studio, it's all there, ready to go.
In effect, a modern IDE is "programming ability" multiplier. It helps me code smarter and faster. That plus understanding what's going on behind the scenes is a powerful combination.
Vim and Emacs actually have quite a bit of support out of the box for code development - the ability to follow tags, goto different files, code completion, syntax highlighting, build integrations, etc.
The difference is that IDE-like features Vim are simply tuned for C (add Lisp for Emacs) instead of Java; plugins give them support for other languages. Anyone who has tried to write something other than Java in Eclipse can attest to how much plugin creep starts to enter the fray.
Sure, but the biggest problem with modern IDE's is the fact that they are terrible at editing text.
IDE's and text editors overlap in their uses, but they are not the same. Sometimes you really do just have a text editing task, and none of the IDE functionality will help with it. Also, the ways in which IDE's are extensible is lacking compared to something like Emacs. Yes, they come with a bunch of built-in useful stuff, but sometimes you want to add a keybinding to do some editing task you do a lot in a particular project or company, even if it's not useful in a more general-purpose setting.
Yes, they come with a bunch of built-in useful stuff, but sometimes you want to add a keybinding to do some editing task you do a lot in a particular project or company, even if it's not useful in a more general-purpose setting.
Don't know what IDE you used but Netbeans is very customisable and extensible.
I think this is true for IntelliJ and eclipse as well and it would surprise me if it wasn't for Visual Studio.
(In fact I think I have seen vim modes for all of these and even embedded vim in eclipse.)
I think I probably didn't explain my meaning well. For Netbeans, Intellij, Eclipse, VS, etc. you tend to have to create a new project to write a plugin.
In Emacs, adding a simple extension is simply a matter of adding a function to your .emacs file. So adding useful functionality is very low friction, low enough that you can afford to do it when it wouldn't be worth the effort in an IDE.
Note, it sounds like Kakoune is trying to be a text and code editor first. Not just a text editor, like Vim is out of the box. Completion and code related tools appear to be first class citizens.
With that said, it's purely speculative on my part, i clearly don't know - Kakoune is new to me.
To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?
Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.
I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.
With that said, i'll be quite glad that we're moving towards standardizing (of sorts) a code editor protocol so that new editors don't suffer from lack of tooling. It will be great to see a single set of tooling (formatting, linting, imports, syntax checking, etc) plug into any new editor that might pop up.
Switching editors has enough friction, tooling shouldn't be one.