Re: Slow evolution of Perl = Perl is a closed Word

[samizdat]

Boy... AM, you sound a lot like one of the guys I had working for me. We switched from a PHP-based *working* web system to developing in Java, on his insistence that "Enterprise apps are all done in Java now." The Java prototype is *still* in a sandbox, two years later, and I've sold out my piece of the company in disgust.

A long time ago, I did a lot of app programming in Digitalk Smalltalk/Win. There was a really nifty add-on available called WindowBuilder that made GUI-building amazingly simple. The basic IDE had all the traditional Smalltalk inspectors and class hierarchy browsers, and it was totally fun to work with. Smalltalk syntax was a witch, and that was the only downside. Whoever thought up using two kinds of brackets for nesting parentheticals should receive a topcoat of hot tar and feathers! OTT, I was a happy camper. Until, that is, I had to go beyond the GUI and talk to hardware. Therein lies the rub. My Smalltalk system, and also Java, really was not happy venturing outside of its sandbox. I had to code '86 asm at the DOS level and load it asa TSR via batch file. Anybody else here remember the Norton Editor? ;-]

Specifically to your points, I'd have to agree that a good IDE can really help make a GUI app elegant and easy to use, but it can't make up for deficiencies in the language and its libraries. I agree that the arcane nature of Perl5's syntax and state-driven parsing does make some of the niftier IDE features difficult, but Perl5's deep integration with UNIX makes it so much better than most other languages for a huge class of applications in systems and embedded programming. Yes, GUIs are nice, and Windiots are helpless without them, but under the GUI hood lies the heart of the program, and that's raw code. In Perl, that raw code is very concise, unlike in Java or C source.

FInally, I think the last word has not been written on multiprocessing scheduling and development paradigms, and won't be until easy-to-use multiprocessors are commonly available and people have a chance to cook with them. We're doing something about that at D***, and I don't mean multi-core in the usual x86 sense. :)))

[Anonymous Monk]

Just one comment: Do not use JSP!

JSP for me is not Java, and is a very bad option for Web. For web PHP and Perl are better. Or you can use GWT (Google Web Toolkit) where you still can use Java without the JSP mess.

[samizdat]

Like I said, I walked away from the whole mess. I have lots better things to do with my time than discussing religion with programmers, and my ex-partner's the one who gave them the go-ahead over my objections, so he gets to feel the pain of the Java boondoggle.