7 ms·
Awesome Functional Programming
- l5870uoo9y 5y agoStared only to never use it.
- petilon 5y agoFor some scenarios, functional programming is a good match. For example, Big Data. FP has features such as lazy evaluation, which is important for Spark, for example. Not surprisingly many Big Data libs, including Spark, are written in FP languages (Spark was written in Scala). For JavaScript FP is not a good match [1]. Certainly, many ideas that originated in FP work well in JavaScript, for example lambdas. But some people take FP to an extreme, to the point of saying that OOP is now obsolete. How can OOP only now become obsolete, given that FP has existed long before OOP? That doesn't make sense. [1] https://medium.com/weekly-webtips/dysfunctional-programming-in-javascript-cae5c085a76e https://medium.com/weekly-webtips/dysfunctional-programming-...
- ravi-delia 5y agoHonestly I've derived enormous enjoyment programming in Clojurescript, I don't think FP was a detriment at all. The way I see it, there's a pretty wide scope where FP or OOP will work just about as well and it's just a matter of preference. For me, FP makes sense in a way OOP never has. I gather that for lots of people, the opposite is true. It's certainly not true that OOP is obsolete though. There a lots of people that prefer it, and they do perfectly good work!
- choeger 5y agoYou seem to confuse a few things. Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complications. Eagerly evaluated functional languages are quite normal. An imperative language could use lazy evaluation as well (and you can easily emulate it in one), but programmers would likely be confused by the ordering of intentional side effects and some typical imperative paradigms might even not work in a lazy setting. Object-oriented programming has long been criticized, but not in the context of JavaScript. As JavaScript is untyped, the downsides of OO programming aren't that visible. The big divide between (typical, statically typed) functional languages (say ML) and (typical, statically typed) object-oriented languages (say Java) lies in the organization of data. In the former you will typically use algebraic datatypes, which normally force you to define a complete data structure in one place and allow you to define many operations on it everywhere in your code (operational extensibility). The latter do the opposite and allow you to add new subclasses (structural extensibility). See "expression problem" for more info. In practice, it turns out that operational extensibility is much more important for safe code and there are functional patterns that give you the best of both worlds ("finally tagless"). It is because of this design-space divide that some people claim that (statically typed) object-oriented programming is a dead end.
- petilon 5y ago> Eagerly evaluated functional languages are quite normal. Probably not very efficient. Are there commercially successful examples of such a language? > An imperative language could use lazy evaluation as well Certainly! I believe Microsoft's Linq is one such example.
- duped 5y ago> Probably not very efficient. Are there commercially successful examples of such a language? Global lazy evaluation by default is the exception, not the norm. Standard ML, F#, OCaml, Scala, ... I actually would have more trouble finding a classic "functional" language that is lazy like Haskell but isn't Haskell. Not to mention, almost all the multiparadigm languages that can utilize FP like C++, Rust, etc are eager.
- petilon 5y agoRust does lazy eval.
- duped 5y agoExpressions in Rust are eagerly evaluated, but you can write lazily evaluated things without issue.
- bidirectional 5y agoBasically every language has some kind of opt-in lazy evaluation, Rust is strict by default as is basically every remotely mainstream language bar Haskell.
- munk-a 5y ago> Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complications. It definitely requires control of the data - i.e. having a partially evaluated linked list somewhere directly accessible by pointer without signaling any generating function will break a lazy implementation. That said I absolutely love lazy evaluation and have built a lot of tools in less functional languages like PHP and C++ for handling very large data sets. When dealing with large report generation (i.e. all transactions from a quarter compiled for the accounting department) it can be necessary to avoid ever actually realizing full data sets into memory for efficiency and capacity reasons - that's an area where abstractly defining various transformations on the result set and then executing them in an iterative or batched manner can be exceedingly useful. I have killed many OOMs in my days.
- Zababa 5y agoI wish people would stop being such zealots when talking about functional programming. JS is mostly an imperative language, with OO and FP features, that you can use when they make sense. From the article you linked: > This is a function but it is not functional because it mutates state and uses iteration. The state and iteration was only internal, JS doesn't support TCO and the algorithm is very simple. Sure it's only an example but it's not a great one. Then it continues: > To be functional it is not sufficient to simply remove classes and write top-level functions. You have to completely change your way of thinking. The functional way has no side effects or state mutations. It has no assignments, no iteration, and no conditional statements. That's not "being functional", that's Haskell. I can write a program with side effects, state mutations, assignements, iterations and conditional statements in OCaml or Scala without issues. > Assignment and iteration are typical of imperative programming. In functional programming changing the value of a variable using an assignment statement is not allowed. It is allowed though: let x = ref 0; x := 5 (* x is now 5! *) Again, that vision of "functional programming" is "strictly Haskell". > This is because JavaScript lacks a critical feature known as lazy evaluation. Lazy evaluation means not calculating things until they are actually needed. JS has lazy evaluation with iterators. What it doesn't have is chaining/transformation of those iterators: map, filter, reduce are not defined for iterators. You can make your own prime iterator (with internal state!) and iterate on it though. > Because of a lack of features such as tail call optimization and lazy evaluation you can’t do “real” functional programming in JavaScript. No true scottsman fallacy. By the way, Safari implements TCO, so you should be able to do real functional programming on Safari with iterators! > Functional programming and side effects Again, that's only for Haskell. And you can write scary imperative code in Haskell too: toto x = if x == 0 then error "Ooops" else x + 3 This will add 3 to any integer, except 0, in which case it will raise an exception. This is nowhere in the type of toto. Also, all that mention of "pure and impure" programming and no mentions of monads and promises, which are almost just like monads? > Among some JavaScript programmers, it has become fashionable to completely avoid classes and OOP because they think functional is better. But given that you can’t do real functional programming in JavaScript, completely avoiding OOP will only eliminate the advantages of OOP while not gaining the benefits of pure functional style. False dichotomy, you can write plain imperative code in JS, and it works well. > That’s not to say there are no benefits at all to incorporating some functional style into JavaScript code, but wholesale replacement of OOP with functional style is not warranted. Again, most existing JS code is imperative style and not OO. No mention how functional code is easier to test? That's a bit weird. All in all, it's a bad article based on limited views.
- choeger 5y agoThe number of monad tutorials in the haskell section is ... interesting. If you order all concepts in prison programming by the product of usefulness and confusion it must be somewhere at the very top.
- dack 5y agoThe concept itself is extremely useful (in a programming language like Haskell, at least), but for whatever reason it resists understanding in the way most people want to teach it. I'm not sure why it's different than other programming concepts in this way... maybe just because it's such an abstract concept where most people have no frame of reference. You don't appreciate it until you've used it in a bunch of different contexts and finally see why this one abstraction works for all of them
- foldr 5y agoI feel that a certain segment of the Haskell community doesn't help matters by pretending that monads (in the Haskell sense) have something interesting to do with category theory. Fundamentally, a monad (in Haskell) is just a set of operators that obey some simple algebraic laws. These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you really want to, you can use the language of category theory to talk about monads in Haskell. Some people seem to get a great deal of satisfaction out of doing so (and I suppose that it's harmless fun). But it does build up a certain undeserved mystique around monads in Haskell.
- aesyondu 5y ago> These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you could share some of these examples, or perhaps a link to those examples, I'd greatly appreciate it.
- kaba0 5y agoI wrote an explanation for them here: https://news.ycombinator.com/item?id=28844533 https://news.ycombinator.com/item?id=28844533 Though I’m not the best at explaining things, hopefully it makes sense.
- nesarkvechnep 5y agoToo much JavaScript.
- NAR8789 5y agoStupid question: how do folks generally use awesome lists? I think it's neat they exist, but they don't really live up to the "curated" promise in my mind. Mostly they seem to be a grab bag of everything under a topic, and it's left to the reader to sort through. As such they've never come to mind when I'm actually researching anything.
- phildenhoff 5y agoI've found this exact same problem. It's a huge list of links, I'll open a few projects that might be interesting, save them for later — and then when I look at them, I don't remember the context (why I saved them, what for) and I'll just remove them from my list. They have their use as a jumping-off-point, but what I _really_ want is a truly curated list. LessWrong has a list of "best textbooks" where you have to provide a "best" and one (or two?) other textbooks that you've read which you didn't like as much, and an explanation on why the former is better. I think it's a great way to curate a list. I wish there were more like that.
- TheGoodBarn 5y agoI like them when I am new to a technology or programming language. For example last year I spent a significant amount of time writing Go code and doing Solidity/blockchain development. Being able to scan https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go, https://github.com/bkrem/awesome-solidity https://github.com/bkrem/awesome-solidity, and https://github.com/gianni-dalerta/awesome-nft https://github.com/gianni-dalerta/awesome-nft for general resources, projects, guides, or just general information was a nice resource to have in my back pocket. I think your point is valid, but it's also a personal expectation of what you get out of the resource. I think the fact that they are open ended helps both developers who are trying to reach an audience and people who are browsing for new tools, ideas, etc.
- NAR8789 5y agoAh, I hadn't thought about it from the publishing side. That makes sense. Easier to break into as an unknown writer than google rankings.
- tromp 5y agoI'd like to recommend the following awesome expositions by Ben Lynn as well: https://crypto.stanford.edu/~blynn/lambda/ https://crypto.stanford.edu/~blynn/lambda/ https://crypto.stanford.edu/~blynn/compiler/ https://crypto.stanford.edu/~blynn/compiler/
- creativeCak3 5y agoForgive me if this sounds ignorant, but who is using pure-functional approaches in industry? Again, please correct me if I'm wrong since I've been industry for barely 2 years: back in school functional programming looked cool, but when I entered industry(and even in my exploration through personal/OSS projects), I have found it to be nothing more for the most part than a cool toy to play with. I can somewhat see the benefit when it comes to parallelizing Big Data, but that seems to be a very special case. Again if I'm just being ignorant, please educate me :)
- lhorie 5y agoLots of people take useful parts of the functional paradigm without bringing in the whole shebang. Javascript being at the top of the list of languages in that page is a good hint at how people use it: things like Array.map are often used instead of procedural counterparts because people consider the pipeline-like data flow to be easier to understand than ad-hoc for loops, to give one simple example. Promises and the async/await syntax sugar on top of them are another JS construct that borrow quite a bit from functional literature.
- creativeCak3 5y agoI see what you mean...Even I myself have written code along the lines of "array.map.filter.this.filter". And indeed it can be more readable certain times. But I guess what I was referring to is that sometimes it seems that people are "preaching" functional programming as gospel. But I could be misinterpreting things.
- lhorie 5y agoI mean, you can go all the way to the deep end, but like any tool, there are good reasons to be pragmatic, and avoid just using a tool for its own sake. Sure, you can get lost in fantasy land[0] algebras if you really want to, but generally I see it as a pyramid of usage (i.e. a small number of people that care about the mathematics, a slightly larger group of library authors that use fantasy land and friends to inform API design decisions, and a larger portion of library consumers that benefit from the academic roots of those design decisions.) [0] https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land
- yakshaving_jgt 5y agoI honestly wish people new to web development would learn Elm before trying to learn the dumpster fire that is the JavaScript ecosystem.
- Solarsail 5y agoSpeaking of which, how learnable is Elm without any HTML familiarity? I more or less gave up on learning it once the (previous) Elm book started piecing together HTML tags in Elm syntax...
- yakshaving_jgt 5y agoIt's not any more difficult than writing the markup in any other language or library, but if you're making websites then you're going to need to know how to use HTML.
- fermigier 5y agoI see there is a short section about Python (6 resources). I have been maintaining for the last 5 years a slightly richer collection at: https://github.com/sfermigier/awesome-functional-python/ https://github.com/sfermigier/awesome-functional-python/
- ffhhj 5y agoToo bad Github search doesn't find that entry in the Awesome listing: https://github.com/sindresorhus/awesome/search?q=functional%20programming https://github.com/sindresorhus/awesome/search?q=functional%... And Github search should display the rendered markdown so we can click the links.