Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Dominus (464)

Dominus
  mjd@plover.com
http://blog.plover.com/
AOL IM: bigblueoctopus (Add Buddy, Send Message)
Jabber: mjd@upenn.edu

I wrote "Higher-Order Perl".
+ -

  Comment: Perl '67 (Score 1) on 2010.03.09 11:10

by Dominus on 2010.03.09 11:10 (#71763)
Attached to: The ghost of Algol 68

I had a similar experience about fifteen years ago. I was reading a description of a late-sixties-era programming language and thought "wow, this sounds just like Perl".

Here is the description:

PERL (Practical Extraction and Report Language) is a programming language developed with the intention of combining features of commercial languages (such as COBOL) and scientific languages (such as ALGOL). Commercial applications with their emphasis on efficient handling of large volumes of data have led to the development of languages with sophisticated input/output facilities; scientific problems with their emphasis on rapid definitions and description of complex problems have led to the development of highly sophisticated algorithmic languages while neglecting the data handling aspects. PERL aims at combining the problem-solving facility of scientific languages with the data-handling capabilities of commercial languages, in order to meet the needs of increasingly mathematical commercial analysis and increasingly large volumes of data being processed by scientific routines. Among the more important features of PERL are the following:

  1. The language is modular in structure. This means that the user need only master the set of facilities necessary for his programming needs. More complex problems can use more extensive subsets of the language.
  2. The language has a `default' feature by which every error or unspecified option is given a valid interpretation, thus minimizing the effects of programming errors.
  3. The language structure is `free form'. No special documents are needed for coding, since the significance of each statement depends on its own format and not on its position within a fixed framework.

An example of PERL is given below; it is a routine designed to read the maximum and minimum temperature for each day of the week.

The language being described was actually PL/I.

Read More 10 comments
Comments: 10
+ -

  Comment: Higher-Order Perl as a catalog of design patterns (Score 1) on 2009.11.05 13:04

by Dominus on 2009.11.05 13:04 (#71046)
Attached to: My favourite Perl Design Pattern
I have a semi-finished blog post sitting around that interprets much of the content of HOP as a catalog of design patterns for Perl. Chapter 4 is probably the best example. Most of that chapter is concerned with methods of implementing generator functions that enumerate large quantities of data, one element at a time.
Read More 6 comments
Comments: 6
+ -

  Comment: Anecdote (Score 1) on 2009.10.13 21:06

by Dominus on 2009.10.13 21:06 (#70867)
Attached to: Synthetic Classes
I once had the chance to give the Red Flags talk in a beautiful conference room that had a giant column smack in the middle. It was a perfect illustration.

"Did the people designing this conference room say 'Let's make a beautiful conference room! It will have lots of windows, to let in natural light, and a big front wall with a giant whiteboard. And best of all, a giant column smack in the middle to block everyone's view of the speaker!'

"No, the column is there because without it, the building would fall down."

Read More 12 comments
Comments: 12
+ -

  Comment: I changed the terminology (Score 1) on 2009.10.13 21:05

by Dominus on 2009.10.13 21:05 (#70866)
Attached to: Synthetic Classes
I realized after a couple of years that architects have the same distinction. They have "structural" and "functional" elements. The simplest example is a tent. It has a functional element, which is the cloth; the cloth is the whole point of the tent, which keeps the rain off of you. But it also has a structural element, the tent pole, whose purpose is to hold up the cloth. The pole is a pure liability. If you could get the cloth to stay up with no pole, you would, but you can't.

So instead of "natural" and "synthetic" I now discuss it in terms of "functional" and "structural" code, which I think makes the point better.

Read More 12 comments
Comments: 12
+ -

  Comment: Re:To TDD or Not To TDD (Score 1) on 2009.03.11 13:00

If you compare two programmers, one using TDD and one not, you have to account for productivity, knowledge, experience, and creative differences between them.

Sociologists deal with that sort of thing all the time. Their methods aren't perfect, but they do manage to get somewhere.

The secret is that you don't compare two programmers; you compare two thousand.

Read More 9 comments
Comments: 9
+ -

  Comment: TDD not useful for HOP? (Score 1) on 2009.03.11 12:53

by Dominus on 2009.03.11 12:53 (#67765)
Attached to: Anecdote Driven Development, or Why I Don't Do TDD
For a lot of the HOP code, TDD would have been useful. My OSCON question was specifically about the "linogram" system of chapter 9.

"Linogram" was a program that was completely unlike any other program I had ever seen. When i started, I had no idea what the input language would be like, no idea how it would work, even no idea of what the program's capabilities would be. If you had asked me "will linogram be able to draw a box with an arrow coming out of the side" I would have said "I think so, but I'm not sure about the arrow". And I also didn't know how a user would ask for such a diagram, or how the program would figure out where the box and arrow went, or how big they were, or how the user would specify those things, or how the actual rendering would be done.

People at OSCON came up to me afterwards and insisted that it was possible, but it became clear that they did not understand what I was talking about. "There must be a specification," a couple of people said. "Just write the tests to check the requirements in the specification." There was an amazing disconnect here between what I was asking and what they were answering.

Often there is a specification, or I at least have some clue what the behavior of the program should be before it is written. But very often the scope of the project is almost completely undefined, and my job, as engineer, is to find some reasonable balance between scope and cost and then implement it.

If someone is still not getting my point, or thinks I should be using TDD anyway in such cases, I invite them to consider this example. I have a great idea for a new kind of word processor for writing philosophic research papers. It will not be a WYSIWIG word processor. Instead, you will draw a picture of the structure of your document and the relationships between the various arguments you intend to make. Then the word processor will let you fill in the details of each argument, checking to make sure that the relationships are as required and that the arguments are sound.

I would love to see this program, and even more I would love to see the tests for this program. Advocates of TDD-everywhere are invited to work up the test suite and send it in.

Or, if you are scratching your head and asking "what do you mean by 'relationships', exactly", then you begin to see the problem.

Read More 9 comments
Comments: 9