※ 引述《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