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

I'm coming to this thread late, but I have a couple of observations.

Perl 5 is still the best language to use to process text data, but the world today needs much more resources:

A good IDE, like Eclipse for Java.

Good multi-threading.

Standard and rich GUI.

I'm not sure what your thesis is. I'm an engineer, and my motto is, The right tool for the right job!

For me, Perl turns out to be the preferred tool for most of what I do on the job. Sometimes I *could* use Perl, but a shell script is just easier. The fact that it's lighter weight is a bonus.

Wanting to use an IDE is a developer preference. I loved Borland's Turbo C when it came out, about 20 years ago, and I used it professionally on DOS in the late 80's and early 90's. I moved to OS/2 and Presentation Manager after that, and went to an editor called KEdit. It had some IDE features like reading the error file and placing the cursor on the source file line with the syntax error.

These days gvim is enough of a development environment for me .. if I have a syntax error, I can find it as quickly as I need to, and if I need to look up a function, I'll just open an xterm window and look it up using perldoc -f split, or even open up my copy of the Camel.

I'm still not sure that good multi-threading is absolutely necessary -- I suspect that the number of problem domains that need this feature is small, and that this argument is a red herring.

The whole GUI thing is just a toy. I'm happiest on a command line, and I've been using a command line for 30 years. A GUI is fine when you want to do a limited number of things. It's very frustrating when you want to be creative. For example, recently I wanted to print a bunch of Java source files, two up. How the heck do you do that with a GUI? With the shell, I just did

ls *.java | xargs -iyy 'mpage -2 yy | lpr'
[download]

and I was done. Yes, I had to read the man page for xargs -- I don't use it often enough -- but I knew it existed, and that it would do the right thing.

If you're talking about development of a GUI application, I'm not sure Perl is the best platform for that -- you probably want to think about using Java for the frontend, and Perl for the backend. That way you get the best of both worlds: A flexible GUI that's portable, and terrific power in the backend where you need it.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Comment on Re: Slow evolution of Perl = Perl is a closed Word Select or Download Code

Replies are listed 'Best First'.
Re^2: Slow evolution of Perl = Perl is a closed Word by naikonta (Curate) on Sep 11, 2007 at 16:50 UTC
if I need to look up a function, I'll just open an xterm window and look it up using `perldoc -f split` You mean you don't like `:!perldoc -f split`? Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!	[reply] [d/l] [select]
Re^3: Slow evolution of Perl = Perl is a closed Word by talexb (Chancellor) on Sep 11, 2007 at 17:04 UTC
That's a cute way to do it, but it doesn't allow my to look at the `split` documentation while I update my code. Anyway, I use Windowmaker on a two screen system, so I have all the screen real estate that I need -- an extra xterm just showing me documentation on `split` just makes sense. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply] [d/l] [select]
Re^4: Slow evolution of Perl = Perl is a closed Word (OT: g?vim) by naikonta (Curate) on Sep 11, 2007 at 17:21 UTC
Well, I'm not trying to convince you, (and not mention that this may be awkward) but you still can look at the `split` doc in the splitted window, `:new +r!perldoc\ -f\ split` (of course, it can be handier with a mapping or two :-)). Then `ZQ` to discard it when you're done with it. Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!	[reply] [d/l] [select]