Design Patterns and Functional programming - Theory and Concepts

This is a discussion on Design Patterns and Functional programming - Theory and Concepts ; Jon Harrop wrote: > topmind wrote: > > The existence of a language does not prove the utility/benefits of > > weak or strong typing. It only proves implementability. > > Have a look at statically-typed languages with type inference ...

+ Reply to Thread
Page 11 of 20 FirstFirst ... 9 10 11 12 13 ... LastLast
Results 101 to 110 of 198

Design Patterns and Functional programming

  1. Default Re: Design Patterns and Functional programming


    Jon Harrop wrote:
    > topmind wrote:
    > > The existence of a language does not prove the utility/benefits of
    > > weak or strong typing. It only proves implementability.

    >
    > Have a look at statically-typed languages with type inference that Steven
    > referred to. They solved the problems you cited, combining the development
    > speed and brevity of dynamic typing with the assurance of static checking.
    > There is basically no need for dynamic typing now.


    Frankly, it is not my job to present such evidence.

    I agree a language can be a hybrid. I never said it couldn't.

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


    -T-


  2. Default Re: Design Patterns and Functional programming

    On Wed, 11 Jul 2007 23:24:33 +0100, Jon Harrop wrote:

    > Dmitry A. Kazakov wrote:
    >> On Wed, 11 Jul 2007 18:44:25 +0100, Jon Harrop wrote:


    >>> Dmitry A. Kazakov wrote:
    >>>> ? If side effect is functional, then I don't what to say. At least it
    >>>> implies that assignment is functional too.
    >>>
    >>> Exactly, yes.

    >>
    >> Then where is any difference?

    >
    > Elsewhere. :-)
    >
    > 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.

    >> Note that if OO is understood as typed, as ADT, then that necessarily
    >> includes functional decomposition, because one cannot define types without
    >> operations on them.

    >
    > If functions are first-class values then values can represent objects,


    Hmm, why should it? Value could be a natural number 1 from N. Object could
    be a run-time thing used to express 1 in the program. Why would you like to
    have it reverse and to invent some values for objects? [ That were trivial,
    for any program runs on a finite machine and thus have a finite number of
    states. ]

    > 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!

    >>>> Why impurity is needed?
    >>>
    >>> Impurity is not required, as purely functional languages do exist, but it
    >>> offers a different set of trade-offs that are preferable for certain
    >>> classes of user. In particular, impure functional languages are among the
    >>> fastest languages in existence whereas purely functional languages tend
    >>> to trail with dynamically typed languages as the purity requires laziness
    >>> (thunks) and graph traversal for evaluation.

    >>
    >> It seems that you say here that most (how many?) of known algorithms
    >> cannot be implemented in a functional way achieving their theoretical
    >> complexity. E.g. instead of O(log N) you get O(N). If it is indeed so,
    >> then, sorry, you have to scrap your paradigm completely.

    >
    > 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? Then we have to conclude
    that states should be scrapped down. Whatever performance loss might appear
    it should be marginal, we could upgrade the computer and everything would
    be OK... Either way, your position is inconsistent. [ Daniel already tried
    to drive you this conclusion.]

    >>> This is very beneficial in practice as it catches a lot of errors.
    >>> Moreover, this form of static checking requires the pattern matcher to be
    >>> integrated with the type system.

    >>
    >> I don't see why pattern matching is required here, whatever thing the
    >> compiler use to parse literals of the type t, that is up to the compiler.

    >
    > Then compiler leaves it up to the programmer. Consider a trivial pattern
    > match that rotates addition nodes to be left-associative:
    >
    > a+(b+c) -> (a+b)+c


    Huh, that is a road to nowhere. What about this:

    a + (b or c) -> (a + b) or (a + c)

    Or maybe

    a + (b or not c) -> ?

    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.

    > 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? Trivial inference is OK. Non-trivial is
    not. The latter is when the programmer identifies types to solve the
    problem. Nobody can do it for him.

    [...]
    > Just infer the types. ;-)


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

    >>>>> Well, an immutable value cannot have state. Mutable values do, of
    >>>>> course.
    >>>>
    >>>> No, there is no such thing as a mutable value. Mutable can be a
    >>>> variable, parameter, object. They are functions mapping execution states
    >>>> onto values. Switching states just selects another value without
    >>>> changing them.
    >>>
    >>> This is just nomenclature. In OCaml, a mutable reference is a type of
    >>> value:

    >>
    >> Hmm, reference itself should have a type and a value.

    >
    > 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! (:-))

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

  3. Default Re: Design Patterns and Functional programming

    In article <f73c1t$vlq$1@aioe.org>, S Perryman <q@q.net> wrote:

    > JXStern wrote:
    >
    > > On Wed, 11 Jul 2007 17:21:44 +0100, Jon Harrop <jon@ffconsultancy.com>

    >
    > >>I certainly stopped using dynamically typed languages when I found them too
    > >>error-prone for significant projects. Since then I have learned techniques
    > >>to leverage static type systems that let me do things I could not possible
    > >>have done in a dynamically typed language.

    >
    > > As long as the type system supports assertions, I much prefer dynamic.

    >
    > > Suspect you have other process, design, and coding issues if type
    > > errors are a significant problem for you.

    >
    > Weakly-typed prog langs cannot be used across the range that strongly-typed
    > prog langs are. No one builds large-scale safety-critical systems in a
    > prog lang that pops up with "message not understand" errors at runtime
    > when I request the nuclear reactor object to shut-down to prevent
    > melt-down.


    Do you mean 'statically typed'?

    >
    > The only argument there has ever been in favour of weakly-typed prog langs
    > has been for meta-typing based problems or (similarly related) , types for
    > which possession of properties may be conditional. No other forms of
    > problem appear to be easily solvable in weakly-typed prog langs but not
    > similarly so in strongly-typed prog langs.
    >
    >
    > Regards,
    > Steven Perryman


    --
    http://lispm.dyndns.org

  4. Default Re: Design Patterns and Functional programming

    JXStern <JXSternChangeX2R@gte.net> wrote:

    > ON THE OTHER HAND, my own use of OO often comes down to using
    > classes as types (or name-spaces) and not hierarchies anyway,
    > neither single nor multiple inheritance seem to me as fundamentally
    > useful as long as the only relationship they implement is IS-A.


    One could make the argument that if you aren't using dynamic dispatch,
    you aren't doing OO. There is nothing wrong with not using dynamic
    dispatch of course, if the problem doesn't require it.

    For my part, I find that dynamic typed languages shorten development
    time considerably. I think the reason is because they are more condusive
    to change during the development processes. However, I find that when I
    am dropped in the middle of an ongoinng program, static type-systems are
    much easer to understand than dynamic ones. It seems easier to focus on
    what classes go where.

  5. Default Re: Design Patterns and Functional programming

    On Jul 13, 7:05 am, "Daniel T." <danie...@earthlink.net> wrote:
    > JXStern <JXSternChange...@gte.net> wrote:
    > > ON THE OTHER HAND, my own use of OO often comes down to using
    > > classes as types (or name-spaces) and not hierarchies anyway,
    > > neither single nor multiple inheritance seem to me as fundamentally
    > > useful as long as the only relationship they implement is IS-A.

    >
    > One could make the argument that if you aren't using dynamic dispatch,
    > you aren't doing OO.


    May I ask, what is your definition of "dynamic dispatch"?

    > There is nothing wrong with not using dynamic
    > dispatch of course, if the problem doesn't require it.
    >
    > For my part, I find that dynamic typed languages shorten development
    > time considerably. I think the reason is because they are more condusive
    > to change during the development processes. However, I find that when I
    > am dropped in the middle of an ongoinng program, static type-systems are
    > much easer to understand than dynamic ones. It seems easier to focus on
    > what classes go where.




  6. Default Re: Design Patterns and Functional programming

    Daniel T. wrote:
    > For my part, I find that dynamic typed languages shorten development
    > time considerably.


    Have you tried any static languages with type inference?

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

  7. Default Re: Design Patterns and Functional programming

    topmind <topmind@technologist.com> wrote:
    > On Jul 13, 7:05 am, "Daniel T." <danie...@earthlink.net> wrote:
    > > JXStern <JXSternChange...@gte.net> wrote:


    > > > ON THE OTHER HAND, my own use of OO often comes down to using
    > > > classes as types (or name-spaces) and not hierarchies anyway,
    > > > neither single nor multiple inheritance seem to me as fundamentally
    > > > useful as long as the only relationship they implement is IS-A.

    > >
    > > One could make the argument that if you aren't using dynamic dispatch,
    > > you aren't doing OO.

    >
    > May I ask, what is your definition of "dynamic dispatch"?


    Google it. It has a fairly standard definition.

  8. Default Re: Design Patterns and Functional programming

    Jon Harrop <jon@ffconsultancy.com> wrote:
    > Daniel T. wrote:


    > > For my part, I find that dynamic typed languages shorten development
    > > time considerably.

    >
    > Have you tried any static languages with type inference?


    I can't say that I have. I expect though that static languages with type
    inference will suffer the same advantages/disadvantages for me as
    dynamic ones do. AFAIK, the only difference between them and dynamic
    languages is when the type-mismatch is detected.

  9. Default Re: Design Patterns and Functional programming

    Daniel T. wrote:
    > I can't say that I have. I expect though that static languages with type
    > inference will suffer the same advantages/disadvantages for me as
    > dynamic ones do. AFAIK, the only difference between them and dynamic
    > languages is when the type-mismatch is detected.


    If a dynamic language even finds the errors at all.

    Also, static languages tend to be vastly faster as well. Some useful
    techniques are practically impossible without a static type checker
    catching your bugs, e.g. continuation passing style.

    You may be interested in this article by a Python programmer learning OCaml:

    http://members.verizon.net/~olsongt/c3a/

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

  10. Default 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/product...ournal/?usenet

+ Reply to Thread
Page 11 of 20 FirstFirst ... 9 10 11 12 13 ... LastLast

Similar Threads

  1. Replies: 168
    Last Post: 10-21-2007, 08:00 PM
  2. Re: Design Patterns and Functional programming
    By Application Development in forum lisp
    Replies: 4
    Last Post: 07-23-2007, 08:24 PM
  3. Design issues and Design patterns
    By Application Development in forum Object
    Replies: 6
    Last Post: 05-10-2007, 06:53 AM
  4. Design Patterns - Which design pattern to use?
    By Application Development in forum Software-Eng
    Replies: 3
    Last Post: 12-09-2005, 11:35 PM
  5. Design Patterns in OO Computer Programming
    By Application Development in forum C
    Replies: 0
    Last Post: 02-11-2005, 01:58 PM