Re: [討論] 請大家聊聊 JavaScript的缺陷
是說應該要定義什麼是好什麼是爛,
我是覺得啦, 能解決問題叫好, 不能解決問題叫爛.
但這就有一個操作空間, 就個人對語言的掌握程度/能力程度,
會影響到一個人對語言的判斷.
像是有人對直譯器(interpreter) 的理解不夠,
對 contract based 的程式邏輯掌握度不夠.
所以騎個腳踏車還需要裝兩個輪子(TS/TSX)在旁邊輔助, 才能正常寫程式.
這是能力的問題.
但雖然裝輔助輪慢了點, 久了總是會到終點了, 歡喜甘願就好.
當然, 自古以來許多人能力不好就怪環境不好,
這自然是可以理解的, 但這種情況要互相討論, 可能就有點高處不勝寒了.
動態語言跟強型別語言本來從開發工作,
開發方法, 工作做法都會不一樣,
拿十字鍬去伐木, 砍不斷樹是自然的.
所謂的缺點跟優點是相對於要解決的問題的,
就以控制 dom event, render html/css , 發起請求等來說, 他已經夠好了.
該有的語法特色都有, 喜歡 class 的也終於在 ES6 邁向皆大歡喜.
主流的 async 處理方針, async/await 也都在ES7 都跟上了.
如果我們今天說的是十年前, CORS 還沒發展好, fetch 不完整,
display 還沒好好的實裝, float 還很難用沒有 flexbox 的年代.
要說的話就是要引用的基礎類別有點多, 計算量有點大.
當年還要面對 js interface 不統一的問題 (該死的 document.all ),
而且當時還要引入 jQuery 才有 selector.
但到這個年代,早期最被詬病的那些問題早就都有解法,
要討論優點跟缺點, 要同時把要解決問題拉出來談, 不然這都是瞎談.
不然直接說一句 js 要移殖 c++ 程式很難寫, 大家就散會就好.
(啊 其實也有 wasm 可以用啦)
每個語言都有他的樣態跟生態, 跨語言比較的盲點就在,
你會其中一個, 但你不會另一個啊.
你不懂得理解兩個不同的語言的差異之處啊.
程式只是工具, 人才是決定 code 是不是垃圾的載體.
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
推
其實我覺得選擇多本來是好事，但就會出現被人為限制的問題
比如 new 的對象，有傳統 function this prototype 寫法
也有 ES6 後為了迎合物件導向而給的 class
但往往一堆專案為了統一也法而限制開發人員要用何種寫法
然後選擇舊寫法的人常被新寫法的人當雷包、老古板在看
基本上看 code 寫的乾不乾淨，如果寫的乾淨清楚，用啥都行。 寫不乾淨就別跟我談什麼套件語法， 好好練基本功吧。 組織函式，組織功能，訂好介面是所有語言必要的項目。 syntax 是用來幫助這些事情的，不是拿來當藉口的。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 01:16:38當然不是用啥都行，稍有規模的公司都有coding style吧
為了style的一致性用舊語法寫應該是滿常見的
這其實還是回到團隊共識問題，正常來說，架構師會選擇對當時最適合的結構。 不一定是舊的也不一定是新的，舊 code 也能翻新，只是需要轉換過程。
我個人是覺得TypeScript目的是增加多人協作時的可維護性
你自幹的時候，當然你的大腦掌握了全局，但別人在讀你的
程式碼時可不見得是這樣
要開發快速當然不要去搞什麼TS，但人多的時候欲速則不達
多人協作強調的是工作方法論跟模組切分的能力，用 TS 並不意味著你可以更好的做到這些事情。
推寫不好就怪工具
這篇可以被戰，就我所知人才不會去寫前端xd
聰明人不會浪費時間處理特例和例外。
當年寫jq的都去寫angular/react/vue了，哪年ARV三大會不
被別的技架（如webassembly）取代都不知道，也只能說，
長江後浪推前浪，一代新物換舊物，想吃工程這行飯，就得
持續學習，讓自己的技能與知識與時俱進才行。
sorry，打錯，是技術框架。:P
js是要編譯的喔
interpreter 那段是要討論 js 是有機會從 runtime 再塞東西進來的，在一些情境下，這是個要留意的特點。
推
從單兵作戰角度看也許是這樣，但不要忘記軟體工程討論的
不只是單兵作戰，避免 antipattern 也應該考慮在語言能
力之中；講 js 有他的任務有歷史包袱無可厚非但我不覺得
相比其他語言精通起來學習成本高不是一個缺陷
again ，這是相對於目標的。如果我們今天談的是 ui handling ，放眼望去在所有語言(如 windows form or android)，要處理 dsp 跟 requesting，同時不 block UI thread ，這些都是複雜的。 如果單談可以快速寫個 for 或 資料處理，純語言面特性。 我還真沒看過有人嫌 js 難上手的，畢竟不用裝複雜的環境，語法內建就靈活，array 就能當 list 用還不需要定義長度。 object 內建就是 map。 js 談的就是好寫，被靠北的多是 async 的複雜度跟 error handling ， async 是相對於 ui 的需求， error handling 其實不是做不到，該有的語法都有， 但我覺得本質上就是語法特性太好寫，大家根本懶得寫 error handling 。 所以要說 js 的學習成本高， 很多人都會說一些特別比較不好懂。 但說真的，寫這麼久 js ， 真的要用到那些不好懂的東西還真的少。 所以，好歹定義一個情境他解題起來，比其他語言差吧。 我剛有想到一個啦，他的 reduce api 開爛了，在拿來對 collection 拿來做加總之類操作時，實在是很難寫。 不過可以用別的簡單方法替代，就是有點鳥。 寫久了對他哪邊好哪邊不好，自然會很清楚。 另外只要你倚賴語言，所有語言都有 antipattern，要避免 antipattern 靠的是對「情境」的瞭解。 也是我這篇在強調的，你不能把語言跟工具脫離於情境。 ex. Lua 我寫過覺得不是個好寫的語言，但他在 game 曾經有過輝煌的歲月。 有些 dsl 被創造出來是有其目的跟意義的，這不是任務跟歷史價值，而是他的需求。 也不用拿著一把刀解決所有的問題，要用適當的工具解決適當的問題。
※ 編輯: TonyQ (114.136.69.202 臺灣), 11/16/2020 09:04:29 ※ 編輯: TonyQ (114.136.69.202 臺灣), 11/16/2020 09:05:51 ※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 09:16:57 ※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 09:22:04我覺得ts 方便的點在於我們看到變數時我們知道他的資
料結構長怎樣，不然只能爬code然後console 看他吐出
什麼樣
問題是你沒辦法讓整個世界照 ts 的規矩走, 而且還有 any 的存在, 這只是個不會到達的理想國. 而且即使他宣稱是這個結構, 實務上他還是可以傳入不是這個結構的程式給你.
天氣預報也會報錯啊，所以你也反對天氣預報嗎？「你不能
讓世界的天氣照著天氣預報走」XDDXXD
所以你每天早上都看天氣預報決定自己要做什麼反應嗎? 選用基礎環境工具意味著你每件事情都不得不參考他, 你幹嘛花這麼大的代價綁住自己只為了一個看不見的餅. 這就跟當初 java 體系一堆人跑去搞 scala/groovy, 因為不喜歡 java的一些特性, 有些人會寫的很爽, 我不反對, 事實上也是. 但他們要紅就得自己去感染世界, 而不是宣稱在原本世界的人都是蠢人吧. 誰蠢都還有得討論咧. 拿出情境, 拿出案例, 講清楚哪個案例他更有優勢, 如果你覺得自己可以完全不學 js, 只在 ts 世界度過一輩子, 那ts 肯定很適合你. 但如果你得回到 js 世界, 恭喜你, 你學習成本一定大於只學 js 的人.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:10:20你平常看不懂別人在做什麼的時候都不會問“你在做什麼”
嗎？別人給你的回答就像是程式語言的 type，雖然因為語
言精細度的關係，別人可能沒辦法很清楚的解釋他在做什麼
，但是它可以給你一個 idea
而在程式裡，type 和 value 的關係比現實生活中用嘴巴講
的要強多了
雖然大部分語言都沒有一個像 Idris, Agda 這樣完備的 typ
e system，來保證所有的 type 都是正確的（甚至可以當作
數學、邏輯命題驗證系統來用，也不可能會出現你講的偷塞
any 的事情），但是我也不認為大部分的人都有能力用像 I
dris Agda 那樣精確的語言來寫程式，ts 對於 js 已經是一
個 improvement，而且也是一個符合大部分人的能力的 impr
ovement（不會太難），不認為有什麼好 criticize 的
覺得還是類比錯誤，js到ts幾乎是無痛學習吧
就我學過 Java,JS,vbscript,jscript, ruby, python, php 等語言的經驗, js 到 ts 我不覺得是無痛學習喔, 這種看起來很像, 但有專屬語法的東西學起來反而特別煩. 設定環境也是痛, 設定 IDE 也是痛, 找更相容的套見也是痛, 但你要覺得無痛我沒意見, 只是我對無痛提反對一票.
對於有其他語言經驗的人來說，學習成本低到不行
扣掉一些進階特性ts一樣是你認識的那個js而已
問題還是我幹嘛學 ts ? (btw 其實我會寫 ts 啦, 幹嘛假設我不會? 我只是懶得寫 ts. 理由同原文.)
推 寫不好就怪工具
看了你的回覆，提醒你，理論電腦科學的根基就是 type 和
calculus，任何東西只要能夠在電腦中出現，一定能夠有 i
ntroduction 和 elimination rule，也一定可以 reduce
成一個 NF，並且它的根本就是離散的而非連續的，所以在
電腦的世界裡根本就無法存在像你講的“不能用 type 描述
”或“只能 ill typed 描述”的東西，問題只是你的 type
system 願不願意把自己做得這麼精確而已，因為會讓很多
沒有數理邏輯底子的人不會用，如果你想要，你可以完全只
寫 well typed 的程式（就像你講的不要回到 js），完全沒
有做不到的事情，問題是我不認為大部分的人有能力做到這
樣，而 ts 正是這樣 compromise 下的產物
拆開來每個字都看得懂, 合起來怎麼看都覺得在浪費我時間.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:40:58Java,JS,vbscript,jscript, ruby, python, php...
好吧，我不該在這裡和你認真的，就繼續你的 OO 治理世界
吧
如果你真的知道 type theory 和任何一個與 lambda calcul
us 等價的 calculi 在做什麼，我想你大概就可以合起來也
看懂了，但我想你還是算了
確實沒什麼興趣看你念經.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:50:32如果你沒自信懂這些，那我想你應該也沒有自信可以批評 ty
pe 的用處才對？
這是我想要講的
我是很佩服你這麼有自信說這些話, 但我覺得這讀起來沒證明任何事情. XD 你要講什麼都可以, 這世界不缺人自言自語. 但要講讓別人聽得懂, 那就需要些技巧了.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:54:36我認為這些都是理論電腦科學的基礎中的基礎，不認為這需
要什麼“神奇的技巧來解釋”
但我可以把它說得更清楚一點：
任何 term 都有 I/E rules，而且都能夠 reduce 成 NF，
而且 NF 具有相等性（題外話，甚至不同 NF 也能有等價性
，參考 Homotopy Type Theory），加上電腦不處理連續的
問題
所以，任何可以用電腦解決的問題都可以是 well typed 的
程式，而且不存在可以用電腦解決，但只能 ill typed 的程
式（唯一的例外大概就是 random access array 和 input/o
utput，但相關的解決方案也已經存在很久了）
從以上你之前說的“無法讓整個世界照著 ts 走”就是有問
題的敘述（如果把它理解成“無法把所有程式都寫成 well t
yped 的程式”的話）
雖然看起來很像又把之前講的重複一遍，但這是我能想到最
不佔篇幅又最貼近問題的講法了
這些沒辦法拿來證 ts 是 compromise 的選擇喔. 文不對題在任何作文通常都是零分啦. 另外 無法讓整個世界照著 ts 走, 並不是讓整個世界寫成 well-type 的程式, 而是無法解決使用 ts 的引入成本在此刻仍然很高的問題. 我談的是一直是 cost. 事實上如果把 any 視為是一種 type, well-type 並不困難. 本來 js 世界要達到抽性別共用就是把 object 這一層抽象掉才達成的. 而 any 就是被創造出來相容這件事情的. 但這種繞圈子的說法我覺得不是在討論問題而是在抬槓了.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 15:38:46any 就是 compromise...
type 不是 first class 也是 compromise
不能把 forall 寫在任何地方也是 compromise...
而造成這些 compromise 的原因就是因為要照顧只會寫像 js
這種語言的人
你不能說因為有這些 compromise 所以 ts 也沒比 js 好到
那，甚至進而又反過來說 ts 做的改變是反而是不好的
另外，當你要討論一個語言的缺陷的時候，你不能說因為它
引入的 cost 比較低所以缺陷比較小，我猜這也是為什麼很
多人覺得你的 claim 不能 hold 的原因
有人, 不等於很多人. 反過來, 也有人支持我的 claim. 另外我沒宣稱 ts 是不好的, 我說的是他有他適合的用途, 也有他的問題. cost 低當然是一個優點, cost 高就是一個缺點, 為什麼不能說, 你的邏輯看起來充滿著選擇性呢.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 16:00:03當你在討論語言的時候，缺點/優點不能 imply 缺陷...
舉例：
缺點/優點：效能高/語法容易/工具健全/容易取得...
缺陷：不能表達某個在 System-F 中可以表達的 term/不能
deduce 某個 term 的 type/不能區分某兩個不同的 term..
.
just to be correct，我說的很多人意思是在那些不認同的
人之中的很多人，不是試圖說有多少人不認同
說真的, i don't care what you think.
像是這篇很多人提到的 NaN 之類的問題不是都屬於缺陷的
部分嗎？
例如 NaN 屬於數字，意思就是它無法區分 NaN 和數字之間
的不同
我只是想要說，如果你想討論有/沒有哪些缺陷，你不能只
說引入 cost 低所以缺陷都不存在，我想你也同意這點
沒用到就不算是缺陷. 就跟我們不會說菜刀砍不了樹, 電鋸切不了魚是缺陷一樣. NaN 搭配 isNaN 來說有他的用法, 也可以考慮在 parse 之前先做檢查. NaN 是不是個問題也要看前後文. 我不會說缺陷不存在, 但重點是你想拿他來做什麼. 另外我也沒有想討論有沒有缺陷, 我想討論的是, 在討論這些缺陷之前, 我們要解決的問題跟這些缺陷到底有沒有關係.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 16:34:58前幾樓要不要直接回文啊？這也打太長
不錯哦，問題都在人身上了，這樣也沒啥好討論啦
工具也是有差
你是不是對機器語言瞭解不夠才要裝程式語言當輔助輪
這麼說也沒錯啊，這輔助輪棒的呢。
唸過PL的人 在這邊幫沒念書的人上課 我是覺得白費力氣
你就讓他在他的世界活得好好的, 不是很好 他也不介意
那些複雜的Church-Turning, Curry-Howard 一點意義
我 2006 年就修過 PL 了，但這串到底誰在談 PL 啊，靠北，PL 是這樣談的嗎？ XD
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:09:40 ※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:10:31你真的修過PL會不知道Curry–Howard–Lambek correspons.
帶來的意義? type = logic = catgory?
說啥type跟calc分開 你好像不知道他們就是等價的
啊我沒講的東西，你要假設我不會我是沒意見，PL 一個三學分的課我確實只修了些該學的。 但你可以不要罵錯我沒講的東西嗎？ 我可從來沒否定型別的價值，我只是在意成本。XDDDD
抱歉.. 上面那一句不是你講的 你連那個概念都還沒有
聽起來像是「這爛工具用久了還是有好用的地方啦」 古有為
賦新詞強說愁 今有為寫程式強說讚？笑死
不可否認JS爛是有背景因素啦 就是各家大廠對前端各懷鬼胎
惡性競爭下來的權宜之計 權久了莫名奇妙就做大了 但原因
是一回事 爛不爛又是另一回事
倒也沒有要說 js 沒有爛的部分，看大老那本 js the good part 的人都不會反對js 有爛的部分。為了 js 強說讚的大老很多，我們大腿抱緊包好。 只是 ts 是不是解決 js 爛的方法，抱著問號而已。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:38:03想不到tonyQ大大還蠻懂css,沒flexbox的時代切版很累
推情境和要解決的問題是關鍵.
3
npm 的問題，我試著安裝了一下 因為說是去年7月遇到的，所以我使用 2020/06/30 發佈的 node 12.18.2 搭配 npm 6.14.5 在只有裝 archiver-utils 的情況下，他很平，可能比我婆軟體還平 archiver-utils 底下沒有 node_modules ， readable-stream 底下也沒有![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://i.imgur.com/LMWcPMfb.png "Re: [討論] 請大家聊聊 JavaScript的缺陷")
34
在開始之前，先說個笑話 ※ 引述《keev (a)》之銘言： : 我會試著反駁 互相交流 然而下面這串推文直接被無視 : 推 vi000246: 還要學打包工具 好麻煩 11/03 00:222
聽到你說 C# 一樣有 js 四捨五入的問題，我驚呆了，你肯定沒有嘗試過，沒關係，我幫 你試過了！ 真不知道你的自信哪裡來的 我承認浮點數是個棘手的問題，但是有的語言會謹慎處理，有的語言就是隨便處理，事實![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://i.imgur.com/2vMuAkJb.jpg "Re: [討論] 請大家聊聊 JavaScript的缺陷")
X
其實我覺得戰場大家自己拉開的亂七八糟， 我也不過就是逐一回覆， autocomplete 我也說了根本不是語言的重點， 是其他人重視，這樣可以說你們在討論缺陷， 我在討論 autocomplete 我也覺得是有趣。3
你完全搞不清楚狀況喔。 dotnet 的 Math.Round() 預設是 四捨六入（五遇到前面為基數才進位）的設計，也就是 銀行家捨入法，也就是第三個參數為 ToEven 模式，我指定 AwayFromZero 是因為想走四 捨五入。 拔掉這個，走四捨六入也行，dotnet 就是照本宣科來，根本沒有你說的浮點數精確錯誤![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://i.imgur.com/u1WLSnhb.jpg "Re: [討論] 請大家聊聊 JavaScript的缺陷")
3
JavaScript 的概數運算確實沒有實作 IEEE 754 的標準， IEEE 754 中，Nearest value rounding 的方法有兩種： 1. Banker's rounding - 取到最接近的「偶數」 2. 取到最遠離 0 的數（效率佳） 但搞不清楚狀況的是對該語言不熟就隨便拿一個 function 來做概數的人，1
其實我上一篇已經有提到 Rounding mode 的選擇是關鍵了了, 然後那個不叫四捨六入...... 另外 tofixed 又誰跟你說他是四捨五入了.... 他是用浮點數的定位表示法（fixed-point notation） 計算的, 詳細實作有點囉嗦, 自己翻論文.![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://i.imgur.com/JddrvWWb.jpg "Re: [討論] 請大家聊聊 JavaScript的缺陷")
8
不太認同, 如果今天的task是計算1加到10000 從紙上開始 1 + 2 + 3...一直算到10000可以解決問題 用等差數列的公式也可以解決問題 寫段code直接寫個function讓function可以支援不同的min, max也同樣能解決問題 這些方法都能解決問題？難道他們都是好方法嗎？17
我想 auto complete 可以算是開發工具的部分 （我猜任何語言理論上都可以有 auto complete，所以和語言本身無關） 而且在這篇沒看到原原 Po 提到，暫不討論 : 而且我還是那句話, 你今天碰到 ts 世界以外的模組, : 你是要怎麼 autocomplete 跟省時間.2
project scan 就是需要時間, 你檔案數多到一個程度, 就是慢. webpack 有那麼多 tooltip 再加速效能, 難道是假的. 說真的, 這段話反過來說也是可以還給你的. 連自己的 type 跟 convention 都掌握不好的, 是有什麼好靠邀的. 另外 js 的 autocomplete,
18
Re: [請益] 轉職仔的語言選擇語言不是重點，要看接在什麼主題後面 學寫程式，語言不是重點(O) 轉職，語言不是重點(O) 領更高的薪水，語言不是重點(O) 但，目的是了解程式，語言就是重點了16
Re: [討論] 108課綱，我們真的要讓孩子這樣學程式？身為一個 SDE.. 我來說說我的想法 先說結論 TL;DR 我覺得這個的學法沒有什麼不好.. 回答你的問題 - 程式設計師的工作和生活具體該怎麼形容？ 解釋給國小國中學生的話 我每天在做的事情就是 跟夥伴們一起想辦法解決g8靠杯複雜的問題![Re: [討論] 108課綱，我們真的要讓孩子這樣學程式？](https://i.imgur.com/HMJeOrob.png "Re: [討論] 108課綱，我們真的要讓孩子這樣學程式？")
11
Re: [討論] 請大家聊聊 JavaScript的缺陷推 laputaflutin: 同意樓上，不過看到這次美國大選很多新聞網都拿 11/04 21:02 → laputaflutin: svelte來寫，感覺蠻有趣的，應該會拿來試試看 11/04 21:03 禁不住好奇心的我終究還是去看一下 Svelte， 原來它是個反 React、反 Vue、反前端在瀏覽器動態解析樣板的框架兼開發工具。 它讓你在開發時期能夠先以 js 程式碼定義資料，![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://drek4537l1klr.cloudfront.net/volkmann/Figures/cover.jpg "Re: [討論] 請大家聊聊 JavaScript的缺陷")
13
Re: [請益] 程式怎麼選擇與入門?在這個年代， C 語言應該不是最適合初學者第一個學習的程式語言。 對初學者來說，一開始能夠培養語感、學會用程式解決問題的能力才是最重要的。 先試著習慣寫程式，並習慣用程式邏輯言思考與表達，同時看能否嘗試解決一些自己在意的問題， 試著從實作中獲得成就感並了解是否適合這種人格特質。 如果在這個情況下還想進一步徹底瞭解電腦 (機器/Machine) 底層運作的機制的話，C 語言就可以是一個很好的開始。12
Re: [討論] 請大家聊聊 JavaScript的缺陷我覺得Javascript最大的問題是它是prototype語言，大家不習慣，尤其從class based語言來的人。 像我上禮拜在看web component的時候，看不懂一段程式。 if (this.hasOwnProperty(prop)) {![Re: [討論] 請大家聊聊 JavaScript的缺陷](https://web-dev.imgix.net/image/FNkVSAX8UDTTQWQkKftSgGe9clO2/uZ3hQS2EPrA9csOgkoXI.png?auto=format&fit=max&w=1200&fm=auto "Re: [討論] 請大家聊聊 JavaScript的缺陷")
9
Re: [討論] 請大家聊聊靜態語言的缺點問靜態和動態有缺點。怎麼不想想你公司是怎樣型態 如果你們公司成員 新舊和程度不一樣 就需要靜態語言處理程式，強制要成員遵守並規範。只要規範好，一般猴子也會按照著寫程 式。 動態語言吃的是開發人員素質，要自律，要對程式碼負責。1
Re: [討論] 請大家聊聊 JavaScript的缺陷小弟介紹自己語言的圖譜。 1.寫 Java 三年（沒在寫了）。 2.被公司逼寫 Nodejs 寫了五年（現在還在寫）轉換成本半年。 3.被公司逼 TS 四年（現在還在寫）轉換成本一個月。 4.被公司逼 GO 兩年（現在還在寫）轉換成本兩周。1
Re: [問卦] 老師說程式語言只是工具，有掛？注意這篇文章超級長，可直接左轉。 以下強者我朋友： 各位好，我是資工肥。 是這樣子的，我看到有位資工阿肥在這裡發了一個問卦，問 老師說程式語言只是工具，有沒有掛。他說他有兩位教授，