Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

program design language - a reality?

by ailie (Friar)
on Feb 20, 2001 at 07:29 UTC ( #59568=perlmeditation: print w/replies, xml ) Need Help??

part 1 - the information

According to Code Complete (Steve McConnell, Microsoft Press, 1993), program design language (PDL) was originally described in a paper published by Caine and Gordon in 1975.

Guidelines for effective use of PDL include:

  • Use English*-like statements that precisely describe specific operations
    *or other spoken language
  • Avoid synatic elements from the target programming language. Thinking in programming language constructs eliminates the main benefit of design at a higher level.
  • Write at the level of intent. Describe the meaning of the approach, rather than how the approach will be implemented in the particular programming language.
  • Write PDL at a low enough level that generating code from it will be nearly automatic.

Benefits from using PDL:

  • Reviews are easier - no need to examine source code.
  • PDL supports iterative refinement - successive refinement in small steps allows you to check design as you get more detailed.
  • Changes are easier.
  • Commenting is done for you - turn the PDL into comments.
  • PDL is an easy-to-maintain form of design documentation.

part 2 - the query

This PDL stuff sounds pretty good to me - maybe it's just new to me because I don't have any formal programming training. My background is in science, and I picked up any "programming knowledge" I might possess as the situations presented themselves.

I'm wondering, is PDL something that people actually use?

Replies are listed 'Best First'.
Re: program design language - a reality?
by dws (Chancellor) on Feb 20, 2001 at 11:27 UTC
    To put a bit of historical context around this: In 1975 there weren't many viable display options. Personal graphic workstations were science fiction. This was five years before the then forward-thinking "3M" initiative, where "3M" referred to a machine with 1 Mb of disk, 1 megahertz of processor, and a megapixel (1024 by 1024 by 1 bit) display. Sounds silly now, but this was before the Apple ][, the IBM PC, or the first Mac. In that context, it's not surprising PDL was text-based. Research in graphics design techniques hadn't advanced very far beyond what could be done by pen/pencil and plotter.

    Roll the clock forward two and a half decades. Laptops with 1024 x 840 flat-panel graphics are a commodity, years of methodology wars have reached a momentary truce that's given us UML, and drawing tools like Visio have templates that support it. Getting hardcopy takes a few seconds (or minute, if you have to warm your laser printer up), and costs a few pennies per page.

    Meanwhile, on the software front, languages have evolved that let us specify class structures and interfaces separate from implementation. And people have decided that reviewing these isn't such a bad thing after all.

    PDL was overtaken by technology. Pseudo code remains a viable design technique to be applied now and then, but it's more often than not used as footnotes on UML diagrams.

Re (tilly) 1: program design language - a reality?
by tilly (Archbishop) on Feb 20, 2001 at 19:38 UTC
    I don't think that PDL is in widespread use, but there are definitely people who use it. For instance athompson mentioned using it at Re: Rewriting some code.

    I don't always find it a fit, but I tend to use a variation on the basic idea where I write high-level pseudo-code, turn those into function calls, and then write the functions in a similar way. When I work this way I find that my functions become (well at least to me) both readable and short. In fact my functions average around 10 lines.

    Most people definitely don't do that. OTOH it works for me, and I am arrogant enough to think that I am somewhat better than average...


    So definitely try it. I didn't find that doing it rigidly worked for me, but it was a worthwhile experiment, and I still use a variation on it.

    Now if you will excuse me, I have some pseudo-code to sketch out...

      Most people definitely don't do that

      Consider me a member of your minority. ;-)

      I have always done it this way, little scraps and outlines; successive approximations. My favorite software design tool is a white board and a lot of colors.

      Always keep a song in your heart.
      It's like karaoke for the voices in your head.
      I tend to lay out a new program in simple 4-5 word comments describing the general flow and major function calls. This, I have found, gets me going in the right direction.

      Of course I have to move some of them around as the solution becomes more clear to me.

      But generally speaking, I think tilly... your way of doing things is very similar to mine or should I say "my way is similar to yours" - as far as program design. I still have far to go but my average function is below 20 lines now.


Re: program design language - a reality?
by SilverB1rd (Scribe) on Feb 20, 2001 at 10:27 UTC
    I don't think Microsoft uses it ;)

    I do know that languages are out there that are vary like spoken languages. At my work they use a 4GL(4th generation language) called "Progress" and it reads almost like english.

    I'm just the web guy so I don't get to use it though :(
      Time to get --'d....

      I've used progress... I've worked in a progress shop. I wrote Perl in this shop. Progress is painful. Writing *simple* things in progress are hard, writing hard things are impossible. The 4GL and the DB are tied together so tightly. The DB is *slow* and underpowered, it just now has set logic, as it previously was record logic. I would program in Perl and hit a MySQL DB box about 95,000 dollars cheaper than their transaction server with a 24 hour old dump of the Progress DB imported into a MySQL schema. The OLAP queries I wrote would have taken hours to execute on Progress took minutes or seconds on MySQL. It's late, and this comment makes very little sense, however listen to this bit of advice. 4GL's like Progress and even to a degree even things like COBOL were designed so that "executives" could read a program and understand what it did. We have since found, in programming language research, that is not neccesseraly what you want out of a programming language.

      If you want to describe a problem and a program, use UML. Use visual modeling tools. Use stories. Use use-cases. Use state diagrams. Don't bother with meta-languages. I ain't found a good one yet.

      The extremely tired and cranky ed...
        While eduardo may be a little cranky, it is not without good reason. There is no reason why Perl, C, or even assembly code cannot be programmed in such a fashion that it works as intended, is readable, and is maintainable by someone other than the original author. You don't need a "magic bullet" like PDL to make it happen.

        PDL may have its utility in specific situations, such as desigining a 50 million lines-of-code nuclear missile launcher network operating system, but then you will recall that even PDL developed applications are not without the fundamental element of human error (i.e. the "Y2K" problem).

        Perl, in fact, has it's own built in English meta-language that can make the program easy to read, even for the "manager" types.

        They're called comments.
Re: program design language - a reality?
by danger (Priest) on Feb 21, 2001 at 03:21 UTC

    If you are interested, Literate Programming provides much of the benefits of PDL, and additional benefits as well. You describe your program and define it in a series of named 'chunks' -- within a chunk, you may include other chunks. Then you define/refine each chunk. The chunk names are rather like the pseudo-code. The literate source code file may be 'tangled' into an actual source file, or 'woven' into a typeset document (LaTeX, HTML, or some other format depending the tools you are using).

    So the root chunk (the chunk that defines the program) might look like (for a program called 'faqgrep'):

    <<faqgrep>>= #!/usr/bin/perl -w use strict; <<initialize_variables>> <<read_in_perlfaq_filenames>> <<search_and_print>> <<faqgrep.pod>> @

    And then later you'd create the definition for each of those included chunks (and those may include chunks as well). So you get stepwise refinement and flexible order of presentation (we don't have to present those chunks in the order given, though in a case such as above it probably makes more sense to go linearly). Each of these 'chunks' is preceded (and/or followed) by the explanatory text (usually in LaTeX). Tangling assembles the chunks into the proper order to create your source code, and weaving turns it into a typeset document with any indexing and cross-reference features you (and the LP tool) have implemented.

    To find out more about LP: The faq is located here, and Mark-Jason Dominus has an article on I use the noweb LP tool myself (not religiously though). I've been considering writing up a little introductory LP article for perlmonks, so let me know if you are interested.

Re: program design language - a reality?
by Anonymous Monk on Feb 21, 2001 at 06:42 UTC

    I think that PDL is used as a writer would use an outline. Personally, I'm not that type of writer or programmer. I'd rather just use comments in my code, rather than writing pseudocode (which PDL seems similar to me).

    I think it can be rather useful, but not necessary. It does help those out there (programmers) that do not like to comment their code .. to remember and comment everything and make sure everything is well documented.

Re: program design language - a reality?
by ColonelPanic (Friar) on Feb 21, 2001 at 09:00 UTC
    I think there's a fundamental problem with the idea of PDL. Only the human brain can completely parse English, or any other language. Any attempt to convert this into a form understandable by a computer will be bound by the same strict syntax requirements as any other programming language, only with more typing. Sure you could make it accept multiple ways to do each thing, but that wouldn't necessarily make anything easier. Now, there's only one if statement (broadly speaking). What if there were 17 different right ways to create an if, but also 9 wrong ways? It would be impossible to keep track of, and guess what? you would end up always doing it the same way to avoid confusion. So you end up having a cumbersome language with the same capabilities as a normal language, but far less efficient. In short, I'd like to see an idea like this implemented. I'd also like to use my mental powers to think a nice cup of coffee into existence right about now.

    When's the last time you used duct tape on a duct? --Larry Wall

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2021-11-28 12:20 GMT
Find Nodes?
    Voting Booth?

    No recent polls found