Slashdot Mirror

In short anywhere which requires a web-oriented application (preferably cross-platform) would do very well to evaluate Mozilla as a development platform. I expect database and server-side apps will ship in due course with applications based on Mozilla to do form design and other administrative tasks in a cross-platform manner.

An example of this kind of thing would be Komodo, an IDE for Perl/Python/Tcl/ development.

I seem to recall that some use MSIE as a component architecture to develop generalized applications in much the same way, but I can't think of any examples of this right now.

Last time I checked you could load perl and php modules into your IIS server and run all that free code.

If a brain dead MCSE like me can do it so can you.

With windows the admin's education is limited to what M$ wants them to know. Thus severly handicapping their diagnostic abilities and their intuition.

Exactly, that's the whole point. Nobody of the poeple I know in person really knows Windows, and that includes our CS lab admins. Windows admins generally don't have any knowledge of the system, so they assume that there's nothing more to Windows than what they see, they can't tell the different Windows components apart (how many times did you use the term "Win32" to mean the whole system? well, it's wrong, Win32 is just a part, and not that unreplaceable either), basically they're slaves of the machine

Learning to code (and I remind you that Windows has one of the best Perl distributions around, and that Python does OLE) is a step in the right direction, but not enough. The Microsoft documentation for low level stuff is full of half truths, silences and plain lies

If you really want to get your hands dirty and actually learn something about Windows, have a look at ReactOS (shameless self-plug ;-): it's Windows, it's open source

With windows the admin's education is limited to what M$ wants them to know. Thus severly handicapping their diagnostic abilities and their intuition.

Exactly, that's the whole point. Nobody of the poeple I know in person really knows Windows, and that includes our CS lab admins. Windows admins generally don't have any knowledge of the system, so they assume that there's nothing more to Windows than what they see, they can't tell the different Windows components apart (how many times did you use the term "Win32" to mean the whole system? well, it's wrong, Win32 is just a part, and not that unreplaceable either), basically they're slaves of the machine

Learning to code (and I remind you that Windows has one of the best Perl distributions around, and that Python does OLE) is a step in the right direction, but not enough. The Microsoft documentation for low level stuff is full of half truths, silences and plain lies

If you really want to get your hands dirty and actually learn something about Windows, have a look at ReactOS (shameless self-plug ;-): it's Windows, it's open source

Well there is Perl.net...

So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.

The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.

There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.

What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.

Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.

In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).

So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.

Understanding the value of the freedom that OSS gives to users is a good thing.

The next step should be to understand that they are free to program their computers.

Most computer users are good candidates for casual programming, but they have no idea how easy it is to write simple scripts to fit the needs of their daily tasks.

Make sure you include ActiveState Batteries Included distribution of Tcl/Tk and make sure that your users run the demos. It can be a revelation for them. It was for me.

--

Understanding the value of the freedom that OSS gives to users is a good thing.

The next step should be to understand that they are free to program their computers.

Most computer users are good candidates for casual programming, but they have no idea how easy it is to write simple scripts to fit the needs of their daily tasks.

Make sure you include ActiveState Batteries Included distribution of Tcl/Tk and make sure that your users run the demos. It can be a revelation for them. It was for me.

--

I eagerly await the day when i can include GoBe Productive on this list, it is really 'suite' (if you will forgive the pun).

Wrong. There are many more at MozDev, as well as links to other Mozilla/XUL sites. Also Komodo , a commercial product was written with Mozilla. Activestate is actually making money with this.

O'reilly is taking this seriously. Maybe they know something you don't ;-)?

I don't really think it is about Netscape or AOL. The people who worked on the Mozilla project were not necessarily working on a specific corporate project; they were working on an open-source _idea_, which has some far-reaching benefits.

Yes, I agree that there needs to be more organization, documentation, and in general more attention paid to this project for it to catch on. That's why I am posting this. I hope more of you reading this will realize the potential that is here, and maybe contribute some...

As for it's usefulness as an application dev platform, at least one company has made a pretty nifty commercial product out of it. ActiveState's Komodo was written with the Mozilla framework. It is not a toy: it is actually a fairly capable programmer's IDE and text editor. I was surprised. Yes it is not as fast as a native C++ app, but it is definitely better than an IDE using Java for it's GUI engine (Zend, anyone?).

One great thing about this framework is that it doesn't try to be everything, like so many other frameworks out there. It concentrates on client-side UI, letting you do server-side, or even client-side logic in whatever language you want. Since it is XML-based, it is a natural for any language with XML/XSLT capabilities, which is just about every server-side scripting language these days.

Don't waste your time with anything less

I've not used perl2exe, but have used PerlApp in the Perl Dev Kit by ActiveState. It has worked very well for my needs: the client I currently work for installs perl on every machine, but it is the original pre-activestate version bundled in the NT Resource Kit. I need to use a more modern version for something, but they wouldn't agree to upgrade. Hence PerlApp.

Ideally, I would upgrade all the machines, and have a shared site library for additional modules, but if until then, or for sites where you can't rely on perl being everywhere, PerlApp and perl2exe do a good job...

I've not used perl2exe, but have used PerlApp in the Perl Dev Kit by ActiveState. It has worked very well for my needs: the client I currently work for installs perl on every machine, but it is the original pre-activestate version bundled in the NT Resource Kit. I need to use a more modern version for something, but they wouldn't agree to upgrade. Hence PerlApp.

Ideally, I would upgrade all the machines, and have a shared site library for additional modules, but if until then, or for sites where you can't rely on perl being everywhere, PerlApp and perl2exe do a good job...

Unfortunately, Perlapp does not seem to support BSD, and supports only x86 architecture RedHat and Debian Linux. See Perl Dev Kit

But, it is good to know PerlApp is available.

In an attempt to keep our software build process as uniform as possible, we keep most of our build tools under version control, including a perl script to do a basic product release. Obviously, putting ALL of perl under out VCS just so people could run the build script was abhorent. The answer was to use perl2exe (actually perlapp from the Active State PDK, but the behaviour is similar).

The script is not small, it performs alot of grunt work (version labeling, coping to archives etc) and I have NEVER had any problem with it. The executables it produces are perhaps a little big as they include everything necessary to run the script, and of course, startup time sufferers, but in terms of convenience, it can't be beat!

My two cents anyway.

Ian

PHP is a widely used embedded-in-html scripting language, but it is by no means the first. PHP started off as a templating language, but features were continually added which it caused it to grow beyond Server Side Includes. As such, PHP is not a well designed scripting language. If you separate your code into functions, it is extremely difficult to track down errors, because you only get the line that the error occured on and not the line that called that function.

PHP is definitely very easy to start programming dynamic web pages, but it is
increasingly problematic as your code base grows. If you primarily do web
design and just want a little dynamic content, PHP's shortcomings won't affect
you. However, web based applications will run into problems with PHP
repeatedly. Besides the problem where it copies objects out of an array
when you use a "foreach", you are also stuck remembering to put an amperstand
in front of every object so it gets passed or assigned by reference and not
value.
For example:
$x = $obj; # $x is a copy of $obj
$x = &$obj; # $x and $obj refer to the same object

Besides the overhead of copying large objects, it just creates one more
"gotcha" that you have to remember to avoid. It is not that good code can't
be written, but it is so much easier to write problematic code.

Other projects for embedding scripting into HTML:
http://pmz.sourceforge.net/

http://webware.sourceforge.net/
http://www.kryogenix.org/code/castalian/

http://www.zope.org/

http://aspn.activestate.com/ASPN/Reference/Produ ct s/PerlEx/Embedded.html

If you want proof you just have to look at mozdev.org. But by far the most compelling evidence of it's flexability is Komodo. It's an IDE that is completely built on top of mozilla, and I believe it is excelent. I have done some testing of it's PHP abilities and I would use it, if it wasn't so expensive.

. . . but so long as that little IE icon is sitting on the Windows boxes that ship, I'm not sure Mozilla will gain enough foothold to beat down Microsoft.

That won't matter. For folks making apps based on Mozilla, they'll ship and install their own customised (or not) mozilla anyway. Take a look at how Komodo, a shipping commercial app based on Mozilla gets installed. It installs a copy of Moz in it's own directory. Doesn't need to be pre-installed on the OS.

Very high level languages like Perl are far easier to program in than lower level languages like C and C++. No worries about memory allocation, array sizes, easy string manipluation and so on...

But of all the software currently running on your desktop, probably none of it is written in Perl. Why? Because Perl cannot be truly compiled. Sure, using perlcc I can convert a Perl program to C, but this is still experimental and doesn't really work well. Systems like Perl2Exe and Activestate's Perl Dev Kit that package the perl compiler and program into an executable are an improvement, but the resulting executables are large and have a high start-up time.

I'm sure there will be some people who don't consider this problem: i.e. leave Perl on the server-side and for general sysadmin tasks, as C and C++ have already got the desktop sewn up, but just think how much easier and faster it would be to develop a program like a GUI FTP client in Perl.

If there was a true Perl compiler, Perl could easily become the language of choice for many if not all GUI applications. Currently the only end-user targeted GUI app I have seen written in Perl is UploadAway--and even this is hardly aimed at a mainstream audience.

Tarballs, zips and diffs of all recent ActivePerls are here.

Neither Larry nor Guido are ActiveState employees. They are on the Technical Advisory Board. However, Sarathy (former Perl pumpking), myself (Tcl core release manager), David Ascher (Python notable) and many other notables are developers at ActiveState that do spend time contributing back to the core of our respective languages. It is, was, and will still be, part of our business.

Neither Larry nor Guido are ActiveState employees. They are on the Technical Advisory Board. However, Sarathy (former Perl pumpking), myself (Tcl core release manager), David Ascher (Python notable) and many other notables are developers at ActiveState that do spend time contributing back to the core of our respective languages. It is, was, and will still be, part of our business.

You can automate the whole sequence in Perl :
1. Search for windows, paste data : use Win32::SetupSup module - http://jenda.krynicky.cz/perl/
2. Inject code, attach to process for debugging : use wdeb module - http://www.wolf.vigelin.de/mathe/ntcont.html
3. Shatter windows : That is your part ! Happy hacking !
At least we use it for bad behaving install programs under Windows...

Komodo and WindIDE
Komodo is a full featured IDE. I've never personally used WingIDE but all the comments I've read about it have been very positive.

I'm amazed that there is nothing here about Tcl. I use everything from shell to C to Perl, but Tcl is consistenly one of my favorite languages. I don't know why it doesn't get more respect.

Anyway, Activestate is a great place to start, especially the cookbook. The weekly Tcl-URL is published at Dr Dobbs. The Tcl Developer Xchange also has a lot of resources. Most of the major Tcl developers hang out in comp.lang.tcl (probably one of the most civil newsgroups there is). Quick answers to questions are always available there.

I'm amazed that there is nothing here about Tcl. I use everything from shell to C to Perl, but Tcl is consistenly one of my favorite languages. I don't know why it doesn't get more respect.

Anyway, Activestate is a great place to start, especially the cookbook. The weekly Tcl-URL is published at Dr Dobbs. The Tcl Developer Xchange also has a lot of resources. Most of the major Tcl developers hang out in comp.lang.tcl (probably one of the most civil newsgroups there is). Quick answers to questions are always available there.

application server: here and here

IDE: here, here, here

Oops, you really mean, written in Perl? Sorry, apparently all those tried, failed.

Well, you might either shell out some bucks (USD 29.95 upwards) for ActiveState's Komodo - if your working with windows. Or you might just write a plug in for Eclipse or Sharpdevelop. Remember, your effort might be just what will help others as well.

But when will it support that most popular of languages, Perl? I hear talk, but I don't see action! Is there a serious effort for Perl? That'd rock, and I'd join 'em immediately!

ActiveState has a Perl IDE, called Komodo. It's NOT open source, but it has saved me a ton of time. They have a 21-day evaluation version, and if you want a home license it's $29.50 (under 30 bucks, the price point all software should strive for).

Check it out: Komodo . They have both Linux and Windows versions, and the IDE is based on Mozilla (and other open source technologies). It's kind of a shame they make it closed-source, but it's well worth the money. It also supports many other languages (Perl, Python, PHP, Ruby, Tcl, XML, XSLT and more -- 24 languages total).

Create a folder named "My Documents" in each server "home" directory (in Alice's and Bob's, etc)Then remove the My Documents folder in the root drive of the Win9x machines (and the c:\documents and settings\[username] directory on NT/2000). Now create a shortcut named "My Documents" in the place of the ones you just removed and have it point to the ones on the server. Make the shortcut "Read Only" (Right Click on the shortcut | choose Poperties | In the resulting dialog, choose the General tab and click the Read Only attribute). This should prevent any software from overwriting it.

The only rule that you have to make then is that users save everything to their "My Documents" folder which will actually force everything to be saved on the server in thier home directories on the server. This shouldn't be too difficult as most software for windows that creates stuff will set "My Documents" as the main save location anyway.

Now... run backups on the server. Relatively little effort is required.

The second, more cumbersome option is to write a script that is loaded onto each machine (grab a copy of Active State Perl for this... it is free). This script would connect to a remote server on a timed basis (once every couple of hours) and upload the contents of specific directories (that the staff would have to be told to use... My Documents comes to mind). You could also search the drive for specific extensions (based on the applications that you use) like .doc and .jpg and back those up for good measure (in case the users are not saving in the proper places). Then back up the server.

The drawback is that you would have to write the script and maintain it (a lot of effort on your part if you don't know Perl already... relatively little if you already know it at least a bit). The benefit is that you can possibly catch files stored in the wrong places.

The third option is to use a 3rd party product like IBM's Tivoli which uses a client side program to back up those systems in its backup routine. The upsides are easier managment and fine grained control of backups. The downsides are increased administration duties, expense, and finding a solution that works for every platform in your organization.

Good Luck.

Since you were thinking about using Perl I just wanted to make sure you knew about Visual Perl over at Activestate. Perl integrated into Visual Studio with full graphical debugger.

I'm not a perl guru so maybe this stuff already exists in other places but something like that would seem like a godsend if you do decide to go with perl.

i've tried a year ago to use an IDE called komodo
which can be used to at least highlight
your code text.
don't know what is its actual state
may be this link can help
http://www.activestate.com/Products/Komodo/

And I can say from experience that it works incredibly well. I've compiled a script which used 20,000 lines of code amongst the various modules I'd built, not including Perl/Tk and the many other CPAN modules I used, and out popped a nice binary which worked just as if run from Perl.

I develop on Linux, but I can use it to generate binaries for Windows users. It opens up a whole new audience for me. I develop quickly on the platform I am efficient on, and all the Windows users know is that they get something with a nice GUI that works as advertised and which was developed in half the time.

Needless to say, I recommend it highly.

I thought that Komodo was an integrated development environment built on Mozilla?

Active State Komodo.

Perl and flash can be integrated. The web site hasn't been updated in quite some time, but I can definitely see you using this module, together with something like Komodo, to cobble together something fairly user friendly.

Since database connectivity is vital to most web type apps these days, it might be good to demonstrate how to connect to SQL Server via VB, and then a simple example in PHP, Perl, and Python, all interacting with SQL server.

I've only used PHP with mssql, and here is a great reference point,
http://www.php.net/manual/en/ref.mssql.php

I am assuming the others are easy to get going, but I might be wrong.

The reason I mention multiple languages to a MS database as opposed to VB to MySQL is because:

1) .NET has flooded MS users/developers/managers with talk of multiple language support. While this is sometimes just implemented VB and C#, showing a common use (DB connectivity) of multiple languages to a SQL Server promotes the idea of true choice for developers and might open the eyes of some people that have been itching to use this or that language.

2) It promotes the theme you mentioned of working with the technologies under one framework, such as that of using MySQL and VB.

Don't forget activestate.

Simple.

Java is Java. You cannot plug any other language into the VM. The VM is Java, and Java is the VM. This means that you have all the good and bad associated with this language (more in a minute).

With .NET, and C#, C# is not .NET. The CLR allows you to plug in other languages. See ActiveState for details. You can plug in Perl, Python, Tcl, etc. And it works.

Why this is important (and it is): No one language is suitable to all tasks. Things which are trivially expressible in Perl or Python are non-trivial in Java. Things you might be better suited to use Fortran or C++ for (for speed or other reasons) are best left in those languages.

Java makes the fundamental mistake of attempting to be all things to all people. It really isnt as good as the hype surrounding it makes it out to be. And the hype has been shrill as of late.

What is Java to do? Well, it can shrivel up and go away, or adapt. This means that it would need to open its VM up to other languages. It is not C# vs Java that is the problem for Java, it is J2EE vs .NET. J2EE suffers from all the problems that Java suffers from (it has to). .NET has its own issues, but Mono is coming along nicely, and it runs nicely.

My best guess is Java will probably continue to win designs for another year or two as this technology (.NET and Mono) firm up. Microsoft is smart enough to know that Linux is its strongest and fastest growing threat in server-land, so if they can give the Linux world something they can deal with (by allowing Mono to continue and interoperate), they get to kill off J2EE by sucking the oxygen out of it.

And that is exactly what they are doing.

Java and J2EE are "dead languages/environments walking" for a few more years, unless they can open up the VM and interoperate like Mono, .NET, and the CLR allow them to. Check out the articles on perl.com about using Perl with the CLR and .NET.

Komodo is built on the Mozilla platform. Portions of Komodo were created using source code governed by the Netscape Public License (NPL) and the Mozilla Public License (MPL). The source code for the portions of Netscape 6 governed by the NPL and MPL is available from under those licenses. more info

Komodo 1.2 was built off the Mozilla 0.9.5 branch as of 16 October 2001. Mozilla patches for each Komodo release are available from the ActiveState download server.

If you're talking about Komodo from ActiveState, then they're using XUL (I don't think Gecko is used IMO)

If you're talking about Komodo from ActiveState, then they're using XUL (I don't think Gecko is used IMO)

Cygwin's bash runs passably well. However, I can't really recommend cygwin due to the basic conflicts between Unix and Windows conventions. Most Unixes have case-sensitive filenames, for instance, but Windows doesn't. And there's no clean mapping of Unix permissions to NTFS ACLs. Cygwin's nice, and I keep it around for a few things, but personally I get frustrated when I run up against things that are almost but not quite like they should be.

On the other hand, if you're just looking for a decent command shell for Windows, you can't do much better than 4NT from JP Software. 4NT is compatible with 'cmd.exe', yet adds a whole bunch of features reminiscent of a good Unix shell. I've been a big fan of 4DOS/4NT for quite a few years.

Oh, and don't forget to download Perl, Python and/or Tcl from ActiveState.

Seen FORTRAN under XP yet?

Yes

There's also COBOL, Perl and Python

Seen FORTRAN under XP yet?

Yes

There's also COBOL, Perl and Python

I used to think that Mozilla was too slow and bloated. I still used it every day on my Linux box, but it wasn't the most pleasant of experiences.

However the speed issue was put on the back burner once I started using a small fraction of the features. Tabbed browsing, disabled onload popups, javascript console/debugger, etc, etc...

I still kept thinking, jeez, its just a browser people, it can't be _that_ hard to make something that renders HTML. However once I downloaded Komodo ( here )
and used it for a couple days, I saw the light. Mozilla isn't just a browser, its a platform. Komodo still suffers from Mozilla's slowness, but the amount of useful features included with it easily makes up for any speed issues. Mozilla will start to speed up once it matures more, so thats something I can wait patiently for.

Kudos to the Mozilla team, keep up the good work!

Mark Hammond did a lot of work on a .NET compiler for Python. Info available at http://www.activestate.com/Initiatives/NET/Researc h.html
Last I looked, they weren't going to pursue a complete implementation.

Well, I agree, and if they had, they wouldn't be compatible with Perl or Python.

However, I think they managed to do something else, like use the .NET framework within Perl, and somehow wrap Perl programs into .NET components.

ActiveState has a lot of documentation about this on their site, specifically under PerlNET; it's worth taking a look.

A couple other languages/environments you may wish to look at are:

• Delphi 6/Kylix (Object Pascal)
• Perl 5 with ActiveState's IDE

I don't have much experience with Delphi 6/Kylix or Object Pascal, but Perl 5 will handle most of your requirements.

Personally, I would go back to your boss and ask why he needs all these features. The list of requirements sounds more like a buzzword-compliant list of programming language features that a typical PHB would come up with than a real requirements list. For example, if a design document hasn't been created, it's likely that this list of requirements is bogus.

NOTE: I found Cliff's question appended to the end of this story very confusing. It's orthogonal to the original question, at best. At worst, it's going to cause two entirely separate topics of discussion which will be difficult to distinguish when reading comments.

Actually, Fujitsu COBOL is part of the .NET framework. There's also Eiffel, and I think PERL too! Adding language support is easy, just build a compiler that can compile to MS's IL (Intermediate Language) instead of machine code.