Programming Languages and Design Patterns

Question

Hello,

different programming languages have different features or lack certain features. Design patterns are a way to work around those shortcomings. I have seen the books and lists about design patterns in static, object oriented languages (Java, C++), but also the Videos about design patterns in Python.

I'm interested in to see some common design patterns in other languages like Forth, Icon, Lisp etc. A short description how they look like and why are they needed in a language would be nice. Maybe a short comparision to another language that solves this problem without a design pattern.

Answer 1

In Lisp, instead of design patterns you are using:

• lambda and closure (anonymous functions and capture environments)
• higher order functions (functions dealing with functions)
• macros (syntax extesnions)
• different evaluation strategies (lazy evaluation, backtracking)
• first class functions, classes, namespaces, modules, etc.
• dynamic environment (e.g. replace functions at any time)
• etc.

I don't really know what a design pattern means in this context. If a design pattern is a recipe which one should follow to solve certain kinds of problems, then it is a lack of feature in the programming language or the environment. Computers can handle repetitive tasks pretty well, so design patterns must be implemented and just called with the actual parameters.

Answer 2

For design pattern in LISP, you could read this, by Peter Norvig.

Quoting this slide:

16 of the 23 design patterns are either invisible or simpler

Answer 3

Design Patterns aren't really meant to be tied to any language. They are more general solutions to common problems.

Answer 4

Delegates and events in C# and .Net make it trivial to implement the observer pattern, since it is so commonly used, e.g. to handle GUI events.

Answer 5

Design patterns are sometimes called "idioms". In non-OO languages (C, Forth, COBOL, etc.) they're just "the usual ways of doing things". Sometimes, they're called "algorithms". Every languages (indeed, every discipline) has patterns of designing solutions.

If you've seen something two or three times, you've seen a pattern. If you can describe the context, the problem, the solution and and consequences, you've elevated the pattern from something vague to something concrete and specific.

In non-OO languages, the patterns aren't often named and catalogued. Don't know why this would be the case, it it seems to be so.