Pre/post-processors, code-generation, one-command deployment, performing release, running functional tests, etc. It poses a question that spans a lot of these editor customizations – should they really be part of the editor? Don’t they belong to the build tool instead? Many of them indeed belong to the build tool. Remember the example where you add a shell-script that runs selenium tests. At your own risk, of course, and soon you may spend hours debugging which two files are in conflict and are blocking your IDE, but that should be available. Simply dropping a file (in any jvm language, for example) should have the ability to alter the behaviour. So a very important thing I would like to see from IDEs – they should be more easily customizable. It’s an overkill to write a plugin for such small things. If you want to write a plugin, you may need to know OSGi, SWT, a complex plugin API and whatnot. ![]() Luckily, IDEA had these things configurable, but it might not have had them. Very minor things that it turns out are important for me. And hovering on a class didn’t show its package. I didn’t realize it until I had to switch to IDEA and there ALT+arrows didn’t jump through camel humps, but only through whitespaces. The cool text editors allow you to write simple scripts that plug into the editor and thus let you improve your experience. ![]() Minor, even subliminal pitfalls maybe, but still – an editor isn’t leaking anything because it doesn’t have anything to leak.īut let’s elaborate a bit more on customizability. The IDE may make it too easy to generate tons boilerplate code, that will later be hard to support. Novice developers may commit absolute build paths, the IDE might have a very cool support for a framework, but lack one very important parameter that appeared in the latest version, so that you have to make a workaround. So, you might be better off going for a text editor?Īdditionally, the IDE may leak something into the application. But with a text editor you can easily plug shell scripts that run your grails application and then run selenium tests, while running a grails application from within the IDE is (or at least used to be) painful. The IDE has syntax coloring, autocomplete where possible, jumping to files with shortcuts. Writing Java in anything other than an IDE should be restricted only for educational purposes, otherwise you are losing too much.īut it’s not that black-and-white for other languages, where the IDEs are not that mature or you cannot have some of the features that you have in statically-typed/compiled/jvm/. ![]() ![]() It is a no-brainer there and the IDE wins by a huge margin, because of all the wonderful features like refactoring, debugging, hierarchies, integration with frameworks and build tools. Let’s first look at the trivial example – Java (and C#). And of course, I’m starting with the disclaimer that the distinction between “IDE” and “editor” is not that sharp. Either way, it’s an interesting topic to discuss – what are the pros and cons of using an IDE vs using a customizable text editor (vim/emacs/Sublime/…). Are you using an IDE, or an editor? Are you a “hardcore” programmer, or you are one of those sissy modern developers that use IDEs? Have you personalized your emacs or vim to make you 200% more productive? Or do you think that emacs is useless, at least for Java.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |