Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Potential project - Perl Beads?

by Masem (Monsignor)
on Sep 24, 2001 at 04:29 UTC ( [id://114225]=perlmeditation: print w/replies, xml ) Need Help??

While reading a Java magazine recently, they meantioned the open-source effort Xbeans, which are a set of JavaBean classes that basically are black boxes that can be connected together; the input of one bean is transferred the next bean using XML.

Having tried something similar though not as intensive a while back in JAva, I was wondering if a similar system has been thought about for Perl. In perl, of course, this individual pieces would be called "Perl Beads", a play on the Java Bean concept.

One advantage with perl is that assuming that code can be written properly, the beads can be connected with a simple text description file, and require no extra compilation outside of perl's internal stages. And of course, there's absolutely no reason that a GUI couldn't be written that prepares this file, thus allowing the development of a 'rapid development' processor made of arbitrary Beads.

From a doable aspect, it seems rather simple, since most of the effort should be done by the individual Beads which can be developed by third parties. But as with most other projects I try to start on , I want to see if there's already an effort out there for this. Had anyone heard of anything similar to this?

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
Re: Potental project - Perl Beads?
by dws (Chancellor) on Sep 24, 2001 at 07:05 UTC
    Had anyone heard of anything similar to this?

    This sounds like it might have some overlap with Martin Fowler's exploratory work on Information System Architecture.

    His section on Organizing the Web Server talks about something called a TransformView, which uses XSLT to build chains of XML-to-XML transformations, ending with an XML-to-HTML transformation.

    Fowler has some definite opinions on Beans. It's worth reading through his work to get those opinions in his own words. He comes at them from a very pragmatic angle.

    And even though he's working in Java, many of his architectural ideas map well to Perl.

Re: Potental project - Perl Beads?
by princepawn (Parson) on Sep 24, 2001 at 13:29 UTC
    Well, I would certainly think about the Perl 6 vritual machine in terms of compilation of the bead-to-bead connectivity. There is a website for parrot now: right here

    And when I did neurobiological computer networks, there was an excellent package with 220 little pictures of little blackboxes available called SESAME. And finally, you might look for a small 60-page book called "Machines" which has a bunch of itty bitty little machines that can be hooked together to do computation.

    SESAME("Software Environment for the Simulation of Adaptive Modular Systems") SESAME is a prototypical software implementation which facilitates * Object-oriented building blocks approach. * Contains a large set of C++ classes useful for neural nets, neurocontrol and pattern recognition. No C++ classes can be used as stand alone, though! * C++ classes include CartPole, nondynamic two-robot arms, Lunar Lander, Backpropagation, Feature Maps, Radial Basis Functions, TimeWindows, Fuzzy Set Coding, Potential Fields, Pandemonium, and diverse utility building blocks. * A kernel which is the framework for the C++ classes and allows run-time manipulation, construction, and integration of arbitrary complex and hybrid experiments. * Currently no graphic interface for construction, only for visualization. * Platform is SUN4, XWindows Unfortunately no reasonable good introduction has been written until now. We hope to have something soon. For now we provide papers (eg. NIPS-92), a reference manual (>220 pages), source code (ca. 35.000 lines of code), and a SUN4-executable by ftp only. Sesame and its description is available in various files for anonymous ftp on ftp ftp.gmd.de in the directories /gmd/as/sesame and /gmd/as/paper. Questions to sesame-request@gmd.de; there is only very limited support available.
Re: Potential project - Perl Beads?
by perrin (Chancellor) on Sep 24, 2001 at 17:30 UTC
    I've got an idea. Instead of using XML, which is incredily slow to parse and create, we could just use standard Perl data structures. We'll call them objects. Then we'll need a text language for writing the description of how to connect them. We'll call that Perl.

    Okay, that was kind of mean. However, looking at your examples, I'm pretty sure that no one who isn't already a competent programmer will be able to do anything useful with this visual tool you're talking about. (Tokenizers?) Also, I find that Java developers often spend great amounts of effort building things that are only necessary because Java is so limiting. It's trivial to do code generation in Perl with the power of eval(), so why create an entirely new way to do it? Just define a simple API that Perl Beads objects must implement and make a Tk tool that can hook them up to each other.

Re: Potental project - Perl Beads?
by suaveant (Parson) on Sep 24, 2001 at 07:09 UTC
    Ok, though this sounds like a cool idea, for those of us unfamiliar with java beans a bit of an example of how they are useful and what they would do might help to form a postulation on how useful/easy it would be.

                    - Ant
                    - Some of my best work - Fish Dinner

      First, the concept of a Java Bean is that it is a drop-in component that can be configured by an external mechanism (a so-called 'Bean Box'); this is done by inheriting certain functions, and having specific names for the methods that get and set properties for the Bean (eg getString, setString), thanks to Java's Reflection package. Typically, these end up being GUI elements but there's no need for them to be that way.

      This isn't a problem in perl thanks to numerous ways to introspect a module after loading.

      As for examples, let me try to give a couple. Let's say you wanted a stock quote off a certain web page out of the rest of the junk on the page. Sure, this is a breeze in straightforward perl, but the idea with Beads is that you can put this together without knowing the language to any great extent. So the connection in Beads would be something like:

      ConstantBead : Stores the URL | V HTMLRetriverBead : Retrived the value from the input | : bead and returns the text of the | : HTML page that it refers to V LineMatcherBead : Given a multiline text document, | : return all lines that match a given | : pattern V TokerizerBead : Given a line, returns text that | : matches a given pattern V OutputBead : Prints input text to screen.
      Note that the beads should be sufficiently reusable.

      As another example, let's say I wanted to make a web page of thumbnails from a directory of images. Here's a possible Bead string for that:

      ConstantBead | V DirectoryListingBead | V LineMatcherBead : limit to just .jpg | \ \___________________________ | \_________ \ V \ | LoadImageBead | | | | FileProperties Bead V V | ResizeImageBead StringModifierBead | | | :("<>-thumb.jpg") | V | | SaveImageBead <---------/ / / / / Value Bead HTMLTableGeneratorBead <------------/ :get size | V OutputBead
      Here, I hopefully demonstrate that data sent through beads would need to have synchorization; here, SaveImageBead would wait until it has both inputs from data that was generated by LineMatcherBead, and HTMLTableGeneratorBead would also wait for the same. Note that this means that some beads would run in a threaded environment, while others would be 'batch' operations.

      Again, these examples are easy enough to do in straightforward perl but what I'm aiming for is a way for those not familar with programming or scripting to have a solution to put together advanced 'scripts' without help. While XBeans, the JAva solution, will probably work too, using perl means that you avoid the overhead of instaniting a Java environment, you are probably insured of it working without the installation of additional packages on most *NIX installs, and that adding to the system by third parties should be much simpler than adding to it via Java.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      It's not what you know, but knowing how to find it if you don't know that's important

        So, if I am grokking this correctly, it would almost be like building a super-layer scripting language on top of perl, and each bead is kind of a super function that encompasses popular perl code. Similar to modules or objects, but with a stricter set of rules for defining them... I suppose this could be a useful thing, but maybe not so useful as in java, since java is much more of a pain in the a** than perl :)

        I can see it as a good thing for perl, what I think would go well with it would be the ability to call a bean you didn't have, and the first run of the script would load all necessary beans from a known source, all you would need is use Perl::Beads; Just a thought. I suppose anything in the FAQ or Tutorials section would be fair game for a bead, as well.

        I'm not sure... it sounds plausible, but unless it is designed just right it could easily become so much perl cruft... but if designed right, it might help those less familiar with programming...

                        - Ant
                        - Some of my best work - Fish Dinner

Re: Potential project - Perl Beads?
by dragonchild (Archbishop) on Sep 24, 2001 at 17:21 UTC
    My question would be why duplicate the wheel? I always conceived of Perl as an alternative to JavaBeans for those that didn't want their programming spoon-fed to them. (Now, there's nothing wrong with spoon-feeding. It's very handy, just extremely restrictive.)

    Plus, you'd have to develop the GUI to go along with your Perl Beads, wouldn't you? Otherwise, you now have a reduplication of most of the modules on CPAN in a somewhat non-intuitive-for-programmers format...

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Re: Potential project - Perl Beads?
by princepawn (Parson) on Sep 24, 2001 at 22:54 UTC
     I've got an idea. Instead of using XML, which is incredily slow to parse and create, we could just use standard Perl data structures. We'll call them objects. Then we'll need a text language for writing the description of how to connect them. We'll call that Perl.

    This is exactly why Mark-Jason Dominus wrote Text::Template and it is exactly why it is paradoxical that you would be such a Template Toolkit fiend when it is in fact a 3rd technology between two technologies which can stand quite well on their own two feet (HTML and Perl). As MJD said: "the second you start writing your own language, you realize you need a loop. And then a reference. And pretty soon you realize you need Perl.. and you already know it.. so why not use it! (paraphrase).

    It's trivial to do code generation in Perl with the power of eval(), so why create an entirely new way to do it?
    Perl is a verysyntax-heavy and syntax-complicated language. Now it makes for easy English-like hand-coding, but for program text generation, Prolog and Lisp are the easiest because they have 50-100 times fewer syntactic elements and 100 to 1000 times fewer funny ambiguous overloaded operators and statements. Exageration intentional, but not far off the mark.
      The goal for this idea, as I understand it, is to write a GUI program which allows users to specify connections between components and then generates code to do it. There's no real need to create an intermediary specification language there, since it's so easy to do code generation with Perl. Seriously, it's so simple that beginners often use it too much, eval'ing as a solution to everything.

      Of course, if people WANT to write the specification language by hand then you could use XML for it, or you could use some kind of simple macro language. If it was simple enough, you could use Template Toolkit for it. Regardless, I don't think you'll see non-programmers writing it by hand.

      I don't think the HTML templating debate is really so similar. HTML with templating constructs usually is coded by hand, often by non-programmers, and it doesn't lend itself to the same kind of GUI tool approach that's described here because it's a mix of formatting and simple control structures that can't be fully shown with either a WYSIWYG approach or a flowchart approach (like XBeans seems to have). I generally prefer mini-languages like Template Toolkit over in-line Perl solutions when generating HTML because they make things easier on the HTML coders and help prevent pollution of templates with too much programming logic. These concerns don't really apply to an XBeans project.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://114225]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2024-03-28 21:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found