[問題] 以 java 當批次語言方便嗎?
在 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://www.ptt.cc/bbs/java/M.1411591353.A.3D6.html
推
09/25 06:11, , 1F
09/25 06:11, 1F
→
09/25 06:12, , 2F
09/25 06:12, 2F
→
09/25 06:13, , 3F
09/25 06:13, 3F
聽起來反而很神奇,像程式產生器的做法
但自我參考變化的程式,debug 是地獄啊..
推
09/25 06:46, , 4F
09/25 06:46, 4F
→
09/25 07:47, , 5F
09/25 07:47, 5F
→
09/25 09:39, , 6F
09/25 09:39, 6F
→
09/25 09:40, , 7F
09/25 09:40, 7F
→
09/25 09:41, , 8F
09/25 09:41, 8F
C like 我學過 php,它也可以在命令列執行
不過問題在 debug
腳本 (嗯,我總是用詞不精確;你這詞才對,幸好大家看懂我的意思)
用腳本語言可以改一行馬上跑,不用 build
但它沒一個像 eclipse 的環境讓我監看變數,寫 log 很辛苦
一開始都會喜歡它不用 build 的便利
但愈寫愈大後就受不了
尤其是大型專案的 make file 竟然還是 perl 寫的
真是受不了
→
09/25 10:00, , 9F
09/25 10:00, 9F
推
09/25 10:50, , 10F
09/25 10:50, 10F
這個也很出名
-----
同事說'你熟什麼就用什麼',很寬容
(反正他又不看我程式,他只要我做出來)
我想我的關鍵在'我無法靠 log 去 debug 太大的程式'
依據我的個性,當然腳本語言就都擺一邊了
(還是哪個 script 又可以步進,又是 c like?)
我要做的也不全是腳本啦
有時也會有中介於 compiler 階段的程式或資料要動態產生
反正前端資料同事給,我又要產生什麼給同事
比較通俗的說法好像叫 parser
所以都有一堆開檔讀寫, scan, printf 等等
因此以前才用 c 寫 exe 進來操作
※ 編輯: HuangJC (60.251.197.63), 09/25/2014 12:03:29
→
09/25 12:11, , 11F
09/25 12:11, 11F
→
09/25 12:11, , 12F
09/25 12:11, 12F
有一次的任務是購買來的 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 又可以直接用
哇,這就是它的優點啊,這才是人生~ (阿宅工程師自我滿足)
推
09/25 12:52, , 13F
09/25 12:52, 13F
→
09/25 13:29, , 14F
09/25 13:29, 14F
→
09/25 13:50, , 15F
09/25 13:50, 15F
→
09/25 14:09, , 16F
09/25 14:09, 16F
推
09/25 15:31, , 17F
09/25 15:31, 17F
> 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
→
09/25 22:59, , 18F
09/25 22:59, 18F
→
09/25 23:09, , 19F
09/25 23:09, 19F
→
09/25 23:09, , 20F
09/25 23:09, 20F
→
09/25 23:09, , 21F
09/25 23:09, 21F
→
09/25 23:12, , 22F
09/25 23:12, 22F
→
09/25 23:12, , 23F
09/25 23:12, 23F
→
09/26 07:57, , 24F
09/26 07:57, 24F
懂了,原來 JIT '廣義' 來說,字面翻譯可能是'即時'?
所以我原本知道的是 VC 的 JIT debugger
它可以在 exe 獨立執行遇到錯誤時,呼叫 IDE 進來
(要不然只有在 IDE 內執行才能 debug,也很辛苦)
這裡的是 JAVA JIT Compiler, 指的是 JAVA 的最佳化技術
※ 編輯: HuangJC (60.251.197.63), 09/26/2014 10:29:02
推
09/26 21:05, , 25F
09/26 21:05, 25F
→
09/27 01:11, , 26F
09/27 01:11, 26F
推
09/29 10:09, , 27F
09/29 10:09, 27F
→
09/29 10:09, , 28F
09/29 10:09, 28F
→
09/29 10:10, , 29F
09/29 10:10, 29F
→
09/30 14:51, , 30F
09/30 14:51, 30F
→
09/30 14:51, , 31F
09/30 14:51, 31F