Re: [wxperl-users] porting a perl/tk application to perl/wx

[Bob H. <cat...@ya...>]

I understand that wxWidgets is a very complex
meta-library for local graphic libraries, but why
would anyone be bothered with so many details? tkPerl
could be just as cumbersone as wxPerl, but is not. I
still think that a perl interface to wxWidgets, wxPerl
that is, could be more perlish, easier that is. The
complexity of the underlying library needs not to show
up in the API. No one could fly an airplane with two
arms if the interface would be closer to the hardware
than to the human. My programs are intellectually
manageable because I make an effor in that direction,
including using PERL instead of JAVA, for example. I
was perfectly happy with tkPerl's API, but had the
well known limitations of a tk interface. Can't we
have an easier API for wxPerl? I think we can. One
approach would be to retain the API of tkPerl, or
possibly have a simpler one, and move additional
detail to a separate file, if any are needed, with no
need to struggle with unintuitive interface builders
and our code, going mad in between. Perhaps I will get
used to it, but I cannot believe I have to give up
PERL's philosophy when programming in PERL.

"The  computer languages taught in schools and used in
industry, from Fortran and Pascal to C and C++, all
share in common the mis-feature of forcing programmers
to worry about all kinds of things that get in the way
of expressing what they're trying to do. [...] We need
to optimize both computer time and human time, but
when push comes to shove, computer time is getting
cheaper, and human time is (we hope) getting more
valuable. The  person has to come first." [Larry Wall,
The Origin of the Camel Lot in the Breakdown of the
Bilingual Unix, Communications of the ACM,
42(4):40-41, 1999.]



 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/