※ 引述《easterday (數牙)》之銘言： : 我現在的概念是,如果on Native Code,我應該再去看看組語的書,這樣我在debugging : 會比較有概念 : 如果on VM,那當然是看那個VM的書...用熟工具....放棄debugging的細節... : : 這兩件事情可能都要花至少1年時間 : 大家的意見如何?... : : 有個大學生說,1:簡單的事情就用RAD Tool on VM隨便拉一拉就好了 : ,最佳化再用Native Code來做 : : 但是這種概念好像 : 和用 2: UML,ER Diagram做事的那種潮流不太同調 : : 例如因為我已經 : 1.Coding on VM的Project(尤其是精心設計,想了很久寫了很久...) : 常常dependent on [(精心設計的)VM], : 2.然後我把UML圖畫出來初稿 ========== 假設把 project 定在 Java VM 上實現, 也在 Java VM 上 跑得好好的, 但現在想把這個 project 的程式轉成 native code 由 XX 硬體直接執行, 因此考慮底下 3, 4, 5 問題. : 3.再要把dependent part再弄出來 : 4.再來一個UML定稿 ========= 因為這個 java program 依賴 JVM 支援, 所以要把依賴 JVM 支援的這部份功能, 從 C 或 C++ library 找出來或自行用 C 開發, 所以此部份再用 UML 再設計繪圖出來. : 5.才可以成為Project Coding Native Code ? : ======== 假設真的是這樣做, 雖然做了兩次 UML 設計與程式開發, 但這 並沒有違反軟體工程開發的概念, 反而是依賴 JVM 支援的那部 份功能, 因為 JVM 提出的功能協助, 反而有了清析的功能規格. 整個軟體設計反而模組畫分清楚. 再假設你能把 Java Program 以人工方式轉成 C++ 或 C 語言重 新人工轉譯出來, 真正的問題會出在 Java JVM 的執行環境支援 可能欠缺規格與架構的知識而無法自行用 C 寫出來. 某些解譯語言的程式(如 BASIC)也是能從中間碼轉譯成為可讓機 器直接執行的 native code , 但要使用配合該解譯語言提供的 library 與 run-time support . 換言之, Java JVM 也可以有 某類 cpu 機器碼的執行核心, 可以跟轉譯到該機器碼的 java 程式合併執行, 這樣做就是買某類處理機的 Java Machine support 來配合執行. 如果這樣做就可免除 3, 4 步驟了, 但花 錢買這個 Java Machine support 是要的. : ps: 我希望我能提供很適用的GUI給我的作品... : : 所以第一個問題就是: Coding on VM / Coding on C++ and learn x86 Assembly? : 第二個問題是: Project on VM / Project on C++ ? : : 謝謝大家的意見... ========================= 現代的資x人, 學了演算法的斤斤計較, 就怕走冤枉路. 但學習與經驗是那種 不經一事不長一智的東東, 而舉一反三也不在演算法那類的捷徑裡. 做出作品, 最重要的是先能 "賣出去" 或者說是受到 "賞識". 暫時賣不出去, 也得要是稍經改良, 就會有將來換成大錢的可能. 假如能吸引來投資, 就可因 為有資金來之不易, 再去考慮用甚麼方式找那些高手來發展. 所以是要能吸引 投資為先, 先恰到好處, 求完美其次, 等成了投資的重大案, 再來煩惱整套的 軟工發展方式會比較務實. 使用 Java 就是容易先兜起來展示再說, 造量產產品賣錢的就會換成不好被抄 走的 native code program . --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.4.12