在 win 下，批次檔是 *.bat 在 unix like 下（含 mac)，變化就多了 從前在 win 下如果我有複雜的需求，會寫一個 C++ 專案，編成 exe 執行 因為專案管理需求，自己寫些執行檔做管理，而不是賣給客戶用的 也許 dos shell command 做得到，但 dos shell 實在也沒很熟 如果寫大了，debug 更是地獄；無法步進執行，要一直 log unix like 下，perl 常看人用，但 perl 我也不熟 工具當然以自己熟練的為主（不長進 ~^_^~) 碰到 java 倒很方便，從 C++ 帶來的基礎算好轉移 而且在 eclipse 下可以跨 win & unix like,也能步進執行 所以我才積極希望能用命令列執行；也成功了 不過好像沒看人這麼用，perl 仍是主流 而且 C 號稱可攜性佳，我只是沒學一下 g++ compiler 也許無痛轉移可以比 java 還容易？ 但沒學之下，我就無法想像 C++ 怎麼在 unix 下步進執行 （抱歉，也許我該自己找答案；但 java 在命令列下執行我已花了好幾天， 現在也凌晨了） 我其實真的是把 java 當 C++ 在寫自己的工具程式 很方便的解決了一些問題 而且因為有 gc,這太方便，我也回不去了 ~^_^~ (C也許可以更低階，更有效率；但工具程式只求正確，速度並不很要求） -- 睡前不該想你 會讓你走入夢裏 夢裏輕聲笑語 詢問是否還要繼續 那兩年前未竟的嬉戲 我卻不敢當真,怕又被你放棄 樓下奔來鐵騎 電影中才有的場景 蜂火,警笛,還有搜索令 這一幕結束在變調裏 你又再一次從我懷裏被奪去 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.251.197.63 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1411591353.A.3D6.html 聽起來反而很神奇，像程式產生器的做法 但自我參考變化的程式，debug 是地獄啊.. C like 我學過 php,它也可以在命令列執行 不過問題在 debug 腳本 （嗯，我總是用詞不精確；你這詞才對，幸好大家看懂我的意思） 用腳本語言可以改一行馬上跑，不用 build 但它沒一個像 eclipse 的環境讓我監看變數，寫 log 很辛苦 一開始都會喜歡它不用 build 的便利 但愈寫愈大後就受不了 尤其是大型專案的 make file 竟然還是 perl 寫的 真是受不了 這個也很出名 －－－－－ 同事說'你熟什麼就用什麼'，很寬容 （反正他又不看我程式，他只要我做出來） 我想我的關鍵在'我無法靠 log 去 debug 太大的程式' 依據我的個性，當然腳本語言就都擺一邊了 （還是哪個 script 又可以步進，又是 c like?) 我要做的也不全是腳本啦 有時也會有中介於 compiler 階段的程式或資料要動態產生 反正前端資料同事給，我又要產生什麼給同事 比較通俗的說法好像叫 parser 所以都有一堆開檔讀寫， scan, printf 等等 因此以前才用 c 寫 exe 進來操作 ※ 編輯: HuangJC (60.251.197.63), 09/25/2014 12:03:29 有一次的任務是購買來的 source code （連 compiler 整套一起買） 程式超大，我們要替它做多語系，patch 一下貼牌變我們的產品 :P 程式大到沒空看懂是一回事 但字串搜尋一下，大概就知道怎麼代換人家的程式了 翻譯社當然不想看程式，他們會給的像這樣 Eng:Love Cht:愛 Jap:(阿宅只懂亞美蝶，但這好像不是愛 XD） 總之啦，在進入購買來的 compile 前端之前 我要再 patch 一個 precomiler; 也許是很多餘，但至少我不用去懂它 resource.txt <= 買來的 source code 中的翻譯表，有某種格式，非常不適合閱讀及整理 （多打個 tab or space 就會導致翻譯錯亂） translate.txt <= 翻譯社給的翻譯表，以換行當分格，還算好閱讀 以上兩個讀進去，產生新的 resource.txt 嚴格依照其格式；以程式產生，不由人類閱讀及整理 這種東西我當然寫 exe 做啊 －－－－－－－－－ 最近的任務是：參考中文常用字文件，列舉所有 unicode 中文常用字 5401 字，以 big5 來看算是區塊連續，有兩百多個區塊 以 unicode 看並不連續 所以，以 forloop 去跑 big5, 再做 big5 => unicode 全轉好後得到 5401 個 unicode, 再排序後輸出 這次我用 java 做了，還不錯 :) 其實也是我自找麻煩，因為我改用 mac 了 所以環境能換 mac 就換 當然裝個虛擬機在裡面灌 win7 & vc 來跑也可以 但我想想頭皮發麻啊 所以在 mac 灌 java 我覺得比較直接 哪天我又回到 win 環境下，java 又可以直接用 哇，這就是它的優點啊，這才是人生～ （阿宅工程師自我滿足） > bitlife: 算統計、轉檔類的資料批次性作業? 那Java確實是不錯,jit > bitlife: 集中在熱點迴圈後效率也不差 這邊不了解，請教一下 jit 就是我所謂的整合環境 debug 嗎？ 然後又什麼集中熱點迴圈？ 剛才又跑了個 java 寫的程式（android 開發 tool 中，畫 9-patch 那個） 能畫圖，跨 win & mac 嘖嘖，並不是只有 stdio 這讓我很混亂了，當初公司為什麼全力使用 VC+MFC 開發產品 敝公司是自有硬體的小週邊商 不過硬體不稀奇，一向以軟體在行銷硬體（利用綁硬體的方式） 光軟體會被破解，都賺不到 光硬體則競爭對手也有做，我們也沒比較便宜 硬體出來後，也一直有客戶問 linux driver 等等 照這樣看，其實只要用 c 寫 driver 然後應用程式用 java 寫，可以很快取得相容性，各平台發行 這樣不是比較好嘛 －－－－－－－－－－－－－－ 目前我們的架構是硬體出來後 會先出 Android app, 再出 iOS app (以前著力在 PC 端軟體，現在著力在手機端軟體） 雖然邏輯可以搬，domain knowledge 一樣 但 UI 這一塊是最不相容的 一個不好就是 Android 上寫得出來，iOS 上寫不出來 粉辛苦滴.. Java & Object C 都是泛C 一族，做起來頗有 porting 的感覺 不過底層嘛... 比如，我們想發送一則推文至臉書，Android 端寫出來了， iOS 端又要重看... ※ 編輯: HuangJC (60.251.197.63), 09/25/2014 22:37:50 懂了，原來 JIT '廣義' 來說，字面翻譯可能是'即時'？ 所以我原本知道的是 VC 的 JIT debugger 它可以在 exe 獨立執行遇到錯誤時，呼叫 IDE 進來 （要不然只有在 IDE 內執行才能 debug,也很辛苦） 這裡的是 JAVA JIT Compiler, 指的是 JAVA 的最佳化技術 ※ 編輯: HuangJC (60.251.197.63), 09/26/2014 10:29:02