Skip to content

Commit

Permalink
[self]
Browse files Browse the repository at this point in the history
  • Loading branch information
Huxpro committed Oct 8, 2018
1 parent 33173f1 commit 8f7b3e6
Show file tree
Hide file tree
Showing 2 changed files with 42 additions and 15 deletions.
30 changes: 15 additions & 15 deletions _posts/2018-09-27-avoiding-success-at-all-cost.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,47 +12,47 @@ tags:
- 🇬🇧
---

"Avoiding success at all cost" is the informal motto behinds Haskell. It could be parenthesized in two ways, either "Avoiding (success at all cost)" or "(Avoiding sucess) (at all cost)".
"Avoiding success at all cost" is the informal motto behinds [Haskell](https://www.haskell.org/). It could be parenthesized in two ways, either "Avoiding (success at all cost)" or "(Avoiding sucess) (at all cost)".

I'm not going to interpret them directly but rather share some thoughts on "the success vs. costs" basing on my very own understanding.
I'm not going to interpret them directly but rather to share some thoughts on "the success vs. costs" basing on my very own understanding and experience.

### The success vs. cost of language design

There're always trade offs (or compromises) in any software design, and programming language design has no exceptions.

In other words, all language design decision that made them "successful" i.e. being popular and widely-used in industry or education for some reason, all comes with theirs own "costs": being unsafe, limited expressiveness, bad performance, etc.
In other words, all language design decision that made them "successful" i.e. being popular and widely-used in industry or education for some reasons, all comes with their own "costs": being unsafe, limited expressiveness, or having bad performance, etc.

Whether or not the "cost" is a problem really depends on scenarios, or their goals. For instances, Python/JavaScript are both very expressive and beginner-friendly by being dynamically-typed, sacrifing the type safety and performance. Java, in constrast, use a much safer and optimization-friendly type system but being much less expressive.
Whether or not the "cost" is a problem really depends on scenarios, or their goals. For instances, Python/JavaScript are both very expressive and beginner-friendly by being dynamically-typed, sacrifing the type safety and performance. Java, in constrast, uses a much safer and optimization-friendly type system but being much less expressive. Another typicial comparison would be memory management in programming languages, where languages that are "managed" (by either ARC or Gabage Collector) could be much easier and safer (in terms of memory) for most programmers but also considerred slower than languages that are "closer to the metal".

None of these "costs" really prevent them from being immortally popular.
None of these "costs", or "differences", really prevent them from being immortally popular.

For Haskell, the story becomes quite different: being research-oriented means the goal of it is to pursue some "ultimate" things: the "ultimate" simplicity of intermediate representation, the "ultimate" type system where safety and expressiveness can coexist, the "ultimate" compilation speed and runtime performance, the "ultimate" concise and elegant concrete syntax, the "ultimate"...I don't know. But it has to be some "ultimate" things that is very difficult, probably endless and impossible, to achieve.
For Haskell, the story becomes quite different: being research-oriented means the goal of this language is to pursue some "ultimate" things: the "ultimate" simplicity of intermediate representation, the "ultimate" type system where safety and expressiveness can coexist, the "ultimate" compilation speed and runtime performance, the "ultimate" concise and elegant concrete syntax, the "ultimate"...I don't know. But it has to be some "ultimate" things that is very difficult, probably endless and impossible, to achieve.

This, as a result, made all language decision in Haskell became very hard and slow, because **almost nothing can be scarified**. That's why Haskell insisted to be lazy to "guard" the purity regardless of its problems; a decent IO mechanisms is missing in the first 4 yrs after the project's start until P Walder found _Monad_; and the _Type Class_, which first proposed in P Walder's 1989 paper, spent yrs long to implement and popularize.
This, as a result, made all language decisions in Haskell became very hard and slow, because **almost nothing can be scarified**. That's why Haskell insisted to be lazy to "guard" the purity regardless of some problems of being "call-by-need"; a decent IO mechanisms is missing in the first 4 yrs after the project's start until P Walder found _Monad_; and the _Type Class_, which is first proposed in P Walder's 1989 paper, spent yrs long to implement and popularize.

As a side note though, it doesn't mean there is no compromise in Haskell at all. It's just as minimized as it progress. When one audience asking why we have Haskell and OCaml, which're quite similar in very high level, both survived, SPJ replies:
As a side note though, it doesn't mean there is no compromise in Haskell at all. It's just as minimized as it could be during its progress. When one audience asking why we have Haskell and OCaml, which're quite similar in very high level, both survived, SPJ replies:

> There's just a different set of compromises.
### The success vs. cost of language design process

Another common but extremely controversial (if not most) topics of programming language design is about its process: would you prefer dictatorship or a committee (a dictatorship of many?)? Would you go with proprietary or standardizing? How formal you want the standardization going, in human language, pseudo code or formal semantics? How many and frequently a breaking change dare you make? Do you let open source community involve in it?
Another common but extremely controversial (if not the most) topics of programming language design is about its design process: Would you prefer dictatorship or a committee (in other words, a dictatorship of many?)? Would you prefer being proprietary or standardized? In which form would you write the standards, in human nature language, pseudo code, or formal semantics? How many and how frequently breaking changes dare you make? Would you let open source community involve in?

Again, I think there is no THE answer for this question. Majority of popular programming languages came and still on going with very different paths.
Again, I think there is no THE answer for all those questions. Majority of popular programming languages came and are still on going with very different paths.

Python, whose creater, Guido van Rossum, known as the "Benevolent Dictator For Life" (BDFL), i.e. good kind of dictator, still play the central role (until July 2018) of the Python's development after Python getting popular and adapt a open source and community-based development model. This factor direcly contribute to the fact that Python 3, as a breaking (not completely backward-compatible and not easy to port) but good (in terms of language design and consistency) revision of the language can still be landed, despite of many communities' pressures. There're many language (Ruby, Perl, Elm) also choose to follow this route.

JavaScript, widely known as being created by Brendan Eich in 10 days, in comparision, quickly involved into a committee (TC39) and standardized (ECMAScript) language as both the open nature of the Web and its fast adoption. But Brendan, as the creater, wasn't even powerful enough to push the committee landing ES4, also a breaking revision, but ended up with the ES5 (Harmony), a backward-compatible, but much less ambitious version after some political "fights" between different parties (e.g. Mozilla, Microsoft, Yahoo etc.) and couldn't change the history. Even the latest rising of "modern" JavaScript (ES6, 7, 8...) is mainly driven by the new generation of committee parties (+Google, Facebook, Airbnb etc.) and still in a very open and standardized way.
JavaScript, widely known as being created by Brendan Eich in 10 days, in comparision, quickly involved into a committee (TC39) and standardized (ECMAScript) language due to both the open nature of the Web and fast adoption of itself. But Brendan, as the creater, wasn't even powerful enough to push the committee landing ES4, which is also a breaking but much better revision, but ended up with the ES5 (Harmony), a backward-compatible, yet much less ambitious version due to many political "fights" between different parties (e.g. Mozilla, Microsoft, Yahoo etc.) thus the history wasn't changed. Even the latest rising and yearly releasing of the "modern" JavaScript (ES6 or ES2015, 2016, 2017...) are mainly driven by the new generation of committee parties (+ Google, Facebook, Airbnb etc.) and still in a very open and standardized way.

Even the history and progress of two relatively similar community-based languege can be so different, not to mention more proprietary programming language e.g. Java in some terms, C# etc. from Microsoft, OC and Swift from Apple (though the latter was open sourced) or more academia and standardized language e.g. having formal standard (SML and Scheme).
As you can see here, even the history and progress of two rather similar languages can be so different, not to mention more proprietary languages such as Java from Sun/Oracle, C# from Microsoft, OC/Swift from Apple (though the latter was open sourced) or more academia and standardized language like SML and Scheme which both has a standard written in formal semantics.

Haskell, being an academia language, while choosing a route closer to C++/OCaml i.e. the compiler implementation over standardization; having committee but very dictatorial in terms of making breaking changes, then trained a very change-tolerant community is quiet unique but avoid it "becoming too success too quickly"
So it's not not obvious that Haskell, also chose its own unique process to suit its unique goal. Although it backs on academia, it chose a rather practical/less-formal approach to define the language, i.e. the compiler implementation over standardization (plus many "formal" fragments among papers though), which is more like C++/OCaml from this point of view. It has a committee, but instead of being very open and conservative, it's more dictatorial (in terms of average users) and super aggressive in terms of making breaking changes. As a result however, it trained a group of very change-tolerant people in its community...All of these quirks and odds combined works very well and avoid the Haskell "becoming too success too quickly".


### End thoughts

To be fair, Haskell has alreay been very "successful" nowdays, in particularly academia (as the sexy type laboratory etc.) but also industry, either being used in real business or being very reputable among non-academic programmers (as being both hard and fun).
To be fair, Haskell has alreay been very "successful" nowdays, in particular academia (for education, sexy type laboratory etc.) but also industry, either being used in real business or being very reputable among programmers (as being both hard and fun).

I am not confident to say Haskell is success in the right degree at the right time now, but it's great to see it, after more than 20 and now almost 30 yrs, very successfully avoiding the "success" they want to avoid and figure out its very unique way, to "Escape from the Ivory Tower", and going beyond.
I am not confident and qualified to say Haskell is success in the right degree at the right time. But it's great to see it, after more than 20 and now almost 30 yrs, slowly figure out its very own way, to "Escape from the Ivory Tower", and keep going beyond.


27 changes: 27 additions & 0 deletions _posts/2018-10-06-vim-cn-im.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
layout: post
title: "Vim 与中文输入法"
subtitle: 'Using Vim with non-english input method'
author: "Hux"
header-style: text
tags:
- Vim
---

Update: 我最后还是放弃在 Vim 模式下输入中文了,mental model 的 cost 太重了(

---

我相信很多中文世界的 Vimer 都遇到过这个烦恼,在 vim 的 insert 模式时可能突然想输个中文,输完之后会本能的直接 `esc` 接 normal 模式操作,结果发现跳出来的是中文输入法……对于 vscode,我一般会在几次错误之后被逼到退出 vscode vim 模式,而对于终端中用的 neovim,就只能尽量不输入中文了。

为了满足我 1% 用 vim 输入中文的场景(比如写博客),我还是想看看有没有什么解决方案,Google 出来的解决方案基本是:*在退出 insert 模式时记住当时的输入法,并自动切换到默认输入法(一般是英文)给 normal 模式用,并且在下一次进入 insert 模式时再切换回来。*

原生 vim 的话,可以使用 [smartim](https://github.com/ybian/smartim) 插件,原理是调用 [im-select](https://github.com/daipeihust/im-select) 这个 CLI 工具来切换输入法。

对于 VSCode-vim 的话,smartim 的移植也在近期的 PR 中被 merge 到了插件里,[详情见文档的这部分配置]( https://github.com/VSCodeVim/Vim#use-im-select),需要指定一下默认输入法和 im-select 的 binary 路径就好。

---

不过实话说,在 vim 中编辑中文的效率和体验和英文比都是大打折扣的。因为中文分词难度太高,不像英文可以简单依靠一个 `split " "` 搞定。所以其实无论 vim(`w`ord,`b`egin,`e`nd),emacs 还是操作系统自带的(比如 macOS 中的 `alt + 箭头`) 「按词移动」功能对于中文都仅仅是跳转到下一个空格处而已,对于中文来说基本就是下一句了……其他常用操作诸如 `f``/`, `r`eplace, `t`ill 也都无法很好的工作。

不过也算聊胜于无吧,由于我常用 HHKB,能用 vim 操作的一个子集(`hjkl`, `o`, `A`, `I`, `v` etc.)可能也比按住 `Fn` 的方向键好用……

0 comments on commit 8f7b3e6

Please sign in to comment.