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.

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

[Wellspring]

I'm not surprised.

One of the advantages of open source development is that, if you have enough projects going, you have a tremendous potential for reuse of code. Another is that since APIs and file formats are genuinely open standards, modules become more consistent and encapsulated. Still another consequence of using open standards is that 'embrace and extend' becomes very difficult, if not impossible. Adding new features is easy, but it is tough to lock your users into your product line.

Result: (ok this isn't anything new for us, but I'm getting to my point) UNIX-- where you have a million highly optimized tiny programs that do one thing well (and are reused everywhere by everything) instead of a few monolithic packages that barely interact with one another.

OK, nothing new so far. Here's the point: this is old hat to us, but a brand new concept to the end-user world! The whole idea that you could use parts of one application in another is just foreign to them. In the DOS/Mac world, features come from individual blocks of code. In the open source world, features are derived from the links between those blocks. If you didn't grow up with it, it is a totally new way to think about computing.

Another result- development of brand new applications will be faster, too, since good code gains value with every re-use with minimal development, rather than having to be reimplemented.

Say someone wants to create a WYSIWYG word processor, or a page layout program. Or some totally new application concept. Well, hey, let's just use pieces of Mozilla. And the program is in alpha release a few months later. I suspect that it will take years for the full significance of the concept to hit people.

"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.

Re:Who's side are they on?

[Captain Teflon]

ActiveState got into a business relationship with Microsoft about a year(?) ago. Forgive me if I err in some details, but AS got some money, and MS got better support for Perl, which apparently is used quite extensively within MS.

ActiveState also apparently benefit from MS knowledge, specifically at the time producing a version of fork() which would work on Perl for Win32.

I've used the Win32 version of ActivePerl extensively. It's a GOOD product, more than making up for the lack of decent command scripting tools in base NT. The only real deficiency at the time was the lack of multiprocessing or thread support, which the latest version (with fork()) has recently implemented.

You can get Python, Zope, Java for Windows. Free. Perl for Win32 has been around for a while, ActiveState just took it to a new level of professionalism. Even Apache has a Windows offering, which is an excellent and far less clunky replacement for PWS.

Some of us need to use Win32 at work. Some of us, shock horror, may even like some aspects of it.

I can't see ActiveState coercing Unix Perl users to go over to the enemy. Rather I think it may help give Win32 programmers an insight into Unix-based tools and maybe get them to check out this Linux stuff.

Zealotry and anti_MS paranoia does get really boring at times. Guilt-tripping AS because they don't share your paranoia about MS is in my opinion a sign of immaturity.

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.

---

Re:IDE

[Carnage4Life]

You must be a college student or probably just learned how to program. An IDE is a tool, that may simplify certain tasks in certain environments.
You contradict yourself by asking two contradictory questions. If the question is "Do you consider an IDE useful?", the answer is definitely yes. All it takes is trying to manage a project with 20 - 50 files each with a 1000 or more lines of code to quickly turn one against bare bones editors and towards IDEs. Now if you are asking which is better to learn a language with then the answer definitely should be a bare bones editor so that certain quirks of the IDE do not seep into one's programming style. Novice programmers are fond of using IDEs as a crutch and more than once I've seen kids crash and burn when removed from the Visual Studio world and transplanted into a Unix environment. I hope this answers your question. Of course questions like yours ignore the fact that a programming language is merely a tool used to perform a task and not a religion or esoteric art to be mastered in all its minutae. Frankly anything that makes you more productive gets an A in my book.

Now so as not to be marked offtopic by some anal retentive moderator here are my comments about the article, clientside perl will be welcome addition to the scripting arena, it is really cool that Mozilla's original plan to be more than a browser and instead to be an engine/building block component similar to MSFTs COM components is working. Go Mozilla!!!

About Komodo

[Money__]

From: http://Activ eState.com/Corporate/Media_Center/News/Press959150 636.html "We view Mozilla as a very exciting platform as it offers an open, modern component framework for cross-platform application development," stated Dr. David Ascher, Senior Developer and Mozilla Product Leader, ActiveState. "Our contributions to the Mozilla open source effort will start with adding Python and Perl bindings to XPCOM, Mozilla's component architecture. This change will open the Mozilla architecture and eventually make it available to Perl and Python programmers."
___

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.

Never thought i'd see this

[pneuma_66]

On activestate's homepage there is a link to a press release about Visual Perl and Visual Pyhon for MS Visual Studio 7.0

cristiana

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 ?

IDEs for OOP

[JohnZed]

Ok, so I do a lot of C/Perl programming in Linux, but I also do plenty of C++ and Java work too. For non-OOP languages, all I really need is a good way to jump to the definition or implementation of a particular function or structure. With some hassles, ctags/etags + vi or emacs can pull this off, and they're quite passable.
But with Java and C++, the advantages of an IDE become huge. Class browsers and Intellisense (also called autocompletion) actually make it intuitive to work with hundreds or thousands of different classes at one time. So sue me if I can't remember the order of the parameters that go into some obscure method on a class I hardly ever use. Intellisense makes that a total non-issue.
Also, many people who tried IDEs years ago, but haven't looked at the newest crop, should really take another shot. I mean, GUI-builders have become vastly more sophisticated in the past years, and wizards have grown from relatively-useless little aids to incredibly poerful tools. Think about how many programming tasks are really "boilerplate". Getting rid of repetitive tasks is NOT dumbing-down of programming. Really, it's just the opposite. Programmers should only have to spend their time THINKING. Not writing stupid makefiles. Not re-typing simple code that hundreds of other people have already written. And we certainly shouldn't have to spend our time switching back and forth between DDD, emacs, and cscope.