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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Dueling Rhetoric of Clojure and Haskell

106 点作者 dukerutledge超过 7 年前

12 条评论

bpolverini超过 7 年前
The dueling rhetoric is the same rhetoric that has been around for decades: Some people really feel type systems add value; others, feel it&#x27;s a ball and chain. So which is it? The answer is probably &quot;yes.&quot; We should all believe by now since history has proven this correct. Most of the time you start with no type system for speed. Then you start adding weird checks and hacks (here&#x27;s lookin&#x27; at you clojure.spec). Then you rewrite with a type system.<p>I&#x27;m a devout Clojure developer. I think it delivers on the promises he outlines in his talk, but I also have no small appreciation for Haskell as an outrageously powerful language. Everyone robs from Haskell for their new shiny language, as they should. Unfortunately, not a night goes by where I don&#x27;t ask God to make me smart enough to understand how a statement like &quot;a monad is just a monoid in the category of endofunctors&quot; can radically change how I implement marginably scalable applications that serve up JSON over REST. Clojure talks to me as if I were a child.<p>Rich Hickey is selling the case for Clojure, like any person who wants his or her language used should do. His arguments are mostly rational, but also a question of taste, which I feel is admitted. As for this writer, I&#x27;m glad he ends it by saying it isn&#x27;t a flame war. If I had to go to war alongside another group of devs, it would almost certainly be Haskell devs.
评论 #15604724 未加载
评论 #15604005 未加载
评论 #15606953 未加载
评论 #15605153 未加载
评论 #15603947 未加载
评论 #15605111 未加载
评论 #15606123 未加载
wellpast超过 7 年前
&gt; Much of the rhetoric that is currently flying around is a false dichotomy.<p>The author here is missing the rhetoric. The rhetoric is not about the programming language but about how we should be doing information processing. Except that the author <i>isn&#x27;t</i> missing that point:<p>&gt; In Haskell we typically “concrete” data with record types, but we don’t have to.<p>Great. That <i>is</i> the dichotomy. And it&#x27;s not a &quot;false&quot; one. This is the question: should we be &quot;concreting&quot;? That&#x27;s the whole dichotomy&#x2F;point that is being made. By encoding EDN&#x2F;Clojure in Haskell the author has gone through a cute intellectual puzzle but hasn&#x27;t contributed to the crux of the discussion. (Indeed, he&#x27;s tried to dismiss it as &quot;false&quot;.)<p>The ergonomics that he ends up with are fairly lean (at least in the examples he&#x27;s shown), though the Clojure expressions are a little leaner. But that&#x27;s probably because Clojure has actually taken a stance&#x2F;belief&#x2F;opinion on the very real question&#x2F;dichotomy at hand.
评论 #15604127 未加载
评论 #15604381 未加载
enugu超过 7 年前
Watching Hickey&#x27;s talk, many of the complaints seemed to be valuable, <i>but they didnt seem to be about static types</i>. Rather, it was about some problems with existing data types locking one into a rigid data model when the domain is constantly expanding.<p>This post by DeGoes makes the same point. <a href="http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;kill-data" rel="nofollow">http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;kill-data</a><p>The default model of algebraic data types is too inflexible.<p>There are different extensions which work with this issue. Good record system, Extensible cases, using free monads etc. We can have concise syntax for automatically declaring an interface for a algebraic data type based on some field values (ie, customizable deriving statements). Namespace qualified keywords, so we have rdf like attribute based semantics.<p>The post doesnt respond to the issue but suggests that if you want to do the same thing in clojure with error handling etc, you will need to think about this stuff.<p>Also, Hickey&#x27;s mention of Monads was again not about static types. Monad laws are not typechecked. Their motivation is purity. The only slight inconvenience in a dynamic context is that you dont have return type polymorphism, so you have to type IOreturn instead of return.
评论 #15605767 未加载
评论 #15605481 未加载
评论 #15615637 未加载
christophilus超过 7 年前
I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language extensions were a contributor to these feelings. I also felt as if I spent more time wrangling with the type system than actually solving my business problems.<p>Yet I really do like Clojure, F#, and PureScript. There&#x27;s an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target?<p>Anyway, one of the things I like about PureScript is the row-types. Does anyone know if there&#x27;s a plan to get row-types into Haskell?<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;andyarvanitis&#x2F;purescript-native" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;andyarvanitis&#x2F;purescript-native</a>
评论 #15604562 未加载
评论 #15603900 未加载
评论 #15604106 未加载
评论 #15603882 未加载
aero142超过 7 年前
I recently added Flow Type to a Javascript project and it changed my opinion on this debate. I realized that I really don&#x27;t care about static vs dynamic typing. What I care about is a hierarchy of the ways that my code can be more likely correct. Given the same level of verification, integration tests and are worse than unit tests are worse than runtime checks are worse than compile time checks. There may be cases where static typing makes code more performant, but I usually care a lot more about development speed and correctness. In this world, I just want a way of verifying my code as quickly as possible. Gradual typing lets me specify some validations of my code that will run at compile time. This is a huge win for me in both correctness and development speed.<p>I don&#x27;t know if we will ever invent the perfect static type system, but I do know that having the ability to specify some types in a pretty good type system, is better than not being able to specify any types.<p>I&#x27;m convinced that a language with a progressive type system is strictly better than one without. Therefor, any debate that compares static vs dynamic, instead of static vs progressive is not interesting to me.
emidln超过 7 年前
Fwiw, you can map over Maps and Strings in clojure:<p><pre><code> (map identity &quot;foo&quot;) ;; a seq for String is its chars ;=&gt; (\f \o \o) (map identity {:foo :bar}) ;; a seq of a Map is the ;; pairs of key&#x2F;values ;=&gt; ([:foo :bar])</code></pre>
评论 #15604378 未加载
dustingetz超过 7 年前
EDN (<i>Extensible</i> Data Notation) is extensible in userland, which is the whole point of it. This is JSON plus some extra types.<p>.<p>.<p>.<p>r&#x2F;clojure on JSON vs EDN: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;6gytlf&#x2F;json_vs_edn_what_does_rich_hickey_mean&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;6gytlf&#x2F;json_vs_edn...</a><p>Transcript of Rich Hickey EDN talk which OP obviously hasn&#x27;t seen: <a href="https:&#x2F;&#x2F;github.com&#x2F;matthiasn&#x2F;talk-transcripts&#x2F;blob&#x2F;master&#x2F;Hickey_Rich&#x2F;LanguageSystem.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;matthiasn&#x2F;talk-transcripts&#x2F;blob&#x2F;master&#x2F;Hi...</a><p>Transcript of Rich Hickey talk OP linked, C-f &quot;edn&quot;: <a href="https:&#x2F;&#x2F;github.com&#x2F;matthiasn&#x2F;talk-transcripts&#x2F;blob&#x2F;master&#x2F;Hickey_Rich&#x2F;EffectivePrograms.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;matthiasn&#x2F;talk-transcripts&#x2F;blob&#x2F;master&#x2F;Hi...</a> Perhaps OP had his fingers in his ears while he watched it. This blog post should be retracted with an apology.
评论 #15605652 未加载
tome超过 7 年前
What&#x27;s <i>really</i> sorely lacking from these discussions is concrete examples of functionality that&#x27;s easy to write in Clojure and hard in Haskell. I don&#x27;t mean functions like `assoc-in`. I mean real functional parts of programs.
评论 #15605607 未加载
grandalf超过 7 年前
This is great. Why have I never heard anyone make this argument over beers when the debating starts?<p>Seems like critiques of a programming language or paradigm are usually made by someone imagining a very bad codebase from their past.
wz1000超过 7 年前
A dynamically typed language is a statically typed language with precisely one type.<p>It is extremely easy to use haskell in &quot;dynamic mode&quot;. Just use `ByteString`(or Data.Dynamic for safety&#x2F;convenience) for all your data. Types just present a way to encode some statically known guarantees about the structure of your data&#x2F;code. You are free to not encode any properties if you want to.<p>But it is very rare that the data you are working with requires the full generality of `ByteString`. You usually have <i>some</i> sort of structure rather than just working with strings of zeros and ones.
评论 #15604129 未加载
评论 #15604501 未加载
weavejester超过 7 年前
<i>&quot;If EDN is an improvement over JSON, then it is marginal at best.&quot;</i><p>Why is it only a marginal improvement? It adds considerably more semantic information.<p><i>&quot;Utilizing EDN also promotes a lot of invisible coupling. Some may tell you that dynamic types don’t couple, but that is incorrect and shows a lack of understanding of coupling itself. Many functions over Map exhibit external and stamp coupling.&quot;</i><p>Coupling implies a bidirectional connection. Functions rely on data types, but not vice versa.
brandonbloom超过 7 年前
EDIT: deleting this post because it was needlessly counter-inflamatory.
评论 #15604226 未加载