ruby元編程

1. 游戲開發中常用哪種腳本語言

隨著《魔獸世界》(以下簡稱wow)在世界范圍內流行，腳本漸漸被人們所熟知。由於wow強大的自定義界面系統，Lua這一腳本語言一舉成名。x0dx0ax0dx0a其實早在Lua腳本語言被大眾所熟知以前，游戲業內人士就已經開始使用腳本來開發游戲了。我們熟悉的很多國內的網路游戲大都運用了腳本開發，比如網游的長青樹「夢幻西遊和《大話西遊2就大量應用了腳本技術。特別是《大話西遊2》，其實現基於Lua腳本游戲開發的時間要遠早於《魔獸世界》。在腳本技術上，國內與國外其實是站在同一起跑線上的，並不存在什麼差距，這也為國內游戲產業趕超國外游戲產業提供了強有力的技術保證。x0dx0ax0dx0a在單機游戲時代，腳本這個詞幾乎很少出現，那麼，為什麼在網路游戲時代它卻成了業界的寵兒呢?原因是多方面的。x0dx0ax0dx0a單機游戲時代，無論游戲主機還是PC機，它們的性能都非常低下，從而需要具有較高執行效率的編譯型語言對機器的性能進行「壓榨」。隨著科技發展和硬體性能的不斷提升，腳本逐漸被開發者所接受並利用，但這並不是腳本流行起來的決定性因素，真正的原因還在於游戲市場有這方面的需求。x0dx0ax0dx0a網路游戲時代的市場競爭激烈、變化莫測，如果延用單機時代一年半載才出一個新版本的開發方式，必然會被游戲行業激烈的市場競爭所淘汰。正是這種游戲市場需求旺盛和開發工具效率底下之間的矛盾，促使腳本語言迅速地發展起來。腳本的興起使得傳統編譯型語言(asngC／C )的性能優勢在硬體功效大幅攀升的今天已經不復存在。x0dx0ax0dx0a除了市場和硬體這兩個因素之外，還有一點我們不能忽略。那就是用C／C 進行游戲開發的高成本和高項目風險。隨著java／．net逐漸流行，學習C／C 編程語言的人越來越少，而網路游戲市場的需求卻越來越龐大，在程序人才大量匱乏的情況下，造成了c，C 人才的高成本。即便是有能力僱傭大量C／C 程序員的公司，在開發游戲的過程中，也不能無視C／C 的高級特性和高度靈活性帶來的高項目風險。C／C 是易學難精的編程語言，在開發大型項目的時候由於程序員的水平參差不齊，所以極易造成溝通不暢。不僅如此，c，C 濫用的高級特性也容易引入大量bug。正是由於這些原因，游戲公司開始在游戲中使用腳本，希望通過腳本來解決這些高成本、高風險的問題。x0dx0ax0dx0a二.腳本的現狀x0dx0ax0dx0a腳本不僅解決了c/C 無法解決的開發效率難題，還降低了開發的成本和風險。因此腳本技術在游戲業內蓬勃發展起來，並且已經成為游戲業中不可或缺的一環。縱觀當前腳本技術現狀，形勢一片大好，不僅語言百家爭鳴，而且書籍種類也越來越多；不僅在游戲業界開花結果，在web等其它應用領域也大放異彩。x0dx0ax0dx0a首先，我們來看看目前比較流行的腳本：python、Lua、ruby和Erlang。Python和Lua是網路游戲開發的中堅力量；ruby憑借 rubyonrails的web開發框架的強勁力量，其在游戲業的發展前途亦不可小視；Erlang在高並發性上的原生優勢吸引了無數追求高性能網游伺服器的開發人員的目光。x0dx0ax0dx0a其次，我們來看看書籍方面。大家都知道，文字對語言的普及起到了催化劑的作用，甚至可以看作是語言的有機組成部分。Python經過基金會的多年經營而得到NASA、Google重用的原因，就是由於其相關書籍種類比較豐富；Ruby隨著RoR的流行，這兩年行情看好，書籍也出版得越來越多了；Erlang是典型的少眾語言，但隨著多核時代的來臨和高並發網路應用的需求，Erlang有著光明的發展前景，現在<>等書也已經在策劃出版了；反觀Lua，雖然目前越來越流行，但由於它晦澀的介面設計和缺乏大型應用的支持，使得相關書籍寥寥無幾。x0dx0ax0dx0a最後，我們把焦點重新聚集到游戲開發行業中，其實不難發現，除了前文提到的《魔獸世界》和網易經典「西遊系列」使用了腳本外，現在大多數比較流行的程序也都使用了腳本，如騰訊的QQgame))和搜狐的《天龍八部》等。不僅如此，現今的游戲引擎也都提供了腳本介面，無論是商業的unreal引擎還是開源的 OGRE，無一例外。x0dx0ax0dx0a三.腳本的優勢x0dx0ax0dx0a腳本之所以能夠在游戲業中找到自己的一席之地，是因為網路游戲市場需要一個快速開發方案來避免C／C 開發帶來的項目高成本和高風險。那麼，腳本相對於C／C 這類編譯型語言到底有什麼優勢呢?x0dx0ax0dx0aI易於學習,代碼可維護性強x0dx0ax0dx0a腳本的語法通常都非常簡單，也沒有太多高階的特性，學習的門檻較C／C 低得多，比如Python可能只需要花一個下午即可學會。這使得游戲開發公司可以招聘完全沒有腳本、編程經驗的新手，通過低成本的培訓，他們便能迅速地走上工作崗位。除易於學習外，腳本代碼也有較強的可維護陛(盡管寫出沒有人看得懂的Lua代碼也非難事)。因為腳本沒有很多高階特性(如c 里的模板元編程就是高階特性)，所以腳本程序員就有更多的精力去架構、模式、重用和測試等工作，從而提高了代碼的可維護性。相應地，正因為沒有那麼多讓人困惑的高階特性，也使得腳本代碼「簡潔」不少。x0dx0ax0dx0a2．降低開發成本x0dx0ax0dx0a如上所言，由於腳本易於學習，游戲開發公司可以大量起用新手，這正是降低成本的有效手段。那麼如何來確保新手所寫代碼的質量呢?眾所周知，新手無論用什麼語言寫程序肯定會出現bug，但用C／C 和Python做比較，可以看出，一個新手用C／c 編寫出的程序所出現的bug肯定會比用Python編寫出現的bug要多。由於c程序需要編譯，而腳本程序(大部分)都可以直接解釋執行，所以在排除 bug方面腳本也佔有一定的優勢，這也使腳本在降低成本的同時能夠更好地保證代碼質量。x0dx0ax0dx0a3．形成人才壁壘x0dx0ax0dx0a軟體開發行業是一個頗為動盪的行業，無數的程序員都在跳槽和謀劃跳槽的狀態中生活，使用腳本開發形成人才壁壘是游戲業減少人才流動的有效手段。因為現在腳本除了在游戲業中非常流行外，並沒有在其它行業形成廣泛應用(雖然在web開發方面也有燎原之勢，但終究不如在游戲業中的地位高)。這就使得游戲程序員很少會考慮非游戲行業的職位，但其它行業的程序員卻可能會因為腳本的易學習性而轉投游戲業。腳本除了能有效形成行業間的人才壁壘外，也能有效地形成企業間的人才壁壘。由於現有的腳本種類繁多，不同公司往往有不同的選擇，甚至有些公司使用自己開發的腳本語言，所以程序員從公司A跳槽到公司B可能要學習使用另一種腳本，這就提高了跳槽的成本，從而減少了人才的流動。x0dx0ax0dx0a四.腳本的發展趨勢x0dx0ax0dx0a依照目前趨勢來看，腳本語言一定會更加的普及，而且會逐漸滲透到其它行業中。隨著網路游戲從業人員數量的增長，腳本程序員也一直增加，而且Web2、0熱潮引起的網路需求，也促成了一批批新腳本程序員的誕生。網路游戲市場就像一個正在滾動的雪球，推動著腳本的普及。x0dx0ax0dx0a隨著腳本在游戲業中越來越流行，市場對生產效率的需要也會相應提高。腳本雖然在一定程度上緩解了生產效率與生產工具之間的矛盾，但仍然不夠完善。由於市場競爭日趨激烈，而網路游戲在很多功能上的實現又都相差無幾，如網路、資料庫、圖形甚至部分邏輯，這必然會引起網路游戲生產的組裝化一一大量中間件相互組合形成新的網路游戲。從目前來看，Bigwofld、PhysX和Unreal等都是比較流行的網路游戲中間件。腳本語言則是粘合各個中間件的良好膠水語言，所以隨著網路游戲的生產組裝化，腳本將有更大的發展空間。x0dx0ax0dx0a那麼，當腳本發展到如日中天的時候，可能取代C／C 這些編譯型語言嗎?筆者認為不會。腳本語言和編譯型語言在生產效率和執行效率上各擅勝場，網路游戲既需要能快速應變的腳本，也需要能快速執行以提供更絢麗游戲效果的編譯型語言。未來，它們之間一定會保持長久的和諧互補關系，相輔相成。x0dx0ax0dx0a五.結語x0dx0ax0dx0a綜上所述，網路游戲時代是上帝賜予腳本語言發展的絕好時機，腳本語言很快將迎來光芒四射的時代。腳本語言擁有編譯型語言無可比擬的生產效率優勢，所以它們將互補互助並肩奮戰在游戲的最前線。

2. Ruby VS JAVA 到底誰比誰更強 （1）

他的顧問公司專注於Java 持久化框架和輕量級開發方法，同時他也是這些流行的Java圖書的作者， Spring: A Developer's Notebook, Better, Faster, Lighter Java, 以及 Bitter Java。 1，在《超越Java》中你花費了大量的時間在Ruby上面，看起來是它像在你說那些將超越Java競爭者中出類拔萃。你覺得是什麼使Ruby比 php，Python這類語言優越？這些都是好語言，但是都有一些缺點。對大型應用，PHP和Perl不能連續地產生可讀的代碼。Lisp，Python和Smalltalk這些就缺少了偉大語言好像應該擁有的催化劑。Ruby是一種好語言，和催化劑（Rails）提供了引人注目得新價值（以效率的角度）以及還在飛速地增長。Ruby不一定是最好的語言，但是它將是我所見過最有可能的。Ruby不大可能在委員會那裡超過Java。它很有可能首先在一個更小但是卻重要的環境中取得好成績。這個環境也就是一個有web UI大的胖關系資料庫。 2，是否Rails就意味著Ruby？其他語言包括Java難道就不能實現同樣的思想？如今，Rails就是超過象Netscape之類語言的催化劑，具有Java一樣的功能，可通過網路實現應用的傳送。但是我認為Rails很有可能僅僅是Ruby元編程框架浪潮的第一波。 3，你的書中很多都基於典型的「將一個web介面連接到資料庫」場景，Ruby的成功案例看上去也僅僅是一兩個開發人員的小項目。但是你也承認了Java的重量級企業框架對一些項目的價值（即大型系統上的大型應用）。什麼情況下一個項目對於RoR來說過於大的呢？如果一個RoR在那方面的特性發展緩慢呢？有Ruby和小團隊你可以做很多事情。基礎代碼幾乎都是一個人寫就的，但卻關乎整個公司的生計。在一些主要的公司開始進行認真的嘗試之前，我們不知道你可以利用ruby或者rails到什麼程度。其中一個最吸引我的事情是經濟的規模，更小的規模。萬一生產力的數字是真實的呢？萬一確實可以得到5X的增長？那麼你可以在一個部門內劃分工作，將工作劃分給團隊中的一個。交流將很少會成為問題。管理和疏忽也很少會成為問題了。我們都知道對於一間公司增長, tipping points意味著什麼。因為增加溝通和管理的級別會產生很多的障礙, 所以一間公司增長要超過1，5，10，40，甚至100倍是很困難的。但是，在這一點上, Ruby on Rails的可擴展性是非常的好。 4，你是否看到Java開發人員轉向Ruby嗎，還是Ruby將會給新一代的開發人員採用？我覺得兩者都有可能。有開發人員不能容忍學習servlets， Spring， XML， Hibernate， Struts 然後還要學習一些 UI 粘合的框架。在Rails中，他們將會完全給釋放出來。同時也有Java開發人員已經在尋找更加優勢的方法，他們發現了Ruby on Rails。接受了Rails的Java夢想家們的數目是令人驚愕的，他們有Thought Works，James Duncan Davidson，Stuart Halloway 更有 David Geary。 5，難道Java本身就不能做一些事情來維持它的傑出地位？如果過於復雜和膨脹，什麼可以阻止開發人員倒退到jdk 1.4？Java將會繼續處於頂峰,並在企業應用上保持良好的表現，但是時間不會停滯不前。在某種意味上它終將會給替代。我們將需要一個更高級別的抽象。我認為我們最好的希望就是在JVM上做充足的投入，更好地支持動態語言, 擁抱新的事物，對於舊有的java代碼,則最好是保留保守的態度。

3. 關於Ruby

Ruby on Rails是一個用於編寫網路應用程序的框架，它基於計算機軟體語言Ruby，給程序開發人員提供強大的框架支持。Ruby on Rails包括兩部分內容：Ruby語言和Rails框架。

什麼是Ruby?
Ruby 語言是一種動態語言，它與Python、Smalltalk和Perl這3種編程語言有些類似。Ruby語言起源於日本，它的研發者是日本人松本行弘（Matsumoto Yukihiro）。松本行弘在1993年開始著手Ruby語言的研發工作，他開發Ruby語言的初衷是為了提高編程的效率。 1995年12月Matz推出了Ruby的第一個版本Ruby 0.95。

Ruby語言的主要特點如下。
1．純的面向對象語言
在Ruby中，一切皆是對象。下面舉一個例子來更直觀地說明Ruby語言的這一特點。
在Java中，求一個數的絕對值的代碼如下。
int c = Math.abs(-20);
而在Ruby語言中，一切皆是對象，也就是說「-20」這個數也是一個對象，因此，求一個數絕對值的Ruby代碼形式如下。
c = -20.abs
這樣的代碼編寫方式是不是更形象一些呢？

2．解釋型腳本語言
Ruby 語言是解釋型腳本語言，它既有腳本語言強大的字元串處理能力和正則表達式，又不失解釋型語言的動態性。一方面，在最初設計Ruby語言時，Ruby的研發者松本行弘考慮到文字處理方面的需要，他借鑒了Perl語言在文字處理方面的成功經驗。另一方面，松本行弘將Ruby語言設定為一種解釋型語言，Ruby 的動態性使得由Ruby語言編寫的程序不需要事先編譯即可直接運行，這為程序的調試帶來了方便。同時，這一特點可以實現開發過程中的快速反饋。

3．其他特點
（1）動態載入。可以在運行時候重定義自己，類也可以在運行時繼承或取消繼承。
（2）自動內存管理機制。
（3）多精度整數。
（4）迭代器和閉包。
（5）開源項目。有大量活躍的社區支持Ruby語言。

什麼是Rails?
雖然Ruby語言有很多優點，但是一直以來，其流行的范圍也僅限於日本。直到2004年，Ruby才逐漸被世界上其他地區的人們所認識，那麼是什麼讓Ruby語言走向世界的呢？是Rails。
Rails 框架首次提出是在2004年7月，它的研發者是26歲的丹麥人David Heinemeier Hansson。不同於已有復雜的Web 開發框架， Rails是一個更符合實際需要而且更高效的Web開發框架。Rails結合了PHP體系的優點（快速開發）和Java體系的優點（程序規整），因此， Rails在其提出後不長的時間里就受到了業內廣泛的關注。

Rails框架主要有如下的6大特點。
1．全棧式的MVC框架
Rails是一個全棧式的MVC框架，換句話說，通過Rails可以實現MVC模式中的各個層次，並使它們無縫地協同運轉起來。
在實際開發一個MVC模式的Web應用項目時，如果使用Java開發，需要用到Struts（Model層）、Hibernate （Controller 層）和Spring（View層）3個框架，而且需要額外整合3個框架開發出的內容。而使用Ruby語言開發相同的項目時，只需要用到Rails框架就可以完成。

2．約定優於配置
為了說明各個對象之間的關聯關系，一般的Web應用開發框架往往採用寫入XML配置文件的方法。這種方式雖然可以解決一些問題，但是卻帶來了管理上的混亂。
Rails 對此的態度是約定優於配置，這意味著在Rails中不會出現XML配置文件。Rails使用Web應用多年來積累的各種常見約定（更具體地說是命名規則）來代替XML配置文件，而在Rails內部的映射與發現機制根據這些約定可以實現對象之間的關聯。在第1章中，通過Rails的映射與發現機制實現了數據表與Ruby對象之間的關聯。

3．更少的代碼
使用約定來代替XML配置文件說明Rails本身完成了大量的底層工作，這意味著使用更少的代碼來實現應用程序是極有可能的。此外，代碼量的縮減也減小了出現bug的可能性，降低了維護程序和升級程序的難度。

4．生成器
Rails 使用的實時映射技術和元編程技術，免去了開發人員在開發過程中編寫大量樣板文件代碼的煩惱。在少數需要使用樣板文件代碼的時候，開發人員可以通過 Rails內建的生成器腳本實時創建，而不再是通過手工編寫。Rails的這個特點可以使開發人員更專注於系統的邏輯結構，而不必為一些瑣碎的細節所煩擾。

5．零周轉時間
對已有的Web應用系統進行修改後，其一般需要經過配置、編譯、發布、重新設置、測試等一系列步驟才能投入使用，這明顯浪費了許多時間。而使用Rails開發Web應用系統，可以通過瀏覽器即時查看程序運行結果，從而節約了大量的時間。

6．支架系統
Rails的支架系統可以自動為任何相關的資料庫表創建一套包含標准CRUD操作和前台視圖的系統。通過支架系統，開發人員可以方便快捷地操縱資料庫中的數據表。此外，Rails也允許開發人員使用自己設計的代碼或視圖來替換自動生成的代碼和視圖。

目前，Rails的最新版本是2005年12月13日發布的v1.0.0。從RoR正式提出到v1.0.0的發布，RoR在一年多的時間里受到了業內人士的廣泛關注。RoR受到廣泛關注主要有如下兩個原因：首先，RoR的開發效率高（部署容易）、功能豐富（支持Ajax等流行應用），有消息稱對於相同的 Web開發項目，使用RoR開發比使用Java體系架構開發快5~10倍；此外，令人不可思議的高性能是其受到關注的另一個重要原因，根據CSDN上轉載的新聞稱使用RoR開發出來的項目性能，比基於Struts+Hibernate+Spring的Java應用還要高15%~20%。
RoR 當前遇到的主要問題是使用RoR搭建的大型商業應用還很少，究其原因可以概括為兩點：第一，從開發能力的角度，RoR是一個基於Ruby語言的輕型Web 開發框架，很多開發者對其是否適合大型應用難以把握。第二，本身使用RoR開發的大型商業應用較少，使得後來者持觀望態度。
綜合分析來看，RoR的發展前景還是很光明的。RoR在短時間內取得了巨大的成就，它打破了Web開發領域的固有觀念，方便快捷的開發方式使其被廣泛接受。而事實上，現在已有幾家跨國公司正在使用RoR開發自己的Web應用程序，並且有多家大型公司在考慮使用RoR進行Web應用開發。

4. RUBY元編程怎麼樣

在java的時代，因為不滿面向類/對象的復雜機制，自己借鑒研究了對象裝備模式，後來發現就是spring的原理。當時不知spring的情況下，還自己實現了利用運行時反射機制來動態的給對象設置空類，拼裝方法共享實例對象屬性，做出來雖然很欣慰，但是很難看，很慢，不可能到生產環境。 後來了解了js的函數原型prototype，可以動態的定義方法和傳遞閉包，簡直口水直流，直接轉成了web前台開發，只做ajax，直到ruby的出現。大概是06年，那時候資料賊少，全是日文，英文的都不多，學了皮毛就擱置了。 今年，因為自己回歸開發，想實現一些想法，嘗試了php之後，毅然決定打死不用php，與其深入研究php不如決心搞ruby，打眼一看，發現中文資料太多了，太幸福了，當看到這本元編程的時候，馬上想起java時候的辛酸啊。 Ruby讓人快樂，元編程更是快樂的魔法，創造出令人興奮激動的東西。 計算機不再是僕人，而是朋友，我能理解你，你也能理解我。 如果說寫java就像寫論文，那麼用js就像寫英文詩，而ruby像五言絕句。 所以不學元編程，不如用java

5. 為什麼python的元編程能力沒有ruby強

Ruby的確是比Python更干凈的OOP，這也不奇怪，Ruby根本就是Smalltalk換了點語法而已。
但這個更干凈並不是a.length vs. len(a)，名詞在前還是動詞在前的問題，否則OOP也未免太膚淺了。
在Python里，對於a.f()可能是調用a所屬的類的方法f，也可能是調用a的屬性f。這個二義性在metaprogramming時帶來很多不一致和麻煩，比如Python對__xxx__ magic method lookup的特殊規定。

6. 怎樣用JS實現非同步轉同步

源起

小飛是一名剛入行前端不久的新人，因為進到了某個大公司，儼然成為了學弟學妹眼中'大神'，大家遇到js問題都喜歡問他，這不，此時他的qq彈出了這樣一條消息

"hi,大神在嗎？我有個問題想問，現在我們的代碼裡面有這樣的東西,可是得不到正確的返回結果

1234567functiongetDataByAjax () {return$.ajax(...postParam)}vardata = getDataByAjax()if(data) {console.log(data.info)}

"哦，你這里是非同步調用，不能直接獲得返回值，你要把if語句寫到回調函數中",小飛不假思索的說到，對於一個『專業』的fe來說，這根本不是一個問題。
「可是我希望只是改造getDataByAjax這個方法，讓後面的代碼成立。」
「研究這個沒有意義，非同步是js的精髓，同步的話會阻塞js調用，超級慢的，但是你要一再堅持的話，用async:true就好了」
「不愧是大神，我回去立刻試一試，么么噠」

兩天後，她哭喪著臉登上了qq
「試了一下你的方法，但是根本行不通，哭~~」
「別急，我看看你這個postParam的參數行嗎」

123456{...dataType:'jsonp',async:true...}

"這是一個jsonp請求啊，老掉牙的東西了，，jsonp請求是沒有辦法同步的"
「我知道jsonp請求的原理是通過script標簽實現的，但是，你看，script也是支持同步的呀，你看tags/attscriptasync.asp」
「額，那可能是jquery沒有實現吧，哈哈」
「大神，你能幫我實現一個jsonp的同步調用方式嘛，拜託了(星星眼)」
雖然他有點奇怪jquery為什麼沒有實現，但是既然w3school的標准擺在那裡，碼兩行代碼又沒什麼，

loadJsonpSync = (url) => {varresult;window.callback1 = (data) => (result = data)lethead = window.document.getElementsByTagName('head')[0]letjs = window.document.createElement('script')js.setAttribute('type','text/javascript')js.setAttribute('async','sync')// 這句顯式聲明強調src不是按照非同步方式調用的js.setAttribute('src', url)head.appendChild(js)returnresult}

額，運行起來結果竟然是undefined！w3cshool的文檔竟然也不準，還權威呢，我看也不怎麼著，小飛暗自想到。

「剛才試了一下，w3school文檔上寫的有問題，這個非同步屬性根本就是錯的」
「可是我剛還試過一次這個，我確認是好的呀」

12<script src="loop50000 && put('frist').js"></script><script src="put('second').js"></script>

(有興趣的同學可以實現以下兩個js，並且加上async的標簽進行嘗試。)
「這個，我就搞不清楚了」，小飛訕訕的說到
對方已離線

抽象

關於這個問題，相信不只是小飛，很多人都難以解答。為什麼ajax可以做到同步，但jsonp不行，推廣到nodejs上，為什麼readFile也可以做到同步(readFileSync)，但有的庫卻不行。
（至於script的async選項我們暫時避而不談，是因為現在的知識維度暫時還不夠，但是不要著急，下文中會給出明確的解釋）
現在，讓我們以計算機科學的角度抽象這個問題：

我們是否可以將非同步代碼轉化為同步代碼呢？(ASYNCCALL => SYNCCALL)

既然是抽象問題，那麼我們就可以不從工程角度/性能角度/實現語言等等等方面來看(同步比非同步效率低下),每增加一個維度，復雜程度將以幾何爆炸般增長下去。

首先，我們來明確一點，==在計算機科學領域==同步和非同步的定義

同步（英語：Synchronization），指對在一個系統中所發生的事件（event）之間進行協調，在時間上出現一致性與統一化的現象。在系統中進行同步，也被稱為及時（in time）、同步化的（synchronous、in sync）。--摘自網路
非同步的概念和同步相對。即時間不一致，不統一

明確了這一點，我們可以藉助甘特圖來表示同步和非同步

注意看我們標紅的地方，如果你完成了小測驗1，就會得到和這張圖一致的順序

==同步執行的代碼片段必然在非同步之前。==

所以，無論從理論還是實際出發，我們都不得不承認，在js中，把非同步方法改成同步方法這個命題是水月鏡花

哦對了，最後還需要解釋一下最開始我們埋下的坑， 為什麼jsonp中的async沒有生效，現在解釋起來真的是相當輕松，即document.appendChild的動作是交由dom渲染線程完成的，所謂的async阻塞的是dom的解析，而非js引擎的阻塞。實際上，在async獲取資源後，與js引擎的交互依舊是push taskQueue的動作，也就是我們所說的async call

推薦閱讀： 關於dom解析請大家參考webkit技術內幕第九章資源載入部分

峰迴路轉

相信很多新潮的同學已經開始運用切了async/await語法，在下面的語法中，getAjax1和console之間的具有同步的特性

1234asyncfunction() {vardata = await getAjax1()console.log(data)}

講完了event loop和非同步的本質，我們來重新審視一下async/await。
老天，這段代碼親手推翻了==同步執行的代碼片段必然在非同步之前。== 的黃金定律！
驚不驚喜，意不意外，這在我們的模型里如同三體里的質子一樣的存在。我們重新審視了一遍上面的模型，實在找不到漏洞，找不到任何可以推翻的點，所以真的必須承認，async/await絕對是一個超級神奇的魔法。
到這里來看我們不得不暫時放棄前面的推論，從async/await本身來看這個問題
相信很多人都會說，async/await是CO的語法糖，CO又是generator/promise的語法糖，好的，那我們不妨去掉這層語法糖，來看看這種代碼的本質, 關於CO，讀的人太多了，我實在不好老生常談，可以看看這篇文章，咱們就直接繞過去了,這里給出一個簡易的實現
/5800210.html

functionwrap(wait) {variteriter = wait()const f = () => {const { value } = iter.next()value && value.then(f)}f()}function*wait() {varp = () =>newPromise(resolve => {setTimeout(() => resolve(), 3000)})yieldp()console.log('unlock1')yieldp()console.log('unlock2')console.log('it's sync!!')}

終於，我們發現了問題的關鍵，如果單純的看wait生成器(注意，不是普通的函數)，是不是覺得非常眼熟。這就是我們最開始提出的spinlock偽代碼！！！
這個已經被我們完完全全的否定過了，js不可能存在自旋鎖，事出反常必有妖，是的，yield和*就是表演async/await魔法的妖精。
generator和yield字面上含義。Gennerator叫做生成器，yield這塊ruby，python，js等各種語言界爭議很大，但是大多數人對於『讓權』這個概念是認同的(以前看到過maillist上面的爭論，但是具體的內容已經找不到了)

擴展閱讀---ruby元編程 閉包章節yield(ruby語義下的yield)

所謂讓權，是指cpu在執行時讓出使用權利，操作系統的角度來看就是『掛起』原語，在eventloop的語義下，似乎是暫存起當時正在執行的代碼塊(在我們的eventloop裡面對應runPart)，然後順序的執行下一個程序塊。
我們可以修改eventloop來實現讓權機制

小測驗2 修改eventloop使之支持yield原語

至此，通過修改eventloop模型固然可以解決問題，但是，這並不能被稱之為魔法。

和諧共存的世界

實際上通過babel，我們可以輕松的降級使用yield,（在es5的世界使用讓權的概念！！）
看似不可能的事情，現在，讓我們撿起曾經論證過的
==同步執行的代碼片段必然在非同步之前。== 這個定理，在此基礎上進行進行逆否轉化

==在非同步代碼執行之後的代碼必然不是同步執行的(非同步的)。==

這是一個圈子裡人盡皆知的話，但直到現在他才變得有說服力（我們繞了一個好長的圈子）
現在，讓我們允許使用callback，不使用generator/yield的情況下完成一個wait generator相同的功能！！！

functionwait() {const p = () => ({value:newPromise(resolve => setTimeout(() => resolve(), 3000))})letstate = {next: () => {state.next = programPartreturnp()}}functionprogramPart() {console.log('unlocked1')state.next = programPart2returnp()}functionprogramPart2() {console.log('unlocked2')console.log('it's sync!!')return{value: void 0}}returnstate}

太棒了，我們成功的完成了generator到function的轉化(雖然成本高昂)，同時，這段代碼本身也解釋清楚了generator的本質，高階函數，片段生成器，或者直接叫做函數生成器！這和scip上的翻譯完全一致,同時擁有自己的狀態(有限狀態機)

推薦閱讀 計算機程序的構造和解釋 第一章generator部分
小測驗3 實際上我們提供的解決方式存在缺陷，請從作用域角度談談

其實，在不知不覺中，我們已經重新發明了計算機科學中大名鼎鼎的CPS變換
Continuation-passing_style

最後的最後，容我向大家介紹一下facebook的CPS自動變換工具--regenerator。他在我們的基礎上修正了作用域的缺陷，讓generator在es5的世界裡自然優雅。我們向facebook脫帽致敬！！egenerator

後記

同步非同步 可以說是整個圈子裡面最喜歡談論的問題，但是，談來談去，似乎絕大多數變成了所謂的『約定俗稱』，大家意味追求新技術的同時，卻並不關心新技術是如何在老技術上傳承發展的，知其然而不知其所以然，人雲亦雲的寫著似是而非的js。

==技術，不應該浮躁==

PS: 最大的功勞不是CO，也不是babel。regenerator的出現比babel早幾個月，而且最初的實現是基於esprima/recast的，關於resprima/recast,國內似乎了解的並不多，其實在babel剛剛誕生之際， esprima/esprima-fb/acron 以及recast/jstransfrom/babel-generator幾大族系圍繞著react產生過一場激烈的斗爭，或許將來的某一天，我會再從實現細節上談一談為什麼babel笑到了最後~~~~