blocks|key|1957384|text|首先，不要担心失去了一些特殊的特性，比如动态类型。由于您熟悉Common，一种设计得非常好的语言，我想您应该知道一种语言不能简化为它的特性集。这都是一个连贯的整体，不是吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1957385|在这方面，Haskell与Common一样明亮。它的特性结合在一起，为您提供了一种编程方式，使代码非常简短和优雅。更精细的(但类似地，更难理解和使用)概念，如monads和箭头，在一定程度上缓解了宏的缺乏。静态类型系统增加了您的功能，而不是像在大多数面向对象语言中那样阻碍您的方式。|1957386|另一方面，用Haskell编程的交互性要比Lisp差得多，而且像Lisp这样的语言中存在的大量反映并不符合Haskell预设的静态世界观点。因此，您可以使用的工具集在这两种语言之间是非常不同的，但是很难相互比较。|1957387|我个人更喜欢一般的Lisp编程方式，因为我觉得它更适合我的工作方式。然而，这并不意味着你也一定要这么做。|1957388|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

First of all, don't worry about losing particular features like dynamic typing. As you're familiar with Common Lisp, a remarkably well-designed language, I assume you're aware that a language can't be reduced to its feature set. It's all about a coherent whole, isn't it?

In this regard, Haskell shines just as brightly as Common Lisp does. Its features combine to provide you with a way of programming that makes code extremely short and elegant. The lack of macros is mitigated somewhat by more elaborate (but, likewise, harder to understand and use) concepts like monads and arrows. The static type system adds to your power rather than getting in your way as it does in most object-oriented languages.

On the other hand, programming in Haskell is much less interactive than Lisp, and the tremendous amount of reflection present in languages like Lisp just doesn't fit the static view of the world that Haskell presupposes. The tool sets available to you are therefore quite different between the two languages, but hard to compare to one another.

I personally prefer the Lisp way of programming in general, as I feel it fits the way I work better. However, this doesn't mean you're bound to do so as well.

blocks|key|1957411|text|简短答覆：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1957412|对于宏您可以做的几乎任何事情，您可以用一个高阶函数(我包括monads，箭头等)，但它可能需要更多的思考(但只是第一次，它很有趣，您将是一个更好的程序员，和|unordered-list-item|1957413|静态系统是足够普遍的，它从来不会妨碍您，而且它实际上“有助于实现敏捷性”(正如您说过的)，因为当您的程序编译时，您几乎可以确定这是正确的，因此这种确定性允许您尝试一些您可能会害怕尝试的东西--编程有一种“动态”的感觉，尽管它与Lisp不同。|1957414|[注意:有一个"模板Haskell“，它允许您像在Lisp中那样编写宏，但严格地说，您不应该需要它。]|offset|length|1957415|entityMap|0|LINK|mutability|MUTABLE|url|http://www.haskell.org/haskellwiki/Template_Haskell^0|0|0|0|8|9|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|U|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|V|8|@]|9|@$I|W|J|X|1|Y]]|A|$]]|$1|K|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

Short answer: 

<ul>
<li>almost anything you can do with macros you can do with a higher-order function (and I include monads, arrows, etc.), but it might require more thinking (but only the first time, and it's fun and you'll be a better programmer for it), and</li>
<li>the static system is sufficiently general that it never gets in your way, and somewhat surprisingly it actually "aids in achieving agility" (as you said) because when your program compiles you can be almost certain that is correct, so this certainty lets you try out things you might be otherwise afraid to try -- there is a "dynamic" feel to programming although it's not the same as with Lisp.</li>
</ul>

[Note: There is a "<a href="http://www.haskell.org/haskellwiki/Template_Haskell" rel="noreferrer">Template Haskell</a>" that lets you write macros just as in Lisp, but strictly speaking you should never need it.]

blocks|key|423604|text|当我继续我的Haskell学习之旅时，似乎有一件事情有助于“替换”宏，那就是定义您自己的infix操作符并自定义它们的优先级和相联性。有点复杂，但是一个有趣的系统！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|423605|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As I continue my Haskell-learning journey, it seems that one thing that helps "replace" macros is the ability to define your own infix operators and customize their precedence and associativity. Kinda complicated, but an interesting system!

blocks|key|423645|text|在Haskell中进行元编程的需求要比在Common中少，因为许多元编程都可以围绕monads进行，而且添加的语法使嵌入的DSL看起来更不像树，但是正如ShreevatsaR所提到的，始终存在模板Haskell，如果您喜欢括号，甚至还有李塞尔+(Haskell语义%2B+Lisp语法)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|423646|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/392733/haskell-lisp-and-verbosity#392893|1|http://www.liskell.org/^0|24|B|0|3A|3|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

There's less need for metaprogramming in Haskell than in Common Lisp because much can be structured around monads and the added syntax makes embedded DSLs look less tree-like, but there's always Template Haskell, as mentioned by <a href="https://stackoverflow.com/questions/392733/haskell-lisp-and-verbosity#392893">ShreevatsaR</a>, and even <a href="http://www.liskell.org/" rel="nofollow noreferrer">Liskell</a> (Haskell semantics + Lisp syntax) if you like the parentheses.

blocks|key|1957525|text|在Haskell中，可以定义if函数，这在LISP中是不可能的。这是可能的，因为懒惰，这允许更多的模块化程序。这篇经典论文:约翰·休斯(+John+)的“为什么FP重要？”，解释了懒惰是如何增强镇静的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1957526|entityMap|0|LINK|mutability|MUTABLE|url|http://www.math.chalmers.se/~rjmh/Papers/whyfp.html^0|25|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

In Haskell you can define an if function, which is impossible in LISP. This is possible because of laziness, which allows for more modularity in programs. This classic paper: <a href="http://www.math.chalmers.se/~rjmh/Papers/whyfp.html" rel="noreferrer">Why FP matters</a> by John Hughes, explains how laziness enhances composability.

blocks|key|423723|text|我是一个普通的Lisp程序员。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|423724|在一段时间前尝试过Haskell之后，我个人的底线是坚持CL。|423725|原因：|423726|动态输入(请查看动态和静态类型--+Pascal+Costanza基于模式的分析)|unordered-list-item|offset|length|423727|可选和关键字参数|423728|具有宏的统一同音列表语法|423729|前缀语法(不需要记住优先级规则)|423730|不纯的，因此更适合快速原型|423731|具有元对象协议的强大对象系统|423732|成熟标准|423733|广泛的编译器|423734|Haskell当然有它自己的优点，并且以一种根本不同的方式做一些事情，但对我来说，从长远来看，它并没有减少它。|423735|entityMap|0|LINK|mutability|MUTABLE|url|http://www.p-cos.net/documents/dynatype.pdf^0|0|0|0|8|W|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1B|8|@]|9|@$I|1C|J|1D|1|1E]]|A|$]]|$1|K|3|L|5|H|7|1F|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1G|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|H|7|1K|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1M|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

I'm a Common Lisp programmer.

Having tried Haskell some time ago my personal bottom line was to stick with CL.

Reasons:

<ul>
<li>dynamic typing (check out <a href="http://www.p-cos.net/documents/dynatype.pdf" rel="nofollow noreferrer">Dynamic vs. Static Typing — A Pattern-Based Analysis by
Pascal Costanza</a>)</li>
<li>optional and keyword arguments</li>
<li>uniform homoiconic list syntax with macros</li>
<li>prefix syntax (no need to remember precedence rules)</li>
<li>impure and thus more suited for quick prototyping</li>
<li>powerful object system with meta-object protocol</li>
<li>mature standard</li>
<li>wide range of compilers</li>
</ul>

Haskell does have its own merits of course and does some things in a fundamentally different way, but it just doesn't cut it in the long term for me.

blocks|key|1957631|text|在Lisp中，您可以使用宏实现一些非常酷的东西，这些宏在Haskell中非常麻烦(如果可能的话)。例如，“回忆录”宏(见Peter的PAIP第9章)。用它，你可以定义一个函数，比如foo，然后简单地计算(memoize+'foo)，它用回忆录版本代替foo的全局定义。你能用高阶函数在Haskell中实现同样的效果吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1957632|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are really cool things that you can achieve in Lisp with macros that are cumbersome (if possible) in Haskell. Take for example the `memoize' macro (see Chapter 9 of Peter Norvig's PAIP). With it, you can define a function, say foo, and then simply evaluate (memoize 'foo), which replaces foo's global definition with a memoized version. Can you achieve the same effect in Haskell with higher-order functions?

blocks|key|745092|text|关于宏，这里有一个关于它的页面：哈斯克尔，再见，李斯特。它解释了在Haskell中不需要宏的观点。它提供了一个简短的例子作为比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|745093|例如，为了避免计算这两个参数，需要一个LISP宏：|745094|(defmacro+doif+(x+y)+`(if+,x+,y))|code-block|syntax|javascript|745095|例如，Haskell没有系统地计算这两个参数，而不需要任何类似宏定义的内容：|745096|doif+x+y+=+if+x+then+(Just+y)+else+Nothing|745097|和沃拉|745098|entityMap|0|LINK|mutability|MUTABLE|url|http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/^0|G|B|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|15|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

Concerning macros, here is a page which talk about it : <a href="http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/" rel="nofollow noreferrer">Hello Haskell, Goodbye Lisp</a>. It explains a point of view where macros are just not needed in Haskell. It comes with a short example for comparison.

Example case where a LISP macro is required to avoid evaluation of both arguments :

<pre><code>(defmacro doif (x y) `(if ,x ,y))
</code></pre>

Example case where Haskell does not systematically evaluates both argument, without the need of anything like a macro definition :

<pre><code>doif x y = if x then (Just y) else Nothing
</code></pre>

And voilà

For those of you experienced in both Haskell and some flavor of Lisp, I'm curious how "pleasant" (to use a horrid term) it is to write code in Haskell vs. Lisp.

Some background: I'm learning Haskell now, having earlier worked with Scheme and CL (and a little foray into Clojure). Traditionally, you could consider me a fan of dynamic languages for the succinctness and rapidity they provide. I quickly fell in love with Lisp macros, as it gave me yet another way to avoid verbosity and boilerplate.

I'm finding Haskell incredibly interesting, as it's introducing me to ways of coding I didn't know existed. It definitely has some aspects that seem like they would aid in achieving agility, like ease of writing partial functions. However, I'm a bit concerned about losing Lisp macros (I assume I lose them; truth be told I may have just not learned about them yet?) and the static typing system.

Would anyone who has done a decent amount of coding in both worlds mind commenting on how the experiences differ, which you prefer, and if said preference is situational?

Haskell, Lisp, and verbosity

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

对于那些在Haskell和一些Lisp风格中都有经验的人来说，我很好奇，用Haskell和Lisp编写代码是多么“令人愉快”(使用一个可怕的术语)。一些背景:我现在正在学习Haskell，之前我使用了Scheme和CL (以及对Clojure的一些尝试)。传统上，你可以认为我是动态语言的拥趸，因为他们提供了简洁和快速的...

问Haskell，Lisp，和详细
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Haskell，Lisp，和详细EN