Live data from Hacker News

One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

andrewbrookins.com

1–10 of 41 posts

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#2
I first tried PyCharm when I had to do a project for the Boxee platform , it was my first time doing anything in python and it helped greatly. Even back then the autocomplete was great, debugging just worked and for a complete noob it was perfect. Since then I switched to the full blown IntelliJ IDE and never again will I use anything else.

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#4
I can only agree, PyCharm ist really great work by JetBrains, i love it.

What i think he really missed in features though:

- VCS integration is really really good

- Plugins for the Atlassian suite (never open Jira in a browser again!)

- virtualenv support

- remote debugging and execution and uploading support

- vagrant support

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#5
post #4

I can only agree, PyCharm ist really great work by JetBrains, i love it. What i think he really missed in features though: - VCS integration is really really good - Plugins for the Atlassian suite (never open Jira in a browser again!) - virtualenv support - remote debugging and execution and uploading support - vagrant support

Indeed. Virtualenv support is fantastic: have a virtualenv dir already there? No problem, PyCharm will detect it. Want to create a new one? Why, let PyCharm do it for you, it will even install packages!

The only outstanding gripe I have is the lack of full PyQt support in the autocompletion / intelligent import features. I know it's a hard problem and there are hacks, but if they could fix it for good it'd make it The Only True Python IDE for me.

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#8

For those wondering, us Emacs creatures use Rope + ropemacs + rope-mode to achieve the same thing. Vim has access to the same tooling more or less.

From the article:

> Rope-based completion was always unreliable, slow or both.

I haven't used rope. Is the author wrong about this?

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#9

Unless they fix their 64bit Linux version [1] I'm not bothering try it out again and give up within a few minutes. http://www.reddit.com/r/Python/comments/182siy/pycharm_27_is...

Try adding these lines:

  -Dawt.useSystemAAFontSettings=on 
  -Dswing.aatext=true
  -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
to the pycharm64.vmoptions file.

Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective

#10

For those wondering, us Emacs creatures use Rope + ropemacs + rope-mode to achieve the same thing. Vim has access to the same tooling more or less.

I am a huge fan of VIM's design (and by extension EVIL http://www.emacswiki.org/emacs/Evil in Emacs, which is what I use most of the time), and I agree that all to most of this is achievable in Emacs.

I really like Jetbrains products though, and when I am on Windows those are my goto tools as I don't have the UNIX user space to leverage alongside Emacs or VIM.

They provide a great environment for those languages that don't have great support outside of commercial IDEs or for people turned off by Emacs/VIM.

My first experience was using IDEA for Java (both VIM and Emacs support for Java is an area where they are weakest somewhat surprisingly) and I was very happy with IDEA, so I tried PyCharm later on when I was on Windows and using Python there.

However, Emacs makes use of Python's REPL much more fluently than what I've experienced in PyCharm where the IDE has no interaction with the REPL outside of user engagement.

PyCharm in comparison seems entirely ignorant that it has a REPL it can exploit and integrating tightly with it would pay dividends.

Coming from Emacs where REPL integrations tend to have at least some sense of intelligence about them this was jarring.

PyCharm's intentions though are also very nice and isn't something I've found in Emacs or VIM to the same extent.

The IDE still has the same trait I've seen in Eclipse, VisualStudio, XCode, and Jetbrains' products though where it makes determining what the project entails into an overly complicated affair though, an area where VIM and Emacs have less red tape to get into.

There seems to be a great deal of improvement in that area for tools to get into where they are smarter without requiring so much user facing bureaucracy up front.

On one hand we have Emacs and VIM that largely pretend there is no such thing as a project and that tools could perform actions on that as a unit.

Then on the other side IDEs want to recognize that a project is an actionable unit and that it is a unit but then engage in 20 questions just to get started on a project and even after that get easily confused when moving files around.

Anyways, as far as IDEs go, Jetbrains' products have been the most enjoyable to use.

I do wish they were full open sourced though so that contributing improvements voluntarily wasn't a comparatively precarious trade off compared to VIM or Emacs or whatever open source tools you use.

Also, I wish IDEAVim was a lot nicer support of VIM's features than what it currently has so that I didn't have to want for some functionality at times.

Both the Emacs and VIM or typical IDEs have a lot of room for improvement in general though, tooling could be a lot nicer and homogenous across languages to the extent possible.

I really wish anyone would run with Bret Victor's idea of closing the feedback loop in programming (http://vimeo.com/36579366) adamantly and also implement Douglas Crockford's idea of scope based coloring everywhere (https://www.youtube.com/watch?v=dkZFtimgAcM), the latter of which I really want in functional languages like Haskell/OCaml.

Those two alone would add significant utility to the available tools.

After seeing Crockford's scope based coloring idea syntax based coloring seems incredibly superfluous even though I use it myself.

It really feels like we are in a tooling stone age with a great deal of retreading and regression in some respects despite having a lot more man-months thrown at the area.

Post reply on HN