An IDE will never help you develop "Clean, Professional, Maintainable, [and] Quality" code if you're not interested in writing it in the first place. And if you're interested in writing good code in the first place, an IDE is hardly a requirement.
Frankly, as a developer who has tried a number of IDE's and text editors, I'm not sold on the idea that your choice of editing environment has any correlation to any of those titular descriptors in the first place.
I was thinking exactly the same thing reading the headline.
Good design will give you a lot cleaner professional maintainable code.
I do databases, but I like Linus's quite about getting the data structures right, and not needing to worry about the code. I find if the application level is getting too complex, it probably means the database design isn't matching the problem correctly. Others on my team would keep adding "if" statements to the forming ball of mud. (Usually) I find it easier to take the pain of a schema migration up front. The code then becomes simpler, more reliable, and I can usually forget about it.
As for the text editor comment. In general no, but I know a lot of poor programmers who are too lazy to set up / learn an IDE (or any other way of using a step through debugger).
Nor will python. Python is dynamically typed. It may not be impossible to write big functioning python apps, but it's damn hard.
And specifically, it's a lot harder than doing it in java or C++. I've seen C++ codebases that exceed 8 million lines of code and held together (not without friction, that I guarantee). I've seen java codebases with about half that that held together a lot better than the C++ ones.
Even accounting for the fact that python easily lets you achieve 5 times as much in the same amount of lines (at the cost, imho, of more surprises when wrong types get passed to your functions). I'm not sure "normal python" is more than a little bit more succint than (good) C++ though. Easier to read, sure, if you're allowed to make assumptions about types. But not that much shorter.
I've yet to see the first million line python codebase. And python has certainly had sufficient time to develop such codebases. Why aren't they here already ? Those C++ codebases were almost operating systems though (with extremely tricky threading support libraries, every project it's own of course), something you fundamentally can't do in python. The java codebases were financial stuff though, something that could easily be done in python, and they certainly have the money to absorb the increased hardware cost, and looking to have faster development turnaround. That's another discussion I can guarantee you will have with your boss if your app really grows, the hardware cost. When it comes right down to it, a programmer is worth (rule of thumb) about 15 servers. If python means one less programmer, but 50 extra servers, you will lose that discussion with your boss.
Dynamic typing is certainly a massive advantage for small codebases. It becomes more and more of a disaster on larger ones though. So an IDE for python ... it merely lets you lose the battle with your code that much faster.
I have been using PyCharm for few months after using Sublime Text 2 for years. It is very well engineered tool and has greatly improved my code quality.
Just came to know 'Python code compatibility checks' option. Will definitely be helpful as I am starting to write Python 2/3 compatible code.
PyCharm was the reason I started coding in Python. I know it sounds weird, but I was a visual studio addict & going to sublime text or a plain text editor just didn't compare.
I wish they had a "startup" package so even boots trappers can get started right.
My concern about PyCharm is that it's becoming the Microsoft Office of IDEs. I feel like there's more and more bullet points per release that are more marketing-oriented than widely useful. While my needs remain simple. Maybe everyone needs only 2% of the feature set, and a different 2%, but we all have to pay for the bloat anyway.
I keep repeating a cycle where I try an IDE because it sounds interesting, but a few weeks later I find I'm spending a lot of time doing things like arranging tool windows, dismissing alerts, trying to figure out how to turn off or customize features. So I always go back to a simpler text editor that I've been using for 15+ years and does everything I need very well without the sluggishness of a feature-rich IDE.
For example, every time I open a PyCharm project I get an alert I need to dismiss that managing files will be slow because they're on a network drive. Technically it's a network drive but it's really mounted from a VM on my local machine, so no, it's not slow, and if it was I wouldn't need Clippy telling me so. There may or may not be a way to turn off this alert, but I shouldn't have to hunt for these things so often. I want to use PyCharm but keep getting annoyed with it.
If your text editor works better than PyCharm, then by all means use that instead. However, the article is actually trying to make some point about what an IDE can do that text editors can't so perhaps you'd want to respond to that?
> Maybe everyone needs only 2% of the feature set, and a different 2%, but we all have to pay for the bloat anyway.
This is not a useful mental model for thinking about software. First, big doesn't equal bloated, and one thing my IntelliJ IDEA fanboy colleagues highlight is just how sleek, light weight and fast it is, especially compared with Eclipse (we're in Java land). Second, if everybody only uses 2% of the package, then basic price theory tells us that everybody is only paying for those 2%. (I think, in reality, the number is significantly higher, although I agree that probably nobody uses 100% of the features).
I've been trying PyCharm for a few days. It doesn't do anything that emacs can't do (maybe refactoring, but that's on the list ahead), but it's easier to setup. If it's really a memory hog like people are saying, I didn't notice, and didn't look, and didn't care, my computer has enough memory.
Maybe it gets better with practice, so I'll keep trying a bit more, but currently, count me as unimpressed:
1 - About code inspection. Well, I fully understand that inspecting Python code is hard, and any tool will have either false positives, or false negatives. But PyCharm gets false positives to the extreme, it complains about not resolving Python standard functions (like open), and it can't find some libraries at my virtualenv. It's so full of false positives that I'm not sure I'll be able to keep reading them - I normaly can't stand code with warnings, but in PyCharm there is no other way.
2 - About formating. It fully enforces PEP8, the most completely enforcement I've seen on any tool (no I didn't try the emacs el for that). That's a good thing if there is an option to turn it off, what I don't know, because I didn't search for it yet.
3 - About refactoring. No, PyCharm, I don't want Django to change because I changed a function name in my code. Maybe there is a way to tell it not to touch some dirs, but the default settings makes PyCharm much less reliable and slower than grepping the old name and replacing it by hand. I'll try to find such setting when I get out of work today, but it's making the case of PyCharm being easier to setup way less appealing.
FWIW, if you're a developer who uses IntelliJ's flagship IDEA Ultimate IDE, you can get the Python plugin and get nearly all the functionality of PyCharm. Same goes for most of their other products (WebStorm, PHPStorm, etc.). Fabulous products for those of an IDE-inclination.
My biggest problem with the JetBrains IDE is that it scatters file turds through your project; making it a pain for developers to use source control without generating random conflicts. An IDE's files have no reason to be version controlled in every project (nor should a project require every developer to use the same IDE).
If they had a sane way to keep IDE files in a single top level project directory, I would be much happier.
I've certainly seen the IDE turd files you mentioned, but I'm pretty sure they all live in .idea. Github has a nice .gitignore build for these (and other common ignores):
The compelling use case for me was that I was already used to the Intellij key bindings, which tend to (mostly) remain constant across JetBrains products. It does use a fair amount of RAM, but these days 8GB seems fairly standard and seems to be plenty most of the time. I currently have PyCharm open and it's using 427MB.
The linked article is really nothing more than an advertisement for PyCharm. Is it acceptable now for companies to just post links to advertisements for their products on Hacker News?
I'm a fan of JetBrains and I own PyCharm and WebStorm, but I don't want this to become a trend...
Same here. It seems like a really solid IDE, but I like a more lightweight development environment, and there's always that one vim command that vim emulator plugins miss. However, I've recommended PyCharm to several of my coworkers who use IntelliJ for Java development, and they love it.
I have been a long time Eclipse / Aptana user. I gave the community edition for Pycharm a try, but it lacked a number of features. Plus I have used Eclipse for long enough that I have a fair idea what to when it screws itself up.
Yes, you can.
They can be set from: File->Settings->[Project Settings] Code style. You'll then be able to set the indentation level for each filetype separately.
[+] [-] falcolas|11 years ago|reply
Frankly, as a developer who has tried a number of IDE's and text editors, I'm not sold on the idea that your choice of editing environment has any correlation to any of those titular descriptors in the first place.
[+] [-] paukiatwee|11 years ago|reply
I always use IDE to refactor code, as other developers might not writing clean code, even myself.
[+] [-] collyw|11 years ago|reply
Good design will give you a lot cleaner professional maintainable code.
I do databases, but I like Linus's quite about getting the data structures right, and not needing to worry about the code. I find if the application level is getting too complex, it probably means the database design isn't matching the problem correctly. Others on my team would keep adding "if" statements to the forming ball of mud. (Usually) I find it easier to take the pain of a schema migration up front. The code then becomes simpler, more reliable, and I can usually forget about it.
As for the text editor comment. In general no, but I know a lot of poor programmers who are too lazy to set up / learn an IDE (or any other way of using a step through debugger).
[+] [-] waps|11 years ago|reply
And specifically, it's a lot harder than doing it in java or C++. I've seen C++ codebases that exceed 8 million lines of code and held together (not without friction, that I guarantee). I've seen java codebases with about half that that held together a lot better than the C++ ones.
Even accounting for the fact that python easily lets you achieve 5 times as much in the same amount of lines (at the cost, imho, of more surprises when wrong types get passed to your functions). I'm not sure "normal python" is more than a little bit more succint than (good) C++ though. Easier to read, sure, if you're allowed to make assumptions about types. But not that much shorter.
I've yet to see the first million line python codebase. And python has certainly had sufficient time to develop such codebases. Why aren't they here already ? Those C++ codebases were almost operating systems though (with extremely tricky threading support libraries, every project it's own of course), something you fundamentally can't do in python. The java codebases were financial stuff though, something that could easily be done in python, and they certainly have the money to absorb the increased hardware cost, and looking to have faster development turnaround. That's another discussion I can guarantee you will have with your boss if your app really grows, the hardware cost. When it comes right down to it, a programmer is worth (rule of thumb) about 15 servers. If python means one less programmer, but 50 extra servers, you will lose that discussion with your boss.
Dynamic typing is certainly a massive advantage for small codebases. It becomes more and more of a disaster on larger ones though. So an IDE for python ... it merely lets you lose the battle with your code that much faster.
[+] [-] neokya|11 years ago|reply
[+] [-] chhantyal|11 years ago|reply
Just came to know 'Python code compatibility checks' option. Will definitely be helpful as I am starting to write Python 2/3 compatible code.
[+] [-] ericcholis|11 years ago|reply
[+] [-] buster|11 years ago|reply
I wish they had another big sale so i could afford the latest pycharm again.. :(
[+] [-] sigzero|11 years ago|reply
[+] [-] Killah911|11 years ago|reply
I wish they had a "startup" package so even boots trappers can get started right.
[+] [-] vially|11 years ago|reply
More details here: https://www.jetbrains.com/estore/startup/
[+] [-] mseebach|11 years ago|reply
You could also stay at your day job for a day or two longer and save up for the $99 personal edition.
[+] [-] kunstmord|11 years ago|reply
[+] [-] gdulli|11 years ago|reply
I keep repeating a cycle where I try an IDE because it sounds interesting, but a few weeks later I find I'm spending a lot of time doing things like arranging tool windows, dismissing alerts, trying to figure out how to turn off or customize features. So I always go back to a simpler text editor that I've been using for 15+ years and does everything I need very well without the sluggishness of a feature-rich IDE.
For example, every time I open a PyCharm project I get an alert I need to dismiss that managing files will be slow because they're on a network drive. Technically it's a network drive but it's really mounted from a VM on my local machine, so no, it's not slow, and if it was I wouldn't need Clippy telling me so. There may or may not be a way to turn off this alert, but I shouldn't have to hunt for these things so often. I want to use PyCharm but keep getting annoyed with it.
[+] [-] mseebach|11 years ago|reply
> Maybe everyone needs only 2% of the feature set, and a different 2%, but we all have to pay for the bloat anyway.
This is not a useful mental model for thinking about software. First, big doesn't equal bloated, and one thing my IntelliJ IDEA fanboy colleagues highlight is just how sleek, light weight and fast it is, especially compared with Eclipse (we're in Java land). Second, if everybody only uses 2% of the package, then basic price theory tells us that everybody is only paying for those 2%. (I think, in reality, the number is significantly higher, although I agree that probably nobody uses 100% of the features).
[+] [-] marcosdumay|11 years ago|reply
Maybe it gets better with practice, so I'll keep trying a bit more, but currently, count me as unimpressed:
1 - About code inspection. Well, I fully understand that inspecting Python code is hard, and any tool will have either false positives, or false negatives. But PyCharm gets false positives to the extreme, it complains about not resolving Python standard functions (like open), and it can't find some libraries at my virtualenv. It's so full of false positives that I'm not sure I'll be able to keep reading them - I normaly can't stand code with warnings, but in PyCharm there is no other way.
2 - About formating. It fully enforces PEP8, the most completely enforcement I've seen on any tool (no I didn't try the emacs el for that). That's a good thing if there is an option to turn it off, what I don't know, because I didn't search for it yet.
3 - About refactoring. No, PyCharm, I don't want Django to change because I changed a function name in my code. Maybe there is a way to tell it not to touch some dirs, but the default settings makes PyCharm much less reliable and slower than grepping the old name and replacing it by hand. I'll try to find such setting when I get out of work today, but it's making the case of PyCharm being easier to setup way less appealing.
[+] [-] rpmartz|11 years ago|reply
[+] [-] mckoss|11 years ago|reply
If they had a sane way to keep IDE files in a single top level project directory, I would be much happier.
[+] [-] ericcholis|11 years ago|reply
https://github.com/github/gitignore/blob/master/Global/JetBr...
[+] [-] chojeen|11 years ago|reply
Brilliant way of describing the IDE metadata files, BTW. I got a nice chuckle from that.
[+] [-] infecto|11 years ago|reply
gitignore .idea/ and you should have no trouble. What other type of files are you finding scattered in the project?
[+] [-] Walkman|11 years ago|reply
[+] [-] grandinj|11 years ago|reply
[+] [-] msluyter|11 years ago|reply
[+] [-] filippovd20|11 years ago|reply
[+] [-] ColinCera|11 years ago|reply
I'm a fan of JetBrains and I own PyCharm and WebStorm, but I don't want this to become a trend...
[+] [-] nl|11 years ago|reply
I do mostly Java, and wow I never realized how much I'd miss that until it was gone!
[+] [-] farresito|11 years ago|reply
[+] [-] chojeen|11 years ago|reply
[+] [-] benblu|11 years ago|reply
[+] [-] collyw|11 years ago|reply
[+] [-] Siecje|11 years ago|reply
I would like 2 spaces for JavaScript and HTML but 4 for Python.
[+] [-] vially|11 years ago|reply
[+] [-] dyadic|11 years ago|reply
Or, it's certainly possible to have custom formatting rules in IntelliJ and AppCode and I assume that PyCharm is the same.