patterns, language and syntax

[stefp]

This was originally an anwer to Tilly on Any interesting philosophy of programming articles to recommend?, but it has grown into a full fledged meditation.

The Open Source communauty (and the Free Sotware one for the purists) insists to much on code because that is the thing that is compiled to working code and is licenced.

But the notion of a common culture is as much important because it is the ultimate enabler; and social and technical structures that host porters, mongers and monks are necessary ecosystems, We must learn the conceptual software building blocks and have a common language to talk about them. For example, I am amazed how many programmers don't know the concept of iterators.

This culture evolution goes toward increased abstraction. For example, it starts close to the hardware with goto, then the syntax of languages captures the notion of loop, then the idea of a state capturing the iteration and so on. Design Patterns, Elements of Reusable Object Oriented Software ISBN 0-201-63361-2 is about such patterns, but usually of higher level. The examples are in C++

Most books are about languages (and how to use them) and algorithms. This one is original because it focuses instead on higher object oriented patterns not captured directly by syntax of current languages (but can nevertheless be expressed in them). It names these patterns and describes them, giving a common vocabulary to programmers.

The most important long term programming activity is indeed to identify patterns and capture them in the syntax of languages and libraries. They don't have to be as high a level as in "Design patterns".

Indeed, one of the reasons of the success of Perl is its ability to capture the essence of patterns, but lower levels ones, maps (aka hashes), arrays and operation on them. Compare that with the approach of C++ which must resort to a standard library and templates. In Perl you do: grep { whatever } keys %a while in C++ you must explicitely create iterator objects.

Languages like C++ have instead focused directly on capturing higher patterns but not necessarily well established ones. As a result C++ imposes on you a certain view of Object Orientation.

On the other hand, Larry seems to indefinitively deferring the support of higher patterns inside the language. But, as a result it is up to the communauty to select the best higher patterns. For example, he forces us to use the lowly @_ to pass parameters. But eventually with perl5, we discover we can pass references to hashes that is a richer mechanism than positional parameters. Eventually damian (?) comes in the upcoming perl6 with the pair concept that makes things even more powerful.

Good support of low-level patterns foster the creation and selection of good high patterns. Early specialization can lead to evolutionnary dead-ends.

Some books like Mastering Algorithms with Perl" or <a href=|http://www1.fatbrain.com/asp/BookInfo/BookInfo.asp?theisbn=1565922433&from=MDZ411">the Perl Cookbook are invaluable to explain how to map patterns in the perl syntax.

To finish on patterns, one must be careful to understand the spirit of a pattern and not to be stuck by the letter of it. Writing print "hello world" is equivalent of declaring a Main class with a main method printing "hello world\n" using some System.print() method.

Like natural languages, Perl encourages ellipsis, that is dropping altogether unformative or redundant material. One thing is to identify patterns, an altogether different issue is to find how to express them (or here not explicely express them). This is not because a complex pattern captures a simpler one that we must be forced to used the complex pattern. Nevertheless it is good to identify the simple pattern as a particular case of a richer one because someday it will indeed be good to evolve it to the richer pattern. As a result of expressivness, like natural languages, Perl is hightly irregular and hard to learn, but it is the cost of real expressiveness. I am not surprised that Perl comes from someone who insists on its linguistic background. A mathematical or engineering scientific background is not enough to design a expressive language.

So unlike what is said by Molière who jokes about Jourdain who discovers he is speaking in prose, it is useful to introduce words and concepts if they can help us to better grasp the "world". But there is indeed, a fine line between mere "echolalie" and a structured discourse. So it is probably good to joke about pedant teachers and their victims.

thanks to Hofmator for giving me the links to the books. I did not doctored them, so I hope he will get credit from FatBrain :)
and to Rudif for pointing us to www.classicreader.com

-- stefp

[clemburg]

Most books are about languages (and how to use them) and algorithms. This one is original because it focuses instead on higher object oriented patterns not captured directly by syntax of current languages (but can nevertheless be expressed in them). It names these patterns and describes them, giving a common vocabulary to programmers.

You might be interested in Design Patterns in Dynamic Programming by Peter Norvig.

This presentation shows how to express common Design Patterns in Common Lisp.

It classifies Design Patterns into three levels:

• Invisible: So much a part of language that you don’t notice (e.g. when class replaced all uses of struct in C++, no more “Encapsulated Class” pattern)
• Informal: Design pattern in prose; refer to by name, but must be implemented from scratch for each use
• Formal: Implement pattern itself within the language -Instantiate/call it for each use - Usually implemented with macros

And concludes:

16 of 23 patterns are either invisible or simpler, due to:

• First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility
• First-class functions (4): Command, Strategy, Template-Method, Visitor
• Macros (2): Interpreter, Iterator
• Method Combination (2): Mediator, Observer
• Multimethods (1): Builder
• Modules (1): Facade

This matches my personal observation that after learning programming in Scheme and Common Lisp, I often find the standard object-oriented languages like C++ and Java to be clumsy and lacking abstraction features (no functions as first-class objects (no closures, no functions as return values), no access to continuations (call-with-current-continuation (call/cc)), no macros, just to name the most important ones). Patterns like "Strategy" or the common C++ "Functor" idiom simply look like an indicator of poor language design when viewed from the perspective of a language with first-class functions.

The paper continues with an interesting historical observation:

Long ago, subroutine call was just a pattern

• Involves two parts: call and definition

  load R1, x       SQRT: 
  load R0, *+2     ...
  branch SQRT      branch @R0
  

• Nowadays, made formal by the language

  sqrt(x);         function sqrt(x) ...
  

So yes, indeed, the real task is to put all these Design Pattern stories into code. If the languages we use do not support this, we should change them to do so.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

[Hofmator]

Just to make the access easier, here are the links to the books you mention:

• Design Patterns: Elements of Reusable Object Oriented Software (your ISBN had a small typo :)
• Mastering Algorithms with Perl
• The Perl Cookbook

-- Hofmator

[Anonymous Monk]

... and of course Le Bourgeois Gentilhomme aka The Middle Class Gentleman

Rudif

[stefp]

This page from Norvig is interesting for many reasons. He is searching a langage with a syntax more expressive than Lisp but less convoluted than Perl to use for its example of code in his books.

Without citing explicitely Perl motto Perl makes easy things easy and hard things possible, he uses it as an operational criteria that I call the expressivness criteria. So his new language of choice to convey code examples is Python. He compares lisp to python as a way to teach python to lisp programmers.

I cite (but you should read the whole page):

Python has the philosophy of making sensible compromises that make the easy things very easy, and don't preclude too many hard things. In my opinion it does a very good job. The easy things are easy, the harder things are progressively harder, and you tend not to notice the inconsistencies. Lisp has the philosophy of making fewer compromises: of providing a very powerful and totally consistent core. This can make Lisp harder to learn because you operate at a higher level of abstraction right from the start and because you need to understand what you're doing, rather than just relying on what feels or looks nice. But it also means that in Lisp it is easier to add levels of abstraction and complexity; Lisp makes the very hard things not too hard.

This remark confirms my hypothesis. A good language does not early freeze in its syntax of too high level (unproven) patterns but sensible low level patterns from which to build upon. Nevertheless it is eventually good at some point to capture proven patterns in the language syntax to make it more expressive.

Lisp failed to do that over its very long course, so Norvig is compelled to provide his examples in a newer language: Python. Another reason is the availability of JPython that makes python available accross the board.

-- stefp

[stefp]

Continuing my language quest.and their support of low level patterms...
I am reading A Comparative Overview of C# by the author of c# essentials. C# has foreach statement. To bad it falls short of the grep one.

C# is a good compromise that fits a gaps left between Java and C++. Java feels like severe bondage too me and C++ is way to complex.

Another interesting resource that compares the java and the .net frameworks and takes care of explaining all the TLAs.

An example: The Microsoft's implementation and adaptation of the above standard has resulted in difference in terminology, for example Common Intermediate Language (CIL) is called Microsoft Intermediate Language (MSIL) and Common Language Infrastructure (CLI) is referred to as Common Language Runtime (CLR).

-- <a href="

-- stefp