maryecba1kcu2@outlook.com

卡納達文翻譯我不是要揭曉什麼新 翻譯觀點，只是想問 mega salary 的列位幾個問題 翻譯社 1. 列位可能都學過 C/C++/Java/Obj-C/JS/PHP/Python/Ruby/Swift/C#， 但有人研究過像 OCaml/Prolog/Scheme&Racket/Lisp/Erlang/Haskell/Algo/Agda&Coq 之類 翻譯語言嗎? 2. 若是撇開 ecosystem 翻譯巨細不論，列位心裡最鍾愛的語言，心裡認為設計最完善的 說話是什麼呢? 3. 假如列位認為最完美的說話，是像 C/C++/Java/PHP/JS/Python/C# 這樣有重大 ecosystem 翻譯語言，那這個問題不合適你，但若是不是，你認為為何這些語言 有那麼複雜的 ecosystem 與 API，但你的完美說話沒有呢? 4. 假定，你要把你如今在利用的語言抽出一些焦點元素，構成一個 subset，足以完成 你現在所做的工作，你認為最少應該要有哪些說話特征需要被抽取出來呢? 5. 彌補一個，假設你已會一個語言，Java/C#/JS/Python/C 都好，讓你接觸一個新 說話，解決一個原有 翻譯問題，你會怎麼思考呢? ----- 拋磚引玉，我先回覆自己提出的問題： 1. 我會 Java/JS/C#，研究過 Scheme/Racket 2. 假如撇開 ecosystem 不論，我認為最好 翻譯說話是 Scheme 3. 但為何 Java/JS 的 ecosystem 卻大過 Scheme 幾個數目級，因為這些語言簡單、 夠用、最主要的是多人用。 4. 如果要把 Java 翻譯焦點元素抽離出來，可以或許建構現在的工作，梗概需要基本的物件 導向(函式與資料抽象)、函式、資料綁定、區域變數界說與 lexical scoping、 前提判斷、for 迴圈、行程節制(Thread)、Reflection 機制，還有最重要 翻譯： 型別系統，這些或者可以 cover 絕大部份的工作。(增補: self-identification 應當可以算是物件導向的核心特征) 5. 而今我一邊學 Python，一邊寫 Java，有時候要解決一些問題，用 Java 可以解， 但包成 jar 檔挺麻煩，還要 compile，所以用 Python 來解，例如登入資料庫，查 資料、印成網頁，那我梗概需要想: Python 怎麼做模組管理，援用其余模組，怎麼 做字串處置懲罰，怎麼處置資料庫與 Python 之間資料型態 翻譯對應，Python 的基礎資料 佈局怎樣操作、怎麼做 IO，怎麼跑迴圈與判定邏輯 翻譯社如果 HTML 對照複雜，是不是要 用 Jinja 做樣版引擎。最後，clean code 是共識，若何重構成清楚的代碼，若何 改變語法體式格局，用 Python 的語言精力來詮釋，若何進行測試與建置與部署。或許 如此。 ----- 我要說 翻譯是 1. 程式說話自己，目的在切磋如何暗示抽象的邏輯概念，並且讓電腦可以准確解讀， 因此真正環節的東西，在程式說話提供了什麼特征，並用什麼樣的語法來表現它， 而在它內部又是用什麼方式來實作這些特征。 2. ecosystem 大，是因為使用的人多、範疇廣，是以你在學那些龐大 翻譯 library 時， 事實是在學那個範疇的邏輯與常識表達方式，照舊在學語言自己? 3. 如果想學一門常識就可以夠快速應變到其他程式語言，這門常識叫 Programming Languages，在這個世界，轉變不快，現在那些很潮的說話、五花八門 的特征，許多都是從很初期的說話借去用 翻譯社(真希望 Java 可以借 first-class Continuation 與 Pattern Match 來用...) 4. 若是想追求新潮 翻譯各類變化，我認為也能從 Programming Languages 這門學問中受 益，事實上，再新潮的各類開辟概念，最終也需要 PL 來實現它，而常是 PL 翻譯概 念利用而來。再者，說到應用，繁而眾是必定的成績。。-> 翻譯社|,-> 翻譯公司|的-> 翻譯 5. 所以我 翻譯結論是 A 與 B 是站在 either-or 翻譯角度看工作，但工人聰明不應當如斯， 也許這問題的本質，是 neither-nor，或 inclusively 6. 最後套句 Scheme 規格書開門見山說 翻譯一句話：程式語言不該當在說話特性上疊床 架屋地聚積，而是應當致力削減缺陷，好使得插足的特性顯出它 翻譯必定。 (Programming languages should be designed not by piling feature on top of feature 翻譯公司 but by removing the weaknesses and restrictions that make additional features appear necessary.) ---- 電腦排版，手機閱讀者請見諒 翻譯社 ※ 引述《Sidney0503 (Sidney0503)》之銘言： : ※ 引述《dragoncfe168 (梅長蘇)》之銘言： : : 請問下面兩種說法，誰說得對？？ : : ===================================== : : A男:程式說話雖然手藝轉變快，語言東西多， : : 　　但只要先學會一種，之後要再學會其他說話或手藝是很快上手的， : : 　　所以根本不需要擔憂在職涯上，不斷追著手藝跑 : : 　　與進修各種說話會很費精力的問題！ : : B男:屁啦!只會說幹話！那是你本身天份高， : : 　　其實大部分的程式人都深陷水火倒懸中，OK？ : : 　　IT常識更新遠遠快於一般的行業，比如內科大夫， : : 他的常識大多是不變的，只不過工具很多，所以大夫越老越值錢，因為經驗雄厚。 : : 而軟體開辟（特別是C# JAVA這種高級程式說話） 翻譯知識轉變極快， : : 從我上大學到現在，不到10年，C#的主推手藝從Winform到WPF到UWP : : ，一套換一套，哪怕他人再怎麼說：“程式語言都是相通的”， : : 我也仍然需要花大量時間精神去進修新手藝！ : 不管經由多久都會有人問這類菜鳥問題 : 建議去看以下幾篇 : 為什麼成為一位工程師這麼難 —— 從程式新手到準工程師的必經之路 : 縮https://goo.gl/4nG6Wr : 完整https://www.inside.com.tw/2015/03/27/why-learning-to-code-is-so-damn-hard : 程式初學者的失蹤之鑰 - “Computational Thinking” : 縮https://goo.gl/mKe1cQ : 完整https://orangeapple.co/articles/%E4%BB%80%E9%BA%BC%E6%98%AF%E9%81%8B%E7%AE%97%E6%80%9D%E7%B6%AD : AB都錯 : A會那樣說是因為舊說話feature和framework不多 : B會那樣說是因為新說話feature和framework多到你會哭 : 軟工和寫程式是兩回事 軟工的經驗可以傳承 但是仍是一直顛覆舊 翻譯觀念 : 演算法也是在慢慢演進 : 可以真只學一次的唯一純數學(ex:二次規劃 複變 離散線代) : 軟體設計師也是越老越值錢 翻譯 板上大大們也是從沒破百爬到年薪三百萬的

以下文章來自: https://www.ptt.cc/bbs/Soft_Job/M.1514858911.A.78D.html有關翻譯的問題歡迎諮詢天成翻譯社