Re: [討論] 大家對於物件導向程式語言的選擇...
※ 引述《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
推
04/20 03:09, , 1F
04/20 03:09, 1F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 28 之 34 篇)：