[lcdproc] Not in perl...

David Glaude dglaude@netbrain.be
Thu, 15 Mar 2001 18:01:20 +0100


>v0.5 is stalled (again), in the design phase. Mostly because I haven't
>gotten a chance to work on it much lately.

Design phase is the most important one,
 but as long as there is nothing out for v0.5 no-one will be able to add
something to it.
Because v0.5 is suppose to come, this stop peaple from investing time in
working on v0.4.

>Here's one reason why I shouldn't work on it much right this instant:
>I'm learning Perl, and was nearly convinced to try reimplementing
>LCDproc in Perl a couple of days ago. :) Then I got some sleep.

As you say, you are learning Perl.
This is not a good reason to use Perl. (this remind me of the LcdProc++ in
C++ argument)
This is actualy a bad idea because you write better C than Perl code and
that may stay true for some among of time.
It is also a bad idea because other developper know about C but maybe not
Perl (or like me bad Perl).
Also we have some low level code to deal with parallel port... are you going
to do it in Perl?

>It actually wouldn't completely suck, except it reduces portability a bit.
Now if you consider portability, security and embeddability...
Perl is risky, big, consume memory...
I trust less a perl script (because it is difficult to understand once it is
writen) than a C code.

David GLAUDE

If you want to do something with Perl, then a Perl module to have an easy
way to write client in Perl
is something nice, usefull, portable, bringing more client to the server...


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net