joannm5l3688@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有關翻譯的問題歡迎諮詢華頓翻譯社