Perl losing momentum ?

[spurperl]

Hi Monks,

This post is a sort of a rant, so excuse me in advance.

Lately, I feel that Perl is losing momentum against the other dynamic languages, and especially Ruby. This means that much less newbies are coming to the languages, that much less new developments use it and that people are reluctant to integrate it with different interesting packages.

A good example is GUIs. I'm a long time Perl/Tk user, but I really want to move forward. Tk just doesn't look good on Windows PCs these days, and good looks sell. When I want to brag to the bosses about a shiny new GUI I made for one of the programs, I feel embarrased showing Tk, when other people use native C# GUIs and LabView.

I tried using wxPerl a couple of years ago - the looks are much better (at the expense of performance...) but the library is poorly documented, and the bindings are incomplete. Today I tried looking at wxPerl again, and to my surprise it hardly advanced at all!!

wxRuby, on the other hand, seems to be production quality. Binary distributions for Windows, detailed documentation for the API (not "look at the C++ wxWindows API"), tutorials, and so on. This is not surprising in light of Perl's obvious loss of momentum versus Ruby.

This is pity. It's all I have to say. Once Perl used to be at the front, but now you have to resort to other tools. I hope Perl 6 will bring the lead back.

[g0n]

To build slightly on jetteros response, what are you doing about it? I can think offhand of a couple of different projects that might lower the barriers to getting started with Perl:
• A 'visual' Perl distribution - a downloadable Perl installation with an integrated IDE. There are two open source Perl IDEs that I know of offhand: OpenPerlIDE and Eclipse with EPIC (I make no comment about the relative merits of either). Bundle one of these with a compiled Perl for Windows, put it in a nice installer package, and that should make things much easier for newbies to get started. You could even include a GUI builder, there are a few around if you look carefully.
• As you've suggested, whizzier GUI libraries, easier to use might help. I've gone on at some length about the relative merits of different GUI libraries before Re: GUI toolkit choice, and am currently working on an abstraction module to try and make Tk coding in OO paradigm easier, based on the stuff I wrote for TPR last year. But if Tk doesn't look whizzy enough, why not get involved and try improving it. Or as Jettero has said, writing docs for Wx (although TBH, once you get used to it, the existing docs are fine - maybe a meta doc helping the newbie get used to using the C docs?)
• Write something for automagicmikes perltv project
• No doubt many others

On the GUI question, personally I have reservations about the 'if you want to write a GUI, use something else' argument. I find most of the GUI facilities in Java even more grotesque and work intensive than Tk. Perl is a good enough general purpose language that I rarely have occasion to use anything else - relegating it to nothing but text processing and glue is IMO doing a huge disservice to Perl and all the people who've put massive amounts of work into facilities like Tk, Wx, Prima etc.

On a really general point for anyone reading this and thinking 'yeah, that might be good if someone did that': it can be difficult to get your head fully around the grassroots paradigm - I know I struggled with it quite recently. To try and make it clearer: If something needs doing, get on and do it. If you don't feel you're competent to do it, do it anyway - you're almost certainly wrong. Once something is underway if it looks useful people will help, and it can always be cleaned up and improved on later.

[jhourcle]

Some of what you're talking about with the 'visual' Perl distribution, at least for Windows, is being worked on as "chocolate perl"

[Erez]

I think there are a few flaws in the original assumptions.
First, the 'Perl losing ground compared to' idea. A mature, well spread language, with just over 20 years of active development cannot have the same growth rate of a new one. It has nothing to do with market share or with spread of usage.
It's the same concept as giving full numbers to your incremental releases, it has no actual meaning.

Second, the GUI example. Tk is a portable, custom-widget based Tool kit, while .NET uses the Windows controls API. You can use that same API in Perl and have the same flashy bling Windows users can't appear to live without. It doesn't apply to Tk, nor to Ruby's better support of Wx.
Perl has a good support of Gtk and others, but even with a great support of any portable Tool kit, Microsoft will always provide better support for their proprietary tools.

The final issue is "good looks sell". Buzzwords also sell. Claiming your technology is "Business-standard, Enterprise service oriented for rapid, practical development" sells. It doesn't make a technology better when your NT Java-based server farm crashes every other week for garbage-collection problems.
A few years ago, Perl was the hype for web-development, then it was J2EE and its ilk, now it's Python, PHP and, Rails, and actual numbers be damned. If in a few years it will be Erlang or something similar, should that mean that Perl 6 needs to eschew everything and become a concurrent, functional language?

[moritz]

If in a few years it will be Erlang or something similar, should that mean that Perl 6 needs to eschew everything and become a concurrent, functional language?

Actually Perl 6 is becoming that ;-)

It's planned that Perl 6 will get a concurrency model that was protoyped with Haskell, and it has many features that are typically found in functional languages, like Currying, lazy lists, continuations (think gather ... take) and many more.

But it supports so many other paradigms (for example object-oriented and logic programming (think of regexes...)) that you won't be forced to use it as a functional language. And it will be "hidden" with nice syntax ;-).

Sorry for the digression, couldn't resist ;)

[moritz]

I never thought of GUI design as one of Perl's strengths.

For many Perl programmers the strengths are in the fields of log file analysis, database connectivity and dynamic web pages. And I haven't found any evidence for a decline in these areas, especially not in the first two.

(I personally use Perl for nearly everything, but that's a different matter).

GUIs fit very nicely in the object oriented paradigm (a window is an object, a button is a object etc.), and while supported by perl, it's certainly not it's strong field.

So it doesn't surprise me when you say that other, object oriented languages have nicer, more up-to-date GUI bindings.

[amarquis]

Your post got me thinking about what Perl is good for.

I can't talk about the full-time programming crowd, but I've no doubts that Perl is a great tool for anybody multi-disciplinary. Heck, my job title has "marketing" in it, and I'm using Perl all the time. I've got voluminous logs of e-commerce activity every day, I've got database systems here and with our distributors that don't speak each other's language, and we outsource our IT so I've got some "make these systems work" sorts of problems that come my way. Given all that, Perl helps me save a boatload of time and do my job better.

I've a lot of friends in intro-level IT sorts of positions, too, and they've been really receptive to Perl. With not too much time invested learning Perl, they can now attack systematically problems they were brute-forcing or doing by hand before. Why cycle error logs or mailbox archives manually when you can invest a few minutes making Perl do it for you?

From my perspective, Perl is still the best at what Perl does.

[Velaki]

I believe it all depends on where you use Perl.

I tend to use it as a powerful, glue language on the back end, where I pour over 35 million lines of data through the regex engine. In that particular area, it is not losing momentum by any means. If I need a front end beyond a basic CLI, I might look into perltk for it, but for the most part my jobs run in batch.

Now, why Perl? The system was organically grown, and using a simple-to-implement, ubinquitously available language like Perl was the best choice. But what about languages like Ruby and Python? Ruby is excellent for the OO-esque paradigm, but is not the best for firefighting. Similar arguments can be made for Python, although I'm seeing a resurgence of Jython on GUI side of things.

In the end it all comes down to your specific problem domain, time constraints, business objectives, and deliverable schedule.

Hope this helped,
-v.

[spurperl]

But I want to use Perl for everything !!

I use it for almost everything now, so it's sad to realize that for some things it's just worse than the other options out there. Writing a GUI with wxRuby and tying it to a Perl backend is cumbersome, so I'll pick Ruby for the whole project - because I can write a backend in Ruby too, but I can't write a pretty GUI in Perl.

[Fletch]

But I want to use Perl for everything !!

Aaah, therein lies your problem. "When all you have is a hammer . . . " etc. Diversify; you'll find where the other tools work better (and there will be places they will), and you'll gain valuable perspective on different ways to use the swiss army chainsaw you love when it's appropriate.

[jettero]

Say you were right. What could be done about it? I bet if you offered to write docs for wxPerl (and actually did so), they'd give you IRC hugs. Perhaps that won't help though, if the API is slow.

If there's a "native C# GUI" could it be accessed from XS? Can any C# libs be accessed from XS?

[zentara]

wxRuby, , seems to be production quality. Binary distributions for Windows, detailed documentation for the API (not "look at the C++ wxWindows API"), tutorials, and so on. This is not surprising in light of Perl's obvious loss of momentum versus Ruby.

In other words you want something point-&-click-easy for free. I stand in opposition to new momentum..... I am massive Inertia. ;-)

We'll see. Usually when Ruby or one of the others come out with something, it makes a big splash, then peters out as problems pop up, like window version incompatibilities, trying to find answers to odd problems, or the developers move on leaving an orphan. So many people have looked elsewhere for projects, only to realize, that Tk is easier to get it done (and it's cross-platform). Use what you want, what's the problem? I'm going to always use Perl, unless someone PAYS me to use something else. Does it bother me that you claim "Perl has a momentum problem"? No. What is this momentum other than the current "whiz-bang new kid on the block"? Perl does what I need, rarely fails me, make great gui's with Tk and Gtk2..... so why should I worry? The only thing Ruby would do for me, is waste a half year of time to learn, only to come back to Perl when I fail to get community support from the relative handful of wxRuby Users.

Of course, it may sound like I'm an old dog who won't learn new tricks......but if I'm served well by my current bag-o-tricks.... why change? The Inertia of my big Perl code collection, and the HUGE friendly Perl coding community, compels me to shrug off your attemped momentum change.

[sundialsvc4]

Go learn something. Go write something. You'll feel better soon.

The longer you stay in this business, the more tools you'll learn, and the more tools you learn, the better-equipped you'll be to handle the particular requirements for which a particular language is designed and well-suited.

There will never be a point where you can kick back, toss your knapsack on the table and say, “Well, I've arrived!” This industry in particular is always main-lining growth hormones. It reinvents itself literally every few years. The present cycle, of Windows® dominance in a now-major market segment, is “only” about 20 years old, and already well on its way out. “The web,” well-entrenched though it may appear to be, is barely out of its diapers yet! The next cycle is clearly foreshadowed by iPhone® and other forms of handheld personal electronics. It never stops, and it never will.

Don't be alarmed by what I'm saying; don't let it stress you out. This business has always been this way ... it was “this way,” so I'm told, in the 1940's and 1950's. I think that's part of what makes it so engaging and interesting. “Don't Panic!™”

You must constantly acquire new skills and develop your proficiency with existing ones, just to stay in the game at all. You're also going to have to specialize; it is physically impossible to know it all, or even, some might say, to know very much.

So for example... yes, you need to acquire enough of a cursory familiarity with Ruby® (and Rails™) to be able to “land four-paws-down” if a project presents itself in that language, or to provide knowledgeable advice as to whether it should be used. But you have to add that awareness to your tool-chest; it will never replace what's there. You don't have to become (say...) a Ruby über-geek, unless you want to. You just need to have seen it before, and to know what it might be good for, and to be cursorily aware of where its warts are, too.

In the long run, people are not hired to be walking encyclopedias. (That's what encyclopedias are for.) They are hired for their expertise and their experience, their reliability, integrity and skill. Tim O'Reilly is always going to be publishing a new book and he's always going to want you to buy it, but you don't have to pack his entire library between your ears and you're never going to be “unemployable.” If you're any good at all, you're always gonna have as much work as you care to do, no matter what you do.

[samizdat]

Don't panic? Don't blink! : The Harrow Group used to be a great techno-change insight site before blogging. I can't see if it's still alive, Dell (my employer) blocks it.

UPDATE: It's stale, sorry. All gone.

[dirving]

Your experience with wxPerl seems to be different than the one that I have had. In the year that I've been using it I've found it to be much better documented and easier to use the Tk.

All the objects and methods map 1:1 to the C++ API documented here, and anything that is different in wxPerl is noted in that same document. You can also install Wx::Demo from CPAN, which is a demo script that shows you how to use all of the widgets.

Up-to-date PPMs for ActiveState on Windows are available here. I also had no problem building the module with CPAN on Debian.

I haven't yet run into any classes missing from the perl port that I've wanted to use (although Wx is a huge library and I certainly haven't tried all of it.) In general, everything just works more consistently and looks better than in Tk. I had a lot of problems trying to inherit from Tk classes -- in WxPerl you just use base 'Wx::Whatever' and it works how you would expect.

It would definitely be worth your while to take another look at wxPerl. Although the API is a little less Perlish than Tk's, it is generally cleaner and more consistent, and the resulting GUI is much more attractive.

edit: I just re-read your post and noticed that you were concerned about using the C++ API reference instead of a dedicated Perl document. Essentially the only difference between the two would be changing the class names from wxWhatever to Wx::Whatever and changing the name of constructors to new, so maintaining a separate document would be a waste of effort (and a pain to keep in sync as the main Wx documentation evolves)

[spurperl]

David,

Thanks a lot for these pointers. I will give wxPerl another try.

[xdg]

While I admit that I haven't tried it personally, have you explored the Prima GUI toolkit?

[hpavc]

Perl lacks the Visual Studio tight integration to have the drop and drag love that nubs want. The editors solutions like Eclipse doesn't pretend to address this, they are just editors with bindings and integration.

To be able to set properties and design UI elements you need some intimacy with the packages and the tool that perl doesn't have. VB and what not can do this with their control interfaces. If all packages had the meta-data that developer ready active-x controls and related test harness information we would be pretty solid on this front.

As far as perl GUI, actual end user form interfacing, this is a bummer at times. On the linux side there isn't much positive at all to be said on this front. There isn't a drop dead stupid 'VB', perhaps the best it gets is RealBasic, Delphi never got there, java is all pretty much fail in the wrong direction (though Sun has that nice vb-killer suite they just are ignorant on getting them out there)

Making a win32 perl program that binds UI calls is pretty harsh, the whole event model thing is hard. It much easier to make a perl program that has a soap interface and crack out a mindless vb program quick.

Perhaps there will be a UI service for win32 or gnome that will allow IPC/RPC between perl. That seems attractive to me rather than messing up perl with xs bindings and what not. I would rather deal with UI like jabber than UI without a real modern event model handler.

[toma]

There are slides from an OSCON 2007 presentation about WxPerl GUI development (offsite link).

Cross-platform GUI development is hard.

You could also look at SDL. I have seen some very nice SDL code demos at my local Perlmongers meetings. I believe the SDL code takes advantage of the OpenGL pipeline.

Making a decent-looking GUI is also a lot of work, at least when I've tried to do it. I've stopped blaming the tools! The best thing to do is to try to make a good-looking GUI on any platform, just to see what you are up against. I did this myself by coding Tetris in C++ using SDL on Linux.

Maybe there is a hackish way to create good looks. Something like this - If you knew how to draw a really nice screenshot of your program with any tool, you could carve up your screenshot into Tk::Pixmap images that you put on buttons.

But that's not what I do. I build a little web server into my perl app, use POE::Wheel::Run to launch independent processes, and build my UI out of web pages. I take it easy and let the browser do most of the art. This also has the advantage that the user can change the fonts, window size, search the text, etc. And if someone wants to localize it, they can edit my HTML::Template files.

[Anonymous Monk]

Toma, Your approach of using POE::Wheel::Run and using webpages to build the UI sounds interesting. Do you have a small complete example that you could point to ? Thanks - Terence

[toma]

No, I don't have a simple example now, but if I ever create one I'll link the writeup on my perl page (offsite link).

[shmem]

Wanting to promote perl to have it get a bigger market share seems to be a "rite of passage", similar to developing a new templating framework for web programming, as the saying goes...

Nothing wrong about that, just do it, but don't complain. If your templating solution beats existing ones, it will be the one of choice sooner or later. If you promote well...

But all that "perl promoting" ado reminds me of the old framework stanza:

Don't call us. We call you.

The framework is perl, CPAN, the community. The framework promotes you.

And you, being thus invigorated, use the framework, promoting it...

[talexb]

Lately, I feel that Perl is losing momentum against the other dynamic languages [..] A good example is GUIs.

No, actually, with Perl, GUIs are a *bad* example when you want to persuade people that Perl is losing momentum.

If there are two things that Perl really isn't well suited for, they are high performance computing and GUIs.

Perl is great at running on a very large number of platforms. Perl is great at running with performance comparable to C, but with all kinds of dirty work (memory allocation, file handling, you name it) taken care of. Perl is great at being able to create a usable prototype quickly. And Perl is great at doing Test Driven Development.

Until there's a single GUI developer's toolkit for all platforms (never?), there are going to differences in how a GUI looks on a different platform. Welcome to the world of computing, where there are new platforms every time you turn around. Perl is no exception -- but there are definitely options, as the many replies to your original post show.

Perl is not losing its momentum; maybe the one aspect you looked at isn't moving forward very fast, but it could be that that's a business opportunity for you.

I really enjoy developing in Perl -- the language is fun and the CPAN library is terrific, but the real crown jewel is the community -- that's priceless. Plus, I'm able to find amusing, well-paying jobs where I can develop in Perl. When that stops working, I guess I'll find another language -- but for now, my prospects are good.

[spurperl]

I'm completely in sync with you on this:

I really enjoy developing in Perl -- the language is fun and the CPAN library is terrific, but the real crown jewel is the community -- that's priceless

However, GUIs are important, and Perl is not good at that. The only GUI library Perl really has good bindings with, and comes preinstalled with most distributions is Tk. But Tk is very limited, especially in the "looks & feel" department. I wish I could use Perl for everything I do, but unfortunately I can't. My "losing momentum" claim is that thinks are unlikely to improve from now on, because the focus of most enthusiastic language tweakers is not on Perl any more.

[alexm]

Nowadays, Web UI is far more important than GUI in most cases, and Perl has probably the richest toolset available for Web.

[zebedee]

Maybe Tcl/Tk 8.5 will help? I know nothing about how/if it will get integrated with Perl, though, so might be a complete red herring.

http://www.tcl.tk/software/tcltk/8.5.html

From that page:


---

Highlights of Tk 8.5 * New modern theming engine: New and complementary widgets that make use of platform-specific theming on Mac OS X and Windows to better fit in with those environments, and feature an improved look and feel under X11. (screenshots) * New widgets: Part of the themed widget set, Tk now has core notebook, combobox, treeview and progressbar widgets. * text widget: Smooth scrolling, widget peering, and improved procedures for counting and replacing text. * Font rendering: Now uses anti-aliased text under X11, and a more modern text engine (ATSUI) on Mac OS X. * Additional improvements: Window transparency, new fullscreen option for windows, enhancements to specific widgets and window layout, and more.

[Your Mother]

I sort of said it before. I'll say it again. If this is Perl losing momentum, shovel it on. My new gig is 50% more money than I've ever been paid before (sort of, not counting options and such), meaning a raise of tens of thousands. Perl could probably have 1/10th the support and community it has today and still have a nice and valuable niche. I've been contacted out of the blue by recruiters ... I think 6 times in the last year; last time was yesterday. Decent Perl devs are really quite hard to find. (Sidenote: I'd like to again say that it is largely the wisdom, clarity, experience, and willingness to share of many monks here that made me anything more than a crude dilettante with Perl.)

Also, I still hear good things about Ruby, but I also hear bad things now which was not the case two years ago. The Ruby honeymoon is over. People are starting to judge it as they should: just another tool and not the hot new silver bullet.

[hangon]

Well, xdg was a little quicker than me, but I was wondering the same thing. I stumbled across Prima by accident while searching CPAN a while back. Unfortunately I didn't download it at the time, and later had forgotten the name. It did look interesting though. Has anyone tried it?

[zentara]

I just downloaded it and it compiled with 2 errors

Testing ./Widget/Position...failed (2/7)
Testing ./Widget/Window...failed (2/15)
Total tests passed:28, skipped:0, failed:2

BUT.... the examples run well, and the code is not that hard to understand. It looks like gtk2 programming, and the dependent libs are gtk2 on my linux box. I didn't see a drag-n-drop gui-designer. It looks like they make connecting to events and signals easier. I would say it looks very promising, but it has a drab look like Tk( although "looks" depend on how much you put into it).

Interested people should look at the code in the examples subdir......... the code looks like Gtk2.... I might borrow some of their examples and see if they run as pure Gtk2.

[naChoZ]

I tried it. It works pretty good. I'm *not* a gui programmer by any stretch. I just wanted a little program to start/stop some services in Windows based on which "profile" I clicked. So I just used it because of the visual designer it has. I created a single form with a few buttons on it, saved it as Perl code, then added the important bits afterwards with Vim.

Generating the gui part of what I did took all of 5 minutes, tops. If I had actually cared what it looked like, I could tell there were all sorts of ways I could make it pretty. Play with fonts, graphics, colors, buttons, pretty much anything.

[arbingersys]

I like these arguments, but they all end up being primarily anecdotal, i.e. "I've had this experience... which leads me to believe X". Being exposed to varying opinions is always enlightening. But is there any real hard evidence? Is it possible to get said evidence?

Here's a little data I compiled from the following two links at ohloh.net:

http://www.ohloh.net/languages/8

http://www.ohloh.net/languages/12

projects	contributors	commits	lang	commits/per	contributors/per
799	1,603	87,840	Ruby	109.94	2.01
2,488	7,131	300,288	Perl	120.69	2.87
0.32%	Ruby/Perl project ratio
0.22%	Ruby/Perl contributor ratio
0.29%	Ruby/Perl commit ratio

Based solely on this data (I have no idea how reliable or how good an indicator it really is), I'd say Perl is slightly ahead of Ruby.

Both languages seem pretty healthy, though.

Update: I shouldn't have posted while trying to hurry out the door. I did my division wrong in the "/per" columns, and those numbers weren't correct. It kept nagging at me, so I finally re-checked. The above should now make more sense.

[toma]

If you like that approach, you might also like this article about how O'Reilly uses book sales as a technology trend indicator (offsite link).

[Anonymous Monk]

"Lately, I feel that Perl is losing momentum against the other dynamic languages ..."

"I hope Perl 6 will bring the lead back."

Perl 6 is responsible for this lost momentum.

[spurperl]

In some sense, you're right. So many people now feel that Perl 5 is being phased out "soon" anyway, that investing in it doesn't make much sense. So, the smart people with patience work on Perl 6, and those without patience just switch to Ruby.

[Porculus]

Obsessed with shiny new languages != smart. In my experience, the smart people are the ones who recognise that Perl5 isn't going anywhere (how do you explain 5.10 otherwise?), and who continue to invest in it where it's the appropriate tool for their projects, instead of yearning after Perl6 or trying to force costly ports to Ruby.

[scorpio17]

Perl is still my language of choice, but I, too, have felt that it's been getting overshadowed lately. For example, perl.com doesn't get updated as often as it used to. There aren't as many new Perl books on the bookstore shelves. The local college, which supposedly has a "web development" program, doesn't offer any perl classes! What do they offer, you ask? PHP, java, c#, ruby...

[sundialsvc4]

Your local bookseller wants to move merchandise off the shelves of your local store. Yes, he'lll sell you a cup of coffee while you give the book a once-over, but he's not running a library. Therefore, what you see or do not see on your local shelves is much more an indication of what's moving in your local store than of the health of the language in-general. Any retailer watches carefully to see what is selling where, both to determine how many units to order (and how many unsold units to return to the publisher for pulping), but also to transfer product from one store where it isn't selling, to another store where it is. Technical books will be found in greater abundance at stores which are close to Universities and office-centers where geeks work. Computer books, in paper form anyway, are notoriously expensive, slow-moving and hard to sell. Just look at how many books which have the misfortune of having the once-necessary word “2007” on the cover which are now selling for 15% of the cover price if that. (Next stop:   to become newsprint or a grocery-bag.)

Knowing this, the good Mr. O'Reilley actually sells most of his material on-line, for electronic delivery, which of course makes a great deal of sense to him since they're all just DocBook files anyway. His service can spit out a PDF or whatever-you-want, produced on-the-fly, and either delivered to you or simply made available for online browsing. I'm quite sure that those electronic-book readers are going to be very big in our industry... and good for the planet, too. Ones-and-zeroes weigh nothing.

As we all know, “fashion sells.” Last year's trick is last year's trick. There are literally billions of lines of COBOL out there doing heavy-lifting every microsecond of every day, but books on COBOL are best found at MacKay's (Used Books). The books that are most likely to be placed in retail bookstores are fat (at least 1.5 inches on the edge), cheaply printed with wide margins and big type (to make them fatter...), splashed with easily recognizable trademarks, and are written about “fashionable” subjects like (at the moment...) Ruby.

Here's a wee thought for you. Look at yourself, as a bookseller would. Right now, you are probably feeling that there is something you don't know. Therefore, you are probably fairly self-motivated to buy a book about it soon, if you haven't done so already. Okay, then, what kind of book are you most likely to buy? One about Perl? Probably not. One about Ruby or Haskell or some other “shiny new thing” that promises to be the next silver bullet? Probably. The book that is most likely to make it to the checkout is one that will be written with the slant that you probably know one or more similar programming languages, you want to find a CD-ROM or DVD-ROM in the back cover (although that's expensive), and you'll want to “kick the tires a bit” with some easy-to-do projects that you may or may not do. You'll spend about a week with the book, and put it on your shelf for reference, or you might (bad dog! cheap skate! no biscuit!) return it. And that is what a good retail merchandising director makes it his or her business to know!

[toma]

You can be deceived by the bookshelf-space theory, in the US at least. Books in the US are typically sold on consignment, so the bookstores don't pay for them until they sell. That's why there is so much junk on the shelves. Some publishers pump out garbage and hope that someone is desperate enough to buy it. If not, re-pulp and repeat. It can easily be that there are only a few good books in a bookstore, and the bookstore does fine. In this environment, "the front supports the back", so they really are in the coffee and browsing business.

[chromatic]

Knowing this, the good Mr. O'Reilley actually sells most of his material on-line, for electronic delivery, which of course makes a great deal of sense to him since they're all just DocBook files anyway.

If you mean "most" as in "most of the O'Reilly catalog is available through Safari", then that's mostly true.

It you mean "most" as in a quantified portion of sales (whether units or revenue), then it's not true.

[lepre]

I forgot to mention that mobile platforms (see HTC's Tytn II and Apple's iPhone, for example) prove to be ... the place to be, here and now, for developers who do not want to surf under the wave. Perl seems to be making timid steps into Nokias, but there are core problems that really hit Perl on its head, namely binary apps with tiny footprint and, yes, the GUI again.

[lepre]

On Perl vs the rest, please read

L. Prechelt, "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl", IEEE Computer, 2000.

On GUI for Perl, I asked wxGlade to separate the function from the form, and thus make the code intellectually manageable (possibly better than Perl/Tk). My notes are on their mailing list. They promised to work on it, but the project has a clear drive for Python.

On the poor documentation and ugly coding of wxPerl, I have left notes on this too in their mailing list, long ago. I left with the certainty that it was not going to improve, unless someone with expertise on Perl/Tk would have taken the royal project to redesign wxPerl from where M. Barbon has left.---I looked for notes on how to port Perl GUIs from Tk to Wx, but had seen none so far.

On Perl 5.10.0, after two/three months, there are still too many modules that are not up-to-date, mostly because they do not compile and need patches.

[lepre]

My case study for the GUI: wxWidgets 2.8.7, wxPerl 0.81, and Perl/tk 804.027, they all fail to compile under Apple OS 10.4.11 with Perl 5.10.0, being a hot dish served in cold silence. I am going back to perl 5.8.6, sorry...

[lepre]

The GUI world is spinning of its own...
http://www.adobe.com/products/air/