Re: Design Patterns and Functional programming

On Sat, 14 Jul 2007 03:25:12 +0100, Jon Harrop wrote:

However, it says nothing of the differences between paradigms, which is
important if you give yourself that choice.

Because there is no any difference. "Functional" is not a paradigm.

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.

Types systems are still evolving. As for higher order types, like classes
of classes, there are enough problems to make classes right, Them one could
think about programming in terms of their sets.

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.

There is nothing in OOP which should preclude typed functions and the
constant values of. One could even allow functional variables if one
wished.

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.

It provides (requires) a consistent type system. Traditional
functional-style programming is based on ad-hoc types. This is why
inference is so much pressed on. It is an excuse for being lazy, "please,
infer something I might mean, if I knew what!"

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.

Huh, more efforts? What a perfect paradigm! No, optimization is meant as
requiring no efforts on the programmer's side. What you describe is an
inherent deficiency.

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.

So what is in your opinion the meaning of the word "functional"?

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.

My point was not about popularity, people rather enjoy obscure things. C++
is a great example. The point was about a fundamental problem of patterns,
namely about a lack clear understanding what a more or less complex pattern
would match. Pattern decomposition is hard and irregular.

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.

Really? By passing a closure to the constructor? Come on, it is the same
level of abstraction as to use a global variable for an arithmetic goto in
the constructor's body.

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.

So, returning to "mutable values," neither "x" nor "ref x" are mutable.
Values never mutate. Even polymorphic ones do not.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Can I have Interface & Inheritance together for same class?
    ... Anybody who has a solid grasp of the modular programming paradigm will feel quite at home in an OO context. ... learning the OO paradigm by coding in an OOPL is a very poor way to learn the paradigm. ... Learning the OO paradigm using a single 3GL language is harder than learning it if you understand multiple languages. ...
    (comp.object)
  • Re: Dr. Dobbs | Its Time to Get Good at Functional Programming | 12 3, 2008
    ... Javascript and C# 3.0 are the world's most popular functional languages ... and this article about functional programming fails to mention either of ... need to be used by the majority of users according to that paradigm. ...
    (comp.lang.functional)
  • Re: Programming careers
    ... paradigm, so that might work for people for whom the above *doesn't*. ... Unless someone does the same for programming languages I'm afraid I ... I've been tripped up by missing semicolons since 1992, ...
    (rec.arts.sf.composition)
  • Re: Mainstreaming Prolog a Pragmatic Approach?
    ... The role of the word "paradigm" is interesting here. ... "The Paradigms of Programming". ... general approach to solving a problem (he speaks of languages ... be striving for ONE dominant language." ...
    (comp.lang.prolog)
  • OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)
    ... This sub-topic is really about characterising what OOP *is*, ... of programming and I have also done object-oriented programming. ... I have programmed in functional languages, scripting languages, ... (If there is a pattern to many of the IF statements, ...
    (comp.object)