News for hackers. Stuff that matters.
Re:“Design Patterns” Aren't (2002) by infinity0 on Tuesday November 01, 2016 @05:25PM (#12850167)
This is what strongly-typed functional programming languages have been teaching and preaching and practising for years.
Re:“Design Patterns” Aren't (2002) by oomkiller on Tuesday November 01, 2016 @05:33PM (#12850238)
Can you provide more detail, this is very intriguing. Do you mean that the types are the patterns?
Re:“Design Patterns” Aren't (2002) by throwsincenotpc on Tuesday November 01, 2016 @05:40PM (#12850266)
Not the OP but let's take a tree. In F# it's trivial to describe what a tree structure is with the type system. In Java, you'll need to use the Composite pattern and write classes (tree + leaf) to create a tree like structure. Thus the Composite pattern is made irrelevant in F# since an algebraic type system allows you to describe an intent without writing imperative code.

https://en.wikipedia.org/wiki/Composite_pattern

https://en.wikipedia.org/wiki/Algebraic_data_type

Good type systems are a trade-off between complexity and expressiveness, but it's something that is hard to get right. Obviously Java's type system is simpler thus in theory easier to learn. But in practice F#'s is easier to use if understood and might lead to smaller thus more maintainable code bases.

Re:“Design Patterns” Aren't (2002) by stass on Tuesday November 01, 2016 @11:05PM (#12851969)
It's not really a property of a functional or strongly typed language. Trees are trivial to define and iterate over in e.g. Prolog or Erlang as well. The essential thing here is the first class support for structured/abstract data types.