ActiveState releases Komodo for GNU/Linux

TorinEdge writes "ActiveState has finally released (as in out of Beta) their Komodo IDE for the GNU/Linux platform! Komodo is an integrated dev environment for open source languages. It provides colour-coded editing (and "code-folding" for collapsing sections of code), debugging etc... It's optimized for Perl, Python, PHP, Tcl, and XSLT. Includes the RxToolkit for testing/checking your regular expressions; a godsend. Get it while it's hot!"

Comments

Re:What the ??!?

[rickms]

Just becase it's not free means that /. can't talk about it? Last I checked it was "News for Nerds", not "News about open-souce/Free Softward for Nerds" Comon... Rick

Why oh why

[GusherJizmac]

How many times in the history of mankind must syntax highlighting and folding be implemented in a code editor? Why can't all these IDE makers just use Vim (or even Emacs, or how about either?) as their code editor? I mean, emacs and vim are about a zillion times more powerful and feature-packed than any crappy IDE editor. What's the deal? It doesn't seem hard to just have the IDE contain a curses or terminal emulation layer where you can run a real editor, instead of these crappy knock-offs. It also would seem to be MUCH easier to do that rewriting an editor from scratch, yet again. Ugh.

Re:Why oh why

[GusherJizmac]

The point is, why don't they use those editors as their basis for their integrated editor? Why re-invent the wheel so many times? Clearly, people won't use an IDE because of the superior text/code editing abilities; vim and emacs beat them all hands down. I understand they may not want to release their product as open-source and that may be a factor, but I guess it's a larger issue. Look at freshmeat and see how many IDEs there are, and how many "programmer's editors" there are. Seems like an awful waste of time and talent.

Re:Why oh why

[__past__]

Why can't all these IDE makers just use Vim (or even Emacs, or how about either?) as their code editor?

If they would use Emacs, how much of an IDE would they have to build themselves? Emacs already does about everything modern IDEs do, it just is less color- and more powerful.

Re:Why oh why

[Twirlip of the Mists]

The point is, why don't they use those editors as their basis for their integrated editor? Why re-invent the wheel so many times?

Excellent question. The answer is: the GPL.

Emacs is released under the GPL. VIM is released under a license that is, for all intents and purposes, just like the GPL. (They call it "GPL-compatible.") The restrictions placed on developers by the GPL make it impossible for a commercial concern to use either of these programs, or components of them, as part of an IDE.

If FooCorp, or whomever, wanted to develop an IDE using the VIM editor as the embedded source code editor and glomming on IDE features, they would be required, under the VIM license, to release the source code for their IDE. Nobody in his right mind would want to do that, so as a result every IDE has to have its own editor.

If they released the VIM editor under the BSD license, this problem would not exist.

Re:Why oh why

[GusherJizmac]

Well, there's a boatload of open-source IDEs that I could direct this question to, but moreover, wouldn't it be in their best interest to make it very easy to integrate their tool with any other editor? Surely it wouldn't create a problem, license-wise, to have their tool integrate with any binary version of vim or emacs, right? I would actually consider an IDE that did that, and I think a lot of other people would, too.

Then, their product competes on it's merits of integrating the development process, and not on it's half-assed reimplementation of the same things that have been around for years for free in better editors.

Of course, one could argue, I guess, that this has already happened, and it's called UNIX.

Re:Why oh why

[Twirlip of the Mists]

wouldn't it be in their best interest to make it very easy to integrate their tool with any other editor?

Look at, let's say, the top 10 IDEs available. How many of them include support for full integration with external editors? None? Then you have your answer. No, it is not in their best interest. If it were, they'd be doing it.

Surely it wouldn't create a problem, license-wise, to have their tool integrate with any binary version of vim or emacs, right?

Can't be done. If you're using a binary version of Editor X, then you're not integrated with it. At best, you're using system() calls to fire off an instance of the editor for each source file in the project, which is not the same thing at all.

Then, their product competes on it's merits of integrating the development process

Except, as I pointed out, that you're not actually integrating anything at that point.

Try out a good IDE for a change, like Visual Studio or (much better) Project Builder. It'll change your opinions.

Re:Why oh why

[GusherJizmac]

Can't be done. If you're using a binary version of Editor X, then you're not integrated with it. At best, you're using system() calls to fire off an instance of the editor for each source file in the project, which is not the same thing at all.
Not true. Not sure about emacs, but vim can be run in client/server mode, and you can issue commands to a running instance to basically do anything in the editor you want. A rudimentary version of this is already possible in Visual Studio.

Visual Studio is passable, only because the editor is fairly configurable and it has decent integrated help. I've used Project Builder for WebObjects and on Mac OS X and it is horrible, IMO. It has a very counterintuitive interface, poorly configurable editor, it's slow as death (despite the fact that it's been in existence for many years), and the GUI builder's drag&drop/wiring thing is very difficult to use, compared to what else is out there. I feel sorry for anyone using it that doesn't have a Dual 1Ghz G4 and 1Gig of memory.

Re:Why oh why

[Dahan]

Can't be done. If you're using a binary version of Editor X, then you're not integrated with it. At best, you're using system() calls to fire off an instance of the editor for each source file in the project, which is not the same thing at all.

Well if you can make it look like the same thing, isn't that good enough? Assuming something Unixy, fork()/exec() the editor with stdin/stdout/stderr hooked up to a pty. Have the IDE communicate with the editor through the pty and interpret the editor's output (including any VT100 or whatever display control commands), displaying the output in the IDE's own window. Voilà, integration of any tty-compatible editor. There might be a bit of a problem with mouse support, such as having a working scrollbar, but I guess the IDE could have a list of supported editors and send the appropriate commands to scroll the editor when the scrollbar is clicked. For editors the IDE doesn't know about, you wouldn't have a scrollbar on your editing window, and would have to use the keyboard to scroll around, but when you're coding, scrolling with the keyboard is often more convenient than using the mouse anyways :)

Eclipse?

[variable]

Most of these languages are also supported (or in the process of being supported) in Eclipse. Which is open-source and cross platform and easy to extend.

Re:Eclipse?

[fava]

Actually from reviewing the Eclipse website it seems that none of these languages are currently supported nor does there seem to be any projects aimed at any of these languages. I will admit there could be some discussion on the mailing lists, I did not check those.

Eclipse seems to be mostly concerned with Java and a little bit of C/C++ and cobol.

Re:Eclipse?

[variable]

You are right, nothing that you download with Eclipse nor part of the org.eclipse classes. However, there are many projects on the go adding in language support for other languages like C#, Ruby, Eiffel, etc.

The C/C++ is actually quite an active project with many companies (QNX, Rational, RedHat) participating to make a top-tier C/C++ IDE environment.

What I really need is...

[cornice]

What I really need is an IDE that helps me manage projects but has support for xemacs, gvim or whatever happens to be the best editor today. I know there is another post like this labeled as flaim bait but I think that recreating the editor is a mistake. That's one area where there are fast, mature, time tested, extensible options. We need more IDEs that recognize this and solve the project management issues that exist rather than waste time on the parts that are already done right.

Re:What I really need is...

[spencerogden]

Like the KVim part in KDevelop? Imean if all you want is project management and compile support, then CVS and make are there.

Re:pricing

[ilofwyr]

Actually, that pricing/licensing description is quite incorrect. The correct wording (copied directly from the site) is:

2.0 Professional Edition $295
For commercial usage. Includes Source Code Control Integration, Visual Package Manager, and ActiveState GUI Builder

2.0 Personal Edition $29.95
For non-commercial and educational usage only.

Anonymous Coward here clearly has a nack for fiction.

Free IDE

[prisonernumber7]

On my never ending search to get to know different things, I stumbled upon the Anjuta IDE.

Trying Anjuta was my first attempt at using an IDE since a long time -- and frankly, although Anjuta indeed seems to have a lot of features and matter of factly impressed me by unseen things such as mentioned "code folding" it was not my cup of tea, but I believe that was a personal matter. :)

I gave the IDE a try approximately two or three months ago and it seemed to have quite a bit of bugs. Still, if you are developing from within a free operating system and looking for an IDE you might want give it a try before you shell out the bucks for the above mentioned software.

Re:pricing

[Kidbro]

Did anyone else realize that you need to buy the commercial ($300) version to develop open-source applications?

Nope. But then again, I only looked at their Pricing and licensing page. Care to give us a link to the the page where you got your info?

A Review of Komodo 2.0 by Simon Cozens

[alfaiomega]

There's a Review of Komodo 2.0 (printer/human friendly version) by Simon Cozens on Perl.com from October 09, 2002:

"Every time I get a new copy of ActiveState's Komodo IDE, I do a review that invariably ends "this would be the perfect IDE for me if I were the sort of person who used IDEs". And every time I get the next release, I get closer to being persuaded I should be using IDEs. With Komodo 2.0, ActiveState is getting very, very close to persuading me - but it's not there yet. Let's see what it got right and got wrong this time. (...)"

Read the whole thing, it's more objective than the ActiveState's review. I personally don't use IDEs at all, like Simon Cozens, and I find his review much more interesting from my point of view. If I am to ever start using IDEs I have to know not if it's good for an IDE, but if it's good for people who prefered using Emacs/vi so far.

Re:A Review of Komodo 2.0 by Simon Cozens

[AndyElf]

Speed of Komodo has always been the thing that irritated me most. It is simply dog slow -- they probably are still using not-so-well-optimized chunks of Mozilla code.

Another gripe is that last few times I tried, I could not install the thing on my Windows machine -- .msi installer would simply not run with some bogus "script could not be executed" error.