English Vinglish: People’s journey across the language barrier

I don’t remember I have ever go to the cinema for a Bollywood movie, but I am glad I enjoyed it very much when I did this for the first time.

The movie remind me of the ESL classes I took. The frustration of not being able to express thoughts in English efficiently echoes the wider range of non-English speaking audiences, evidently by the success of the movie in these traditionally non-Bollywood markets, including Taiwan.

Compare to India, the English-speaking culture is different in Taiwan. English is not the working language of the mess, except for some white-collar works in forgiven companies or tech sectors (e.g., Mozilla in Taiwan). There is indeed a tread (or, “debate”) on wider-adoption of English usage in colleges. And of course, English dominance and culture invasion, and so on and so on.

That said, the English-learning students depicted in the movies are very true. If you only speak English and had (or, having) the experience working with people from other cultures, I wholeheartedly recommend you to see the movie. Pay attention to the thoughts and the minds of these the characters. In retrospect, think about the inherent behavior of these people as they went through their life-long journey of working with you in English.

This is the only reason I wrote this post, in English.

當代電腦:簡短的歷史故事與更短的抱怨

此文經由作者同意,翻譯自 David KendalModern computing: A short history and a shorter rant


在最初,使用電腦很不方便。要使用電腦就一定要學會寫程式:除此之外,沒有其他使用電腦方式了。學寫程式很難,它跟學習一種新的符號語言有關,而該符號語言只是設計用來給予電腦指令。

(此文將「當代」定義起始於微電腦時代(約 1970 年)以符合文意,但前述的歷史除了微電腦,也可以套用在與更早的大型主機上。)

有不少人,花了很長的時間,讓電腦能夠更容易使用,例如麥金塔(Macintosh)個人電腦,但使用上的方便並沒有使撰寫程式更容易(反而更難,因為撰寫圖形介面有更多新的程式語言寫法,所以程式比起原本在命令列上執行的更大)。因此,雖然有更多人買了這些「容易使用」的電腦,很少人學會寫程式。

到最後,這些設計電腦的人覺得,既然沒有人學寫程式,寫程式應該跟大部分的人無關。沒有人應該要為了用電腦而學寫程式,只有想要成為軟體開發者的人才需要寫程式。他們認為寫程式永遠都會是很難的事情,沒有人會想要學,除了專業、全職的程式設計師。

所以他們開始推出比起前代更「容易使用」的電腦。更加的「容易使用」,容易到人們完全無法在上面執行任何自己的程式。不只是那些讓使用者能撰寫程式的功能消失了,他們反過來不讓你在自己的電腦上執行自己的程式,除非你付額外的費用來啟用「開發功能」。

但是當最早的「容易使用」的電腦出現時,有其他人還是在努力的要讓撰寫程式能更容易,讓人人都有能力寫程式的。畢竟,寫程式很簡單:只要了解執行條件和重複而已。而且到最後他們還找出了連這些都不用了解的寫程式方法。

這些人知道撰寫程式並不是本質上困難的事情,會這樣只是因為工藝尚未精純,且早期的工具很粗糙且簡陋。他們知道他們可以做出更好的寫程式工具。

他們也知道會寫程式是一件有力量與啟發性的事,因為它讓你能夠完全掌握且控制你周遭的電腦裝置(而不是讓別人,像是某個「程式設計師」,幫你決定做他認為你會想要的)。他們知道,因為他們總是時時撰寫自己的程式。他們能讓電腦幫忙做所有想做的事,從幫助自閉兒童選擇最好的照片、或是選擇約會對象。他們擁有改造自己與周遭人們生活的能力,且他們想要將這個能力傳遞給所有人。


當然,這整篇「歷史」應該是現在進行式。不過有些「最近」的歷史的確是過去式:人們已經花了快半個世紀研究如何讓撰寫程式更加容易,只是他們的成果在個人電腦起飛之後多半被忽略。

反之,撰寫程式在新的電腦上變得越變越困難,尤其是 Apple 的裝置。這很可惜,因為 Apple 的設計很好,但他們似乎認為容許可撰寫程式的功能,和好設計與易用性是相衝突的。這樣的易用性根本就是個幻覺,因為在畫面之下,電腦是一模一樣的。更精確的說,這種「易用性」高的電腦是更不好用的:它無法為人人所用,只能提供某些人(專業程式設計師)所預期的行為。

只要「撰寫程式本來就是困難的事」這樣的迷思存在一日,電腦等裝置的真實力量永遠只能被少數人所掌握,且讓撰寫程式更為簡單的工具永遠不會出現。


譯註:

  • Computer、computing:譯為電腦,但泛指所有能夠執行程式的計算裝置(computing device)。可以很拗口的翻譯為「計算機」但是這不是一般詞彙。
  • Programming、programmability:譯為「撰寫程式」,因為沒有常用的中文詞彙。在簡體中文有很精準的動詞,即「编程」。

Grunt with QUnit setup on Travis-CI, with SlimerJS

QUnit running on Travis-CI, with SlimerJS

Due to performance considerations, I’ve removed IndexedDB dependency completely from JSZhuyin, the Chinese IME implementation entirely in JavaScript. The program now do searches entirely in the memory with pre-built binary data (the data is built with node with JavaScript too). In order to future-proof the development I’ve enabled Travis CI to run tests with SlimerJS too. For those of you who is not familiar, SlimerJS is the Gecko (Firefox) equivalent of PhantomJS, which allow you to control a browser instance (e.g. to run a QUnit test page in this case) with JavaScript API.

Why not PhantomJS?

For starter, I don’t hate PhantomJS because it’s not Gecko. I love the tool and it’s pioneering idea, but the shipping version lacks of a lot of browser APIs needed for my project to run. It does not come with Function.prototype.bind (reason given here); nor I have no idea the version of WebKit it is shipping with, given the fact it comes with ArrayBuffer interface but without other basics like Uint16Array. Since JSZhuyin rely on these interfaces to work on binary data, I would have to set up the CI with anything other than PhantomJS.

The setup

If you are looking to run PhantomJS and QUnit, the grunt-contrib-qunit task is so easy to set up and it’s probably not warrant a post here. For testing on SlimerJS, I’ve turned to the grunt-shell task instead and run it with a shell script. Without messing up the format of the post here, please refer to the actual setup:

The first problem I hit was that SlimerJS does not return exit code due to Gecko constant. tee the output to a file and grep it solve the problem. The last small glitch I encountered when I push everything to Travis CI was the fact $TMPDIR directary is not actually writable in their VMs; so I moved the temporary file to the working directory instead.

Conclusion

I hope this post will help you get everything running. Web testing and automation is a gigantic topic in which I’ve just starting scratching it’s surface; sometimes I wish there should be a simple tool where you could set it up and forget it, but I still enjoy the alternative process before that show up.