6 ms·

>No, you aren't going to be doing pure functional programming very often I do every single day. >In the real world, eliminating mutable state is neither possi

>No, you aren't going to be doing pure functional programming very often I do every single day. >In the real world, eliminating mutable state is neither possible nor desirable. Eliminating state is not what functional programming is about. >If you don't know what "flatMap that shit" means, then it's worthwhile to learn it. Scala is a pretty terrible language to be learning it though. Subtyping makes things far more complex and difficult to learn, just for the benefit of java compatibility (which doesn't matter if you are just learning for the sake of learning).

michaelwww 14y ago
I have a question if you care to answer. I was watching "Overview and Introduction to Lisp" (link below.) I was struck by the idea of a function taking a function as input and transforming it to another function as output. My only experience with something similar is JavaScript, but the idea of a function doing function transforms is new to me. Is this the fundamental thing to understand about Functional Programming? http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/1a-overview-and-introduction-to-lisp/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
- papsosouid 14y ago
  I don't know if I would say it is the fundamental thing, but it is certainly an important fundamental thing. I think if I had to pick a single most important fundamental thing I would say it is composability. That is the underlying reason behind things like monads and lenses for example.
  - michaelwww 14y ago
    Thanks. I'm liking what I'm hearing. I hear functional programmers say state is evil, but it seems like a necessary evil. What I agree with more -- and they say this a lot it seems -- is that complexity is evil. I like the focus on building something large from smaller, easily understood parts.
    - papsosouid 14y ago
      State isn't evil, having everything implicitly being able to mutate state is evil. If you keep mutable state, side-effects, etc locked up in their little boxes, then you limit how much they can cause problems.
- martinced 14y ago
  "I was struck by the idea of a function taking a function as input and transforming it to another function as output." That's a higher-order function (HoF). I'd say it's not the fundamental thing to understand about FP: you can even program in a functional way without using them. And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions: elisp, for example (anyone calling elisp functional is automatically setq'ed to crazy ; ) IMHO Lisp dialects aren't inherently functionals. Some are, some aren't. Even Clojure, which definitely puts the emphasis on FP, isn't purely functional, far from it. But you can use it in a functional way (and Java too, in a way -- I used to do "OO over immutable objects" and use "functional Java"). However you'll probably find that when using Lisps in a functional way, you can use higher-order function often. For example if you have, say, a referentially transparent function and want to add memoization for free then it's very convenient to simply (memoize myfunc). Or if you want to "carry the state" of your program through monads (or to use other kind of monads): then you'll need higher-order functions. To me if there is one thing about FP it is simply idempotent / referentially transparent functions which make it easier to reason about the program. I'm simply beginning to "grok" FP, HoFs and Clojure so take this with a grain of salt : )
  - papsosouid 14y ago
    >you can even program in a functional way without using them. For a very tiny limited subset of programs. Anything beyond the most trivial of toy apps will use them. >And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions Where their usefulness is seriously hampered by the language not being functional. This is the primary reason people think HoFs are no big deal. They've never gotten to actually use them in an environment designed to make good use of them.
bad_user 14y ago
Subtyping isn't just for the benefit of Java compatibility. What makes you think that? Such arguments are in general hand-wavy and born out of folklore or personal biases and I hate to appeal to the popularity argument, but in the presence of overwhelming popularity of languages that do have type-systems with subtyping, you do need at least some sort of proof that subtyping is bad in one way or another. Even GHC has extensions for subtyping, without being burdened with Java compatibility. And what are you comparing Scala with exactly? If you're comparing it with Clojure or other LISPs, well that's like comparing apples to oranges, because there's a world of difference between techniques used in static languages like Haskell/ML and Scala on one hand and LISPs on the other. "flatMap" in particular is not something that you see often in Clojure. You don't quite see many instances of monadic types in languages like Clojure either. Scala's Option[T] or Haskell's Maybe are impractical in Clojure so you'll never see it in Clojure unless you're looking at code that was written by a Haskell developer. Etc... Compared to Haskell, Scala does have some disadvantages, however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem ... you've got everything, including capable IDEs like IntelliJ IDEA and people that complain about SBT never tried Cabal, plus with the JVM you can always use Maven or just plain Jars manually copied in a directory.
- papsosouid 14y ago
  >Subtyping isn't just for the benefit of Java compatibility. What makes you think that? No objects = no subtyping. >you do need at least some sort of proof that subtyping is bad in one way or another. Why do I need proof of something I didn't say? >Even GHC has extensions for subtyping, What? >however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem The ecosystem matters the least when learning for learning sake. The complexity and difficulty of the language matter, and scala is a poor choice for that reason. You can't just learn FP with scala, you also have to learn all the hairy OO/FP integration and the ensuing problems around it.
  - bad_user 14y ago
    > No objects = no subtyping. You are confusing OOP with subtyping. On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. > The ecosystem matters the least when learning for learning sake. Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular, because as soon as you read a couple of chapters from a book, it's usually easy to let your imagination loose and build something. In comparison to learning math where proofs are like puzzles, in software engineering the real joy comes from building stuff.
eweise 14y ago
"Scala is a pretty terrible language to be learning it though. Subtyping makes things far more complex and difficult to learn, just for the benefit of java compatibility (which doesn't matter if you are just learning for the sake of learning)." Functional and OO programming are complementary and is the point of Scala. The class explains their relationship.
- papsosouid 14y ago
  The class is called "functional programming principles". As I said, if you want to learn functional programming principles, scala is a poor language to do so, as you can not focus on that subject and have to learn a ton of extra stuff as well.
Garoof 14y ago
"Scala is a pretty terrible language to be learning it though." Pretty good course though. If you want something like that, maybe because you find it helpful to have exercises with deadlines and things, then I'd reccomend the course. But if you have some alternatives you wanna recommend, that'd be awesome. For Haskell, the only similar thing I know of is the Channel 9 stuff with Erik Meijer. And that's cool stuff. But you're much more on your own there than in a Coursera course. So if you want that kind of thing it might not be a good match.
eli_gottlieb 14y ago
Even Benjamin "SML, SML uber alles" Pierce spends a portion of his Types and Programming Languages text contrasting objects with existentially-typed abstract data types, and finding that, IIRC, objects are often the more practical and convenient approach.

michaelwww 14y ago

I have a question if you care to answer. I was watching "Overview and Introduction to Lisp" (link below.) I was struck by the idea of a function taking a function as input and transforming it to another function as output. My only experience with something similar is JavaScript, but the idea of a function doing function transforms is new to me. Is this the fundamental thing to understand about Functional Programming? http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/1a-overview-and-introduction-to-lisp/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...

papsosouid 14y ago
I don't know if I would say it is the fundamental thing, but it is certainly an important fundamental thing. I think if I had to pick a single most important fundamental thing I would say it is composability. That is the underlying reason behind things like monads and lenses for example.
- michaelwww 14y ago
  Thanks. I'm liking what I'm hearing. I hear functional programmers say state is evil, but it seems like a necessary evil. What I agree with more -- and they say this a lot it seems -- is that complexity is evil. I like the focus on building something large from smaller, easily understood parts.
  - papsosouid 14y ago
    State isn't evil, having everything implicitly being able to mutate state is evil. If you keep mutable state, side-effects, etc locked up in their little boxes, then you limit how much they can cause problems.
martinced 14y ago
"I was struck by the idea of a function taking a function as input and transforming it to another function as output." That's a higher-order function (HoF). I'd say it's not the fundamental thing to understand about FP: you can even program in a functional way without using them. And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions: elisp, for example (anyone calling elisp functional is automatically setq'ed to crazy ; ) IMHO Lisp dialects aren't inherently functionals. Some are, some aren't. Even Clojure, which definitely puts the emphasis on FP, isn't purely functional, far from it. But you can use it in a functional way (and Java too, in a way -- I used to do "OO over immutable objects" and use "functional Java"). However you'll probably find that when using Lisps in a functional way, you can use higher-order function often. For example if you have, say, a referentially transparent function and want to add memoization for free then it's very convenient to simply (memoize myfunc). Or if you want to "carry the state" of your program through monads (or to use other kind of monads): then you'll need higher-order functions. To me if there is one thing about FP it is simply idempotent / referentially transparent functions which make it easier to reason about the program. I'm simply beginning to "grok" FP, HoFs and Clojure so take this with a grain of salt : )
- papsosouid 14y ago
  >you can even program in a functional way without using them. For a very tiny limited subset of programs. Anything beyond the most trivial of toy apps will use them. >And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions Where their usefulness is seriously hampered by the language not being functional. This is the primary reason people think HoFs are no big deal. They've never gotten to actually use them in an environment designed to make good use of them.

bad_user 14y ago

Subtyping isn't just for the benefit of Java compatibility. What makes you think that? Such arguments are in general hand-wavy and born out of folklore or personal biases and I hate to appeal to the popularity argument, but in the presence of overwhelming popularity of languages that do have type-systems with subtyping, you do need at least some sort of proof that subtyping is bad in one way or another. Even GHC has extensions for subtyping, without being burdened with Java compatibility. And what are you comparing Scala with exactly? If you're comparing it with Clojure or other LISPs, well that's like comparing apples to oranges, because there's a world of difference between techniques used in static languages like Haskell/ML and Scala on one hand and LISPs on the other. "flatMap" in particular is not something that you see often in Clojure. You don't quite see many instances of monadic types in languages like Clojure either. Scala's Option[T] or Haskell's Maybe are impractical in Clojure so you'll never see it in Clojure unless you're looking at code that was written by a Haskell developer. Etc... Compared to Haskell, Scala does have some disadvantages, however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem ... you've got everything, including capable IDEs like IntelliJ IDEA and people that complain about SBT never tried Cabal, plus with the JVM you can always use Maven or just plain Jars manually copied in a directory.

papsosouid 14y ago
>Subtyping isn't just for the benefit of Java compatibility. What makes you think that? No objects = no subtyping. >you do need at least some sort of proof that subtyping is bad in one way or another. Why do I need proof of something I didn't say? >Even GHC has extensions for subtyping, What? >however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem The ecosystem matters the least when learning for learning sake. The complexity and difficulty of the language matter, and scala is a poor choice for that reason. You can't just learn FP with scala, you also have to learn all the hairy OO/FP integration and the ensuing problems around it.
- bad_user 14y ago
  > No objects = no subtyping. You are confusing OOP with subtyping. On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. > The ecosystem matters the least when learning for learning sake. Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular, because as soon as you read a couple of chapters from a book, it's usually easy to let your imagination loose and build something. In comparison to learning math where proofs are like puzzles, in software engineering the real joy comes from building stuff.

eweise 14y ago

"Scala is a pretty terrible language to be learning it though. Subtyping makes things far more complex and difficult to learn, just for the benefit of java compatibility (which doesn't matter if you are just learning for the sake of learning)." Functional and OO programming are complementary and is the point of Scala. The class explains their relationship.

papsosouid 14y ago
The class is called "functional programming principles". As I said, if you want to learn functional programming principles, scala is a poor language to do so, as you can not focus on that subject and have to learn a ton of extra stuff as well.

Garoof 14y ago

"Scala is a pretty terrible language to be learning it though." Pretty good course though. If you want something like that, maybe because you find it helpful to have exercises with deadlines and things, then I'd reccomend the course. But if you have some alternatives you wanna recommend, that'd be awesome. For Haskell, the only similar thing I know of is the Channel 9 stuff with Erik Meijer. And that's cool stuff. But you're much more on your own there than in a Coursera course. So if you want that kind of thing it might not be a good match.

eli_gottlieb 14y ago

Even Benjamin "SML, SML uber alles" Pierce spends a portion of his Types and Programming Languages text contrasting objects with existentially-typed abstract data types, and finding that, IIRC, objects are often the more practical and convenient approach.