re: Lambda requirements VIEW POST

FULL DISCUSSION
 

I've worked with an open-source raytracer called POV, as in "point of view".

POV is a fine example of OOP. It was entirely written in C.

C, as everyone probably knows, is not an OOP language. You can write OOP in C, but the OOP part is all DIY.

If three projects are all written in C, each with their own DIY OOP, none of the OOP frameworks will interoperate with each other.

C++ is not a FP language. You can write FP in C++, but the FP part is all DIY.

Compare to writing an FP program in an FP language, like F# or Haskell, the experience is very different. And, in my opinion, a much better experience to use a FP language to do FP programming.

Programming languages are tools. Those tools are suitable for broad domains.

Using C to do OOP, or using C++ to do FP, is much like using a hammer to pound in a screw. It can be done. But not really the right tool for the job.

There are several FP languages available. I recommend OCaml, or F# (which is pretty much OCaml retooled to be suitable for .NET or Mono), or Haskell, or Elm.

I would recommend against trying to do FP with Python, or C++, or Lisp.

Not because they are bad languages... they're not bad, they're excellent. Rather, because they are not FP languages, and doing FP in those languages will not make for a good FP learning experience.

Here's a good quote from the foreward in The Book of F# by Dave Fancher, which enumerates the attributes of FP have and are easy-and-natural to do in a FP language, that OOP languages lack:

"""
I’ll wind down with a lie that OO people who are learning FP tell one another: “Learning FP will make you a better OO programmer.” It rings true, and in the short run it may even be true, but as you internalize immutability, recursion, pattern matching, higher-order functions, code as data, separation of behavior from data, and referential transparency, you will begin to despise OO. Personally, I went from being a Microsoft C# MVP to feeling guilt every time I created a new class file. Once you understand the defects that can be avoided, it stops being a technical choice and becomes an ethical one.
"""
~ Bryan Hunter, CTO, Firefly Logic

 

I thought POV-Ray = Persistence Of Vision?
Brings back old memories =)

I had a CAML background (there was no O yet, ~1990) and experience with Erlang, but LISP dialects like Clojure, Racket, or Scheme have worked pretty well for me to:

  • upgrade my programming skills from OOOnly towards "practical" FP,
  • become a more "educated" JS coder
  • get a hint at how DSLs/languages/interpreters/compilers actually work
  • take a dive into denotational semantics/lambda calculus
  • try (and enjoy) programming against a modern "strongly statically typed system" with oCAML and Haskell.

Had I started reverse, I think I'd have been overwhelmed at step one.

The algebra of types / cat theory is NOT a requirement for Functional Programming, despite all the efforts to mislead wannabe FPers into believing so, at the risk of turning them away from FP forever.

 

Thanks for the comment!

I also think that "coding FP" in a non-FP language is not the best. However, I think one can get used to some of the concepts in a language of his or her preference. As you said, it is just a tool.
After the phase of adaptation I would jump to a FP language like Haskell or F# too. I started with Haskell back at college and never had a bad time with it, but I've seen lots of people saying that it is too hard to digest at first.
Moreover, this quote truly exhales what I've been feeling for the past year regarding OOP. I never tried F# myself (nor books), but I will definitely look at the book after reading this.
Following your thoughts: once you find you can use a screwdriver rather than a hammer, it feels much better. And you know it is right.

code of conduct - report abuse