Functional Programming For The Rest of Us
41–50 of 69 posts
Re: Functional Programming For The Rest of Us
#42> Programmers are procrastinators. Get in, get some coffee, check the mailbox, read the RSS feeds, read the news, check out latest articles on techie websites, browse through political discussions on the designated sections of the programming forums. Rinse and repeat to make sure nothing is missed. Go to lunch. Come back, stare at the IDE for a few minutes. Check the mailbox. Get some coffee. Before you know it, the…
I must admit, I'm like this _sometimes_. But that's only because I'm using PHP :) If you have a problem with your developers doing this, you're doing something wrong.
Re: Functional Programming For The Rest of Us
#43Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus. The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way. A lot of FP explanations start off with immutability. Aft…
This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…
In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.
Sounds exactly what I was thinking - map is not mathematical function - because it can interact with the global state (you can apply map twice to the same data and get different results - for example if in the function you are mapping you use 'time') - and thus using it is not 'functional programming'. If your first-class functions were mathematical functions - then we could agree - but map is not one.
Re: Functional Programming For The Rest of Us
#44Earlier quoted context omitted.
This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…
OK - I checked wikipedia: In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Sounds exactly what I was thinking - map is not mathematical function - because it can interact with the global state (you can apply map twice to the same data and get different results - for example if in the function yo…
> functional programming is a programming paradigm
NOT a programming language. What I think this means is that your usage of map is such that the computation is what matters, not mutating the state. I can do that just as well in Python, JavaScript, OCaml, Scala, Clojure and Haskell. In other languages too, yes, but not nearly as easily (due to lack of closures/complicated functional types/no first-class functions/...).
If you were to insist that functional programming is just math (no mutable state), then even Haskell and Mathematica are far from functional.
Re: Functional Programming For The Rest of Us
#45Earlier quoted context omitted.
I can't answer you with any real authority, since I haven't used OCaml. But from what I understand, it lacks type classes, which are absolutely central to the richness of Haskell's type system. Whether or not it makes up for this in other ways, I can't say. OCaml is also strict by default, with optional laziness, whereas Haskell is the opposite. This could be seen as either an advantage or a disadvantage, but either…
OCaml has a powerful module system which can be used in a way quite similar to typeclasses ( https://ocaml.janestreet.com/?q=node/37 ). The main difference is the lack of purity, which means that the side effects of a function aren't part of a function's type. It also doesn't have the wide variety of extensions which you can use to do really crazy stuff (like verifiably correct red-black trees, https://github.com/yai…
http://news.ycombinator.com/item?id=2622166
http://www.cs.washington.edu/education/courses/cse505/98au/s...
Re: Functional Programming For The Rest of Us
#46Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus. The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way. A lot of FP explanations start off with immutability. Aft…
With that in mind, I recently wrote a series of posts about integrating functional programming concepts into everyday Javascript programming (and AS3, which is nearly identical). The last two, in particular, might be interesting even for programmers who already understand the basics. http://www.alanmacdougall.com/functional-series/ I'd really like to see these techniques emerge into the spotlight, instead of just bei…
Re: Functional Programming For The Rest of Us
#47Earlier quoted context omitted.
This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…
OK - I checked wikipedia: In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Sounds exactly what I was thinking - map is not mathematical function - because it can interact with the global state (you can apply map twice to the same data and get different results - for example if in the function yo…
I don't think I quite understand you. I think when you say "mathematical function" you mean "pure function". And when you say "global state" I assume you mean "impure operations".
But (from my understanding) map is purely functional and doesn't do anything impure like IO. Its purely a mathematical mapping between a collection of input values to a collection of output values, based on applying a function to each input value in turn. You seem to be suggesting "map f (map f x)" (that is applying map twice to the same data) is not the same value as "map f x" and therefore its not "mathematical".
Re: Functional Programming For The Rest of Us
#48Earlier quoted context omitted.
This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…
OK - I checked wikipedia: In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Sounds exactly what I was thinking - map is not mathematical function - because it can interact with the global state (you can apply map twice to the same data and get different results - for example if in the function yo…
With that reasoning you could claim addition is impure, because time() + 1 changes over time. map is definitely a pure function. If you apply it to impure arguments, of course the result will be impure. The point in FP is to avoid using 'time', not 'map'.
Re: Functional Programming For The Rest of Us
#491. The name "functional programming" doesn't sell us; it just sounds impractical. What we do isn't really "functional programming" in a purist sense. We need side effects all the time. We just have an understanding of the need to manage state (not eliminate it) properly. We need a better term for the hybrid functional-preferred/imperative-when-appropriate/very-occasionally-OO style that good engineers use, but all I can come up with (for how we "functional" programmers do things as opposed to the enterprise hoipolloi) is "non-shitty programming" and that sounds biased.
2. Usually, when we showcase FP, it looks like we're hawking complexity. We get into tail recursion and abstract data types right away. In fact, proper use of FP reduces complexity a great deal. For example, Scala is actually less complex than Java by far. On the other hand, it's hard to present Scala to a Java programmer without it appearing that one is trying to shove more complexity into his workflow, because it's only after a few months of learning how FP works (and that you don't need classes to program, you just need functions, because that's what algorithms actually are) that people realize how much simpler code becomes when done properly, and that functional programming (unlike in Java) does provide life-long, substantial boosts in productivity and product quality. Until people get to that point, they'll feel like we're just shoving a tough learning curve on them.
Re: Functional Programming For The Rest of Us
#50Earlier quoted context omitted.
not the most powerful system imaginable for that purpose had to ask, what is more powerful, agda/coq/other?
A full dependent type system is nominally “the most powerful system imaginable”, but it’s also hopelessly problematic. You can’t be sure that type inference or type checking will halt in the general case, although you can infer some value-dependent types (see “Dependent Type Inference with Interpolants” by Unno & Kobayashi). In practice this means you need manifest type signatures, otherwise the type of a function wo…
http://www.cs.princeton.edu/~dpw/papers/TCS04.pdf
http://www.metaocaml.org/concoqtion/techreport.pdf
http://www.cis.upenn.edu/~sweirich/plmw12/Slides/plmw12-Pier...
slide 8:
summary = impossible