A coworker introduced me to PyCharm after years of development in vim, and it has been an incredible productivity boost. It's painful to watch coworkers slowly fiddle around with text editors. I almost don't like telling people this because it's such a professional competitive advantage for me after switching. Even my coworkers using Sublime run into pain points that I don't (perhaps because they aren't installing all the plugins they should?)
* Its uncanny ability to find references and declarations in both Python and JavaScript, even when the references are dynamic. What is this .log() or .render() actually calling? Instantly I'm looking inside the relevant function, even if there are hundreds of functions with the same name. This works across imports and libraries. Doesn't always work, but even when it doesn't, it usually makes good guesses and lets me select from a list. If you're working on a large, unfamiliar codebase, this is a godsend. You will sometimes wonder why your coworkers are struggling to understand code references and then you realize they don't have this power-tool available to them.
* Local file history separate from git history, with fantastic navigation/diffing support. It's an undo/redo button on steroids that keeps months of history.
* When searching for something, you get a full, scrollable preview of the surrounding context of each matching result. Results are organized within the file hiercharchy and are collapsible.
* Remote debugging. Drop an egg in your remote source and go.
* Annotated code, line by line, with the relevant commit and comment next to it.
* Auto-linting to catch common mistakes when coding. It'll immediately underline suspicious-looking code and tell you why. Lots of customizable style-linters to keep your code pristine looking.
I've been a WebStorm fanboy since I purchased a license during a sale two years ago. The biggest selling point for WebStorm for me is its smart searching abilities. "Find In Files" doesn't just do text search, it's also smart enough to allow you to include or exclude matches in strings and comments. It also has a great parser that understands the structure of your code well enough to do legitimate "Find References" searches with really good results in spite of Javascript's dynamicness.
Obviously Python is a very dynamic language as well, so PyCharm has most of the same strong points. I'd been using the Community edition for a while, but finally picked up a Commercial license a couple weeks ago. In this case, the feature that finally convinced me to pay for it was no-kidding Remote Debugging. Drop a .egg next to your deployed app and stick an extra import and connection call into your code, and then PyCharm's debugger (which is another great feature in and of itself) just flat-out works over SSH.
Ultimately, both these tools have saved me enough time and effort to pay for themselves repeatedly.
While WebStorm and other JetBrain IDEs are great, the RAD/WYSIWYG part is missing. We had already Frontage/Dreamweaver for HTML3-4. If JetBrains would add a HTML5 WYSIWYG editor based on webkit/blink to their IDEs, it would be awesome.
I don't think so. They have an excellent IDE for editing html on a source basis and an HTML WYSIWYG wouldn't have a developer as a main target, most developers would prefer editing the html directly (and would need to, unless they used a templating system based on the ideas of Enlive).
These days the target market for WYSIWYG HTML editors would be probably be using an online CMS like WP - which actually has a WYSIWYG HTML editor. Failing that, Microsoft Word actually had nice HTML output last time I checked.
> HTML WYSIWYG wouldn't have a developer as a main target, most developers would prefer editing the html directly
WYSIWYG always had a split-screen view which allows one to work in design and code mode at the same time (and see the changes in the other mode). It's very efficient.
> Microsoft Word actually had nice HTML output
MS Word 2000-2013 web page export is based on the old Frontpage engine, and generates invalid HTML4 and converts vector graphics and word art to VML, the proprietary predecessor of SVG, that IE10+ don't even support anymore (except with legacy quirks mode mode).
> online CMS like WP
The contentEditiable HTML4 API that CMS use is sadly completely broken in every browser in a different way - the experience and the code output quality is far worse than Frontpage ever was - and Dreamweaver is better in every aspect.
There is a reason why we have BBCode and Markdown, because contentEditiable isn't that great at the moment. And as several browser vendors have a competitive advantage with their web based Office services (Office365 Web Word, iCloud.com Pages, Google Docs), they will never fix the various bugs of contentEditiable in IE/Safari/Chrome.
The current year is 2015, MS word has come a long way since 2001. In fact they bragged with clean HTML output, suitable for inserting into your blog, in MS Word 2007. If you haven't worked with Word for almost 15 years do yourself a service and don't assume it looks much the same anymore - most the complaints I hear about it are no longer so much an issue in the newer versions.
Also I have no idea where you got the idea that WYSIWYG always had a split-screen view unless there is some product that is named WYSIYG, for me it has always meant What You See Is What You Get and the entire idea was that you have to mess with how it worked under the hood. As implemented in e.g word (or open office) you don't even have the option of doing that. Are you arguing that Word is not WYSIWYG?
Finally take a look at the the output from the WP HTML editor, I have no idea why you bring up the contentEditable API, but either you are misinformed or wordpress use something else because the output is pretty clean and it can convert between that and free HTML entry.
You are wrong, please test it again. In Word 2010 it still uses the Frontpage engine to output not so good HTML4 code with VML graphics. Btw. Office applications haven't changed that much since Office 97 (beside regular interface changes).
And just because some have never have seen a good HTML WYSIWYG editor doesn't mean it's a bad rapid development method and should not be integrated in a modern IDE.
- contains VML code
- will not render correctly in any modern browser
- If you want to be able to render it in IE11, you have to press F12 (Developer tools)
and change from "Edge" to compatibility to version 7 (or even 5) of the IE engine.
Then it will be drawn "correctly".
To clarify the generated code is invalid HTML 4.01 (20 errors according to W3C HTML4 validator https://validator.w3.org/check ) and the first view lines look like this:
Microsoft split Frontpage in two products SharePoint Designer and Expression Web (the later with a new web render engine), though both products are either a shadow of the former self (no WYSIWYG view anymore) or abandoned (free download without support): https://en.wikipedia.org/wiki/Microsoft_Expression_Web
I think that would not happen, with all the difference and mess in implementation under multiple browsers (even with webkit based Safari and Chrome), and file watcher+auto reload is less of a headache.
WYSIWYG always had a split-screen view which allows one to work in design and code mode at the same time (and see the changes in the other mode).
It's very efficient and less headache. WebStorm could add webkit and sync the code view like Dreamweaver. JetBrain's IDE is Java based and integrating a C++ based WYSIWYG view might be more complicated. And all the Java based browsers have been discontinued like https://en.wikipedia.org/wiki/HotJava .
Not PyCharm user, but IntelliJ IDEA, PhpStorm and WebStorm - they are from one family.
Most important things are:
1) Static errors analyzing. Saves a lot of time. Really, hundreds hours of time.
2) Code completion (VS users call it "IntelliSense").
3) Refactoring tools. You can change name of method in one place and IDE will change all usages of this method everywhere in code. It's extremely important.
I'll second all those points, especially the first one, but I'll add a word of caution. All of the points you mentioned require the IDE to parse all the code, not just the code you are writing at this moment. If it doesn't know the type of $foo, it can't tell what $foo->getModel() calls and therefore it can't rename that getModel(), for example. This means you have to be careful in projects using older frameworks or CMS. From recent experience, a great example of such an atrocious codebase is Magento:
- their method calls are excessively chained, which means a failure to analyse step 2 of the chain blocks analysis of all further chained calls
- their phpDoc either doesn't exist or is actively misleading at times
- they rely on magic methods all throughout the codebase without properly annotating them
I mostly develop in Sublime/Atom + iTerm2, but after working in RubyMine for several months, it feels like I lost some sensation in a limb. (and I only explored the bare essentials) Biggest wins for me: Cmd-click pretty much anything and jump to the file, even if it's a gem somewhere outside of my app. Code hinting. The way a Rails console behaves.
For me the features I appreciate the most are the debugger, framework support, and decent multi-language syntax support (for when there's js embedded in the html). All that and it runs a lot faster than PyDev.
I was so happy when I found out that you can select a string and then inject a new language right there which gets you code completion for that language. I was even more happy when it allowed me to edit that string in a separate window as if existed in a separate file.
Ruby web dev here...I pretty much use liberal puts statements (actually the awesome_print) gem. It's never really been a problem for me with ruby. 2001-2007 I was primarily a Java developer and the debugger was essential. But since switching to ruby in 2007 I've just never felt the need. I think it's probably the cycle time...we were using BEA weblogic as our Java server and cycle times weren't quick so you didn't want to waste time and needed to be able to step through the code. With ruby/rails it's almost instant to see your logging so I've never even looked into how to use a debugger in ruby.
Another ruby dev, back in my java days I used debuggers from jbuilder and eclipse. I now use pry and much prefer it as an experience. I found having everything at your fingertips rather than scattered around a gui far more efficient.
It's almost professional negligence. I had the same situation 15+ years ago when Eclipse was coming out and Java was on the rise. We really didn't know Java all that well and so Eclipse's auto-completion and doc popups were a godsend. The guy sitting there with Vi(m) was bogging down beyond belief. It got to the point, where we had to sit him down and tell him he needs to use the right tool for the job or get lost.
It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".
I guess I can't tell if this post is a troll or not. :)
Someone not getting their job done is a problem. Someone using vim as their editor is not. I could understand giving that feedback ("try an IDE") but telling them their job is contingent on it is probably missing the point.
Most of the people I work with seem to use vim/emacs, and it doesn't appear to be for "machismo" reasons. It's likely just what they're used to.
I've been curious in the past, trying to find a reason to use an IDE. For me, the loose coupling of tools that you get when working with Vim in a console is priceless.
My trick (not really a trick) for efficiency is some simple key bindings to navigate between windows in Screen.
And if I really need power I'll run tabs inside of individual Vim instances within each Screen window.
I really think IDE dependence is one of the things that can prevent agility within a team. As soon as you introduce a product into your stack that a person's IDE doesn't have deep integration with, or doesn't play nicely with, all that productivity that person gained by learning that IDE is all of a sudden gone.
I was that guy & never switched to an IDE because I was really good at tearing through text with the vim model. intellij's vim plugin (ideavim) is top notch. Just having auto completion, find definition, find file and rename are worth the price of admission.
>Someone not getting their job done is a problem. Someone using vim as their editor is not.
The best programmers I work with use emacs or vim and are good enough to keep up even though most others use intelliJ ides, but it is a handicap, they are just good enough to overcome it. I have no doubt they would be even better in a good IDE.
>> Do you really think the best programmers spend enough time refactoring for the use of an IDE to help?
> Is refactoring a bad thing now?
It isn't, he just intended that the best programmers refactor less (since they are the best they must get things right or better predict the future more often then the others).
I work on a large C++ codebase in emacs. I find emacs keybindings and extensibility (via elisp) far superior to any IDE - and I have tried Eclipse, CLion (IDEA for C++), Code/Blocks and Netbeans.
For C/C++ specifically, the state of code analysis in emacs has greatly improved due to clang. For example, I get full auto-complete (including for variables declared 'auto') in emacs with irony-mode [0] for code completion, flycheck-irony [1] for on-the-fly syntax checking, and I get jump to definition/find references/etc via clang-ctags [2]. I assume vim has similar extensions.
CLion is only a few months old and can be considered to be a 1.0 release, its already growing more and more capability on each minor update.
I use PhpStorm, cLion and PyCharm, and im happy to pay for them, the editor itself is very high quality and having common tools across all the 3 languages i use is great. If only they did a "golang" IDE.
You can use the Go plugin for almost any IDE based on the IntelliJ Platform, that includes CLion and Android Studio. And the best of all, it's free. Give it a try by installing it: https://github.com/go-lang-plugin-org/go-lang-idea-plugin
> It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".
Oh, that's amusing, and rather misinformed. Emacs in particular, when programming Common Lisp or Clojure, has a really impressive environment that Java IDEs can only aspire to (in part, that's an unfair comparison, because CL and Clojure are well suited to interactive programming and Java isn't).
I would be more careful with strong words like "professional negligence" or "hardcore, programmer machismo".
In 2015, do you think most people are using emacs or vim to work with Java or with a Lisp? I think this point stands for the vast, vast majority of people using emacs and vim.
> It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".
I feel the same.
Having been brought up with all Borland products, Smalltalk Visual Works and Oberon, I really cannot grasp they keep themselves in a UNIX V7 world, instead of a Xerox PARC one.
And I did use Emacs several years, while deeply missing Borland tooling, as that was the best thing one could look for in UNIX back then (VIM did not exist just VI).
However in 2015, there are so many nice IDEs also available for UNIX...
"It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo"."
What is amazing is that in 2015 there is people out there that believes Vim or Emacs have no intelligent, realtime analysis.
In fact, in year 2015 Emacs and Vim have the best real time, intelligent analysis out there for those that know how to use them and are trained on them.
You can use elisp inside emacs and automate EVERYTHING running circles around anything commercial.
I have a company making software and I know. With the proper training those tools are incredible.
In fact, in year 2015 Emacs and Vim have the best real time, intelligent analysis out there for those that know how to use them and are trained on them.
I develop Cursive, an IDE based on IntelliJ for Clojure code. Its completion and navigation are categorically better than Emacs's, even for a language that supposedly has one of the best levels of support under Emacs.
To say that Emacs is automatically better than everything else is pure Stockholm syndrome.
I have nothing against Cursive, and in fact, have been eying it from afar. But this kind of comment is just needlessly dismissive with little in the way of substance, as far as I can tell. Would you like to expand on what these features that Cursive has that are "Categorically better" than Emacs'?
I'm not saying there isn't any, and certainly I've used better refactoring tools than https://github.com/clojure-emacs/clj-refactor.el in other languages. But what on earth is wrong with the navigation? The main advantage I've seen form a colleague is the highlighting automatically of usages, but I'm pretty sure I can set that up in Emacs too.
I have nothing against Emacs either, and I didn't say that there was anything wrong with its navigation. What I said was the assertion that Emacs and Vim have the best realtime analysis is just wrong - most Emacs modes have none at all.
If you're interested in the implementation of this sort of functionality in Emacs, Steve Yegge's article on implementing JS2 mode is really interesting: http://steve-yegge.blogspot.co.nz/2008/03/js2-mode-new-javas.... He says at the end that IntelliJ's JavaScript support is just better, and it's very clear from the article how difficult it is to retrofit this sort of functionality into something that isn't built from the start to support it.
But you're right that the tone of my comment wasn't great, and in general getting involved in these discussions is just a bad idea. Every so often I see a comment that makes it difficult to resist, but I always regret it.
To answer this specific question - Cursive's Java interop support is much better than anything else I'm aware of. It implements Clojure's type inference in the editor, so method calls are accurately resolved to the right method based on the number and types of the parameters, and completion takes this into account so that you can explore Java APIs almost as well as with Java in IntelliJ. Cross-language navigation and Find Usages works - in Cursive you can navigate from RT.var() calls to the Clojure code, and Find Usages from Clojure will find the RT.var() calls. This also works for other JVM languages - there are quite a few Cursive users with mixed Clojure/Scala codebases, and this all works there.
You can search for all usages of a particular keyword, and it will also find all local bindings destructured from it using :keys. Namespaces will be auto-required during completion based on examples elsewhere in your project, not hard-coded config. This works in the REPL too - you can type str/tr and when it's completed into str/trim Cursive will automatically (require '[clojure.string :as str]) in your REPL.
One other nice thing is that since Cursive works from source, pretty much everything that works for Clojure works for CLJS too.
There's lots more along the same lines, hopefully this gives you an idea. Again, there's nothing wrong per se with Emacs' navigation, but IntelliJ just provides a much more sophisticated infrastructure for it. Obviously elisp is Turing-complete so all this could in theory be implemented but it's much harder, as Yegge describes in the article I linked in my other comment. The clj-refactor guys are doing a great job but the lack of a good indexing infrastructure is going to mean that a lot of this functionality is hard or impossible to implement.
Emacs is a great choice for a lot of people and if you're willing to invest the time to trick it out and maintain it, especially for Clojure you can get a really nice environment. But probably the feature that most people like about Cursive is that it just works out of the box, and stays working with no messing around and no development of your editor required. And WRT my original comment - to say that Emacs has the most sophisticated runtime analysis is just wrong.
Do you realise that emacs supports 'intelligent, realtime code analysis'? I program in Go, and I have auto-completion and documentation.
Emacs is more extensible, and more easily extensible, than Eclipse.
Yes, an IDE is pretty nice for a particular kind of horrible enterprise coding: the sort where no-one understands the system, where everything's horribly over-architected and where, yes, ultra-fast auto-completion is necessary to get anything done. But…why live like that? There're interesting problems and fun environments where one doesn't need to live in that kind of hell.
emacs can handle that, but you have to start asking yourself if it even makes sense to do. A lot of times, those IDEs are just managing spurious complexity, not actually helping build something great.
> where we had to sit him down and tell him he needs to use the right tool for the job or get lost.
One can look at it the other way. If your language needs a million lines of IDE code to function and for programmers to be productive with it, maybe it is time to sit down and tell that language to "get lost".
If you are more productive with a million lines of IDE code backing you up + that language than you would be in Emacs with C++, why would you tell that language to get lost?
That's pure nonsense. There is nothing that prevents languages like Lisp or Smalltalk from being used with a console editor and the compile-pray-debug cycle, but that's no reason to shoot yourself in the foot. This is true of any language, but for some reason there's a large mass of developers of those other languages that see shitty tools and incomplete programs (remember kids, high LOC count means bloat!) as some kind of virtue.
Emacs + slime for Common lisp and tuareg mode for ocaml can do everything that my intellij can do in Java. Then I can extend Emacs to cast a spell, hex vim users and spam HN every time I fixed a bug -- even with plug-ins system I suspect intellij isn't that extensible.
> It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".
I think it's mostly that the current state of "intelligent, realtime code analysis" is so terrible that it can be replaced with "rename" and "find references of". I.e. ctags.
Then you have no idea about the current state of intelligent, realtime code analysis. Any old Java IDE should be able to rename length to size on an interface and have all the classes that implement that interface update the name, then have all the places that calls it update to use the new name.
Try that with rename and you will quickly run into trouble, unless you have only one class that has a method called length.
This is still a rename operation. I have difficulty understanding how this would require an IDE for anything but the more complex codebases, and even then, I would much prefer a discrete code server.
Refactoring is still in its infancy. A), it's not entirely possible on C/C++ because of macros. B), they are serialized extremely poorly to diffs, so any boon from refactoring is sidestepped by SCM. C), most of the refactoring done by programmers cannot be done automagically by the IDE (e.g. type signature changes are painful as hell). D), 95% of changes are supported by ctags-like functionality; i.e., a basic identifier index, and re-compiling to fix the bugs.
Given this, I'm pretty sure IDEs have made a lot of progress towards renaming and looking up references really well, but not a lot of progress towards actually being useful.
That said, I do find that when the language supports it, a precise tool to find usages and/or rename is worth its wait in gold. But this is hardly anything near "intelligent, realtime code analysis". Pretty sure that's referring to typeahead, which again is a step removed from a source code index and can be faked by using a regular expression to extract identifiers to suggest.
Using a tool to refactor is better for source control. The diff sucks, but it sucks because it actually found every instance and refactored properly, meaning going through to review it is simpler as long as you trust the tool. We should be using tools for this type of thing, for exactly the same rules as automated formatting should be the default response to any debate on formatting issues.
It would seem that you've not used Resharper. Best refactoring tool I've ever seen. Actually seems like they are forcing the Visual Studio team to pick up their game.
> (e.g. type signature changes are painful as hell)
Resharper handles this very well.
I think it's that if you use Vim and Emacs properly with the right extensions, then they can be pretty amazing, but if you're just cargo culting and use Vim just to say you use Vim, then it won't work.
I use Emacs to write everything. So, in the last 12 months at least C, C++, D, Haskell, Ruby, and Python.
For Python I use rope and jedi. Auto-complete, goto definition and refactoring.
For C/C++ I use my own package cmake-ide. As the name implies, it only works for cmake builds. But it does work. Similarly to Python, autocomplete, on-the-fly syntax highlighting, goto-definition, ...
For D I use another one of my packages, flycheck-dmd-dub.
For Haskell I can't remember now but it'll all very good.
For Ruby I use flycheck, rubocop and rsense.
Not OP, but I use emacs + jedi[1] for Python development.
In addition to code completion, having documentation available to you as you type, and easily navigating code (e.g. jump to definition), you also have all the usual emacs goodies (unlimited undo/redo, easily defining keyboard macros, writing functions for emacs and binding them to keys).
I've had reasonable success with company mode and rtags for C/C++. Fairly straightforward to set up and reasonably accurate. I'd hesitate to call it streets ahead of even Xcode, let alone Visual Studio, but it does roughly what you'd hope for, without too much hassle. Definitely worth turning off company mode's complete-as-you type functionality, though...
After 9 years of using emacs, I still don't find it unambiguously better than Visual Studio for working with C/C++. The text editing is a lot better in emacs, but the code browsing/completion is not - and for large, multi-person projects I've always found the code browsing/completion functionality more important. You can always load files into emacs for one-off operations if you need to do something in particular.
From hat I've seen I'll disagree. The people that use vim efficiently [emacs users just substitute emacs] don't just use vim. They are also very efficient using the surrounding (Unixoid) environment. Specifically file searching...I'm not sure IDEs have an edge there.
These days there's also things like eclim. I don't know it seems like vim style editing is still the best way to get around the codebase and actually work with the text but IDEs have great integration to work with the code. So I think the optimal solution is a "best of both worlds" approach which means a vim-plugin for the IDE or an IDEfeatures-plugin for vim. I see the former setup a lot.
---
and my wild guess is that emacs actually has great code integration for Lisps. I don't know what the state of the art Lisp IDE is but I'd be shocked if it was better than emacs.
It's more than a little ironic that you claim Emacs/vim users use their tool out of 'harcdore, programmer machismo', and you're doing basically the same thing in the opposite direction by accusing them of being unprofessional.
For me, I've used both IDE's and plain ordinary text editors for close to 30 years (the first IDE being QuickBasic 4), and tend to find that IDE's get in the way more often than not. My personal software designs tend to use single components for single functions, so the additional complexities of an IDE's second compiler, second build tool, second VCS front end are less than appealing to me. That said, I've gotten a lot of use in the last 24 hours out of code refactoring the the IntelliJ debugger, so I think the honest answer is to use both approaches if you like.
>It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".
You found me out! My preferred environment set up is nothing more than machismo directed at you, a complete stranger. If only I'd had the humility to try an IDE, I could have been enlightened
My eyes hurt from rolling them so hard at your comment.
Emacs, Slime and Common Lisp is something that I would give an exception to. The major productivity I give to that combo is the ability to change the code on the fly while debugging, especially Common Lisp's continue from exception mechanism.
Smalltalk environments have had this ability forever. I just imagine how much more productive I could be if in Visual Studio I could edit-n-continue on everything...even if my code wasn't in a successful compilation state.
Java has this and Jrebel has this on steroids, but I want to be able to edit-n-continue even if my compilation state is broken. Just throw an exception when it fails because of bad state.
Common Lisps exception mechanism is indeed out of this world, but that isn't something that has been implemented in any other language that I know of (not even Clojure) and you have to pay a fortune to get a CL system that works cross-platform with things like threading or a FI that allows lisp callbacks from C code. Java has supported both since forever (and its java.util.concurrent namespace means any old Java programmer has access to all sorts of really advanced non-blocking data structures, including a ConcurrentSkipListMap and an AtomicInteger) and for most people, for almost all tasks, that makes Java better. And for Java you need an IDE.
