[lcdproc] Not in perl...
Thu, 15 Mar 2001 18:56:57 +0000 (GMT)
> 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)
>From a code-quality point of view choosing a language on the basis of
continueing your education is probably not the best move. I do howver
think that a port to perl would be welcome.
> It is also a bad idea because other developper know about C but maybe not
> Perl (or like me bad Perl).
It is also true the other way round. I am exclusivly a perl developer, I do
not do C.
> Also we have some low level code to deal with parallel port... are you going
> to do it in Perl?
I though there was an lcdproc library that did all the fun stuff. If that
is the case we can write an XS wrapper and module such that interfacing to
lcdproc is a dream.
> Now if you consider portability, security and embeddability...
> Perl is risky, big, consume memory...
Rubbish. Poorly implemented perl is big and consumes memory. Poorly
implemented C simply core-dumps ;)
> I trust less a perl script (because it is difficult to understand once it is
> writen) than a C code.
Perhaps this is true in your case - but I have yet to find production code
which I have found un-readable (unless someone was aiming for an obfusication
Perl is a higher level language and as such:
1) Should be more readable.
2) Should have shorter developement times.
3) Should be easier to debug.
4) Slower than C.
5) Probably uses more memory.
C on the other hand:
1) Less readable (more code required to do simple tasks)
2) Development times are longer.
3) Harder to debug
4) Have to guard against memory leaks, meandering out of bounds etc...
6) If written well will be smaller.
Note about memory usage... If your user uses a shared perl binary then
memory allocation is near enough non-existant for the interpreter/compiler
and the memory arguments probably don't apply.
To unsubscribe from this list send a blank message to