Thinker 積分 3 編輯於

自從我離職之後, 我就一直在想我可以做些什麼。其中, 我也有想過我們離 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 這件事想的太神奇, 像神奇海螺一樣。 我比較務實一些。

Thinker 積分 2

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

Thinker 積分 2

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...

Thinker 積分 1

Yinwang 似乎很適合 brave 的 donate 方案

Thinker 積分 1 編輯於

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

Thinker 積分 2 編輯於

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

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

Thinker 積分 2 編輯於

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

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

Thinker 積分 1

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

Thinker 積分 2

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

Thinker 積分 3

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

Thinker 積分 0 編輯於

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

Thinker 積分 1

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

Thinker 積分 2

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

Thinker 積分 2 編輯於

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

Thinker 積分 1

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

Thinker 積分 1 編輯於

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

Thinker 積分 1 編輯於

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

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

Thinker 積分 6 編輯於

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