Re: Design Patterns and Functional programming

Dmitry A. Kazakov wrote:
On Wed, 11 Jul 2007 23:24:33 +0100, Jon Harrop wrote:
OO and functional differ in their forms of abstraction: classes vs
functions/functors.

That depends on the settings.

0. It is untyped. There are some bracket constructs and rules to shuffle
brackets disregarding whatever might be within the brackets.

1. It is typed. Functions apply to typed arguments and yield typed
results. Already at this level the carrier of abstractions is type,
neither function nor value. Here the worn issue functional vs.
data-oriented decomposition ceases to exist.

2. The above was classical ADT. What OO adds is sets of types called
classes. Consequently it brings both polymorphic values and polymorphic
functions.

thus
including class decomposition. So the two are equivalent. However, this
says nothing of how much you can check at compile time

Yes, with types you can check far more. In fact you can check undecidable
things. Consider:

type Rational is ...;
type Transcendent is ...;

To check whether X is Transcendent, you should just match its type. The
trick is that the incomputable work is done outside the computer, by the
programmer who chooses the proper type.

or how easy it is to
extend OO or functional decompositions, which are the interesting
questions.

See above. OO can handle sets of types and use functional decomposition on
that level, in the form of polymorphic functions!

For some notions of type, function and polymorphism, that is all true.
However, it says nothing of the differences between paradigms, which is
important if you give yourself that choice.

With regard to type systems: OOP varies from dynamically typed to somewhat
static (e.g. Java) and rather ad-hoc (e.g. C++) but it in no ways excels at
typing. I don't know of any OOP languages that provide higher-order types,
for example.

With regard to "OOP allowing functional decomposition", OOP adds nothing to
ordinary procedural programming with function pointers. In particular,
neither provide first-class lexical closures.

Moreover, OOP itself renders useful static checks inoperable, such as the
exhaustiveness and redundancy checks performed by many languages.

So the important question is "what does OO provide that other paradigms do
not?". I can think of only one thing: covariance and contravariance.

Provided you have laziness, purity only degrades the constant prefactor
and not the asymptotic complexity. Same for dynamic typing.

So, you say it were rather an optimization issue?

Given enough effort, the performance may be recoverable, yes.

Then we have to conclude that states should be scrapped down.

What do you mean by "scrapped down"?

Whatever performance loss might appear it should be marginal,

If performance is important and the algorithm is trivial, I would probably
use mutation, yes.

we could
upgrade the computer and everything would be OK... Either way, your
position is inconsistent.

You may be confusing "purity" with "functional". The statement "purity only
degrades the constant prefactor" applies to the use of const locals rather
than static non-locals in C, for example.

The problem is complexity. Even if you solved all pattern matching
problems which are very hard if the pattern language is any more complex
than regular expressions. Even then, because of this complexity, the
programmer will be unable to understand the program it writes. Patterns
are like gotos. They are *too* powerful and lack any structure.

There is overwhelming evidence to the contrary: many languages have shown
pattern matching to be extremely productive. Many general purpose languages
like Haskell and OCaml integrate pattern matchers into the language. Many
domain specific languages like Mathematica are little more than giant
pattern matchers (term rewriters). The ML family of languages have shown
that pattern matching excels for writing compiler internals.

So there is no question that pattern matching is a hugely productive
language feature and this is why so many modern languages integrate pattern
matchers.

The static type information is still available, you just don't have to
write it down yourself (repeatedly). Note that OCaml inferred the
equivalent of an entire class hierarchy in the example I gave.

How can I know what was inferred?

Concretely, just look at the inferred type. Abstractly, you either use the
defined or inferred language constructs.

Trivial inference is OK. Non-trivial is not.

Absolutely.

The latter is when the programmer identifies types to solve the problem.
Nobody can do it for him.

A mathematician should know the intermediate steps in his proofs. That does
not mean he should have to write them all down.

[Re: dispatch to some virtual method from the constructor]
This breaks the abstraction, because you split one type into two. What
is worse you have to derive from both handling two hierarchies of
types.

Just infer the types. ;-)

You cannot infer transcendent numbers, it is a finite machine after all.

You want a decideable type system, yes. Note that the context here
was "dispatch to some virtual method from the constructor" which is another
OO problem that was already solved by other paradigms and was not related
to transcendent numbers.

The type is denoted:

'a ref

the value is denoted:

ref x

And these type and value are different from the type and the value the
reference points to. No ticks! (:-))

Yes. The type and value referred to are "'a" and "x", respectively.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
.

Relevant Pages

  • Re: Design Patterns and Functional programming
    ... OOP varies from dynamically typed to somewhat ... I don't know of any OOP languages that provide higher-order types, ... With regard to "OOP allowing functional decomposition", ... pattern matching to be extremely productive. ...
    (comp.object)
  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... the model-view-controller design pattern. ... Then you can use pattern matching to manipulate ...
    (comp.object)
  • Universal Translators - undoing babel
    ... the hologram to encode it as a specific image. ... The interference pattern diffracts beams of light creating ... sound waves can be interfered and diffracted as well. ... sounded natural continuous and in each of our respective languages. ...
    (rec.arts.startrek.tech)
  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... this form of static checking requires the pattern matcher to be ... compiler use to parse literals of the type t, that is up to the compiler. ...
    (comp.object)
  • Re: Scheme closures
    ... It's these latter considerations that really limit syntax-rules. ... were writing the macro in a good way. ... > who uses argument pattern matching, ... I like the sort of pattern-matching used in functional languages ...
    (comp.lang.lisp)