Not a big fan of Windows C++ IDEs.... well I'm not a big fan of Windows, I'm not a big fan of IDEs and I don't particularly like C++ either. As far as I'm concerned, if you really need a C++ IDE for Windows you should have started using CodeBlocks or Eclipse. However, if you really want to stick with Dev-C++, at least grab this new version.
The importance of using a modern C++ compiler should not be overlooked.
Orwell Dev-C++: Dev-C++ 5.2.0.3 Released: Time for another pile of bug fixes. I've also added a few features, like an updated set of built in compiler options and full file path hint...
Showing posts with label IDE. Show all posts
Showing posts with label IDE. Show all posts
Saturday, July 28, 2012
Tuesday, August 2, 2011
BBEdit 10 is out
Essentially that is the new. That and the fact that eventually they dropped the price to reasonable levels (39 $, IIRC). Unfortunately, the upgrade from older versions is also 39 $ (so I just bought a new serial).
The real question is why I keep buying BBEdit. I suppose I'm nostalgic about the old MacOS. It is a good editor, nothing to say that. I find it excellent with HTML and also has a nice PostgreSQL mode (not just SQL, it supports PosgreSQL dialect). The syntax highlighted grep searches (that is to say, regular expressions in fact, not grep) is another nice feature.
Other nice features are the possibility to customize the different modes (e.g., Python tab 4 spaces, auto-expand tab -- that is to say that tabs are not written in the source). Nothing other editors do not have, still, it is quite easy to customize. A couple of nice features is the fact that trailing whitespace stripping and trailing newline addition can be enabled. Once again, nothing vim and Emacs do not have, but easy to setup and somewhat missing in other "lesser" editors.
Among the addition of version 10, BBEdit has improved project management features, support for different color schemes (before that, a hack had to be used -- and the hack is forward compatible: color schemes for that can be used for the official feature).
While when I first tried TextMate I thought the next big thing after Emacs and vim was there, BBEdit is just a solid MacOS X editor. I like the fact that many a program is aware of BBEdit and lets me use it to edit stuff (and that is usually an improvement over the built-in editor). I will not stop using Emacs or vim for my serious editing, but BBEdit is a nice tool to have around.
Thursday, February 10, 2011
IntelliJ 10.0.2: LaClojure broken
Here on OS X IntelliJ 10.0.2 update seems to break LaClojure plugin.
I am trying to investigate further.
I am trying to investigate further.
Saturday, January 8, 2011
PyCharm autocompletion
I have not yet figured out how it works and to what extent. In fact I have used it just for one file projects, so I don't really know whether it works across file boundaries. But look at this:
Fairly impressive, huh? There are no user provided type hints. Unfortunately enough, it does not look like the x = f(B()) statement is taken into account: simply the IDE guesses that since I have a class named B a parameter named b may be an instance of b and suggests B.bar as a possible completion. Ok, this is possibly overly optimistic, however, in my experience I've found quite often that this is useful (at least, better than nothing).
In the following screen-shot, I demonstrate how the good old assert isinstance trick we used in WingIDE still works:
Still, I'm not extremely happy with this strategy as it mimics too much static typing. In fact if I wanted to specify types for my parameters, I'd use Java. No doubt that writing
is faster than:
I admit... I don't really like the trick. However, sometimes it is not overly restrictive do such typechecking: e.g., numbers are expected to inherit from the proper abstract base classes and when using libraries such as numpy, it is rather safe to assume that some parameters are numpy arrays.
The point where this strategy fails blatantly is with return types. Having to add type assertions to function return types is horrible, basically infeasible. Here Pycharm is smart and relies on a convention from the standard library, consider for example:
We can see that here we somewhat suggest (in the documentation) the return type of the function. Well, since they implemented that for standard library code, they are letting developers using it as well. PyCharm developers also promised to add similar conventions based on other standards (e.g., Sphynx)
Unfortunately the types of the input parameters are not considered.
Fairly impressive, huh? There are no user provided type hints. Unfortunately enough, it does not look like the x = f(B()) statement is taken into account: simply the IDE guesses that since I have a class named B a parameter named b may be an instance of b and suggests B.bar as a possible completion. Ok, this is possibly overly optimistic, however, in my experience I've found quite often that this is useful (at least, better than nothing).
In the following screen-shot, I demonstrate how the good old assert isinstance trick we used in WingIDE still works:
Still, I'm not extremely happy with this strategy as it mimics too much static typing. In fact if I wanted to specify types for my parameters, I'd use Java. No doubt that writing
bool f(B x) { }is faster than:
def f(x):
assert isinstance(x, B)I admit... I don't really like the trick. However, sometimes it is not overly restrictive do such typechecking: e.g., numbers are expected to inherit from the proper abstract base classes and when using libraries such as numpy, it is rather safe to assume that some parameters are numpy arrays.
The point where this strategy fails blatantly is with return types. Having to add type assertions to function return types is horrible, basically infeasible. Here Pycharm is smart and relies on a convention from the standard library, consider for example:
vars(...)
vars([object]) -> dictionary
Without arguments, equivalent to locals().
With an argument, equivalent to object.__dict__.
We can see that here we somewhat suggest (in the documentation) the return type of the function. Well, since they implemented that for standard library code, they are letting developers using it as well. PyCharm developers also promised to add similar conventions based on other standards (e.g., Sphynx)
Unfortunately the types of the input parameters are not considered.
Thursday, December 30, 2010
IntelliJ 10 and PyCharm
So now I'm downloading IntelliJ 10. I already bought the upgrade, without even trying it. I am a very happy IntelliJ 9 user, the upgrade price is reasonable (especially because I qualify for academic discounts).
Moreover, I tried Pycharm and startup times have improved greatly. And IntelliJ is also very fast, almost comparable with some not too lightweight editors. I think I can live without many of the improvements they did to the X version of IntelliJ, however faster startup + mercurial + github integration for me are worth the price. And then there is the question of Python and Ruby plugins, which alone can make the difference.
If the Python plugin is as good as PyCharm (and it should) then I can do without upgrading WingIDE. WingIDE is still GTK (which bugs me a lot). And it is a nice IDE, I love it. However, it lacks refactoring. Ok, most refactoring in Python can't be done automatically, however simple local variables renames could (and both Eclipse and PyCharm do them).
Moreover, I tried Pycharm and startup times have improved greatly. And IntelliJ is also very fast, almost comparable with some not too lightweight editors. I think I can live without many of the improvements they did to the X version of IntelliJ, however faster startup + mercurial + github integration for me are worth the price. And then there is the question of Python and Ruby plugins, which alone can make the difference.
If the Python plugin is as good as PyCharm (and it should) then I can do without upgrading WingIDE. WingIDE is still GTK (which bugs me a lot). And it is a nice IDE, I love it. However, it lacks refactoring. Ok, most refactoring in Python can't be done automatically, however simple local variables renames could (and both Eclipse and PyCharm do them).
Saturday, December 25, 2010
Friday, November 19, 2010
WingIDE 4.x out!
WingIDE 4 beta is available. I'm trying it right now.
Unfortunately I have not an active Django project to test the IDE.
Unfortunately I have not an active Django project to test the IDE.
Powered by ScribeFire.
Saturday, November 13, 2010
IntelliJ Ruby Plugin
As I promised... more stuff on Ruby! This is about the installation.
OS X and Linux mostly have Ruby installed. However, you may want to install JRuby as well. On windows, I installed them both.
As a development environment, I choose IntelliJ, which I already use profitably for Java. Probably there are better choices (TextMate on OS X springs to mind, gvim/emacs). However, I want to see what can a "traditional IDE" (and a good one) offer for developing with a very dynamic language like Ruby. Unfortunately Python support does not seem as mature (besides, Ruby plugin is supported by IntelliJ developers and they also offer a Ruby IDE -- whose features should be offered by the Ruby plugin as well --).
As a side note, for Python I already bought WingIDE and I'm happy with that. However, since I don't plan to work with Ruby anytime soon, I only consider free (as free f*ckin' beer) solutions.
Here some screenshots from the setup of a Ruby project
So here some stuff on what the plugin can do. It's lots of interesting stuff.
However, I would like to point out that Ruby is a dynamic language; and the first things you are going to do are simple scripts to automate some repetitive task unless you are going to do Rails development. Since I'm not interested in Rails, I just point out that setting up a Rails environment seems very easy and well supported.
On the other hand I'm mostly interested in the "scripting" part, as it's the first you are going to meet if you don't do rails, like I said.
IRB is well supported. But I don't think its integration with the IDE is sufficient. I can open an IRB console and put Ruby commands inside. Good. A REPL is a very important part of dynamic languages development. I can also load a Ruby script directly in IRB (alt-shift-l -- btw, I suppose it will be a PITA on OS X).
However, since that command only 'requires' the file in IRB, successive invocations have no effect, unless you close and reopen IRB. It would be nice if modified versions of the script could be run without closing and opening IRB. It is something I would expect from a Ruby IDE. E.g., in TextMate it is very easy to do; and at the beginning it is just what you need.
The other options is creating a "runner". Which is easy, there is a menu entry that automagically creates one. This is good to run a script (but remember... you already created a project, and then create runners for every -- logically unrelated -- script in the project). This is a lot of useless work.
Things work slightly better if you just select the text and load (the selected text) in IRB. This way you can run the code more than once. Moreover, you can also have functions defined in IRB and than play with them. I think this is far more useful than 'requiring' stuff, especially because you can't reload.
Ok... the nice things another day. Maybe. However, the "environment" support seems really javish. Not happy. :(
OS X and Linux mostly have Ruby installed. However, you may want to install JRuby as well. On windows, I installed them both.
As a development environment, I choose IntelliJ, which I already use profitably for Java. Probably there are better choices (TextMate on OS X springs to mind, gvim/emacs). However, I want to see what can a "traditional IDE" (and a good one) offer for developing with a very dynamic language like Ruby. Unfortunately Python support does not seem as mature (besides, Ruby plugin is supported by IntelliJ developers and they also offer a Ruby IDE -- whose features should be offered by the Ruby plugin as well --).
As a side note, for Python I already bought WingIDE and I'm happy with that. However, since I don't plan to work with Ruby anytime soon, I only consider free (as free f*ckin' beer) solutions.
So here some stuff on what the plugin can do. It's lots of interesting stuff.
However, I would like to point out that Ruby is a dynamic language; and the first things you are going to do are simple scripts to automate some repetitive task unless you are going to do Rails development. Since I'm not interested in Rails, I just point out that setting up a Rails environment seems very easy and well supported.
On the other hand I'm mostly interested in the "scripting" part, as it's the first you are going to meet if you don't do rails, like I said.
IRB is well supported. But I don't think its integration with the IDE is sufficient. I can open an IRB console and put Ruby commands inside. Good. A REPL is a very important part of dynamic languages development. I can also load a Ruby script directly in IRB (alt-shift-l -- btw, I suppose it will be a PITA on OS X).
However, since that command only 'requires' the file in IRB, successive invocations have no effect, unless you close and reopen IRB. It would be nice if modified versions of the script could be run without closing and opening IRB. It is something I would expect from a Ruby IDE. E.g., in TextMate it is very easy to do; and at the beginning it is just what you need.
The other options is creating a "runner". Which is easy, there is a menu entry that automagically creates one. This is good to run a script (but remember... you already created a project, and then create runners for every -- logically unrelated -- script in the project). This is a lot of useless work.
Things work slightly better if you just select the text and load (the selected text) in IRB. This way you can run the code more than once. Moreover, you can also have functions defined in IRB and than play with them. I think this is far more useful than 'requiring' stuff, especially because you can't reload.
Ok... the nice things another day. Maybe. However, the "environment" support seems really javish. Not happy. :(
Thursday, October 28, 2010
jEdit 2
Seems I forgot to mention that it supports rectangular selections, vertical editing (meaning that it is possible to modify more lines with the same command).
I also found quite useful buffer local properties (written in the file itself). However, I feel that using a completely different standard from Emacs and vi is not a very good idea. Yeah, Java is a world on its own.
Unfortunately, it seems that development is going quite slow. Well, as a TextMate user I should not comment on this... ;)
Unfortunately IDEs like IntelliJ have so much more features that for Java development jEdit is not on par. On the other hand the startup times are very reasonable even on my netbook. I actually favor jEdit over other Windows evolved editors. I need more time in order to make a serious comparison with BBEdit (which I have used since the first versions) and TextMate (which is somehow even more intuitive).
I also found quite useful buffer local properties (written in the file itself). However, I feel that using a completely different standard from Emacs and vi is not a very good idea. Yeah, Java is a world on its own.
Unfortunately, it seems that development is going quite slow. Well, as a TextMate user I should not comment on this... ;)
Unfortunately IDEs like IntelliJ have so much more features that for Java development jEdit is not on par. On the other hand the startup times are very reasonable even on my netbook. I actually favor jEdit over other Windows evolved editors. I need more time in order to make a serious comparison with BBEdit (which I have used since the first versions) and TextMate (which is somehow even more intuitive).
Tuesday, October 5, 2010
Me and my IDE
Introduction
As customary in my articles on text editors and IDE I originally started this post with a self-condescending presentation of my skills and expertise. Then there have been some miscomprehension between chrome and blogger and the second part of the draft was not saved although blogger stated otherwise.
As a consequence I had the more self-condescending part and I lost the slightly more interesting one. I thought to do everybody a favor and delete that stuff. Now, a slightly less condescending paragraph on myself in order to motivate my point of view.
The past
I almost always used editors. Emacs, vim… and when on BBEdit and TextMate. Ah… light tools. Not only that: I was quite vocal in the IDE vs. Editor war (from the editor side, of course). And this can also be related to my choice of “freedom languages” (more on this on later posts, perhaps?).
But some weeks ago I realized that now, without noticing, I’m mostly using IDEs. How has that happened? The easy part to explain is the Java related one. Java greatly benefits from IDEs (or perhaps the widespread diffusion of IDEs has tampered the development of good language features?); in fact it is quite much harder to develop Java without an IDE, since the language is very verbose. On the other hand its restrictions and bounds make it quite easier to develop good and powerful tools. Of course I could use UltraEdit on Windows… but no luck with OS X and Linux (moreover, I had to pay that as well… and I preferred to buy IntelliJ).
Emacs has very nice modules to work with Java. On the other hand they have to be installed separately (and in my experience also slowed down normal operations). When I have to loose to much time configuring my editor, I usually try other solutions. That is why I used TextMate and BBEdit extensively… because they are almost already set-up. I also like vim, since has decent default setups for most situations.
For somewhat similar reasons, I bought WingIDE to work with Python. I could set up Emacs (or vim) to do that stuff, of course. Still, I had not much time, not motivation… and I bought the thing. I especially liked it because it worked equally well on single files and on large projects. It also had the best auto-completion for Python I ever tried, nice debugging features (I use them rarely, but when I do I love to have an easy to use environment, especially because I use them rarely and I tend to forget the tricks). In the pack there is also nice support for unit-testing (and that is a definite plus).
In the same time I worked extensively with C++. I mostly used editors (vim, because I especially like it with C/C++) and BBEdit because of its easy to set up “project management” features. BBEdit also has most the processing power of classical editors and that is nice. I quite enjoyed the best effort auto-completion it provided and ctags based stuff. Ok… still too much template metaprogramming (or simply correct and not basic use of templates) crippled smart “IDE like” features which I would have liked.
In other words, I sincerely craved for a nice C++ IDE. Perhaps I should try Java based IDEs with C++ as well… I may be surprised. Though I hate setting up projects in IDEs. Every IDE has its conventions and it is not always immediate how to work with a project that both needs “classical command line build interface” (which is something I’m not disposed – nor can I afford to – lose) and the IDE based build. Somewhat CMake eases the problem, but at the price of restricting myself to the supported IDEs.
Other languages I use, but I think that they account for less than 30% of my development time (and it is going to drop). And perhaps they could be moved to IDEs as well… as soon as I solve the “single file project problem” [or I simply give up my hopes with that].
This basically rules me out from editor flame-wars. Still, I believe that learning using IDEs is a terrible mistake… but is a modest position. Moreover, nowadays most editor proponents show you how to add all the IDE features to their editor of choice. So what’s the point? It’s not an Editor vs. IDE matter, it’s Emacs vs. Eclipse. And somewhat I believe Eclipse is going to become what Emacs was in the past years. And hopefully it is going to become faster like Emacs did…
The future
So what now? I’m lazy to the bone. And I’m quite new to the IDE world. I have my habits and I don’t really want to change them. And don’t believe the ones who tell that using IDEs is easier. Nor faster. It depends on your skill set. As I have my own requirements, some things may be slower with IDEs, at least until I figure out how to do them.
Which basically means that an IDE is not automatically more productive: it may be, provided that you know the tool. Yes, some have a very good learning curve (like WingIDE), others are very good, but need you to figure the way they work to exploit them fully (IntelliJ). Moreover, I still have to figure out how to develop Java projects easily built both with IDEs and with command line tools. Perhaps I should explore maven (which should be well integrated with all the main IDEs). After-all its racist on my part to spend time with cmake and auto-tools and not doing that for Java “based” projects.
Friday, September 17, 2010
It was better when it was worse (and the RAM...)
I usually deride this kind of arguments. I believe that although specific issue can worsen with time (a part from the obvious ones, such as oil shortage), most things somewhat improve. This is especially true in the computer science/math/science fields. We have better algorithms and better hardware.
My (not so) cheap netbook (which I am using to write this post) would have been a super-computer for the standards of when I started using a computer. I am not only talking about the 14h of autonomy (back then I
don't think the concept of laptop was widespread)... even my crappy Atom CPU would have been a wonder.
I'm usually not very sympathetic with the ones who actually complain about the resources needed to run modern applications (Mind child, when I was your age I had only 640 KB of RAM and I did this and that! -- which in turn must have been generated by some condescending unix hacker or some punched card freak comparing populous with pong when they were young).
In fact their argument is flawed in the sense that modern programs tend to do lots of stuff that their ancestors did not (which can be useless stuff, compare Word 2007 with Word 5.1 for Mac...). Moreover, modern computers have to do lots of stuff older computer did not have to do, operating systems are more complex, we expect stuff like plug and pray to work etc etc etc. It is like complaining why stuff cost less money many years ago: e.g., in "How Blue Can You Get" B.B. King sung about buying his woman a 10 dollar dinner, meant to be a very expensive one (while she thought it was just a snack). By today standards its the price of a fast food meal.
However, there are some constants. Vim is a fast editor. It does not matter: 10 year ago it was a fast editor. Today it is a fast editor (and improved as well the functionality). On the other hand, while Java as a platform improved a lot in the last fifteen years, Java IDEs are always heavyweight. I was there when Eclipse was just a beta, just something more than a proof of concept. And it was slow. And huge. And now... well, it improved, of course... but I have a quad-core MacPro and its barely passable. I let you wonder how it is on the EEE.
By the way, I don't want to criticize too much Eclipse (Idea is much in the same condition....). Yes, I hate the fact that you have to put everything in a workspace. I hate that it is so much project based that you basically have to create projects for everything. But I have to admit that those tools are necessary to make developing in Java bearable (and productive). Moreover, I quite like the idea... small core, everything is a plugin. Reminds me of Emacs; just with less configuration hassle (which is good). Perhaps in another 15 year it will run smoothly on the machines they will have; Emacs took a lot of time to run fluidly on home-computers afterall.
O yeah, and I have to absolutely buy some RAM because otherwise those IDEs are going to make me die of old age while I try to finish my tasks.
My (not so) cheap netbook (which I am using to write this post) would have been a super-computer for the standards of when I started using a computer. I am not only talking about the 14h of autonomy (back then I
don't think the concept of laptop was widespread)... even my crappy Atom CPU would have been a wonder.
I'm usually not very sympathetic with the ones who actually complain about the resources needed to run modern applications (Mind child, when I was your age I had only 640 KB of RAM and I did this and that! -- which in turn must have been generated by some condescending unix hacker or some punched card freak comparing populous with pong when they were young).
However, there are some constants. Vim is a fast editor. It does not matter: 10 year ago it was a fast editor. Today it is a fast editor (and improved as well the functionality). On the other hand, while Java as a platform improved a lot in the last fifteen years, Java IDEs are always heavyweight. I was there when Eclipse was just a beta, just something more than a proof of concept. And it was slow. And huge. And now... well, it improved, of course... but I have a quad-core MacPro and its barely passable. I let you wonder how it is on the EEE.
By the way, I don't want to criticize too much Eclipse (Idea is much in the same condition....). Yes, I hate the fact that you have to put everything in a workspace. I hate that it is so much project based that you basically have to create projects for everything. But I have to admit that those tools are necessary to make developing in Java bearable (and productive). Moreover, I quite like the idea... small core, everything is a plugin. Reminds me of Emacs; just with less configuration hassle (which is good). Perhaps in another 15 year it will run smoothly on the machines they will have; Emacs took a lot of time to run fluidly on home-computers afterall.
O yeah, and I have to absolutely buy some RAM because otherwise those IDEs are going to make me die of old age while I try to finish my tasks.
Subscribe to:
Posts (Atom)