Greetings fellow Monks.
Given the short week (thank you Thanksgiving), I am able to relax at work and join in some PerlMonks fun. I would like to present the idea of Perl as an interface and see other thoughts about using Perl in this fashion.
At work we had the opportunity (or rather the necessity) to rewrite a tool that we had been using for quite some time. The tool (like many we use) was an in-house tool and quite custom. The problem was that the interface was custom as well.
Originally, the tool took a simple input file with simple settings such as x=2, y=3, etc. This, of course, lacked power that some users needed, so the input file eventually evolved into its own language. There were two main problems with this. First, the language wasn't mature and didn't follow closely to other languages and common syntax. Secondly, for those who wanted to learn, the documentation was sparse because the programmers working on it needed time to code, not to document. Most of the learning was done by example code and going straight to the developers and asking, "How do I do this?"
Another item to note about this tool is that the users were constantly waiting on new versions to implement the features that they needed. I'll come back to this point later.
I was fortunate enough to be on the design team for the rewite. There were about five of us plus a manager. We were discussing the user interface for the new tool. One of my colleagues and I were strong advocates of Perl and wanted to attempt to make a perl interface. The idea is that most of the code would stay in C to be fast, but the Perl interface would solve many problems that we faced with our user base. It was a struggle between the older "Keep it the same" coders and the younger "Flexiblity is power" users, but we finally decided on trying the Perl interface.
Fast-forward to today. As I look back, I am certain that we made the right decision. All of the input files are written in Perl so we inherited all of Perl's power in the language. The back-end is still C so that we can reuse the parts of the original tool and keep the right parts fast. The new-hires do not need to learn a new language as Perl is common. If they do not know perl however, they can pick up a book and learn the syntax to use the tool. So we also got some documentation for free. As I pointed out above, our user base is constantly in search of new features. It turns out that by exposing some of the internals to the Perl interface, the power users were able to work through some of the problems until certain features matured.
We did have some difficulties intially getting Perl connected as the interface, but it seems in the end that it was a cheap price to pay for the power it gave us. I do consider it a big win for this small group. However, not everyone here shares my sentiment.
We have other tools that suffer from the same problems and are approaching rewrites. I will push for a Perl interface because I think that it works, and works well.
My questions for you are:
Have you ever done anything like this?
Would you consider doing it again?
What alternatives do you see ( Lua)?
What is your favorite color?
Enjoy.
|
Re: Perl as an Interface
by dragonchild (Archbishop) on Nov 22, 2004 at 17:41 UTC
|
I once worked on a similar-sounding tool, to automate testing of a rather complex component in mobile phone systems. The initial goal was to create a commandline interface so that the testers could do their work. Each command would map back to a Perl function, which could then do whatever the heck it wanted.
However, the testers eventually wanted a way to batch up their commands, similar to how bash or sh does shell commands. So, we implemented a very simple, almost ASM-like scripting language for the application commands.
For most of the users, this was plenty. However, for the power users, we provide an "eval" command, which allowed them, if they wanted, to dig into the internals and do whatever they wanted from a Perl perspective. Of course, it was highly undocumented and required close cooperation from the developer(s).
We found that this was probably the best compromise. You give 100% of the users 90% of what they really end up needing and 90% of the users 100% of what they'll ever need. Then, you allow a safety valve for that 10% of what 10% of the users will want to do.
This is very similar to what Paul Graham describes in his essays on ViaWeb and the RTML language they created. The goal is to minimize the use of the safety valve by tracking what users do and, if they seem to use the safety valve for the same thing over and over, you make it so that they don't need the valve. It ends up being that the safety valve is a way for you to get enhancement requests. :-)
As for Perl itself being the interface ... Perl is a programming language. Unless your users are programmers, Perl is too complex and rich to be a good interface. That was the initial version of the tool I'm describing. A good set of commandline options will do 90% of what's needed. After that, it's just a matter of watching the power users and evolving over time.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
Re: Perl as an Interface
by coreolyn (Parson) on Nov 22, 2004 at 18:35 UTC
|
Have you ever done anything like this?
Sure did and it's probably one of my favorite achievements though I'm no longer associated with it. I created a build and deploy framework for J2EE applications that wrapped Ant build scripts with deployment options for various application servers in multiple configurations. All options able to be either config file driven or set from the command line. It's been in use at the pace of about 30-40 deployments a day for the last 4 years.
Would you consider doing it again?
Sure would, but this time I'd like to see a budget for my work up front instead of it having come from "The time void". The fact is if I handn't just done it on my own initiative, if I had persued it via the appropriate channels, it never would have been allowed to be developed.
What alternatives do you see (Lua)?
Gotta say that being able to push Python into Jython(Java classes) really makes me think I'd have to consider the Python option
What is your favorite color?
Green -- the color of life according to my kitchen sink anyway... :)
| [reply] |
|
|
Green -- the color of life according to my kitchen sink anyway... :)
++ just for that! :-p
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
Re: Perl as an Interface
by samtregar (Abbot) on Nov 22, 2004 at 21:25 UTC
|
Have you ever done anything like this?
Yes. During the design of Krang's element system I opted for a system based on Perl modules rather than rows in the database, which is how Bricolage did things. The result has been a huge increase in the power and flexibility of the system. It's possible to do just about anything with an element now. Better yet, through the magic of inheritence element systems can be reused and specialized for different uses.
However, there has been a cost: only Perl programmers can do element development in Krang. In Bricolage a suitably educated user can at least sketch out new elements.
-sam
| [reply] |
Re: Perl as an Interface
by pg (Canon) on Nov 22, 2004 at 18:29 UTC
|
| [reply] |
|
|
I agree with the above statements. In our case, the interface was the configuration files. So, our input files turned into small Perl scripts. Those that knew Perl could take advantage immediately and those that didn't could use the examples or small documentation we provided on how to write the input files.
It is important to note that this tool was for people who must program as part of their daily job. So maybe the Perl interface is a better match for that reason. dragonchild alluded to this in the post above; for this to be truly effective, the users should be programmers.
| [reply] |
|
|
