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.

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...

/duck!

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.

Prost,
Moe

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>>
@
[download]

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 perl.com. 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.

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.

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.