Slient Plant

  • 首页

  • 关于

  • 标签

  • 归档

Emacs: 编辑代码与工作效率

发表于 2014-11-12 | 更新于 2017-08-27 | 评论数:
本文字数: 2.6k | 阅读时长 ≈ 2 分钟

硬件

投资硬件是最简单直接的提高工作效率的方法

屏幕与键鼠是程序员与电脑之间的输出输入设置,是程序员每天工作接触时间最长的东西,硬件上的提升可以直接提高工作效率以及每天工作的心情。

键盘的选择

认识薄膜键盘,机械键盘与静电电容键盘

不差钱直接上静电电容键盘

机械键盘

先说结论:只选红轴。

键盘这东西最好一步到位一发退烧,不需要反复投入。就机械键盘说来,

  • 红轴与黑轴无冲,适合游戏玩家,不同的是按到底所需的力度红轴较小黑轴较大
  • 茶轴与青轴敲击有段落感适合程序员与打字員,青轴所需力度较小但是声音比较吵,茶轴是最多人选择的键芯。 综上选择茶轴机械键盘使用,然后可以考虑转向红轴。最重要的是实际试用自己最符合自己的手感

人体工程学键盘

人体工程学键盘的选择见仁见智

HHKB(Happy Hacking Keyboard)

HHKB吹有很多,盲目买HHKB的更多。不引战,只说个人观点:HHKB不适合重度Emacs用户

键盘布局的选择

市面上一般键盘所用的都是qwert布局的键盘,虽然有数据表示dvorak布局可以提高输入效率以及减少手指疲劳,但是较高的上手难度以及训练过渡期间几乎让你不会打字的痛苦都是使用dvorak布局的成本,而且不见得在你掌握新布局之后打字效率会有多大的提升。

作为程序员打字的速度并不是瓶颈,思考速度才是瓶颈,老老实实使用qwert布局就足够了。

多屏幕

多个显示器可以提高程序员的工作效率,减少切换屏幕带来的上下文切换。 从一家公司是否给员工配置多个显示器可以看出公司是否尊重程序员的工作。

无脑地使用两个显示器即可提高工作效率,你可能还需要屏幕支架。

使用轨迹球,避免鼠标手

Logitech M570 聊胜于无

选择正确的编程字体

windows 下自带的的 Consolas 以及 Mac 下自带的 Monaco 是不错的选择

英文的等宽字体: Iosevka, Hack, Source Code Pro

中文的等宽字体: 文泉驿等宽微米黑, 微软雅黑

好多人还在使用Windows系统默认的字体,那效果用来看代码实在是惨不忍睹。 一旦选择了任一个编程字体,只要15分钟,你几乎不可能还会用回默认的Courier New字体。

Emacs中文与英文对齐

chinese-fonts-setup 分别设置Emacs显示中英文时使用不同的字体和大小,帮助你对齐中英文,在我看来在写org文档时这是一个必备的扩展。在使用org-mode table对齐时特别有用。

编辑器: Emacs

Why it's worth to learn emacs, because the experience will not go away

Emacs的学习曲线是比较陡峭,但是长期来说投资在Emacs上的时间是值得的。逻辑非常简单:

  • 程序员的工作需要进行大量的文本编辑工作
  • Emacs是非常强大的文本编辑器
  • 所以Emacs可以提高程序员的工作效率

key binding

当你在命令行界面使用bash时,你熟悉的ctrl+a跳至行首, ctrl+e跳至行末等快捷键其实就是来源于Emacs,事实上你使用的是bash依赖的GNU readline的默认emacs mode。

Mac OS下的cocoa应用默认有emacs按键绑定,你用发现在Mac下使用emacs按键绑定是很自然的事情。

大多数流行的IDE(Eclipse/JetBrains系列/VS Code)都可以设置为 emacs 布局的按键绑定。

熟悉了 emacs 的基本操作快捷键组合后很多地方都可以用得上。

Emacs的编辑哲学

为什么学习Emacs可以带来好处,因为Emacs会让你对于编辑文本的思考方式不再是基于字符的方法,取而代之的是逻辑上的编辑动作。

从最基本的两个命令(M-x调用命令,ctrl+h查找帮助)开始,你对于日常编辑文本的需求都会变成命令式的。

例子

排序,选中需要编辑的行,M-x sort-lines.

消除行末多余的空格,选中需要编辑的行,M-x whitespace-cleanup.

光标的移动,字符的删除不再是右移一个字符,删除一个字符。使用ctrl键组合进行基于字符的移动和删除,使用meta键组合进行基于词语的移动和删除。

  • ctrl-f右移一个字符 meta-f右移一个词语
  • ctrl-d删除一个字符 meta-d删除一个词语

文件内的跳转不再是基于上下左右移动光标,使用ace-jump-mode或者avy-mode你可以快速将光标定位于你想要跳转到的单词。

jumping around

showcases

想到知道 emacs 在日常的编辑文本工作中可以有多用。Emacs Rocks的一系列简短视频可以告诉你。掌握其中一些技巧可以让你在几秒钟内完成你之前也许需要用分钟来计算的任务。

秘密武器:emacs lisp

原生的emacs也许是很好,但是还不够好。Emacs的秘密在于它的扩展可以使用emacs lisp编程语言来写,Emacs 本身相当于emacs lisp的运行环境和解析器。

emacs lisp是一门完善的编程语言,所以程序员们可以方便地编写扩展来集成调用第三方的应用,也许是一个web api也许是一个命令行工具,然后提供给emacs使用。emacs用户可以方便的使用M-x进行调用,相当于将复杂的编辑需求抽象成一个编辑动作。

杀手级应用

emacs的用户群体已经超出了程序员的范围,现在有许多作家以及科学写作者都开始使用emacs,这些都是emacs的 org-mode 带来。简单的说来org-mode是一个使用emacs来写笔记的扩展,使用一种类似于markdown的语法。

我自己使用org-mode来组织笔记,编写内容然后生成类似readthedocs风格的文档,编写内容然后生成用于演讲分享的slides。

emacs的另一个杀手级应用我个人认为是magit,在emacs里进行 git 的管理。 magit

结语

提高工作效率,投资硬件是最简单直接生效最快的方法。程序员的日常工作需要大量的文本编辑,emacs很有用,但即使不使用emacs投资时间去掌握一个自己喜欢的编辑器/IDE也是值得的,因为每日的工作大量时间花费在编辑器/IDE里面。

Scott H Young - 为什么要学'没用'的东西?

发表于 2014-10-17 | 更新于 2017-08-05 | 评论数:
本文字数: 1.3k | 阅读时长 ≈ 1 分钟

Scott Young是一位我很喜欢的博主,他关注于如何"Learn fast, archieve more",并且身体力行。他最为人津津乐道的事迹是他的MIT Challenge,他在12个月的时间用一种苦行僧的生活方式,近似专业运动员训练般的高强度学习完成了MIT4年计算机系的课程学习并且通过了测试。

Why learn "Useless" Things这篇博文分享了他关于为什么要学习“没用”的东西的观点。

大意概括Scott的观点如下:

  • 多学习知识能够增加人的启发式思考
  • 因为对新领域知识的缺乏在学习新知识时推断当前学习的知识是否“有用”可能不准确,现在看来没用的知识说不定在日后会派上用场
  • 即使所学的东西真的没用也可以让自己对现实理解的模型更加准确(an accurate model of reality)

在与朋友闲聊时谈起在业余时间里评估与接触的各种技术与工具时也曾被人问起:“学这个有什么用?(看这种书有什么用?)不如...",Scott的观点我是十分赞同的,很好的回答了这种问题,对这个问题也曾思索过但是末能够像Scott那样清楚地表达出来。

在程序员的圈子时也有着什么工具框架API用到的时候再说这种观点,这种观点当然是没错的。但是在遇到新的问题,新的应用场景时如果根本就不知道某种工具/技术/理论的存在,又怎么能够快速找到合适的解决方案呢?很多重复制造出来的轮子就是在这种情况下出现的,所以说博识强记是没错的,博识当然有益,强记不必强求。我自己在最近一个项目里快速地做出了让客户满意的方案,这相当程序得益于我平时阅读博客文章,关注技术动向,遇到有可能用到的工具技术时多加留意并记录下来的习惯。

Steve Job应该是个相当好的例子,他在大学的时候去旁听了看起来与计算机毫无关系的美术字课程并著迷于书法和字体,并对排版产生了浓厚的兴趣。但是这却让他在日后设计苹果个人电脑时设计出了漂亮的字体帮助苹果赢得了市场。有时现在看来没用的知识,说不定日后真的会派上用场。

Scott的最后一个观点有些哲学意味,我却是最赞成与喜欢这个观点。霍金在《大设计》一书中提出的最核心观点就是不存在不依赖模型的理论。多学习一点知识也就会获得多一点对于世界的了解,帮助自己形成一个对于认识世界更加准确的模型。从任何意义上说真是有益的。很多人都会有记录日记与写文章的习惯,这能够帮助人思考,但是并不了解这是为什么。几年前的夏天我翻书柜时发现了一本朋友大学时认知心理学的教材,闲来无事读了一遍。却是让我了解到大脑如何主动接受信息的模型,对知识进行深度加工会加深神经元之间的联接从而加深记忆的理论。在那之后我就养成了读书写读书笔记,学习时做思维导图,使用Pocket与Evernote记录信息的习惯。虽然对于认知科学只是有很浅薄的认识,也许我了解的知识不是最准确或者是绝对意义上正确的,但是在自己的实践过程中行之有效并且有益,这就足够了。

开卷有益,古人诚不我欺。

编程的技艺, 禅与道

发表于 2014-10-15 | 更新于 2017-08-05 | 评论数:
本文字数: 4.3k | 阅读时长 ≈ 4 分钟

原文备份

风潮

题目起得很大,实则谈的只是一点个人的随想. 首先要说文中并不过多涉及技术细节, 本人更不是什么大牛, 只是浅谈自己的一些不成熟并带有个人色彩的认识, 难免会有偏颇之处. 说得不对说得不好, 不要削我.

现在似乎有一股风潮(或者说近来有越吹越烈的趋势?), 与计算机, 软件开发或编程相关的事物有时会带上一些有宗教或艺术色彩的文字. 来看看一些例子:

  • 流行的Javascript框架: Dojo(道场)
  • 流行的PHP框架: Zend PHP(阿维斯陀经注解, 网上解释这是波斯琐罗亚斯德教的圣书, 不太知道应该怎么翻译)
  • 来自外星人科技Lisp家族的杰作: 编程语言Qi(气)以及他的后继者Shen(神)
  • 网站设计领域的著名网站: CSS Zen Garden(CSS禅意花园)
  • 在寓言中暗喻程序员修仙之道的好书: The Tao of programming(编程之道)
  • 硅谷创业之父Paul Graham文集, 畅销书: 黑客与画家
  • 计算机领域中当之无愧的传世经典, 被有些好玩的程序员供起来上香奉养的神书: The Art of Computer Programming(计算机程序设计艺术)

他们起这些名字难道是因为名字带上了宗教与艺术相关的词汇之后显得高大上(可以提升逼格)? 答案肯定是否定的. 以上的例子都是饱含智慧结晶的杰作, 不是随随便便被创作出来. 他们的作者似乎都认为编程是一门技艺, 到了相当的程度之后已经是一种境界一种艺术, 追求的事物用中国文化中代表无上境界的文字来说就是: 禅与道. 不闻乎古人有言: 技可进乎道, 艺可通乎神.

曾经看过MIT关于SICP的远古上课视频, 记忆深刻的是在第一课上那个教授在黑板上写下大大的两个单词: Computer Science, 然后回过头来对学生们说了一句话, 大意是We are going to learn computer science, but it's not about computer and not about science. 那么究竟是about what? 这么深奥的说法今天还是无法参透啊, 但是可以作为类比吧, 编程究竟又是关于什么的呢. 编程也不仅仅是像程序们自嘲的那样: 我们程序员只是IT民工, 工地搬砖的. 即使是搬砖的, 还是可以有点小追求的.

在围棋领域中说棋士追求下棋的境界, 人们不会觉得那是他们在扯谈, 而画画, 写作, 作诗, 编曲更是直接与艺术挂钩了. 即使在工程学领域, 作为外行人也曾听闻建筑学上有"建筑是凝固的音乐"这一说法. 它们都有一个共同点, 那就是它们都是一种创造性活动. 而编程作为一种创造性活动, 也是一门技艺. 想写出让人赞叹的程序需要有高超的技巧以及相当的审美观, 如何组织程序, 写出优美的代码, 处理问题逻辑, 考虑系统架构, 设计解决方案就好像画家画画, 作家写书, 同样需要有创造性与灵感以及问题领域的专业知识, 充满挑战与乐趣, 可以称作是工程与美学的结合. 而软件开发更是关于方法论与如何组织人的活动的学问, 研究的是比较玄乎的东西, 不是硬梆梆冷冰冰的计算机硬件. 不同于建筑学此等可以用百年为单位来计数有着悠久历史的学科, 编程或者说是软件开发作为一个行业的历史比较短, 毕竟计算机的大规模普及也只是近代的事情. 关于软件开发没有人知道什么方式是最好的, 所有人都在摸索中前进. 与木匠厨师等职业的经验类似, 前人总结的best practice都是在实践中累积下来的经验之谈, 关于怎么开发软件与编程没有最好的定式, 只有合适实用与否之分. 你没见过厨师做菜的时候切菜要精确到厘米, 下佐料要精确毫克的吧, 即使是有, 这样做出来的菜可以适应不同的食材, 满足不同人的口味吗?

既然编程是一门技艺, 那么就可以去追求它. 在提升思维质量以及累积领域特定的专业知识之外, 编程这个活动还带有强烈的个人色彩, 其中有得审美因素的影响. 在大量的实践与博识之后, 在编程中就会带上个人的品味. 而品味的形成又会促使技艺的提高, 毕竟口味变刁了, 就会对代码有种精神洁癖或者变成细节控, 逼使自己去让程序变得更符合自己的审美, 在打磨的过程中让程序的品质得到提高. 所以要提高自己的技艺就要努力地形成以及提高自己的品味, 而品味的形成离不开大量的实践与广泛的见识. 写程序与写书本质上非常类似, 不同的是用的是编程语言而不是自然语言. 说起编程语言为什么叫做语言呢, 那是因为在计算机的虚拟世界里, 程序员们在用一种机器可以理解的"语言"来和计算机交流, 告诉他外面的世界是怎么样的, 想要让机器如何运作, 自由地进行创造, 所以称作为"语言". 但是随着计算机性能的提高以及编译器理论的发展, 在离开与硬件紧密相连的领域, 现在的程序员越来越重视代码的可读性, 编程有着社交属性, 代码还是写给人看的, 翻译成机器指令的工作就交给编译器.

程序员是工程师, 是problem solver, 问题解决者. 编程员使用工具, 创造工具, 开发软件, 解决问题. 在选择什么工具, 如何创造工具, 如何开发软件, 怎么解决问题的过程中不可避免因为各自审美观与方法论的不同, 各自的答案就会带上个人色彩, 程序员圈子存在着的许多争论就因此而生. 说起来程序员在某些问题上立场鲜明, 与现实中不同党派的支持者政见不同非常类似. 最出名的莫过于Vi与Emacs哪个是最好编辑器之争(顺利一提我是Emacs党, 这篇文章就是在Emacs下写的), 最常见的就各种编程语言支持者之间的争论, 还有类unix vs. Windows, 各种IDE, 解决同个问题的不同库之间的争论等等, 程序员的圈子多姿多彩, 很热闹的啊.

程序员都是高级的工具使用者与方法论者, 个人觉得实践出真知, 程序员应该抱着实用主义的心态, 不人云亦云地去盲目迷信某种方法论与崇拜某种工具. 在这里说一说个人的一些看法:

大规模应用要用云服务器

现在这个云服务器概念非常热门, 谷歌的GAE和亚马逊的AWS就不用说了, 国内的大互联网公司都在开展自己的云服务器服务(新浪云, 阿里云, 腾讯云, 百度云, 就连京东也来掺一脚). 但是不是现在大规模的应用和网站就得要用云服务器了? It depends. 提供一个例子, StackExchange由100多个网站构成,其中包括了Alexa排名第54的StackOverflow(相信这个网站不会陌生)。StackExchang有400万用户,每月5.6亿PV,但只用25台服务器. 它的Windows服务器运行的操作系统版本是Windows 2012 R2,Linux服务器运行Centos 6.4. 5.6亿PV, 25台服务器, 其中有11台运行的Web服务器是微软的IIS. 好像现在一提Web服务器就想起Apache和Nginx, 微软家的IIS不太受欢迎, 但是SO的例子还是说IIS很好用的.

设计模式很牛逼

听说面试经常会问到? 诚然了解各种设计模式的概念并在合适的地方使用它是有益的. 但是反对将它捧得太高, 在代码中为了用它而用它, 好像用了设计模式代码就闪闪发光, 品质立马提高. 了解设计模式之后, 反而会破除对它的迷信. 可能有人会提JDK源码里面用了23种设计模式的例子来支持使用设计模式, 但是个人觉得如果你同时了解Java和设计模式, 你就会发现设计模式的使用正是因为Java这种语言比较冗余缺乏表达力, 所以需求显式地使用设计模式来弥补它的不足. 谷歌的研究主管Peter Norvig在一篇1998年的文章中就讨论了动态语言中设计模式, 你可以看到在表达能力比较强的动态语言(还可以推广到一些强类型的函数式语言)中有些设计模式已经被隐式地包含了, 不需要显式地去使用它. 但是理解各种设计模式的概念能够让你在代码中将它们识别出来, 并在必要的合适的地方使用它们来绕过语言的缺憾来达到目的. 就像Head First Design pattern一书说的, 不能去强行修改代码来迎合某种设计模式. 八封一下, 王垠大神在博客中也有说过每当他在代码中清除一个设计模式, 他的代码就变得更加简洁, 更加容易理解(此等境界, 目前仰望中).

哪种编程语言最好

各种争论之中, 编程语言之争好像是最激烈的, 到处都可以看到不同语言之间的支持者在掐架. 我是right tool for the right job的支持者, 我不会用C来写生成动态网页的程序, 也不会用Haskell来做系统管理的任务. 如果有一种编程语言是最好的, 那一种编程语言就足够了, 那为什么会有这么多编程语言, 而且新语言还在不停地诞生? 近来比较热门的新语言有Go, Rust, JVM平台上的Ceylon, 编译成C的Nimrod, Erlan平台(BVM)上的Elixir. 答案就是没有最好的编程语言, 只有合适的编程语言. 要完成特定的任务就选用特定的语言与相应的工具. 新语言的出现是因为编程语言的理论研究(像新的类型系统)在发展, 程序员的需求在同样也变化, 而越是热门的语言变化就越慢, 当有人感到现在的语言满足不了需要时, 新的编程语言就被创造出来. 多了解几门语言之后就会发现, 类似的编程概念与经验在各种语言之间是相通的, 不同是各种编程语言各自独有的特性与概念. 八卦一下垠神在博客中有说过他不羡慕各种编程语言的特性, 因为他了解背后编译器是怎么实现它们的, 如果他想要他就可以做出来. 他貌似写过很多编译器当乐趣消遣. 他最近加入了sourcegraph, 其中对Python/Ruby代码的分析就是以他的工作为基础的.

敏捷开发

推荐一篇陈皓的文章. 在我离开之前的公司时, 公司内部有着推广敏捷开发的氛围, 各种各样的讲座,分享会, 在团队内部推行daily stand-up meeting, 但是即使是使用了scrum, story, rapid iteration等概念, 实际工作中字官僚主义横行, 项目的流程还是老一套的样子, 只学其形不见其真意. 个人就不多说, 只想说方法论只是方法论, 能不能够真正去使用这种哲学做出好东西来才是重点. 原教旨主义绝对不可取.

作为一个普通的程序员, 想成为一个好的程序员还有太多东西需要学习啊.

Common Lisp - 想说爱你不容易

发表于 2014-10-14 | 更新于 2017-08-05 | 评论数:
本文字数: 3.8k | 阅读时长 ≈ 3 分钟

原文备份

前阵子由阮一峰翻译出版的黑客与画家一书似乎激起了不少人对于Lisp的兴趣,出于个人兴趣开始学习Lisp有一段时间,在这里写写自己接触Lisp过程的感想。

Lisp目前有两种主要的dialect: Common Lisp和Scheme。

Scheme 对于Scheme我了解不深只用过其中一种dialect: Racket一段时间。Racket有一个非常方便使用的IDE: DrRacket(它附带了很多教学包)以及非常详细的文档说明,学习期间阅读了<>和<>,在了解Lisp的基本思想之后我发现Scheme很难使用(也许是我没有深入学习),来google了一些Scheme和Common Lisp的比较后,我转向了Common Lisp。

Welcome to Common Lisp

首先来看一下CL的实现列表,看一下还真不少啊,商业收费和免费开源都有,想当初为选择哪一个实现好纠结了一段时间。从好的方面说,有这么多的实现可以让人选择在不同环境下用不同的实现,但是这也带来了问题:社区的分化和库的通用性问题。如果不想代码只能在特定的CL实现上运行,写代码的就要考虑不同CL实现之间的通用性,真是让人头疼。

IDE

写CL用什么IDE呢?google一下你会告诉大家都用Emacs+SLIME(少部分人用Vim+SLIMV,但是我相信Lisp程序员最终还是用回到Emacs的怀抱的)。Eclipse也有CL的插件Cusp,但个人感觉并不好用。

来看看典型的Common Lisp工作环境:Emacs + SLIME。 你需要掌握:

  1. Common Lisp语言
  2. Common Lisp实现的特定细节 比如run time options,实现对于CL的扩展等
  3. Emacs: 包括基本操作,配置初始文件(.emcas or .emacs.d/init.el)设置好SLIME
  4. Paredit: Emcas的extension,用于方便地编辑括号与Lisp表达式
  5. SLIME: 基本操作

好吧,并不是说Emacs不好,事实上Emcas+SLIME对于熟练的程序员来说是一个非常强力的编程环境,但是对于没有接触过Emacs的程序员来说,在学习CL的过程中就要同时学习使用Emacs,当然长期来说是有好处,但是这么陡峭的学习曲线已经足于让大多数初学者望而止步。

在这里要提一下,CL是一种比较verbose的语言,有些函数名像multiple-value-bind destructuring-bind是相当的长,没有好的编辑器支持补全功能的话会容易写错。如果没有自动缩进功能的话,lisp code写起来是相当痛苦的。

Modern Features

Lisp是一门相当古老的语言,资深的Common Lisper会告诉你X语言的Y特性可以在Lisp中找到或者通过Z的方式用Lisp实现,但是不可否认的是Common Lisp语言本身缺少对一些现今重要的编程概念/工具的支持。

Common Lisp是在94年完成了标准化,标准给具体的实现留下了相当大的空间,Network programming、Thread、GUI都没有覆盖到。也有人说委员会决定了能够经得起时间考验的核心部分,这些个随时间变动的部分就留给具体的实现。当然这些都可以通过库来支持,但是问题也随之而来,不同的实现+不同的库的选择无疑给程序员带来了难题。(支持不同实现的网络编程库有USOCKET,支持不同实现的线程库有bordeaux-threads,当然它们也不是100% portable的)

由于历史原因,Common Lisp没有在不同的数据结构之间建立一个统一的抽象,因为一开始CL中所有的数据结构都是用List实现的(Use Lists For Everything - ULFE)。CL有两套分别用于List和Vector的函数,一套用于Sequence抽象(List/Vector/String)的函数,一套用于hash-table的函数。在提供不同数据结构统一的抽象这一点上Clojure做得非常好。

缺少字面值hash-table(可以通过reader macro在某种程度上实现),用过Javascript和Clojure的应该都明白它的强大之处,最近Java7也加入了类似的功能。

Library & Hacker Culture

许多关于CL的抱怨都是关于库的,CL库的数量比较少(相比于Java/C/C++这些主流语言),而且大多数库都是poor-documented的,缺少详细的说明和例子。写高质量文档对于程序员来说不是件简单轻松的事,而且CL作为一种冷门语言市场上没有太多职位提供给CL程序员,所以也就没有那么人能够得到金钱支持或贡献个人时间来写免费开源的库。我一直听到有人说Lisp是多么多么强大,是的,Lisp非常强大,我知道,但是如果一种编程语言不能容易地与外部世界打交道的话,It doesn't make sense.

举个例子,用Common Lisp来做XML处理,上Cliki找一下发现有不少啊,我应该用哪一个呢?随便点开看看,发现大多数文档中API的说明不太清楚。而且不是资深的CLer的话也缺少相应的知识来回答下面的问题:哪个库更好?这个库可不可以信任?它有没有bugs? 性能怎么样?它是在活跃的开发中还是已经停止维护了(dead-project)?

为什么会样子,这个现象也与Lisp的Hacker文化有关。Lisp是给Hacker准备的语言,它的强大力量只会在越过了陡峭的学习曲线的某一点后显示出来。因为Common Lisp的表达能力是这么的强大几个人甚至一个smart guy单枪匹马就能够写出足够复杂的程序来,所以大规模的CL hacker合作项目比较少。结果就是每个Hacker都有自己的solution,开发者开发它用来解决的自己工作项目的特定问题,后来开源出来了并不代表它适用于其它用户。Common Lisp的强大反而阻碍了库的标准化,而且Common Lisp也没有类似CPAN for Perl这样的东西存在。

QuickLisp的出现是一个福音,能够解决库的依赖问题以及自己下载相应的库,目前有700个上下的库。

Reddit.com讲述了他们从Common Lisp迁移到Python上的原因,主要也是缺少库的问题。

Advantages

在克服了这么多困难之后,你还是选择了Common Lisp,有什么好处呢?

Macro

Common Lisp的强大的Macro会让你轻松的扩展CL本身来迎合自己的需求,最终形成一个用来解决你的特定问题的DSL。Lisp语言的Macro提供了语法层次上的抽象,让你可以将反复在程式上出现的模式抽象出来,这也是Lisp强大以及和其它语言区分开来的一个原因。

多范式

Common Lisp的多范式编程可以让你自由地表达自己思想,指令式编程?没有问题,面向对象?没有问题,函数式编程?没有问题,混合着一起使用都没有问题。

REPL(Read-Evaluate-Print-Loop)

Lisp为人津津乐道的功能就是它的快速原型开发, 为什么快,因为它全程提供了一个REPL环境,在编译型语言中你需要经历写代码-编译-运行-试错-修改-编译...的流程,而在Lisp语言中你可以实时地更新代码,基本是一边写代码一边在REPL中测试然后马上修改然后马上得到新的程序然后继续试验,从编写代码到看到代码的输出的循环是如此的短以至于它极高的提高了程序员的生产率(当然这只是理想情况),read-time compile-time run-time基本上是没有区别的(对于macro来说read-time与compile-time有所区别,这里不详谈),这就是用Lisp能够快速开发出软件原型的原因。PG在这篇被CLer反复提到的文章(Beating the Averages)中提到他开发ViaWeb的故事,Common Lisp就是它的秘密武器。可能最后你的程序会迁移到其它语言/平台上,但是你可以快速地构建出软件的雏形。

End

Common Lisp真的是让人又爱又恨,不过就算不用CL学习它也用对你有所帮助。新技术层出不穷,而Common Lisp会继续稳定地保持下去,它会继续被用于人工智能领域,研究机构,用于解决复杂度非常高的问题,大公司开发的内部工具。然而对于一般的程序员来说,想用Common Lisp作为自己的首要编程语言真的不太容易。在过去50多年的历史Lisp都没能流行起来,未来也许也不会流行起来。如果问哪种Lisp dialect有可能流行起来的话,Clojure 应该就是其中的佼佼者,作为一门新兴的语言它正在吸引越来越多人的眼光,许多人选择它的程序员有着Rudy/Python/Java/Common Lip的背景,基于JVM平台得益于java ecosystem它天生就解决了库的问题。

PS:对于common lisp还有building system和deployment/delivery的问题没有谈,因为没有用CL做过实际项目这些并不了解,但是也知道其中也有被人诟病的地方。

using emacs under mac

发表于 2013-08-10 | 更新于 2017-08-05 | 评论数:
本文字数: 1.8k | 阅读时长 ≈ 2 分钟

在mac下折腾了emacs有一段时间了,写点经验分享一下,顺便一提,mac下cocoa应用全局的emacs按键绑定太舒服了。

安装Emacs

mac默认安装了emacs的,不过版本比较旧(22.x),而且只能在终端下使用,这里选用homebrew来安装Emacs, 首先安装homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
# --cocoa选项表示安装带图形化界面的emacs
brew install emacs --cocoa

安装后brew会提示你可以运行一个命令将emacs 24.3版本链接到/Applications下,这样在应用程序中可以直接双击打开emacs。

Mac下的设置

使用emacs可能会遇到键位设置的问题,有些键盘上没有option键只有alt键,使用发现alt键不起作用,用来运用M-x的绑定变成了Esc-x。解决方法如下:

在自带的终端下使用: 偏好设置 -> 设置 -> 键盘 -> 勾上使用option键作为meta键

在iterm2下使用:Preferences -> Profiles -> 选择配置文件 -> keys -> 在Left/Right option key acts 选项选择 +Esc

在图形化界面下设置需要在emacs初始文件(~/.emacs.d/init.el)中加上:

(when (eq system-type 'darwin)
	;; use option key as meta key
	(setq mac-option-modifier 'meta))

以daemon的方式使用emacs

双击Emacs.app每次都会重新打开一个新的进程来跑emacs, 我更喜欢emacs server + emacs client的方式。用emacs --daemon的方式找开一个后台跑的emacs服务进程,再来emacsclient来连接。

在~/.bash_profile(使用zsh的话就是~/.zshrc)中加入以下alias

# 启动emacs后台进程
alias emdaemon="emacs --daemon"
# 结束emacs后台进程
alias emkill="emacsclient -e '(kill-emacs)'"
# 新建emacs窗口来编辑文件
alias ec="emacsclient -c $@"

在init.el中加上

(setq window-system-default-frame-alist
  '(
    ;; if frame created on Macintosh Cocoa display
    (ns
     (menu-bar-lines . 1)
     (tool-bar-lines . nil)
     ;; mouse
     (mouse-wheel-mode . 1)
     (mouse-wheel-follow-mouse . t)
     (mouse-avoidance-mode . 'exile)
     ;; face
     (font . "Monaco 12")
     ;; frame size
     (width . 96)
     (height . 60)
     )
    ;; if on term
    (nil
     (menu-bar-lines . 0)
     (tool-bar-lines . 0)
     ;; (background-color . "black")
     ;; (foreground-color . "white")
     )
    )
  )

Emacs中文网这篇文章有更详细的介绍关于emacsclient新建frame设置的介绍。

参考文章

  • Setting up the Emacs daemon on OS X
  • Using Emacs as a Server
1…345
Randall Wang

Randall Wang

Just another coder . Heavy Emacs user

22 日志
16 标签
RSS
GitHub
0%
© 2022 Randall Wang
由 Hexo 强力驱动 v3.8.0
|
主题 – NexT.Gemini v7.0.0