TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Functional programming is not popular because it is weird (2016)

223 pointsby l5870uoo9yover 3 years ago

53 comments

goto11over 3 years ago
Languages do not becomes successful due to their intrinsic qualities. Languages become successful when they are coupled to a successful platform. E.g. C became popular because Unix became popular, JavaScript became popular because of the browser, Objective-C became popular because of the iPhone and so on.<p>Therefore observing that a language or paradigm is popular or unpopular does not say anything about whether it is good or bad. JavaScript is the most popular language in the world. If Netscape had decided to use a Scheme-like language or a BASIC-like language it would <i>still</i> be the most popular language in the world. So paradigm has nothing to do with it.<p>Functional programming is less popular because no major successful platform has adopted a functional language as the preferred language.<p>I don&#x27;t buy that functional languages are unpopular because they are unintuitive. Losts of stuff in JavaScript is highly unintuitive. It didn&#x27;t prevent it from becoming the most popular language in the world. People will learn what they need to learn to get the job done.
评论 #28521480 未加载
评论 #28521914 未加载
评论 #28521405 未加载
评论 #28522114 未加载
评论 #28521239 未加载
评论 #28521573 未加载
评论 #28521553 未加载
评论 #28522301 未加载
评论 #28523556 未加载
评论 #28524325 未加载
评论 #28542901 未加载
评论 #28521646 未加载
评论 #28521222 未加载
评论 #28522101 未加载
评论 #28522370 未加载
评论 #28536272 未加载
评论 #28521227 未加载
cardanomeover 3 years ago
For me OOP is weird. I never understood what people mean when they say it is close to how they think. It feels like a way to obfuscate the flow of code and requires to make decisions about what thing should have which responsibility and relation with which other thing and building weird hierarchies that will bite you back in the long term.<p>Relations between Objects change, customers don&#x27;t know what they want, change is always pain with OOP.<p>Now people say, composition over inheritance. Right, but isn&#x27;t that the point of functional programming?<p>Functional programming maps to how I think. The most important questions is always: What data structures do I need? Get your data in order and the rest will flow naturally.<p>I don&#x27;t use functional programming because I am a math nerd or something, I am not even good at math. I use is because it is composible and easy to understand. I can refactor without any fear of side effects.<p>Now is pure functional programming practical? For some tasks, sure but yeah not always. Imperative programming gets stuff done. Work with the strengths of both.<p>The thing you are not used to always feels weird, that is a problem with you not the thing you try to learn.
评论 #28523600 未加载
评论 #28524480 未加载
评论 #28524473 未加载
评论 #28534725 未加载
评论 #28535877 未加载
评论 #28526488 未加载
6gvONxR4sf7oover 3 years ago
Some of the weirdness is so completely avoidable that it frustrates me, but languages and libraries dig in on ‘you get used to it.’ I’m talking about the f(g(h(x))) vs x | h | g | f. Right to left chains of functions seem more popular than chains of pipes in FP, but even being someone who has drunk the kool-aid deeply, I always prefer pipes.<p>‘Take the pan out of the over once it’s been in for 30min, where the pan contains a folded together eggs and previously mixed flour and sugar’ isn’t more FP than ‘Mix the flour with the sugar, then combine with eggs, then fold together, then put it into the oven, then take out after 30min.’ But people new to it so often think it’s an FP thing for no good reason. It’s a new user issue that ought to be totally fixable as a community.<p>FP has enough great ideas that I’d recommend everyone learn pure functional solutions just to put into their tool belt, but it’s absolutely true that getting up to speed is harder than it needs to be. My hot take: it won’t be really mainstream until someone figures out how to make dependent types really ergonomic, which seems a long way away.
评论 #28515256 未加载
评论 #28516614 未加载
评论 #28520626 未加载
评论 #28521698 未加载
评论 #28520585 未加载
评论 #28522291 未加载
评论 #28519966 未加载
评论 #28520845 未加载
评论 #28515535 未加载
评论 #28520318 未加载
评论 #28520283 未加载
评论 #28520871 未加载
评论 #28516150 未加载
评论 #28521452 未加载
rg111over 3 years ago
I recently watched this talk-<p>Why Isn&#x27;t Functional Programming the Norm? (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;QyJZzq0v7Z4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;QyJZzq0v7Z4</a>)<p>Here&#x27;s the HN thread- <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21280429" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21280429</a><p>I learned in that talk, among other things that Oracle spent <i>$500 million</i> to promote and market Java.<p>- <a href="https:&#x2F;&#x2F;www.theregister.com&#x2F;2003&#x2F;06&#x2F;09&#x2F;sun_preps_500m_java_brand&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.com&#x2F;2003&#x2F;06&#x2F;09&#x2F;sun_preps_500m_java_b...</a><p>- <a href="https:&#x2F;&#x2F;www.wsj.com&#x2F;articles&#x2F;SB105510454649518400" rel="nofollow">https:&#x2F;&#x2F;www.wsj.com&#x2F;articles&#x2F;SB105510454649518400</a><p>- <a href="https:&#x2F;&#x2F;www.techspot.com&#x2F;community&#x2F;topics&#x2F;sun-preps-500m-java-brand-push.5852&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.techspot.com&#x2F;community&#x2F;topics&#x2F;sun-preps-500m-jav...</a>
评论 #28520842 未加载
评论 #28520426 未加载
评论 #28520825 未加载
评论 #28521098 未加载
armchairhackerover 3 years ago
Fully functional programming (e.g. Haskell) isn&#x27;t popular because it isn&#x27;t ideal and computers work imperatively.<p>Even in a &quot;functional&quot; task (e.g. compiling) sometimes you just want an imperative algorithm. And while Haskell allows this via state monads, they&#x27;re clunky.<p>Meanwhile there&#x27;s practically no tradeoff to writing functional code in an imperative language. In fact there&#x27;s <i>lots</i> of functional code in most C++&#x2F;Java&#x2F;Python programs. Most &quot;imperative&quot; languages are actually hybrid functional and imperative, supporting &quot;functional&quot; constructs like lambdas and pattern matching.<p>99% of the time a functional program will get executed sequential and strict anyways. The other 1% of the time, in an imperative language you can explicitly encode functionality (e.g. generic stream operators which work concurrently and on lazy streams).
评论 #28515209 未加载
评论 #28515254 未加载
评论 #28520154 未加载
评论 #28521791 未加载
评论 #28516606 未加载
bmitcover 3 years ago
It really isn&#x27;t. Just see Racket, Clojure, Elixir, and F# for practical functional programming languages.<p>This article is pretty terrible. There isn&#x27;t even a functional implementation, with just a half hearted attempt to even understand how to do it.<p>Functional languages <i>excel</i> at state machines. The example is pretty terrible too with regards to imperative programming being a good fit, because literally no one enjoys the real life statefulness and mutation when cooking. If you mess up, there&#x27;s no going back. Why would you want to embrace or repeat that feature in your implementation? Functional state machines just pass explicit state around instead of mutating some random collection of variables.<p>And god, those C++ examples make me nauseous.
评论 #28521386 未加载
jmfldnover 3 years ago
Functional programmer here. It&#x27;s a different way of thinking is all, I don&#x27;t see it as solving puzzles exactly. It&#x27;s unfortunate if people see it as being about complexity or being clever. Done well, it should be the opposite. Once you understand the key abstractions, it can make code a lot easier to write and reason about in some cases. That&#x27;s the joy of it for me. It furthers my day to day software engineering concerns of readability, maintability, testability etc. Nothing more.<p>It&#x27;s just another tool though and there are many places where it&#x27;s not appropriate. It&#x27;s also a personal taste thing, I get that. It&#x27;s worth persisting with it on a deeper level though just for the sheer joy of those &#x27;a-ha&#x27; moments that come. Even if you don&#x27;t use it in your day job, just bending your brain with different programming paradigms is well worth it.
评论 #28515450 未加载
评论 #28515504 未加载
vnoriloover 3 years ago
I don&#x27;t know. I don&#x27;t write functional because it&#x27;s hard and I&#x27;m super smart, I write functional because it&#x27;s easy and I&#x27;m lazy.<p>I&#x27;m also not sure the example in TFA is much of an argument. From a glance looks like the programmer got entangled in their own cleverness, but the slice we are shown is too small to show if there&#x27;s some external reason to do it like that.<p>story time: once did a compile time parser generator with c++ templates. &quot;Zero-cost&quot; abstraction and all that jazz. Turns out the binary was so large that a type-erased vtable system ran faster, for all its nonzero cost.<p>Templates are orthogonal to functional or imperative. It&#x27;s a code generator. Understand what you generate!
评论 #28520609 未加载
评论 #28520403 未加载
csneekyover 3 years ago
Fact: functional programming takes more time to learn. It&#x27;s not full of people that are &quot;smarter&#x27; or &quot;snobs&quot; it&#x27;s just full of people that have taken the time and invested in educating themselves to get to the point where they can do it well. It&#x27;s not &quot;better&quot;, it&#x27;s just a useful tool for certain types of problems. I&#x27;d advise any young engineer to just learn how to do both &quot;imperative&quot; and &quot;functional&quot; programming well and avoid getting dogmatic about it. The vitriol here is in dogma here to be sure
评论 #28520122 未加载
评论 #28520450 未加载
评论 #28520019 未加载
评论 #28520998 未加载
评论 #28520301 未加载
maxbendickover 3 years ago
Subversion:<p>Functional programming is popular because it&#x27;s intuitive!<p>Perhaps &quot;immanent&quot; or &quot;diagrammatic&quot; is a better word than functional. I mean that a function _is_ what it does, but not so with a procedure. One cannot bake a value as one does a cake!<p>See React&#x27;s dominance. See the usefulness of declarative state machines. See async&#x2F;await.<p>Functional programming gets a bad rep. People often fail to see the functional elements in more imperative code and the imperative elements of more functional code. In fact very few language constructs are necessary to open up 99% of functional possibilities in imperative languages (functions as values) or imperative possibilities in functional code (do-notation). Any critique that dismisses one or the other misses the point.<p>May add more explanation later.
评论 #28522511 未加载
评论 #28520673 未加载
评论 #28523130 未加载
ryanmarshover 3 years ago
I&#x27;ve seen a handful of articles and conference talks where the main thrust is &quot;why isn&#x27;t functional programming more popular&quot;. Apparently it works well and is &quot;intuitive&quot; for some people. I think the first thing we should do is recognize the amount of neurodivergence amongst programmers.<p>The WISV-IV GAI tests for verbal comprehension and perceptual reasoning. It provides an estimate of general intellectual ability, with less emphasis on working memory and processing speed. My GAI is 124. Which means I&#x27;m fairly intelligent (sic. &quot;superior&quot;) when it comes to understanding language and reasoning. It makes me a fairly good problem solver. I&#x27;m an ok programmer (judged against the hundreds of programmers I&#x27;ve paired with through my consulting work).<p>That said, I&#x27;ve tried to learn Haskell three times and given up each time. The functional model of D3js kicks my ass. I cannot grok LISP.<p>It turns out my WMI (working memory index from Wechsler Adult Intelligence Scale) is <i>BELOW AVERAGE</i>. This makes holding lots of recursion or abstraction in my head at once quite difficult. I also suffer from adult ADHD.<p>I love long functions in a procedural style. I&#x27;m quite proficient working that way. There&#x27;s not too much abstraction and behavior hiding (why I grew to hate OO). You can see how my neurological makeup impacts what &quot;good&quot; code looks like. I also understand that James Gosling has a kind of synesthesia and that impacts the structure of his code to the point of causing problems for others (see Lex Friedman interview).<p>I said all that to say this. What makes code understandable&#x2F;readable&#x2F;clean is in the eye of the beholder. There&#x27;s quite a bit of neurodivergence in our field and we need to account for that when deciding on how to critique code. After all shouldn&#x27;t code be written first and foremost for humans to understand and only incidentally for compilers? (paraphrased from SICP)
评论 #28515325 未加载
评论 #28515466 未加载
评论 #28515100 未加载
评论 #28515664 未加载
评论 #28520085 未加载
pkilgoreover 3 years ago
I wonder now much C++ matters here. I rarely reach for functional patterns when the language I&#x27;m using does not provide proper constructs for readable, declarative code like pattern matching, nominative discriminated unions, and pipe operators.<p>Sure, you can fake all that with other constructs or patterns. But then it really does feel more like a puzzle.<p>IMO, good FP is good when it is maximally declarative and organized in the linear way in which humans reason best.<p>Maybe the author should try F# or OCaml instead of Haskell! I love FP and have also tried and hated Haskell three or four times.
etaioinshrdluover 3 years ago
OpenAI Codex is pretty good at translating code between languages. It&#x27;s far from perfect - but it can get simple cases perfectly. It knows languages like Rust, Haskell, Erlang, and more.<p>I found that I could translate Python to Haskell using Codex and get more real working Haskell code far, far quicker than I could manually.<p>I think Codex will be a simply incredible tool for learning new programming languages, could definitely make FP easier. It may not be super &quot;smart&quot;, but it&#x27;s smart enough, it knows a ton, and it&#x27;s got superhuman recall.<p>Another idea is that you could filter Codex suggestions for those that pass the type-checker, and keep regenerating until it passes.<p>It&#x27;s so incredibly fun. It made me want to never stop coding.
评论 #28520449 未加载
alanbernsteinover 3 years ago
Functional Programming Is Not-Popular Because It-Is-Weird,<p>not<p>Functional Programming Is Not Popular-Because-It-Is-Weird.<p>I just found the ambiguity amusing, in the title of this particular blog post.
评论 #28514963 未加载
评论 #28515426 未加载
评论 #28523116 未加载
评论 #28521304 未加载
markus_zhangover 3 years ago
It&#x27;s probably just me, but I found loops much more intuitive than recursions for those non-recursion oriented problems. That is to say that I prefer to use recursion ONLY for those are un-intuitive to solve by loops in a trivial way.
评论 #28515248 未加载
评论 #28514862 未加载
评论 #28516650 未加载
评论 #28515380 未加载
评论 #28515467 未加载
评论 #28521923 未加载
评论 #28514953 未加载
streamofdigitsover 3 years ago
Functional programming forces you to think a bit like a theoretical physicist seeking to write equations for fundamental laws: the universe is modeled as interacting particles that start free, collide and interact and end up free again. No concept of historical dependence or sequential evolution. In physics these attributes emerge only as descriptive crutches in the context of poorly understood complex, macroscopic, systems undergoing various transitions. We have much less clue how to write universal equations for such systems.<p>So FP might have a theoretical advantage as a building block of low-level software systems that are not throwaway labor (that is: only valuable in specific historical window &#x2F; context).<p>In any case the factors driving programming language popularity have changed dramatically ever since the developer universe got truly &quot;connected&quot;. There is a winner-take-all network mechanic that basically inflates whatever initial advantage into a (difficult to explain ex-post) catholic dominance.
pansa2over 3 years ago
Functional programming isn’t how people think, and it isn’t how computers work. Therefore it’s a bad way for the two to communicate.
评论 #28522615 未加载
评论 #28520800 未加载
评论 #28520848 未加载
ur-whaleover 3 years ago
I&#x27;m happy the author wrote this blog post, it very much reflects my take on FP.<p>And if I had to keep one sentence from it: mutable states are <i>very useful</i>.<p>FP addicts consider mutable states to be something to be banished at all cost, much like a generation of 70&#x27;s academics tried to do away with goto&#x27;s.<p>The fact is, there are lots of situations in the real world where using mutable state variable is the very best way to model the problem:<p><pre><code> - easier to understand - faster to execute </code></pre> The same holds for goto&#x27;s btw.
评论 #28521810 未加载
AtlasBarfedover 3 years ago
I am not a huge functional programmer, but the big weapon in FP&#x27;s wheelhouse is that pure side-effect FP is far more suited to multicore&#x2F;threading&#x2F;processing, which is where all the future gains in processing will probably come from.
评论 #28519211 未加载
iammiscover 3 years ago
Functional programming is the most popular current paradigm. What is everyone on about? Javascript, a functional language, is one of the most popular languages ever. Rust and go, two other popular languages, also eschew object-oriented programming, the former dominant paradigm, for a truly functional one.<p>C++ is gaining more and more functional features, and this is quickly becoming the predominant style.
评论 #28520759 未加载
评论 #28520812 未加载
评论 #28520929 未加载
评论 #28520761 未加载
Animatsover 3 years ago
Here&#x27;s &quot;clippy&quot;, Rust&#x27;s style enforcement system, complaining about an insufficiently functional form.<p><pre><code> warning: manual implementation of `Option::map` --&gt; src&#x2F;viewer&#x2F;regionindex.rs:265:13 | 265 | &#x2F; match vlinkopt { 266 | | Some(vlink) =&gt; Some((*vlink).clone()), 267 | | None =&gt; None 268 | | } | |_____________^ help: try this: `vlinkopt.map(|vlink| (*vlink).clone())` | note: `#[warn(clippy::manual_map)]` on by default for further information visit https:&#x2F;&#x2F;rust-lang.github.io&#x2F;rust-clippy&#x2F;master&#x2F;index.html#manual_map </code></pre> It wants a map and a closure used on a single value, to replace a simple conditional. I am told that the map and closure will all optimize out, but I haven&#x27;t looked at the generated code.
评论 #28520665 未加载
评论 #28520571 未加载
alphanumeric0over 3 years ago
I like the puzzle analogy but I&#x27;m not sure it holds too much weight. Didn&#x27;t imperative style also kind of feel like a puzzle when you first started learning how to code?<p>Remember those light bulbs that went off when you finally incremented an index variable at the right moment, or when you finally figured out the right condition for a while loop? Clearly all styles are puzzle-like when you are first learning them.<p>I think functional programming has more or less the same learning curve as other styles.<p>In my view, the reason functional programming isn&#x27;t more popular is because of Comp Sci curricula.<p>There are plenty of institutions where there may be one course on functional programming (if you&#x27;re lucky). Then, many students seem to (incorrectly) internalize the idea that anything their degree doesn&#x27;t cover extensively must be of lesser importance.
dangover 3 years ago
Discussed at the time:<p><i>Functional Programming Is Not Popular Because It Is Weird</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11188570" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11188570</a> - Feb 2016 (75 comments)
yewenjieover 3 years ago
This talk by Richard Feldman is an excellent discussion about why Functional Programming is not the norm -<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QyJZzq0v7Z4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QyJZzq0v7Z4</a>
p0nceover 3 years ago
For me the problem is that &quot;functional programming&quot; embodies a lot of questionnable ideas:<p>- the idea that readability is not the first thing to pursue<p>- the idea that macros are great<p>- the idea that leaving performance off the table is OK<p>- the idea that objects and subtyping are useless<p>- the idea that mutability is hard to reason about<p>- the idea that recursion is super important<p>- the idea that somehow closures are more readable than objects<p>- the idea that tuple are somehow better than structs with named fields<p>It is a style that thrive _in opposition_ to the style of useful programs out there: readables, no macros, fast, with an UI, with mutability, with objects, with names.
评论 #28521982 未加载
math-devover 3 years ago
I find functional programming reasonably straightforward to learn but difficult to master.<p>For example, this Common Lisp cheat sheets covers a large part of the language and isnt hard to follow<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ashok-khanna&#x2F;lisp-notes" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ashok-khanna&#x2F;lisp-notes</a><p>I was doing some Haskell and Racket and I found basics not too hard to learn, but I did then too hard to master, but I think thats to do more with the complexities of the problems I tried to solve and less to do with the languages themselves
评论 #28515491 未加载
brundolfover 3 years ago
Something I&#x27;ve wondered is why we can&#x27;t have a language that <i>looks</i> totally procedural but uses monads under the hood to reason about state at any given point in the process. This would mostly be sugar, but I think it could make that stuff much more accessible.<p>We get small, specialized fragments of this in Rust&#x27;s borrow-checker and TypeScript&#x27;s control-flow analysis, but I&#x27;m not aware of something that tries to take the whole of IO-monads and reshape them into a familiar format.
评论 #28515323 未加载
评论 #28516137 未加载
评论 #28515118 未加载
评论 #28519868 未加载
Tozenover 3 years ago
I believe that functional programming is not as popular as some think it should be, because the more popular languages stole a lot of its mojo. Other languages absorbed and used many functional programming concepts.<p>It became like, &quot;No need to go over there, you can do most of it here, in a language you already know.&quot;<p>As for OOP, I think many people have found ways to circumvent or minimize how much they use it, so are not going over the edge with inheritance and another kind of spaghetti. If they can use a struct, record (Delphi&#x2F;Free Pascal also have advanced records), prototype (JavaScript, Lua...), OOP without classes (Go, Vlang...), or classes with only data then they do. There is more awareness to try and avoid the traps and excesses of class-based OOP.
globular-toastover 3 years ago
I actually don&#x27;t like recipes written in an imperative style and I don&#x27;t think this is how cooks think about them internally. They are the norm for written recipes, but whenever I read one I (and I assume other experienced cooks) translate it into a functional style for internal storage.<p>Consider a recipe for macaroni cheese. In imperative style it might be written like this:<p>Thread 1, step 1: melt butter, add flour, gradually beat in milk, simmer.<p>Thread 1, step 2: remove sauce from heat and stir in cheese.<p>Thread 2, step 1: bring water to boil, add salt, add 125g of pasta, simmer.<p>Thread 2: step 2: drain pasta.<p>Join threads: Fold pasta into sauce and serve.<p>Nobody thinks about how to make macaroni cheese like this. My internal record for macaroni cheese is more like this:<p>&quot;Basically it&#x27;s macaroni and cheese sauce mixed together. You cook pasta in boiling water with salt. Cheese sauce is béchamel sauce with grated cheese. Béchamel sauce is made with a roux and milk. A roux is butter and flour.&quot;<p>In fact, if you look in any decent cookery book, the information will be stored like this. A good book teaches you techniques and builds up raw ingredients into basic building blocks and then final recipes. Only a stupid book tells you how to make béchamel sauce 20 times because 20 different dishes use it.
js8over 3 years ago
Hm, what about a language like Joy or Factor? It is written sequentially, as a recipe, and (in the case of Factor) can have side effects. And yet it is deeply functional, because of the compositionality of words.<p>I really like Haskell, but I think Factor is going to be my next thing (although it needs better type system, like Kitten has attempted to), for the reason that it further simplifies Haskell&#x27;s (already simple) syntax.
bluepointover 3 years ago
I am quite intrigued by functional programming and I spent a fair amount of time with Haskell. I believe that there are cases where functional programming should be relevant, for example numerical software, where by definition you pickup an input once, do a lot of calculations and produce an output (think of lapack, or numerical functions). There is no event loop or continuously looking for input to adjust state. Shouldn’t functional languages be ideal in implementing such algorithms in a simple way and perform better than fortran? They clearly don’t thrive there, but they should. So in the end I got the impression that functional languages about the mental challenge of finding a non trivial problem that an a functional language can solve better than a more traditional language. It might be a form of art in programming: finding the best problem for the tool.
goblin89over 3 years ago
There is an opinion that learning things more thoroughly is helped by making said things in some particular ways[0] harder to learn (so we struggle at first, make our discoveries and get that dopamine boost when we grasp a concept).<p>If we take it as a given, then (controversial opinion) it seems possible that popularity of languages and paradigms that are <i>easy</i> and make intuitive sense (and are not <i>weird</i>, like functional languages) could by itself lead to a lowering of average knowledge level across the industry, even if the difficulty of a language has nothing to do with it being objectively somehow better.<p>[0] Not the way Brainf*^%k does it, though.
nameloswover 3 years ago
1. It&#x27;s weird because it&#x27;s different. It&#x27;s different is because it&#x27;s on the other branch of the skillsets most people used to for years.<p>2. To learn things on the other branch, people need to unlearn until they reach the common ancestor node.<p>3. Unlearn is a form of subtraction. Humans suck at subtraction, be it learning things, making products, or just the human civilization itself - it&#x27;s even easier for it to collapse and start over.<p>It&#x27;s the same idea that Japanese is much harder to learn than German: Because it assumes the learner speaks English, while Chinese people that don&#x27;t speak English would mostly find Japanese is much easier.
isaacimagineover 3 years ago
I read this title as: &quot;Functional programming [is popular, but not] because it is weird.&quot;<p>I was hoping how it would discuss how building software using functional programming techniques made the paradigm uniquely suitable for popular use.<p>Anyway, I digress.
keithnzover 3 years ago
I often wonder, if LOGO, which was inspired by Lisp became more popular than BASIC whether functional programming would have become popular earlier. Many Gen X kids like me were exposed to both, but basic was more broadly avaialbe and often was the OS of your computer, But LOGO was really good for its time and it made it simple to structure your program around functions and build upon functions in a semi lispy&#x2F;schemey way. It instantly change the way I thought about programming and often attempted to replicate that method of programming in basic.
评论 #28520287 未加载
评论 #28520505 未加载
eli_gottliebover 3 years ago
I think the actual problem is that a lot of the functional programming <i>discipline</i> is about writing code to be understood by machines (eg: compilers, theorem provers, etc) in ways that can trade off against the convenience of <i>people</i> reading and writing it. When I have to write a program that computes functions of programs, I always reach for my FP knowledge, first thing, and start using the more &quot;theoretical&quot; branches quite quickly.<p>But program analysis and synthesis are different actual endeavors from writing some bog-standard, everyday code.
Nekorosuover 3 years ago
I&#x27;m not convinced with a convoluted C++ example. Why would you reason about FP in a language that was never built for it? Also, there are some mixed paradigm languages (like Clojure) that avoid pitfalls of the pure FP programming. And yes, I do consider purity a pitfall for some kinds of applications. Actually, Clojure even has OOP features that are a la carte and don&#x27;t create the artificial inconveniences that make you build enormous GoF pattern based solutions to overcome those.
eterevskyover 3 years ago
For me functional languages lose to imperative ones because they make it harder to reason about what actually happens when the program is executed. When you see a nested loop, you immediately know that it will probably perform O(n^2) operations. This is not so in functional languages. I clearly understood it when I was reading about Haskell and learned that out of `foldl` and `foldr` one works in constant time and another in linear. I don&#x27;t remember which.
评论 #28521725 未加载
评论 #28521845 未加载
评论 #28521688 未加载
z5hover 3 years ago
Pure Functional programming’s cost comes up front when you are trying to solve and express your solution. Imperative programming’s cost comes after you have written code, because it is inevitably buggy and incorrect. Imperative programmers and managers don’t mind because fixing bugs feels and looks like productive work, and they don’t believe bugs are largely avoidable.
g42gregoryover 3 years ago
Why does functional programming need to be popular or not popular? Functional programming is one of the several programming paradigms in Python, C++ 20 and Java programming languages. It could be used when appropriate, just as other programing paradigms. I think FP is the norm, when needed, in Python and now increasingly in Java and C++.
rajangdavisover 3 years ago
I like functional programming because I like algebra.<p>When I can reason about things in a way that I understand, that makes me happier as a programmer.<p>I don&#x27;t think it needs be any more complicated than that.<p>If it&#x27;s not popular, so be it. Most of what I am interested in is not popular. I don&#x27;t care.
lambdasquirrelover 3 years ago
This article is from 2016, so if we&#x27;re going to look back a bit, then maybe some perspective is in order?<p>In the grand scheme of things, I look at ReactJS today, with its modern incantation of hooks, and <i>that</i> &quot;language&quot; reminds me a lot more of SML (yes, anyone remember SML?), than it does with C or Java. I started programming professionally back in 2005. Back then OCaml was the rage because we thought it would support OO, and bridge FP and OO, and ReactJS did not exist yet. It was taken for granted that OO and &quot;imperative&quot; were practical. So it&#x27;s interesting to me that modern ReactJS is more like SML than it is like OCaml. And it&#x27;s actually practical. People for whatever reason don&#x27;t consider it weird. Meanwhile, &quot;idempotency&quot; is something desired by the masses, even in infra &#x2F; devops. For example, at least amongst my coworkers, we generally agree that e.g. terraform is &quot;better behaved&quot; than ansible.<p>If you&#x27;re looking for a <i>revolution</i> in these sort of things, I don&#x27;t think you&#x27;re going to get it, because FP a la Haskell is indeed too &quot;weird.&quot; As working engineers, the most important thing at the end of the day is to deliver some working tool or product.<p>The current generation of actual-FP languages have been too much of a pain to be practical. They had to be. They were breaking new ground as far as what could be done. In my mind, Haskell proved the limits of System F. The language was pretty much a test-bed for what you could do if you eschewed any attempt at &quot;backwards-compatibility&quot; with previous mental methods of programming. From a research perspective, that was hard enough to do.<p>But meanwhile, Swift is a massively better language to code in because Haskell and SML existed.<p>Change did not come as a revolution, the way we expected it. People understand FP better than they ever have, on some instinctive level, and that&#x27;s how the world was able to move further away from C++ &#x2F; Java, and towards SML. Ironically this happened in UI – and in the web – which in 2005 seemed like the last place where FP could possibly succeed. It was generally understood in 2005 that FP was bad at &quot;state,&quot; and UIs, of all things, were highly stateful. (To be clear, Haskell is still a pain as far as state goes, but not as much of a pain as it used to be.) So when you put this all together, we can say that the world works in weird ways. It wouldn&#x27;t surprise me <i>too much</i> if the languages of tomorrow actually turned out to be weird, but that&#x27;ll probably take another 15-20 years to see out.
评论 #28521003 未加载
ChrisArchitectover 3 years ago
Any new thoughts since this post<p>Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11188570" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11188570</a>
Zababaover 3 years ago
I think the big difficulty in trying to bake the functional cake is that the author tried to name every step, when he didn&#x27;t do this for the imperative cake.
philonoistover 3 years ago
A big shout out to those institutes and universities that teach FP in intro to programming(CS 101). FP is the foundation for computer science theory.
platzover 3 years ago
comments are bringing out grand thesis or bike shed of FP, but wjat OP actually wrote the article about was being forced to use recursion instead of iteration andnconsidered that FP.<p>If OP had titled his post recursion is weird I think we&#x27;d be seeing some different line of comments.<p>Secondly, his recursion example not really support his opening comments about FP and cakes.<p>Thirdly, you dont have to do things backwards in FP.
quickthrower2over 3 years ago
The monadic recipe is<p><pre><code> main :: IO () main = do &#x2F;&#x2F; … followed by imperative recipe</code></pre>
rossjudsonover 3 years ago
This is possibly the best article on functional programming I&#x27;ve ever read.
he0001over 3 years ago
My experience is that fp is notoriously bad at dealing with errors. Errors are quite common in everyday business cases, although usually ignored, (like in c#), which makes it hard to “fit” into whatever you are working with. Any language that doesn’t treat errors as a first class citizen in it&#x27;s syntax is a bad one, which I feel like that languages like Haskell isn’t doing well. Also errors are contextual so it’s not always so that an error is one in some context and may be so in others. So the language must be flexible enough to handle both in a nice way. I think Java is kind of a good example of this where it had checked exceptions to signal errors, but when introducing fp syntax they completely botched how errors work. This left you with a mess and programs keeps crashing because people didn’t know that code could throw errors.
deltasixeightover 3 years ago
&gt;Ah screw it I can’t finish this. I don’t know how to translate the steps without mutable state. I can either lose the ordering or I can say “then mix in the bananas,” thus modifying the existing state. Anyone want to try finishing this translation in the comments? I’d be interested in a version that uses monads and one that doesn’t use monads.<p>He&#x27;s wrong and he completely misunderstood functional programming. It&#x27;s not weird at all. Let&#x27;s get things straight. First off there&#x27;s a difference between functional programming and types. Monads are more of a type centric thing and also haskell centric. Haskell is a big part of functional programming but it&#x27;s only one style. You can do functional programming without monads and also without type checking. Additionally type checking and even haskell-like type checking AND monads can exist in imperative languages as well (like rust.) Does rust having monads make it functional? No.<p>Second functional programs can be very very very very readable. It depends on how you structure it and your naming conventions. See example below:<p><pre><code> list of data primitives (aka ingredients and tools): cake grease flour small_bowl large_bowl pan whisk salt oven cream butter_milk white_sugar brown_sugar walnuts heatedOven = preHeatOven(oven, 175) panWithGreaseAndFlour = putGreaseAndFlourInPan(grease, flour, pan) bowlWithWhiskedIngredients = whiskStuffIntoBowl(small_bowl, whisk, salt, flour, baking_soda) bowlWithSugars = mixStuffInBowl(large_bowl, white_sugar, brown_sugar) bowlWithSugarsAndBananas = mixStuffInBowl(bowlWithSugars, bananas) bowlWithAllingredients = mixStuffInBowl(bowlWithSugarsAndBanas, bowlWithWhiskedIngredients, buttermilk, walnuts) panWithAllIngredients = pourContentsOfBowlIntoPan(bowlWithAllingredients, pan) heatedPan = heatPan(panWithAllIngredients, heatedOven, 30) finishedProduct = coolPan(heatedPan) </code></pre> I mean that&#x27;s so simple I can literally translate that into english:<p><pre><code> Create a heated oven by heating an oven to 175 degrees. Create a pan with grease and Flour by putting grease and flour into a pan. Create a bowl with whisked ingredients by whisking salt, flour and baking soda into a small bowl with a whisk. .... </code></pre> You get the picture... It&#x27;s just real practical english tends to be less pedantic that&#x27;s it.<p>Think about it this way. Let&#x27;s say we live in an imperative world where we have an oven. We then heat the oven. Now in the imperative world the oven is destroyed and replaced by a heated oven. We only refer to the &quot;heated oven&quot; as an &quot;oven&quot; for convenience but in fact the original &quot;oven&quot; is actually destroyed as in it no longer exists.<p>In functional programming THE only difference is that the original oven is NOT DESTROYED. That&#x27;s it. You have a heated oven, but you still have a reference to the original oven. But you don&#x27;t ever need to refer to original oven if you don&#x27;t want to. This makes English describing imperative processes more or less IDENTICAL to functional processes.<p>Another perspective to think about this is that in the English language we create the heated oven but the original oven is not destroyed but moved! The oven is now moved into a namespace called the past, we can only refer to the original oven by appending or prepending one of the many names and phrases of the &quot;past&quot; namespace to the oven! For example: The oven &quot;before it was heated&quot;, the oven &quot;from the past&quot;, the &quot;original&quot; oven,... etc.<p>So from that perspective then the only difference between FP and english is that variables once operated on, are moved to a different namespace. So literally just extra past-tense embellishment on English grammar is the ONLY difference.<p>It gets crazier than this. Is anything in reality really mutable? What does mutability even mean? We live in a universe where each instance of time is it&#x27;s own namespace. The universe is a function of time. At t1 there is an oven, at t2 there is a heated oven. So really mutability is just syntactic sugar over immutability where just gloss over mentioning what time namespace we&#x27;re in for convenience. Yes you heard that right. Everything is actually immutable and mutability doesn&#x27;t exist. Our concept of &quot;mutability&quot; arises from language shortcuts we take and assumptions of present tense.<p>Either way from the examples this guy writes it&#x27;s pretty obvious functional programming didn&#x27;t click for him. He understands the rules like immutability and he sees all the crazy tricks and nutty types people associate with functional programming but he missed the big picture. Hopefully this explanation will let the concept of functional programming click a bit more with people.<p>There is in fact a deeper intuition for why functional programming is &quot;better&quot; than imperative programming. But that&#x27;s another long explanation. Most people don&#x27;t ever reach this point of realizing how functional programming is better. They could spend years doing functional programming and completely miss it. Instead they reach a state where they think functional programming is sort of a style of programming used to express intellectual arrogance with no practical benefits and they give it up and move back to imperative programming. Well, they are wrong and they missed a deeper understanding of a fundamental concept. If this sounds like you, I&#x27;m telling you... you missed the big picture.<p>Literally the OP is a picture perfect example of this. Completely missed the point of FP but spent enough time with FP to understand what a monad is, even though a monad isn&#x27;t really technically an FP thing.
fnord77over 3 years ago
I like the FP syntax in Java 16, rust and clojure.<p>I dislike it in Scala, C++ and javascript
myWindoonnover 3 years ago
Ah, to be reminded of high school, where one could be not popular simply because they are weird.<p>I think that they&#x27;ve confused functional and declarative?
评论 #28515818 未加载
评论 #28515300 未加载
ur-whaleover 3 years ago
People always underestimate how much the aesthetics of things actually matter. Language adoption is a numbers game and good marketing matters.<p>This is why Lisp never won. However powerful and elegant it may be, Lisp syntax is downright ugly.<p>The exact same thing happens with Haskell. However amazing the language is, its freaking unapproachable and the syntax is - like the OP says, weird.
评论 #28515594 未加载
评论 #28520388 未加载