Slashdot Mirror

Activestate's Komodo has an excellent interface, excellent color coding as well as the ability to debug XSLT files, if you are so inclined. It also has an excellent regular expression builder (handy if you ever delve into PERL), it doesn't do too bad with TCL, either.

It works with windows or Linux and is available on a trial, educational, or professional license basis.

I've been using it for about 3 months and it's been rock solid so far. Better than anything else I've used.

btw, activestate's developer network is an excellent resource, too.

My first response to this was "WTF? Komodo is build on Mozilla, how are they selling it as a commercial app?".. I did some digging, and here are the relative parts of the MPL (available here ):

3.2. Availability of Source Code.
Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable version available; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party.

If you look at the very bottom of this page you'll find the link to download their patches against Mozilla 0.9.5. Good luck integrating them yourself with no documentation though.

Shayne

Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.

Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.

Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:

Perl attempts to be all things to all people and ends up being second-rate at everything. Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scripting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become. It has been said that you only need to know 10% of Perl to do 90% of your job. It should be added that anyone trying you utilize 90% of Perl would have time enough to do 10% of their job.

Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should seize this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.

Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.

Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.

Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:

Perl attempts to be all things to all people and ends up being second-rate at everything. Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scripting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become. It has been said that you only need to know 10% of Perl to do 90% of your job. It should be added that anyone trying you utilize 90% of Perl would have time enough to do 10% of their job.

Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should seize this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.

If it works well, then you can read MS docs to figure out what kind of COM interfaces are exposed by Exchange, and work from there.

I don't know if you are making a joke, but somebody already is.

I don't know if you are making a joke, but somebody already is.

• Conform to standards wherever possible.
• Release your API's and your reference, and don't hinder anyone from using your product in the way they see fit.

An example is the Komodo IDE by ActiveState, which uses XUL.

XUL is the next generation browser application platform. Simply speaking, the Mozilla team chose an approach very similiar to JAVA to come closer to a platform independent graphical user interface:

• implement a set of base compenents on the most popular platforms (Win32, Mac, UNIX, ..), that render your JAVA specific widgets in terms of the native GUI.
• implement your applications in your JAVA language
• compile application
• distribute JAVA binaries

XUL goes one step farther, as there is no compilation step.

The XUL application implementation language is a XML language that together with cascading style sheets and JavaScript glue will yield an application one starts in the browser by opening the .xul document.

A possible advantage of XUL might become the relative ease of application development, change and distribution.

Possible problems will be similiar to the ones known from JAVA. The qualitiy of XUL applications will stand and fall with the quality of the XUL implementation for a specific platform, which right now means the quality of its Mozilla or Netscape implementation.

Of course, compared to JAVA, which has underwent several larger development cycles and now features mighty libraries, XUL is a bleeding edge technology at its beginnings.

However it is still possible to make direct use of the various Mozilla widgets as well from C++.

While we all probably get junk mail in our 'snail' mailboxes, it takes no time on our part to sort through it.

Nope, I only get junk mail from a few wierd companies (AT&T), and when the mailman just gets lazy and shoves the general stack of daily junk into my box instead of the apartment next to mine.

To really reduce the junk mail you get (in the U.S.A., anyways), follow the instructions at junkbusters.com-- costs some money to send all the letters out ($5 in postage?), but the amount of general crap I receive in the mail went down dramatically after doing so.

On the email side of things, yes, procmail is nifty, though a better place for such filters is in the MTA (currently done with heavy-handed arbitrary blackhole lists), so that mail can be rejected as spam before even coming near the local delivery agent. You can do this in a proper user-specified fashion with PerlMX, however, that's $$$...

Have a really good day, Mr Katz.

With Java being removed from Windows XP, and AOL poised to start including a Mozilla-based browser in their next version of Internet software, Mozilla could very well become the cross-platform development environment of choice. Keep an eye out for more Mozilla-based projects like this to come.

Rather than seek out organizations or individuals related to the project itself, it's sometimes beneficial to find an implementation company (a la RedHat's model). They usually base their business on providing a stable release of an open source product, with support and such as a fee-based product.

For instance, I would go to ActiveState if I was planning to roll out a large Perl installation. They have core Perl developers on staff, and they already have release cycles and customer service in place. I'm sure there are similar companies for any major open source project.

Even if they're providing no more than the software itself, they still provide a single point of contact for technical questions and software updates. That in itself is usually worth the fees they charge.

~chris

They are *separating* smaller developers from larger ones. They're trying to keep large free software projects off of Windows. (or maybe they aren't *trying* but that's the effect)

Compare writing and debugging a medium scale project with an IDE to without. Big difference. Although Komodo looks like it might be better than DevStudio, and I think it's free for non-commercial use... (hard to tell from their website)

Actually, TclHTTPD (or AOL server, if you prefer so) is faster and easier to maintain for both platforms (UNIX and Windows). It can be found at http://tcl.activestate.com/software/tclhttpd/

Here are just a few of the tools that are considered traditionally in UNIX/Linux/BSD territory that are available for Win32. In all actuality, there's enough out there to get as much of Linux running on Win32 as Win32 running under WINE.
XFree86: http://sources.redhat.com/cygwin/xfree/
KDE: http://kde-cygwin.sourceforge.net/
GTK/PHP/Libglade: http://gtk.php.net/download.php

Apache: http://www.apache.org
PHP: http://www.php.net
PHPTriad: http://www.phpgeek.com
Perl: http://www.activestate.com
Ruby: http://www.pragmaticprogrammer.com/ruby/downloads/ ruby-install.html
Python: http://www.python.org/download/download_windows.ht ml
TCL/TK: http://www.pconline.com/%7Eerc/tclwin.htm

MySQL: http://www.mysql.com
MySQL ODBC: http://www.mysql.com/downloads/api-myodbc.html
PostgreSQL: Included in cygwin (only works on NT)

ATT's U/WIN* Unix for Windows: http://www.research.att.com/sw/tools/uwin/
Cygwin: http://sourceware.cygnus.com/cygwin/
DJGPP: http://www.delorie.com/djgpp/
Native UNIX command-line binaries: http://www.wzw.tu-muenchen.de/~syring/win32/UnxUti ls.html

vi: http://www.cs.vu.nl/~tmgil/vi.html
Emacs: http://www.cs.washington.edu/homes/voelker/ntemacs .html
OpenOffice: http://www.openoffice.org

Mozilla: http://www.mozilla.org
GIMP: http://user.sgic.fi/~tml/gimp/win32/

List of GNU software for Windows: http://www.gnusoftware.com/
And so on . . .

There's a list over at DMOZ.org of a lot of this.

What is PerlScript?
PerlScript is an ActiveX scripting engine that allows you to use Perl with any ActiveX scripting host. At this time, ActiveX scripting hosts include:

• Internet Information Server 3.0/4.0
• 
  Peer Web Services 3.0/4.0
  Microsoft Internet Explorer 4.0x
  Windows Scripting Host
  

... OK, it's ActiveX and it's evil...

BTW, there has been Tcl/Tk browser plug-in for ages. If Tcl tickles your fancy, that is.

Internet Explorer can use any language supported by Windows ActiveScripting, which include VBScript, JScript, and even Perl and Python (with ActivePerl/ActivePython from ActiveState).

But the client needs to have these installed, and they are not as secure as JavaScript because they give access to the whole set of Perl's and Python's functions, allowing things like file i/o on the client's disk (which VBScript also allows if i remember correcly).

So they should never be enabled in a web browser, because of the security holes it opens.

Basically, there's a dependence flow, where each cell on a spreadsheet is referenced to cells on previous sheets.

The Free Software Foundation has a dependence flow manager that can track dependencies between objects in a filesystem and can call programs to re-create files when the files they depend on have changed. This tool is called GNU Make and comes with most distributions of a GNU system or a GCC development environment.

I'd actually love to move to a browser interface

And you can with server-side Ruby, Python, Java, or Perl. Simply port your simulation to a compiled or interpreted language, create a makefile to re-run the simulation whenever the input changes, and write CGI programs to coordinate the whole mess into a Web application. If the whole thing runs on one box (as is most often the case for a flat-file app), and that box must run Windows, use the Win32 version of Apache HTTP Server, the MinGW GCC distribution (or Cygwin if your app is GPL compatible), and ActivePerl or ActivePython.

there's a company that's building yet another python compiler for the .NET framework

The company is ActiveState. Python for .NET (and Perl for .NET) is here.

there's a company that's building yet another python compiler for the .NET framework

The company is ActiveState. Python for .NET (and Perl for .NET) is here.

Komodo from Activestate is very "Visual Studio"-ish and supports PERL, Python, PHP, and a lot more.

You might look at Sun's Forte as well.

Actually, yes, I've been giving it a try too.
Well: it /rocks/.
What's funny is that Galeon points out both Mozilla's biggest strength and, IMHO, its biggest weakness. Its strength is a smart API, that you can use to embed Mozilla into applications. It's how Komodo works, for instance. If IE wasn't commingled (such a nice word... :)) into Windows as a widget control, you could probably replace the IE HTML engine with Mozilla's in that widget. It would be neat.
But Mozilla also has a feature that can count as a weakness: it has its own interface toolkit. It doesn't use Qt nor GTK nor anything of the like: it comes with its own thing. Unless I got it completely wrong, of course, which is also a possibility. :) The good thing is that it looks the same everywhere. The bad thing, well, is that it makes it a more bloated piece of code. Gaelon, on the other hand, uses the Mozilla rendering engine in a GTK browser; it could be what makes it noticeably faster than Mozilla, and it's most probably what makes it lighter.
But enough ranting! I use Konqueror, Mozilla, Gaelon or w3m, all four of them, depending on my mood, and I've never been so happy about the freedom of choice that comes with free(-speech) software! :)

When we moved from Solaris/Apache to Win2K/IIS, I moved all our old Perl/CGI stuff straight over without a hitch (although I did have to redo the sendmail stuff to use CDO).

When we moved from Solaris/Apache to Win2K/IIS, I moved all our old Perl/CGI stuff straight over without a hitch (although I did have to redo the sendmail stuff to use CDO).

When we moved from Solaris/Apache to Win2K/IIS, I moved all our old Perl/CGI stuff straight over without a hitch (although I did have to redo the sendmail stuff to use CDO).

However, if we can also link up diverse scripting environments with SOAP and XML-RPC, there's no reason to worry. Choice is key. Most non-Microsoft scripting languages will never run well inside Microsoft's environment. Make it easy for Perl programmers to participate in SOAP networks without leaving home. Same with Java, Python, Tcl, and everything else.

Focus on the protocols, that's what's important. As long as we invest in diversity, Microsoft can't control. Instead of a one-party-system, let's have an n-party-system. That's how we guarantee choice, eliminate lock-in, and maintain forward motion.

BTW, an interesting detail came out at the open source summit on Tuesday. Dick Hardt of ActiveState reports that Perl does not run well in Microsoft's environment. The problem is that Microsoft's virtual machine is designed to run C-like code, but Perl is not like that.

Now I know the solution, we need a DLL-based open scripting architecture, that allows environments to compile and run scripts and have them call back into the environment, much like the architecture we developed on the Mac in the early 90s. Back then it wasn't so interesting because scripting was still pretty small, it was just us and Apple. Ten years later there's been an explosion, and there's another way, beyond XML-RPC, that's needed to integrate. It can be a tough sell to each individual community, as XML-RPC is, because the benefit is that it makes it easy to bridge to other environments. Most communities tend not to see too well outside their borders. But the larger world wants choice. No matter how great your scripting environment, you will eventually meet someone you want to work with who works in a different environment.

What is this "perl"? I looked all over Microsoft's website and I couldn't find where to download it. Must only be available to beta testers.

Anyway, "MS-endorsed" version of Perl can be found from ActiveState. MS has been known to distribute that version with IIS. I've heard.

ActiveState takes care of the Windows side of the pond.
--

It's just not written by Microsoft.

ActiveState are bringing out their own version of ActivePython, a Python distro for Windows. And yes, it will be kept up to date. A Perl.net has already been released in numerous betas, and it rules. I've been writing GUI Perl applications is Visual Studio for a fair few months now. Very impressive.

For more info, visit their .NET site.

I'd love to write my perl code in a really snappy IDE that has a code folding, chromatic editor that offers command completion, the way Kylix does.

Have you tried Komodo?
--

The problem with the NC model is that it relies on a stable, secure, high-bandwidth connection that has 99.9999% uptime. Can anyone tell me of a network that meets these requirements?

The counter argument is that no computer has a 99.9999% uptime either and that any system can fail locally as well. The response to this argument lies in the idea of local control. If my hard drive fails and I have a report due tomorrow, I can choose to put in a new hard drive and could have myself up and running again relatively quickly. The NC model places those decisions and priorities in the locus of control of someone else. Who is to say that they have my best interests in mind? If you want an example, look at the DNS problems Microsoft had a while back. As a network consultant and support technician, I unfortunately have to spend hours digging through the sludge of Microsoft's technical papers and knowledgebase hoping to find answers to this new problem or that. For three days, during the DNS debacle (can anyone figure out why they didn't have an off-site DNS?!?!... The Road Ahead for sure!), people were out of luck when it came to getting access to those resources. Let me tell you, if the phone system of the US was down for three days, there would be congressional hearings and someone would probably be facing jail time. Now, I'm not saying that a company should be held responsible for its website being down for three days, but if that company was also providing "essential services" (as the .NET strategy is hoping companies will), then I believe that the level of accountability should rise in proportion to the critical nature of the services that are provided.

We have a scary future ahead of us my friends. But you guys already know that, don't you?

While you said you want to explore a different, cross-platform language, the examples you listed were all integrated development environments IDE, not languages. Indeed, ActiveState's Komodo IDE can actually be used to develop in many different languages:

Komodo recognizes multiple languages including JavaScript^(TM), HTML, Perl, PHP, Python, Tcl, XML, and XSLT

But, perhaps the real question is, what do you plan to do with this cross-platform language? Apart from being able to run on more than one platform, do you need:

• speed
• easy GUI development
• standardized database access
• standalone executables, interpreted scripts, browser-as-client, or server-side development

On the IDE side, what features are you looking for:

• syntax highlighting
• syntax completion
• auto-formatting
• debugging
• integrated help and reference info
• drag'n'drop GUI development
• code repository/version control
• IDE itself running on different platforms
• free (beer or philosophically) or proprietary

As with many problems in life, you need to refine your question before you're going to be able to come up with the right answer. Putting together a good set of requirements really helps when you're trying to solve a problem. And it helps other people provide intelligent commentary.

"[Netscape Prez Bankoff] confirmed that AOL has been testing 'Komodo' software, which would let AOL and CompuServe Internet services support multiple Web browsers, including Netscape, as well as perform various other functions."

I've gone through this situation in several discussions for mid- and large-scale operations. Your answer will somewhat depend on how much money, time, and work you want to put into this system, with the usual tradeoff of ( more dollars ) = ( less ( time + effort ) ).

For a free solution, I've found that a sendmail-based solution works quite nicely on Solaris. We ran some internal mailservers with a combination of sendmail for smtp, qpopper for pop3, apache and php for web access, and ActiveState PerlMx for mail filtering. There are many passable imapd programs that would fulfill your IMAP requirement, among other things, cyrus imapd

Don't be fooled, though; this took some elbow grease, and a little tweaking with sendmail and qpopper (mostly for the remote-administration bit; you don't want all of your customers in /etc/passwd on your server!)

If you'd prefer to just lay down a little cash to get a working solution out the door, Openwave has a very reasonable email platform or two. It seems like it supports everything you're looking for, above.

Also, don't forget that Sendmail, Inc. creates some very sophisticated sendmail-based products; it looks like Advanced Message Server may have all of the solutions you're looking for.

However, since I started using komodo, which was built on top of Mozilla I realized Mozilla has a really great potential for writing cross platform applications. Check it out. Also, if you primarily write server-side web apps, as I do, you can use browser components as the shell of your app, say to handle files and printing, while the bulk of your application runs on your web server.

I'd also have to give Mozilla the award for being the single best source of sample code out there in the open source world. Because everything is in there, there is a very good chance that you can learn about what you are trying to do by looking at the code. Hopefully, universities will pick up on this and use Mozilla to help teach CS. That would lead to more Mozilla users(and coders).

Additionally, having a complete, open-source browser suite forces MS to keep on their toes and release a high-quality, standards compliant browser, while at the same time preventing them from having a total monopoly on the browser market.

Yes, I'd have to say that Mozilla matters.

Good Lordy, whatever happened to the day when the whole AOL thing fit on one little floppy that was easily removed from the magazine shrink-wrap?

But Steppenwolf will apparently not include Komodo, AOL's new software currently in alpha testing

I trust they're not referring to Activestate's Komodo IDE, and that Komodo is merely a project name. It would be a shame to have one Microsoft partner sue another.
--

You're not comparing apples with apples here. You're comparing CGI with persistent interpreter. You can write CGI apps with VB and they'd be just as slow as Perl. On the other hand, you can use a persistent perl interpreter (mod_perl for Apache or PerlEx for IIS) and achieve speeds at least as fast as a VB dll. (OK, perl enthusiasts, I know mod_perl has benchmarked faster, but not so much as to be statistically significant)

This site, among many other large sites, can handle all its traffic quickly because of mod_perl.

-bp

But hey - at least AOL is planning to stop using Internet Explorer and instead use their own product, Codename: Komodo/AOL 7.0 (no relation to ActiveState's Mozilla IDE). They may even decide to release an 'official' Linux product at the same time.

I think this is good news for everybody.

Just in case you still don't believe me, read what Tim Bray, one of the co-authors of XML has to say about it.

You're talking about NAMESPACES!!! Not DTDs.

Don't believe me? Read it from the author of the XML spec. See also my own posts in that thread.

Now slashdot moderators, please read some damned XML books before moderating crap like the above up. I recommend XML in a Nutshell, which I was a tech editor for.

Regardless of whether or not people use Mozilla as a browser, it's an excellent idea for distros to ship it. The reason? Mozilla is an application development framework. I may prefer Lynx to Mozilla-the-browser (or any other GUI-based browser...), but that doesn't mean that I'll never want to run Komodo or any of the interesting bits being developed on top of Mozilla at mozdev. Shipping a copy of Mozilla with a distro allows the end users to take advantage of mozilla-based XP apps, regardless of whether they ever *touch* Seamonkey.

KomodoAt Active State.

KomodoAt Active State.

What an incredibly ignorant statement.

Perl 5.6.1 on Windows platforms is currently in beta and should be available soon from ActiveState.

In the future, you should only comment on subjects you are actively educated in.

I have learnt Perl but haven't got around to getting hooked to it. My freinds all seem to be quite happy to be using ASP. Can a perl buff outline the main advantages or is it just the peer group effect?

Oh, and you can use Perl for ASP, just go to http://www.activestate.com

Personally, I believe emacs is still the best choice of an editor, IDE, and all the other stuff you need in this situation.

All your event are belong to us.

You can already run Apache / PHP on windows. You can even run Perl, Python, and MySQL!

You can already run Apache / PHP on windows. You can even run Perl, Python, and MySQL!

• possibly because (speaking for myself) i'm more productive in Linux with things like tab completion, xterms [it is a windowing environ, just run a lot of whatever shell you like], and perl...