Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re: (OT) Programming as a craft

by woolfy (Hermit)
on Dec 16, 2003 at 13:06 UTC ( #315043=note: print w/ replies, xml ) Need Help??


in reply to Re: (OT) Programming as a craft
in thread (OT) Programming as a craft

Indeed, the automation of programming is still quite far away in time, so it seems. I have witnessed two such attempts first-hand.

I once worked for a company that had two departments (this company ceased to exist over 10 years ago). The department I worked in, produced CBT (Computer-Based Training, or courseware, or Computer-Aided Instruction, etc.). The other department worked on designing AI (Artificial Intelligence): they made systems designed to create AI-applications, and they tried to produce AI-end-user-apps.

The European Community subsidised this AI-department with enormous amounts of money. Some spin-offs of their activities became mildly succesfull, like an application to support decision making. They used LISP to build their AI-system, and argumentably they did that in such a way that the applications could never be fast nor maintainable; that decision-making-support-application was horrendously slow. So they turned to the CBT-department, working with TenCORE (nowadays a dying language). The application was completely rewritten in TenCORE (liz did a lot of that work), after which the speed was acceptable. The app could be used to decide on e.g. the holiday destination for a family, using as many factors as that family wanted. As said, the app was mildly succesful, but it never was succesful enough to make up for the many EU-investments.

This AI-department tried to automate programming. And in the end, they failed, and very soon after the EU stopped investing, the department vanished. Their tools were too simple for so complex a task, their goals too high, and they produced hardly any end-user apps.

Back to TenCORE. That was the second attempt on itself. The creators of TenCORE made a system built on TenCORE itself, TenCORE Producer. Producer was just a higher programming language, simplified, made accessible in a GUI. Hardly any AI in it. At the time, there was also Authorware, built in C. Just like developers with Producer could extend their end-user applications with modules built in TenCORE, CBT-developers using Authorware could use C to extend their apps. By the way, developers used TenCORE and Authorware to create websites, multimedia, games (my company used TenCORE to create and maintain hundreds of websites).

CBT can be considered as automation of education. Producer and Authorware can be considered as automation of programming this CBT.

And why didn't this type of programming conquer the world? Because they are just tools. And there are a lot of other factors that influence success or failure, factors like marketing, economical growth, hype-ability.

Creating good software is a lot like writing good books. Or like good project management. Or like good management of a company. You can have as many good tools as you can find, afford and use, but still the tools make the job easier, they don't do the job, that is done by the people that use the tools.

Because of their complexity (both from a conceptual point of view and the implementation aspect), I think CBT and AI are not merged yet to be used succesfully world-wide. This complexity is not just a problem for the programmers, but certainly as well for managers, marketing people and end-users.

Attention was drawn from the further development of AI in software development because the arrival of new hypes in the nineties, first multimedia, later internet.

Now, there is a lot of simple (!) multimedia on the internet. And a lot of simple CBT on the internet. Even a lot of CBT combined with multimedia. But they all lack AI. I even see that most of this "modern" multimedia and CBT is simpler than what was produced 10 years ago (well, except maybe the games).

I am convinced that Perl-specific graphical editors (like Producer and Authorware) would help Perl (just as it would be the case for other languages, like PHP, Java, Javascript, Python) to become more widely accepted as tools for development for software (not just internet scripts). But I don't know about such graphical editors, and I certainly haven't seen any such editors with AI-qualities.

I think it might be a good step in the good direction when someone builds such a graphical editor in Perl for Perl. It should be easy to use, and it should enable a developer to build applications (CBT, multimedia, database management, computer system management, content management, etc.) without having to know much of the underlying language, Perl.

Next step would be to add AI-techniques to it, so a developer would just have to give the program a description of the app to create, a lot of paramaters and a lot of contents.

The first task of that program would of course be to build courseware to explain the use of the program and the underlying concepts. Because the developers need to understand the thing they are working on/with.


Comment on Re: Re: (OT) Programming as a craft
Re: Re: Re: (OT) Programming as a craft
by hardburn (Abbot) on Dec 16, 2003 at 17:42 UTC

    think it might be a good step in the good direction when someone builds such a graphical editor in Perl for Perl . . .

    Perl is highly non-trivial to parse, which is why a any Perl IDE will have a lot of problems, even for jobs as seemingly simple as syntax highlighting. So I think this is another thing will have to wait for Perl6, where parsing should be easier.

    What I don't understand is why a Perl editor should be written in Perl itself. You're ultimatly dealing with a stream of bytes, which is as a completly language-agnostic concept as you can find.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      What I don't understand is why a Perl editor should be written in Perl itself. You're ultimatly dealing with a stream of bytes, which is as a completly language-agnostic concept as you can find.

      But woolfy was specifically describing a Perl-specific code editor, not an arbitrary-stream-of-bytes editor.

      Beyond just syntax highlighting, such a tool might be expected to support the features of some advanced Java and Smalltalk code editors, like:

      • symbol name lookup (tab-completion for variable names, when typing a function name show an example of the arguments it takes, etc);
      • refactoring editor (for example, select a few lines of code and invoke the "move to new subroutine" refactoring, and automatically have those lines replaced by a call to a new subroutine with proper argument passing and return value assignment);
      • run-time/debugger integration (interpreting code as you type, setting break points, editing code in a running program and then continuing);
      • documentation support (WHYSIWYG POD editor, fill in some kinds of POD automatically);
      • testing support (automatic running of tests in the background, integrated display of profiling results and code or pod coverage analysis);
      • plugin support (to let others add support for working with Class::MethodMaker, Class::Contract, Aspect, or other specialized approaches to Perl coding).

      Even if it only implemented some subset of the above, I think such an editor would be providing real value, beyond the traditional solution of a good text editor with syntax coloring and automatic indenting.

      And I don't see how you could really do justice to such a tool without implementing it in Perl, or at least delegating key portions to an embedded Perl instance.

        And I don't see how you could really do justice to such a tool without implementing it in Perl, or at least delegating key portions to an embedded Perl instance.

        For most of the things you list, a Perl implementation isn't required--you just need the ability to parse Perl. In fact, since some of them will probably require hooks into the perl interpreter (or maybe Parrot), it's preferable to do much of it in C. In particular, the run-time debugger and symbol table lookups will probably be best with interpreter hooks.

        Test script support is probably best done by hooking into Test::Harness, unless there is a particularly good reason to come up with something else. It'd also be nice to be able to write plugins in Perl. However, neither of these things make it absolutely required to write entire editor in Perl (as long as proper hooks are in place).

        I'm not saying a editor written in Perl is a bad idea, just that I don't see what benefit it will bring to the user over any other langauge. There are already too many text editors/IDEs out there, and the same people who keep using vi or emacs will probably keep using them.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

      Perl is highly non-trivial to parse, which is why a any Perl IDE will have a lot of problems, even for jobs as seemingly simple as syntax highlighting.

      Nah, I am using Crimson Editor (a Win app), in which scripts can be executed with a shortcut (create your own macros and make one macro to call perl) and that includes syntax libraries for Perl and other languages. It works nicely. It does not parse Perl, it does not need to, but it works nicely together with perl.exe.

      What I don't understand is why a Perl editor should be written in Perl itself. You're ultimatly dealing with a stream of bytes, which is as a completly language-agnostic concept as you can find.

      Well, in my opinion it should be possible with any good language to create an editor. So why not an editor, written in Perl. And why not a graphical editor. It is a proof of strength, of versatility. It is a goal in itself. Write code with something that is written in Perl code.

      Furthermore, such an editor would be (in addition to the test suites) one of the first things to check when a new release of Perl would be published. If it stopped working, it might be a good sign something is wrong with the new release (yes yes, I know, of course, any editor contains bugs).

      Lastly, a good editor included in the Perl distributions is a nice completion of the package. Install Perl and start working in Perl and with Perl. No extra's needed. And when we're at it, a nice module searching/finding/installation/updating feature in the editor would be much welcomed by at least me.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://315043]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (9)
As of 2014-09-01 12:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (6 votes), past polls