TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

What's your strongest opinion against functional programming?

18 点作者 philonoist大约 6 年前

5 条评论

cellularmitosis大约 6 年前
I have yet to encounter any closed stackoverflow question and think to myself “boy am I glad they closed that one!”<p>In fact, most of the time I encounter one of these closed questions, it was precisely the question I was curious about.<p>I just don’t understand why they do this.
评论 #19613442 未加载
评论 #19612612 未加载
评论 #19614053 未加载
ncmncm大约 6 年前
The elephant in the room of functional languages is that they all, somehow, fundamentally depend on garbage collected memory management. This GC is never coded in the functional language itself. Why? Because functional languages are very, very bad at resource management.<p>Real programs typically need to manage resources besides memory. So, they look good depending on GC for toy problems, but fail to graduate from their sandbox.<p>The only powerful languages not dependent on GC are C++ and Rust. They have facilities to manage any resources needed, and that are equally adept at managing memory.<p>As a consequence, it is possible to write libraries for these languages that can work in any program.<p>Programs in obligate-GC languages always need to compromise some aspect of GC to be practical, but that makes them incompatible with the majority of libraries. Thus, you don&#x27;t see good library ecosystems grow up around them.<p>A functional language that did not depend on GC could be useful, but academics would kneecap it immediately. Academia absolute detests the idea of non-obligate-GC languages, for purely tribal reasons.
rgoulter大约 6 年前
<a href="https:&#x2F;&#x2F;pchiusano.github.io&#x2F;2017-01-20&#x2F;why-not-haskell.html" rel="nofollow">https:&#x2F;&#x2F;pchiusano.github.io&#x2F;2017-01-20&#x2F;why-not-haskell.html</a> I found this argument compelling: Haskell is good for programs like compilers: they do many interesting things but without needing to interact with the outside world as much.<p>Whereas &quot;straight-forward CRUD app&quot; is more about interacting with the outside world, which is harder to do in Haskell compared to, say, Go.<p>HN discussions 2018 <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17114308" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17114308</a> 2017 <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13450828" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13450828</a>
评论 #19614501 未加载
评论 #19613919 未加载
评论 #19612978 未加载
magicmouse大约 6 年前
There are many buzzwords in the programming profession. These terms are bandied about with great regularity, and mean almost nothing. Fundamentally, we only have one kind of computer with two variations: the Intel and ARM instruction sets which drive 99.9% of all computers used today. Everything on top of these two hardware platforms is software, and since the hardware&#x27;s only commonly used instructions are arithmetic, copy, load&#x2F;store, compare, branch and call&#x2F;return, the most powerful instruction is the function call and return, and every language from Assembler onward has striven to wring as much utility out of the call&#x2F;return instruction. Functional programming is where you try to give functions more weight, as opposed to the move instruction which was COBOL&#x27;s stock in trade. So one cannot be against functions, it is one of the only power tools we have. What i am against is waving these banners around, like OOP, Functional Programming, Top Down Design, etc., when what we really want is reliable software that is easy to understand. We are evolving towards better notations, but unless you change the hardware (and adding more cores does very little to help) you are pretending these terms actually mean something.
评论 #19615416 未加载
he0001大约 6 年前
Functional programming is beautiful and contained, the real world is cruel, toxic, chaotic and doesn’t give a damn about functional programming.