自從我離職之後, 我就一直在想我可以做些什麼。其中, 我也有想過我們離 AI 進行 programming 有多遠?? 我提出一個問題。如果你是 PM, 你怎麼讓 programmer 幫你寫程式? 接下來, 如果你是一個下個世代的 programmer, 你怎麼讓 AI 幫你寫程式? 於是我有了一些想法!

能幫你做 coding 的 AI 是長什麼樣?

1. AI 能幫你腦補你的 spec 的不足。

2. AI 會問你一些問題,搞清楚問題的細節。

3. AI 要有 domain knowledge。

4. 同 domain 內的一些習慣類似， AI 能透過 domain knowledge 補足你沒說的部分。

於是, 你得到一個特定領域的機器人, 可以幫你寫 code。你只要需要大致描述你的需求，機器人可以過去的經驗/實例為基礎，幫你完備你的 spec (你的輸入和輸出該長什麼樣)。這個完備的 spec, 就是可執行的程式。

AI 怎麼學寫程式? 那你怎麼學會寫程式的?

1. 最基本的 hello world 和加減乘除。

2. 簡單的 spec + 解答 example.

3. step by step 對應 spec 和解答之間的關聯.

4. 練習寫一樣的 code.

5. 題目變化,練習.

6. 一直到內化。

你怎麼寫程式?

1. 看著 spec

2. 寫個簡單的 function 有 input 和 output。

3. 修改、補充中間部分的程式。

4. 測試 (腦中或實際執行)。

5. 對照 spec

6. 回到 3. 直到完成

總結是, 我認為需要一個較易 parse 和使用的 spec 語言(而不是自然語言。專業的 PM 也不完全用一般人使用的語言定 spec。)。AI 能幫我們補充 spec，你提到一個條件，AI 能聯想到其它該有的條件。例如你提到使用者帳號，就會自動聯想到要登入，要有 password 和 ID 之類的。透過 AI 和人類之間的來回修改，完成一個完整的系統。過程就和 PM + 人類 programmer 的運作差不多。

基本上, 就是輔助真人 programmer，自動完成一些事。 yinwang 以乎把 AI coding 這件事想的太神奇, 像神奇海螺一樣。 我比較務實一些。

突然同情起寫 Java 的 programmer, 一個 data class 就可以讓你們 high 起來了 XD

Linked list 的時間是隨距離兩端的長度而線性成長。而 array 則是隨和尾端的距離線性成長。兩者都線性時，快慢的差別在 coefficient。list 的 coefficient 是讀pointer 的 cost ，array 則是 copy 的 cost。讀pointer 的cost 是固定的，但 copy 卻會隨資料而變。

但，也可在 array 裡放pointet,讓 copy cost 最小化。

but but，一般會把 search 和 insert 分開討論。這篇文章實際上是 search+insert 的結果。先 search/index 到特定 element，然後insert在前面。實際使用 linked list 時，都是 push head or tail,或用其他方法快速找到插入的位置。如 cache or hash table...

Yinwang 似乎很適合 brave 的 donate 方案

沒考慮資料大小。array 的問題在 memory copy.如果考慮每個 element 是 128 bytes或更大，情況就不同。

ARM 早就有這樣的 solution，but...... 一些 overhead 加在一起, 視狀況而定(task size), 不一定比較好。

另外, mozilla 的 webrender Link1 算是相關的東西

心有戚戚焉!

大概從 5 年前，我開始大量使用 OTV，從當時寫的一篇文章開始 Link1 。在大量使用 OTV，並取適當變數名之後，即使註解寫的不多，也不會造成閱讀的困難。當然，是否容易閱讀可能取決於個人。但後來我想清一件事，我好像沒義務寫到每個人都讀的懂，但至少自己在半年之後還能讀的懂，這樣就夠了。

OTV 的問題在於有很多人誤以為這樣會降低執行效率。對某些語言也許會，例如 Python，這類語言因為是在 runtime 編譯，因此無法做太多 optimization。但對於 C/C++/Java 這類語言，如果會降低效能，那就是 compiler 的問題了。不如等到實際 profiling 之後，再針對 bottleneck 做局部改善。(前幾天 ptt 好像有人在抱怨主管時，也討論到類以問題)

顯然, 除了 Java 和 Ruby 之外，他沒寫過任何其它高階語言 XD

3 spaces 也太神奇了

怕浪費就不要加 space XD

實情是，不再把 resource 孤注一擲於「手機」，而是同時嘗試多種的可能性....1

如果政府能提供 service/API，讓外國公司能在交易過程透過該服務完成營業稅的繳納，應該有不少公司願意繳納吧! (況且台灣的營業稅相對的低) 麻煩的是營業所得稅，政府很難實際做查察核。

「開放軟體是一種文化運動」 「把 Open Source 誤以為就是把程式碼公開到網路上，供人免費下載，這就是台灣硬體業一直以來的誤解。」 「筆者相信，三星完全了解什麼是 Open source 了。因為他做得很好，現在，Linux 3.0 核心，裡頭有大量的三星程式碼。」 我已經搞不懂他在說什麼了。

第五點還蠻有趣的。但一說出特定的技能，就是引戰!

朋友 A 用了 whoscall, 而我也用了 whoscall。A call 我時, A 告訴 whoscall 打電話給我的號碼。我開始 ring 時，又告訴 whoscall 我收到 A 的電話號碼。打完收工...

讓我想到一件事，當我說中文、寫英文時，有必要學數學嗎? 不一定，但你的主題是什麼? 程式"語言"應該也是一樣的道理。但，數學能訓練你用更精確和抽象的方式思考，能讓你中文說的更精確，英文寫的更切題。值不值得，看個人。

搞不懂這有什麼不爽的?

這要看個性，不是每人都適合。我自知甚明，C 跳 D (應該是 B 跳 C)的事我已据絕多次。小心！ 別拿薪資衡量自己或技術人的成就。只要公司重視技術，一直留在技術 track 也不錯。但要發展出整合他人能力，讓自己的技能加成別人。畢竟時間有限，不可能什麼都自己來。

另一方面，這種情況出來開公司吧

求老闆多給福利，少給薪資。

到 amazon 查一下， 「Drawing on the Right side of the Brian」出過好幾版。最早有看到 1979 年出的 XD

何不送台灣的老闆去米國堅持看看。這是一個 SM 的過程。如果寧願 OO，就別怪別人 XX。

在台灣普遍的想法是這樣，因此什麼都看上司怎麼說，於是什麼也不想堅持。這也使的台灣工程師相對的被動，整個軟體產業自然起不來。根據幾年來的觀察，米國的工程師相對比較主動，認為該做的事就會去做(當然工程師百百款，至少在敝公司大部分的情況是這樣)，除非老闆主動阻止他。相對於台灣的工程師，預設是什麼事都不要做，除非老闆說 GO~ 太過自動有時還會遭白眼。一來一往，結果如何可想而知。

也不是說米國人全都好，台灣人比較好指揮、有彈性(被指揮的彈性)，不會有一堆意見或光說不練。說難聽一點，是當奴隸的好材料。

「千萬別...」太言過其實，「別輕易...」比較中肯。隨著時代的演進，軟體實作的觀念就如同自然語言一樣，會演進的。就像現在人去理解幾千前年，孔子所說話，孟子所寫的文章一樣，難以理解。因此，我們用注釋來解決。軟體也是一樣，但有時侯重寫一次會更好。甚至固定頻率的部分重寫，就像房子需要整修一樣。最好是之前寫過、改過，對這部分程式很了解的人進行重寫。以更精確而易懂的方式(現代人)重新描述，把那些討人厭的補丁給抹平、抹掉。否則，經過幾手之後，現在流行的表達方式退潮之後，後來者就像看到甲骨文一般。