Re: What Perl CAN'T do?

I think perl (especially in combination with XS) can do nearly everything. But some things don't make sense because there exist faster solutions, e.g. 3D programming (Corion showed me at the last frankfurt-pm-meeting that it can be done, but it isn't very fast; a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC) or system drivers.

Btw: Perl/CGI usually seems to be a little bit slower than ASP, but you can probably use mod_perl. And comparing Perl/Tk to VB is a bit like comparing oranges and plumns, since AFAIK in VB you can only use objects, whereas in Perl you can create your own ones (may have changed with .NET, I don't know). And often, the VB-GUI looks more like a windows application than Tk where some widgets look ugly, e.g. Tk::Notebook or Tk::Combobox. But if that is essential, you can as well use wxPerl instead of Perl/Tk)

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Comment on Re: What Perl CAN'T do?

Replies are listed 'Best First'.
Re^2: What Perl CAN'T do? by hardburn (Abbot) on Dec 14, 2005 at 20:13 UTC
a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC If it was limited to using the CPU only, the recent Quake games couldn't work in C/ASM, either. You have to offload operations to dedicated 3D hardware to get Quake-level graphics. You need underlieing library support to take advantage of GPUs, which Perl has. In the game I've been writing in Perl (2d sprites, not 3d), the biggest CPU-hog is collision detection. I'm using a rather naive algorithim (every object tested against every other object), so it does a lot more work than it needs to. With offloading some of the calculations into C code, the game is playable on my 2.2 GHz Celeron laptop (but only just so in some spots). In pure Perl, it's easily playable on my Athlon64 3200+ (2.0 GHz) desktop. Fortunately, collision detection shouldn't be difficult to paralleize (at least from what I've seen so far), so this is an area that can take advantage of multicore processors. Also, there has been some research on using GPUs for collisions. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^3: What Perl CAN'T do? by jplindstrom (Monsignor) on Dec 15, 2005 at 03:41 UTC
One very simple way to optimize collision detection is to sort the objects by pos.x (or y) first. Now you know a lot more about which objects are in proximity. I'm sure there are really clever rocket science grade algorithms for this too :) /J	[reply]
Re^2: What Perl CAN'T do? by Courage (Parson) on Dec 14, 2005 at 17:09 UTC
Ugliness of perl/Tk could be fixed by using Tcl::Tk alternative, see http://vkonovalov.ru/cgi-bin/perl-tcltk-wiki.cgi/41 Best regards, Courage, the Cowardly Dog	[reply]
Re^2: What Perl CAN'T do? by Qiang (Friar) on Dec 15, 2005 at 17:17 UTC
quake 2 has been ported to java. i am amazed. slashdot story on it	[reply]
Re^3: What Perl CAN'T do? by strat (Canon) on Dec 16, 2005 at 08:49 UTC
Well, then it should run as good as under perl, shouldn't it? Best regards, perl -e "s>>F>e=>y)\martinF)stronat)=>print,print v8.8.8.32.11.32"	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks