Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
81–90 of 93 posts
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#82> We have all the features we need to mimic a language like Scala or Haskell with the help of a tiny library or two. Seems misleading at best, as you mimic only some parts of functional programming. For example, for-loops are not used but neither are recursion and tail calls mentioned. > [T]yped functional languages will, without a doubt, be the best place to code in the style presented by this book. JavaScript will…
And to the point... how would one go about taking "Imperative Haskell" Code and making it more functional... you can't. Either you write Haskell functionally or whatever you wrote will refuse to compile. I love this book and the Egghead.io videos that followed. I love this guide and the egghead.io videos. That content made me curious about Haskell and Tacit Programming.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#83FP Resources:https://github.com/functionalflow/brains/projects/9
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#84Earlier quoted context omitted.
Functional programming (FP) is an important paradigm with many practical benefits, such as preventing bugs, improving parallelization, etc. JavaScript is a language in which one can apply the FP paradigm, with some (considerable) effort. This book explains both the underlying FP paradigm and how to apply it in JS. Other languages (e.g. Haskell, Scala, F#) are designed for the FP paradigm and make it much easier to ap…
> with some (considerable) effort disclaimer: I haven't read the book and am not sure if this is mentioned anywhere. What helped me when thinking about functional design in javascript was realizing that all js functions actually only have one parameter, an array of arguments used by the caller: function add(x, y) { return x + y; } is effectively syntactic sugar for function add() { const x = arguments[0]; const y = a…
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#85I wish I knew enough compsci to know why functional programming is useful. I read about half the book, and while interesting from a learning perspective I don't know where I can apply it. Context: self-taught programmer in the data science/statistical modeling world.
I lean towards organizing my applications into very dumb objects which are supported by FP-style business logic. At a glance you can infer what's going on quite easily due to the idiomatic use of the objects, but the object orientation mostly ends there. My business logic is organized into isolated modules that are as pure as I can manage without being a nut about it. The objects recruit or are operated on by that logic, so their implementation is very light and clean as a result. Like I mentioned, tests for this kind of code are really nice. They tend to be concise.
It's not perfect, but I feel like it's a way FP has greatly improved my code and what I deliver to my team in general. It's an attempt to merge the benefits of two paradigms, I suppose.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#86Earlier quoted context omitted.
The weakest definition of functional is that functions are a first-class object that can be passed around. This is the one that C conforms to in that old sense. This is a dead definition because almost everything in modern use conforms to this definition, and definitions are only useful to the extent they create distinct categories. Because almost every modern language has this, it can be difficult to imagine a langu…
Excellent exposition of the current landscape and of the notion that there is no single definition of FP. I'd like to add that type-systems are not a defining feature of functional programming because you can have type-systems in what are considered "non functional" languages as well. Immutability it jives with functional but is really an orthogonal feature as well. So what is left? I would say is the ability to crea…
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#87Earlier quoted context omitted.
There's really multiple definitions of "functional" right now, and the type of "functional" being discussed here, Erlang isn't, and I don't think Elixir particularly is either. This is not a criticism of any kind; this is a point about definitions . There are definitions of functional where Erlang is functional, and IIRC Elixir can be said to support it. (And there are definitions of "functional" where almost every l…
> There's really multiple definitions of "functional" right now > ... >> ...monads... There are also a couple of definitions of "monad" going around -- in array languages (J, APL, Q) a "monad" is something with arity 1 (like unary negate), to be contrasted with "dyads" which take two parameters (infix operators etc.)
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#88Earlier quoted context omitted.
> There's really multiple definitions of "functional" right now It would be very helpful to see an explanation of this spectrum you describe for someone who is not really familiar with the definitions. I would love to read an explanation of the various “functional” paradigms as they diverge from “conventional” (ie. C) programming languages.
The weakest definition of functional is that functions are a first-class object that can be passed around. This is the one that C conforms to in that old sense. This is a dead definition because almost everything in modern use conforms to this definition, and definitions are only useful to the extent they create distinct categories. Because almost every modern language has this, it can be difficult to imagine a langu…
While I'm happy to be corrected, I get the impression that the 'threshold' for calling something FP, by those who consider themselves FP 'practitioners', lies somewhere in the area you describe right before Haskell. And for those who consider FP-style programming alien, Haskell is what they imagine.
Basically, Javascript would be considered barely-enough to do FP style programming, but it's got the kitchen-sink nature against it, offering too easy an escape hatch.
Clojure/Lisp and perhaps Elixir more-so, would be squarely in the FP world, even though they're not strict about it. I'm not too familiar with the former, but the latter makes it rather inconvenient to not write most of your code in a functional style.
Personally my next goal is to go full-on FP and dive into Haskell (or something else, if someone would recommend it!), but Elixir has been the most useful language in my journey so far. I come from Javascript (and before that PHP), and while I've always tried doing things the FP way as much as possible, it's only after getting comfortable with Elixir that I've actually started to 'think functionally'. I feel it's greatly improved my programming even when I go back to JS stuff, because I'm less likely to fall back on the imperative/OO stuff. I'm not saying the latter is bad, but at the very least being consistent in my approach seems to bear fruit.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#89Earlier quoted context omitted.
Excellent exposition of the current landscape and of the notion that there is no single definition of FP. I'd like to add that type-systems are not a defining feature of functional programming because you can have type-systems in what are considered "non functional" languages as well. Immutability it jives with functional but is really an orthogonal feature as well. So what is left? I would say is the ability to crea…
Yeah, I kinda think the Haskell branch ought to have its own term, because of the number of things that are involved that don't relate to "functions" per se, but it's not my call. "Pure functional" sort of works, but I would mean something more like "Pure and functional", that is, two separate adjectives, not one where "pure" is modifying "functional". A pure, non-functional language is certainly possible. "Pure impe…
“Pure functional” programming is functional programming wherein the functions are pure functions, that is: (1) the result of the function is completely determined by the identity of the function and its arguments, and not any other external state, and (2) the function produces no side effects that would impact calls to the same or other functions. (On a language level, only the first is really necessary, because if everything is composed of functions and all functions results are independent of external state, any side effects would necessarily not be observable within the language; but functional purity can be discussed with regard to constructs within a language where purity is not required at the language level.)
> A pure, non-functional language is certainly possible.
You can have referential transparency in a language whose central structure is determined by a paradigm other than the functional (e.g., referential transparency is just as much a key feature in the logic programming paradigm as the functional paradigm, and pure logic programming is already used to describe logic programming with strict referential transparency in the same way pure functional programming refers to functional programming where with strict referential transparency.)
> "Pure imperative" is a bit hard to conceive (Rust probably as close as you can get),
Rust is basically an ML-family functional language that moved off in a different direction than the one toward purity; it's closer to impure functional than pure anything.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#90That seems extremely dishonest. The reason why we name variables, is so that they can hold different values. There is no guarantee that every run of the script will have the same initial variables. If it was, you might as well just type in the result.