Mozilla x (Perl + Python) = New IDE

WhyteRabbyt writes: "ActiveState have announced Komodo, an open-source IDE for Perl, Python and Javascript. The application framework is to be based on Mozilla. The press release is here." tenchiken contributed a bit more information about the project, writing: "More information is here , including the announcement a few days ago that they would be writing python and perl bindings to XPCOM. Like Perl? How 'bout client side perl!" No, it's not out yet -- but it's cool to see Mozilla as the engine behind yet another project.

Comments

Mozilla in 2001; "It's everywhere everywhere!"

[Spoing]

Maybe I'm a little nuts. When I mention this to others, they don't seem to get it. I'll let you decide...

I'm not surprised that Komodo uses parts of Mozilla this way. It's an obvious and practical job that Mozilla is well suited for.

In the next six months, I would be stunned if more programs don't use parts of Mozilla in exactly the way that Komodo does -- both in public and for private projects -- from custom document archiving, information kiosks, and no doubt in the 'Internet Appliances' we're seeing more and more of.

I don't expect that most of these new programs will be anything like web browsers. Mozilla -- as the mother of all monster widget sets -- is well suited to to be part of just about any program.

Mozilla has the ability to turn into a pervasive toolkit, as pervasive as Perl but even more visible to the user.

I pointed this out to a Mac user once, and they responded flatly "Well, I like IE".

Not getting the point, I said "Well, you could use IE as your browser, but parts of Mozilla will show up in more programs...it's the basis of many other programs."

Mac user: Blink. Blink. Silence.

On a different note, the only thing that concerns me with Mozilla are security problems with XML, though I'd expect XML engines to have problems once people push it a bit more. The security problems that I'm not aware of, similar to the ability to get postscript printers to do odd things -- like serve up web pages.

"Real Soon Now" Options

[Baldrson]

Cross-browser compatibility is, and will remain, the most important problem facing cross-platform developers.

As someone who has fielded around 100,000 lines of Perl, among the many "Real Soon Now" options for cross-platform web software development, I side with the strategy exemplified by Tibet 's approach to cross-browser compatiblity.

The difficulty of writing an application that will run on a variety of web browsers is already a primary challenge of software development. Adding more languages to the mix will only make things worse. Adding the relatively static Java to the dynamic Self-like Javascript was one of the biggest mistakes in the short history of the web (one for which Steve Jobs must accept a lot of the blame, but that is another story). By biasing toward installed language multiplicity rather than downloaded compatability-layer consistency, Komodo is in danger of becoming another, albiet lesser, mistake. IE isn't going to relinquish its dominance for a long time to come, not even with the US Federal Goverment fighting it.

IMNSHO, on the strength of environments like Tibet, demand for programmers of Javascript will beat Java "real soon now".

Watch this site for developments.

Re:IDE

[Shaheen]

I definitely think someone should learn a language in the context of a text / CLI environment. But, if you look at the size of projects today, it's pretty insane to do everything that way. Once you've learned a language (or more importantly, "programming"), I find it an important step to move to an IDE that is usable and helpful.

Personally, I like the ease of use of Visual Studio (note Visual Studio - *not* Visual Basic).

Basically, let's say you want to add a function to a class. Well, right click the class' name, click "Add Function" and all you have to do is type in the return type and name of the function (and its privacy class if you like). Done. It even adds the correct include statement to the header file if, say, an argument in your function is the type of a class that isn't defined in your scope.

I like that. I also like the fact that, while typing, Visual Studio will display a tooltip that highlights the arguments of a function, so I know exactly how many arguments there are, of which type, and even overloaded functions are handled fine.

I most definitely like the debugger. It's *MUCH* better than:


gdb stuff
break ...
run
* break hit
next

list
next


and crap like that.

People say that it's not real programming. Well guess what, IDEs are tools. They help you get the job done. Dijkstra's algorithm doesn't change whether you're using an IDE or not. IDEs, in my opinion, are glorified text editors (expensive ones too...) which do the grunt work for you.

I love my IDE, and until *nix has something like it, I seriously doubt I'll be doing heavy development for the platforms.

IDE

[Gurlia]

OK, this is perhaps slightly off-topic... but I'm just curious, what percentage of slashdotters actually find an IDE useful?

Although I've nothing against IDE's, I personally prefer a plain text-editor and the command-line compiler tools. I just wonder who else is like me and dislikes IDE's. :-)

One reason I stay away from IDE's is because it somewhat locks you into a certain interface that you get accustomed to when programming in that language (or environment, whatever). I find it more useful to learn how to use the bare-bones text-editor / CLI interface first, to focus on learning the language itself rather than the IDE's interface. After I learned the language, then I find my learning more easily applied to any development environment -- IDE or otherwise. If I had started out with the IDE, I find myself lost when placed in a situation where only command-line tools are available, and need to spend a lot of time learning the "real thing". It's so much better to learn it the hard way first, then your skills are more marketable/adaptable.

---

Client-side Perl?

[Imperator]

As much as I love the idea of , I'm not sure Perl has any framework for security. (Taint-mode is only useful when the script is trusted but the input is not.) Would this require a whole new security model to be grafted onto Perl?

Penguin Sandbox/Signing system

[ninjaz]

That's what the perl module Penguin does. You can find it on any CPAN mirror in the modules/by-module/Penguin directory. Eg., at ftp.freesoftwar e.com in the /pub/perl/CPAN/modules/by-module/Penguin/ directory. Here's a snippet of the FAQ in its tarball explaning how it works:

'Saaaay, what _is_ the design of Penguin?'

Glad you asked.

Consider two machines, foo and bar. A user on foo (or perhaps a program on foo) wishes to execute a program on machine bar. However, imagine that the people running bar don't want just anyone running code on their machine for security reasons. This is the normal case on the Internet, and one which the World Wide Web attempts to emulate with HTTP and CGI.

Normally, there is no well-known channel for foo to transmit code to bar. Further, there is no provision for the code to undergo verification after transmission. Too, there is no well-defined way for bar to ensure that foo's code does not attempt to perform insecure or damaging operations.

Penguin attempts to solve these issues while making sure the code language maintains some acceptable degree of sufficiency and power. Using Penguin, the user/program on foo 'digitally signs' the code that's earmarked for delivery to bar. The signature encodes the code in such a way that it is impossible to alter the code or deny that the signer signed it.

The code is then wrapped up into a packet and transmitted through a 'channel' to a Penguin process running on machine bar. The channel's protocol layer is abstracted away enough that it becomes unimportant; Penguin code can just as easily be delivered through SMTP or AOL Mail as through TCP/IP, DECNet, AppleTalk, whatever.

The Penguin process on bar unwraps the packet, which contains further verification and checksum information, and then 'digitally unsigns' the code, a process which provides the code in 'clear' form while telling the receiver who digitally signed it.

The receiver then cross-references the signer's identity with a list of rights that the receiver associates with the signer, reverting to a set of default rights if the signer is unknown or unlisted.

A safe compartment is then created, populated with the functions allowed to the signer, and told to limit the operations it can perform to only those permitted to the signer.

The code is then compiled within that safe compartment. If it attempts to do something which the signer is not allowed to do, or if it attempts to call a function not permitted to the signer, the compartment immediately traps the operation and throws the code away before it can execute. If the code uses no unsafe or illegal operations, then it executes and produces a result.

The code executing side then becomes the master in the transaction, and can send code to the original sender, send the return value back in a data packet, and so forth. The process repeats as necessary until both parties are done; the channel then closes, and the Penguin transaction is complete. The basic sentiment behind the idea of 'identity' being correlated to 'rights' in the receiver is that in signing the code, the signer commits her identity and her reputation on the correct operation of the code. 'highly trustable' signers (as one might imagine Larry Wall, Randal Schwartz, and Tom Christiansen to be) might be assigned very high levels of trust and equivalent degrees of 'rights', so that programs they sign can perform very complex and interesting operations on your computer. By the same token, paranoid sites or those wishing isolation could assign zero rights to everyone except for a select (perhaps internal) few.

Part of the 'rights' given to signers include possibly specialized functions that encapsulate the functionality of extremely dangerous operations. For instance, a store opening up on the Internet might put up a Penguin server which put functions called 'list_items' and 'buy_item()' into the limited compartments all users get. 'list_items' might open up a file on the store's machine, read the contents, and spit them out -- an operation which, if allowed in the general case, would clearly breach security. However, by creating a specialized function, the security concern is removed, and by letting potential customers know of the function, the power and ease of use are kept high.

Niggling but important technical issues currently being wrestled with include the way that foreign functions are registered into the namespace, the construction of a foreign function framework so that the names and function of the functions are well-known, and a superior-than-current 'digital signature' method.

Client side perl? Got it

[rjamestaylor]

Client-side perl has been available for a long time. But it's only available using a certain browser:

The folks at ActiveState have also developed something they call PerlScript, which is an ActiveX scripting engine for Perl. This means you can use Perl as your scripting language with any application on Windows that supports ActiveX scripting, such as Internet Explorer, Active Server Pages files, and the Windows Scripting Host. Not too shabby, eh?

(From http://msdn.microsoft.com/workshop/essentials/webm en/webmen1103.asp)

Yep. That's right. Client-side perl using Internet Explorer. Since 1997.

Templets.

[Forge]

What Open Source IDE's, Office Suites and other such things really need are Templets. And yes a proper GUI IDE has more in common with an Office suite than it dose with a Compiler + Editor + Debugger. Both in terms of functionality, design and target user.

What do I mean by Templets ? A typical commercial Office suite comes with literally hundreds of half finished documents and a Typical Commercial IDE has a pile of half finished programs.

Just start up the app, respond to a few questions for general things and you have a working app that may do part or even all of what you want ( if you have simple needs ). A really cool interface is nice and good online docs are extremely helpful but the REAL killer feature is the document files included in the distribution.

What I suggest is that the OSS IDEs designed for beginners ( This, GIDE and KDEvelop come to mind ) should have a well documented and simple method for creating wizards and templets. Then novices should be invited to work on these with the core developers only providing QA and guidance ( You don't want the IRC wizard to generate a client that must be setuid=root do you ? :)

Same goes for the Office suites, except that we should bundle a ton of clipart. Sure it means that latter on when you install Mandrake or Debian ( Both already 2 CDs each ) you have a 3rd CD called "templets and clipart" with nothing but royalty free graphics and sound plus BSD licensed sample source code. The apps will then know how to find it ( don't hardcode /mnt/cdrom either :).

BTW : Did anyone else notice that what separates the downloadeble WordPerfect 8 for Linux and the WP8 Office for Windows ( Motherboard driver disk version ) from the Shrink-wrapped full price versions is just the printed manuals, Templets, clipart and founts ?