[Phoenix-pm] UI Builder in Perl

[Scott Walters]

On  0, Chris Krum <cakrum at cox.net> wrote:
> 
> Funny, I've been lurking on this list for some time now and I've never 
> seen you show any propensity for argumentation. ;-) You always seem so 
> quiet and reserved.

Oh, I have conniptions now and then. I just try really had to keep
them few and far between ;)

> But seriously. What do you mean by "improving the Perl integration"? 
> Are you referring to the integration of Perl and Wx or the ability of 
> wxGlade to generate Perl code?

Honestly, I have no idea what I was refering to. This was just a 
hand waving.

> I guess the thing I have against tools written in one language 
> generating code in another is that something is always lost in 
> translation. Like the saying goes "Nothing does perl like perl." Take 
> the new perl plug-in for Eclipse. Great idea, but I would imagine that 
> there is a lot of perl syntax that a Java framework won't be able to 
> deal with. Maybe I'm wrong but I think that anyone using Eclipse to 
> write perl code will need to avoid most of the more interesting 
> syntactic sugar because Java won't know what to do with it.

Interesting example. Perl 6's grammar is written in Perl [56].
Currently Perl 5, ultimately translated to Perl 6, and there is a
goal of generating a library from the compiled Perl 6 that 
syntax highlighting editors can plug into. This design is to
cope with the syntax becoming even more heuristic. 

Even a Java IDE could do a good job with Perl if the interesting bits
of Perl were properly exposed. Perl's grammar is a good start. 
A running Perl program alone knows about it's class heirarchy,
so some sort of XS/Perl library to expose this would be helpful.
Same for function and method signitures. 

I have no idea how any of the GUI builders for Perl work - I'd
love to learn more about this when I have more time. Slashdot
had a book review a while back that looks interesting -

"MySQL: Building User Interfaces" - talks about Glade among other things.
http://books.slashdot.org/books/04/02/05/1824255.shtml?tid=126&tid=137&tid=156&tid=185&tid=198

But off the top of my head, my impression of Glade is that it generates
the user interface as a bunch files that call call-backs in your code,
making a sort of compile-link-run thing. If wx does the same thing,
making this process interactive would be a worthwhile endeaver. The
glue between the wx builder and Perl could be a Perl application
with XS that links to the embedded builder, runs a run-loop for the
builder's "build a GUI" user interface, takes commands bits of Perl
interactively, eval's them inside of a "sub { }", uses B.pm to convert
the code reference to a B::CV object using B::svref_2object(), 
finds the root bytecode, and splices it at the correct point in
the running program. When the user is happy with the interfave they've
interactively built, B::Deparse could save it as a Perl source code.
Or perhaps that's overly complex =) Making it interactive, where
people can constantly bounce between working on the GUI and working
on the event handlers, would be really nifty. (Or perhaps this 
already works and I'm just more ignorant than I estimated - if so,
I'll try to suggest something else. I love making work for people.).

> And that brings me to another of your points. The idea of "glue in 
> other languages" to allow them to use perl code sounds good, but I 
> don't think anything short of embedding a full perl interpreter is 
> going to work. I don't imagine that's what you had in mind. Are you 
> aware of any languages that have actually embedded perl? I seem to 
> remember that M$ promised that the CRL would allow you to run any 
> language but that when someone tried to create an interpreter for perl 
> they had trouble with the fact that it was dynamically typed.

There was an interesting rant, er, paper at javalobby about exactly
how language independent the CLR is: 

http://www.javalobby.org/pdf/clr.pdf

One of the conclusions was that the more general a VM is, the more
equally bad at everything it is, the CLR is somewhere in the middle.
It was designed to do certain things well, to be able to do some things,
and completely ignored others. The JVM has the same story but 
it actually has far more languages running on top of it anyway than
the CLR does (though things change):

http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html

In fact, someone started to implement Perl on top of the JVM in a proof
of concept. It used a dynamic language layer written for a Scheme-on-Java
project. This makes dynamic types and closures possible. Just like Python
on the JVM, a large amount of the Perl core would have to be ported to
JVM to make this fully operational. Of course, this could be done in Java -
Jython itself is written in Java. Speaking of, Python was implemented
on top of the CLR (I'll dig up the reference if you're interested). 
This is one of those "you could, but it would be ugly, but there's
a lot of demand, so maybe ugliness is okey" areas.

I'm futzing around with compiling Perl 6 back to the Perl 5 VM
(I really want a Perl compiler written in Perl - all truely cool
languages interpret/compile themselves (Scheme, Forth, C) - and
I don't think Perl 6's fate should be tied to Parrot, and I think
I could get something beta before Parrot does) so this topic is
of particular interest to me =)

To address your comment rather than imagining you cared about something
I felt like talking about, yes, embed Perl. Perl has been embedded in
vi, Apache, Postgres (as a PL language - rock!), and, er, lots of other
things (*vigerous hand waving*). Or, alternatively, link Perl to the
wx builder using XS, if you can split the code up into application and
library parts. If you can split the application up into application
and library parts and you don't want to learn XS (scary - I haven't
gone there yet), Inline::C kicks ass. 

> No rant intended. Just juxtaposing myself. (And man did it hurt!)

> Anyway, all I'm really looking for is a perl project to help me keep my 
> experience up. I almost never get to write in perl anymore.

One thing I've learned (and I should really start a file of "one thing I learned"
since I'm turning into a crotchety, forgetful old bastard) is that my willingness
to later maintain something I've written is always near 0, no matter how
cool the project seemed going in. I've worked for a year on a project,
moved to something else, and the first one has just bitrot. And it was
never working as well as I thought. Or the times change faster than it seemed
like they ever would. So I've learned to only spend signficiant energies on things
that are excedingly fun to work on but I don't mind abandoning, or else 
work on things that inheritly don't need maitence from me (such as bug fixes
to other peoples projects, or significant new features to others people
code that other people would be willing to maintain), or else things
that other people would happily get involved with and take over if needed
(and this last case is extremely rare, dispite the Cathedral and the Bizarre
effect on large projects like Linux and Apache - yet this is the model
that most people assume when going into a project). So I could translate this
as saying that I've learned to submit patches and features to other
projects rather than writing my own, or else just write things for fun
and make it a quick hack. This repeats what I said in my first email -
sorry - but I've had a chance to formalize my thoughts a bit more. 
(I should have been a priest - I'm a born preacher, and the hours would
be shorter and I'd be paid better as a preacher).

> Well, thanks for listening.

No, thank YOU for listening =)
Whatever you do (write this in Perl, hack on the existing code, do something else,
do nothing), make sure you have fun. Programming is nothing if it isn't fun.
Keep us posted on your progress - if you create something workable, you'll be
asked to present ;)

-scott

> Chris.
> 
> On Jun 18, 2004, at 8:02 PM, Scott Walters wrote:
> 
> > Hi Chris,
> >
> > I don't know of anything that does this, but I wasn't aware that there 
> > was
> > a GUI builder for wx at all. I only knew about Glade.
> >
> > My money is always on integration. To use a near by analogy: There are 
> > entirely
> > too many windowing toolkits out there.. Tk, Gtk, wx, Prima, X11::Motif,
> > qt... probably some others I'm forgetting. Translating the
> > features of one application into an implementation in another
> > language creates more forks, more code to maintain, more "standards".
> > Tk was widely successful because people wrote bindings for
> > it for Scheme, Python, Perl, and even Java if I'm not mistaken.
> > This was good for Scheme, Python, and Perl (thought the Java camp
> > could care less). This in turn was good for Tk (again).
> >
> > I certainly understand the urge to take out the bulldozer and
> > flatten my workspace before I start writing code, but there is a lot
> > of incentive to resist this uge.
> >
> > Specifically, your energies would be better spent, in my
> > opinion, improving the Perl integration, making it less C-ish and
> > more language netural, improving documentation so that other people
> > don't have to meddle in guts of other languages. This would involve
> > learning Python, but learning new languages is kind of fun and very
> > educational. The Python people did get a few things right.
> >
> > Here's another story. Majordomo is old, crufty, and not that well
> > maintained. It's written in Perl. Mailman is new, and written by
> > a friend of mine who is a security fiend, but it's written in Python.
> > You may have noticed that the mail list changed recently from
> > Majordomo to Mailman after what word of mouth says was a security
> > breech. This, for the Perl users group lists. Outrage? Or wisdom?
> >
> > And another story. PHP has PEAR. Perl has CPAN. CPAN is hugely
> > valuable to Perl and a lot of the success of the language is
> > attributable to the producitivity boost CPAN brings. I'd love to
> > see glue in other languages so that you can use CPAN, much like
> > you can use Inline::Java to get at the AWT from Perl, or use
> > Win32::* to get at the GDI, or use Inline::C to get any any
> > C library. Rather than the PHP camp making any sort of generic glue at 
> > all,
> > they decided to reimplement the best parts of CPAN. This probably 
> > sounded
> > like a perfectly reasonable idea to them, but you and I, with our 
> > understanding
> > of what CPAN is and it's massive scope, find this absurd. I know I do.
> >
> > Okey, end rant. Mind you, I like to argue strongly for things that I
> > don't really feel very strongly about, and just because I have a
> > page full of "reasons" that things should be done one way doesn't mean
> > I won't change my mind in my sleep tonight. So take this all with a 
> > grain
> > of salt. It's just my knee jerk reaction. If I tried really hard, I'm 
> > sure
> > I could make a convincing argument for rewriting it in Perl too ;)
> > So I hope this is at least food for thought.
> >
> > Cheers,
> > -scott
> >
> >
> > On  0, Chris Krum <cakrum at cox.net> wrote:
> >>
> >> I'm looking for a drag&drop UI builder for wxPerl that's written in
> >> Perl. Any such animal out there? I've seen wxGlade and others that can
> >> DO wxPerl but they're written in Python etc. so if I want to make
> >> changes I'll have to learn a new language. Barring the existence of an
> >> established project, would it be a worthwhile endeavour to start my
> >> own?
> >>
> >> Thanks,
> >> Chris.
> >>
> >> _______________________________________________
> >> Phoenix-pm mailing list
> >> Phoenix-pm at pm.org
> >> http://www.pm.org/mailman/listinfo/phoenix-pm
> >
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://www.pm.org/mailman/listinfo/phoenix-pm