10多年前关于java语言的一个争论

宏哥 发布于 2012/07/15 18:46
阅读 1K+
收藏 4

10多年前, java在软件行业正在掀起一场革命.

当时oracle也在8i的产品中采用java作为安装程序,并且把java虚拟机无缝集成到数据库产品当中.那个时候,java在web上的运用还没有普及开

有预言基于java的芯片也将出现...... 

整个软件行业为之感到兴奋, 认为java代表未来. 很少人公开质疑这个观点.

当时我正在linux机器上安装oracle 软件,遇到一些问题,就在国外一个有名的网站上寻找答案, 无意间发现一个争论非常激烈的关于java的讨论. 

有个人,我可以把他称为 Mr. Anti Java, 公开宣称java不能代表未来, 理由非常简单:

他看到, java在除了在java开发工具领域(jbuilder等)的开发上, 没有看到过成功的案例.

--- 这个在当时确实是实际情况.尽管大家对java有很高的期望,但是只见过基于java的开发工具.所有的人都举出各种java语言优势的解释,但是无法反驳他这个论据.都说未来.......

现在回想这个讨论就非常有意思,看看java的现状:

web: Java在这个领域还是非常强势. 角色基本上就是数据库访问语言.

Tools: java在这个领域里面基本上所有的产品就是java开发工具或者数据库开发工具. 简而言之,就是用java开发java开发工具给java开发者用于java开发.

Mobile: j2me在彩屏时代有一定市场,并在安卓时代有进一步发展. 基本上在移动领域,java以UI开发工具的形式出现.

其他领域: java基本上被消灭掉了.

时间过去10多年了, 证明:

 Mr. Anti Java 是对的,大多数人是错的.

 PS: 我是反对Mr. Anti Java的,否则我就不会学习java了.

加载中
1
宏哥
宏哥

引用来自“一千年前的人”的答案

Java 芯片最终没有出现的原因是什么呢。

有没有胜者为王,败者为寇的 可能性呢?       要是java芯片真的出现了, 是不是该说 C码农, C++ 码农些, 不与时俱进, 哈哈 ,  开玩笑哈。

@中山野鬼

我来回答你把, 这个就是  工程 和 理论的区别.

一个API的实现, 需要两个层面,一个是芯片级别,另外一个是软件. 

java的bycode不是根据芯片特点设计的, 这意味着,必须需要一个虚拟机, 要么在芯片里面放一个,要么在软件上放一个. 不管放哪里, 都有很大的代价. 这个代价我们可以用trouble来表达, 就是说, 麻烦从来不会消失,不是在这里,就是在那里.

这里可以有另外一个反例, directx, 这个就是将芯片实现的算法,用api形式在操作系统层面完美表达的一个例子. 这种东西,必须 合服 芯片以及软件两方面的工程设计,才能达到. 而java的bycode,是完全脱离芯片的工程设计来做,就意味着, java芯片必定失败. 芯片不会向java妥协,不是因为强势,而是因为工程上无法实现. 这也同时是directx可以比opengl更成功的一个例子.

反观C的指针,就可以在任何芯片上游刃有余啊, 编译后, 可以无缝和芯片逻辑连接.

1
宏哥
宏哥

引用来自“JFinal”的答案

引用来自“宏哥”的答案

引用来自“一千年前的人”的答案

还有对于语言的争论, 我的理解是php, python 比java高阶,没有过分设计, 代码量更少, 开发效率更高。

但是如果仅仅开发效率高一个优点, 还不足以作为语言选型的最终依据。

java的优势就是: 强类型语言, 生态链广泛, 社区, 大厂商的支持, 码农多。

像 python, 都没有厂商来支持。

我到觉得Java还是有条件提升开发效率,类似 @Jfinal , 我没有用过. 有几个路径:

1: 简化类型转换

2: 简化URI到逻辑段(action)的映射

3: 简化模板

4: 简化SQL 构造.

这里面仍然有几个坑必须避开:

1: 任何涉及到"实体化", 也就是写入磁盘数据 以及事务操作. 必须委托给第三方,不能依赖任何容器. 不要做任何抽象. 不同的第三方,管理数据以及事务的能力千差万别. Java整体体系,没有能力管理"实体化"数据.

2: 任何的数据库访问, 不要做任何假定, 比如数据抽象的假定,特别是不能要求数据库之间进行兼容. 世面上有很多框架,都围绕mysql做样本进行设计,会产生很多"糟糕"的如last insert_id的设计. 必须围绕SQL构造来做. SQL之灵活,无法用对象来表达.

大多框架死在这两个上面.

我还是相信 @Jfinal 能达到这个目标, 上面的目标不仅是可能的,应该也是可行的.  @Jfinal@一千年前的人 , 你们应该有能力自行评估了.

@宏哥 提出的四个路径:简化类型转换、简化URI到逻辑段(action) 的映射、简化模板、简化SQL构造。在JFinal中有1、2、4都做到了,简化模板也是JFinal一直想着做的事情,目前觉得Freemarker简化的空间还非常大。JFinal并未从理论上做出这样的总结,但开发目标与原则与宏哥提出的殊途同归。

我建议你直接把freemaker集成进去.没有必要在这个上面浪费精力. 你说的简化空间很大,我也同意.给你个语法参考: http://www.oschina.net/question/96003_20215

另外,我不认为这方面有很大价值. 

你完全可以将你的智慧用于更加贴近用户需求的方面, 直接将Jfinal集成到能够发布的产品当中.通过产品反馈来改进Jfinal. 直接锁定某个目标市场,比如bpm去做. 现在os做的那些玩意,太烂了.客户更愿意付钱给你,让你直接解决问题,而不是付钱给你,让你教他们写程序.

我相信,用java的大企业,都有一套自己的类,来简化一系列的操作. 这样削弱了你的市场价值.

对于数据库支持,要锁定商业数据库, 至少应该支持mssql和oracle. mysql的客户很难给你带来价值. 它们用ssh和你的框架,区别不大.本来他们的系统,对数据操作都没有高的要求.

 

1
宏哥
宏哥

@Jfinal  ,CMS 低端你很难和php+mysql竞争. 中端很难和sharepoint竞争, 高端很难和opentext竞争. 空间很小.

如果说有什么建议,你不如考虑 做个报销审批系统, 我相信,这玩意, 所有企业都欢迎的.进一步说,完整的财务审批,再进一步, 通用流程审批.

退一步说,可以免费使用.至于开源嘛,你可以开源jFinal

宏哥
宏哥
回复 @一千年前的人 : 乙方也有很多好处. 甲方很多懒人.
一千年前的人
一千年前的人
回复 @宏哥 : 哈哈。 终于明白宏哥为啥跑到甲方去了。 去年 施奈德, 友邦 都有机会, 只是我还没有在乙方呆够....
宏哥
宏哥
回复 @一千年前的人 : 必须从客户那里拿需求.唯一的路径.从小做起.
一千年前的人
一千年前的人
得不到真实的需求, 闭门造车?
宏哥
宏哥
回复 @一千年前的人 : 对于这种困难,我唯一能说的就是 -- 客户是最好的老师.
下一页
1
宏哥
宏哥

引用来自“一千年前的人”的答案

@宏哥

1.  你们也在用notes,notes的文档管理和流程管理,    和 sharepoint  相比怎么样?

2.  notes的文档管理和流程管理   算是中端还是高端?

 

哈哈, 我是不是问题太多了。


1: notes 在文档管理和sharepoint差远了. sharepoint 是很专业的ECM工具.

2: notes 在早期应该算高端, 因为市场上缺乏相应的解决方案.现在,我们叫它legacy.

notes的最大问题, 就是它的meta data无法像数据库的数据建立关系. 导致汇总什么的非常困难. 它的优势据说是开发快,我没有这方面经验.

一千年前的人
一千年前的人
加上sharepoint 和outlook集成一下......
1
宏哥
宏哥

引用来自“一千年前的人”的答案

@宏哥   你知道企业里面员工用的windows桌面, 正版的价格是怎么算的吗?

好像是按年收费的....  假如一个桌面一年500的授权费, 一个1000人的公司, 也不少啊。。。


大的企业通过Dell这种渠道和MS敲定统一价格. 特大的,常常自己和ms敲定价格. 软件企业都有

key account manager来负责到企业的业务.

windows 的license是每PC的. oracle多种授权模式, erp是年费.....

win不算贵,如果你综合考虑了人力成本之后.  就好像高铁不便宜,但是你不会从北京走路回家一样

1
宏哥
宏哥

引用来自“一千年前的人”的答案

引用来自“宏哥”的答案

引用来自“一千年前的人”的答案

弄一个好点的壳子哈:

工作中每天都要用一款软件:配置管理软件。 开发、测试、需求、pm、team leader、配置管理人员都要用。  这款软件同时有 web版 客户端版。 

多数功能。 两者都有, 少数功能 客户端 才有....  

web版 客户端版 都是壳,  他们都是调用的服务端的REST API.  (客户端版 极少数功能例外)。

实际上, 多数操作使用web版 就可以了。 这样就不收os的限制了。

SAP GUI也是一个壳. 好像大小还不如 JDK大.

哈哈。 SAP GUI这个壳子比jdk稍微大一点点哈。 SAP 整个壳子 也就二三百M。  jdk 不到200M。

宏哥可能没有登陆过sap的界面吧, 真的不易用,操作不方便。。。

用友的u8就是真正的vb界面, 看起来就像是大型ms的界面。 比较符合我们的习惯。

我的电脑上就有SAP GUI. 丑得和vim一样.

但是,见过专家玩sap的时候,飞起来就像我玩vim一样. 完全是效率优先的.而且那种丑陋的界面可以摆放任何复杂的表单,还不伤眼睛. 不得不佩服.所以我改变审美观念了.都是快捷方式操作, 基本上熟悉的人就是输入一个字母,然后一个快捷键, bom就找到了.

vb做的界面我相信是很易用的.但是java swing要做到,极其困难.

一千年前的人
一千年前的人
哈哈。 学习! Good night!
1
宏哥
宏哥

引用来自“一千年前的人”的答案

引用来自“宏哥”的答案

引用来自“一千年前的人”的答案

@宏哥

这两天仔细看了asp.net 的开发模型, 并和java、JFinal、php的开发速度做了对比, asp.net 比后三者的开发速度都快得多。 

只是asp.net只能  run on windows

客户大多时候不在乎 是不是windows.

那个 ultimus就是asp.net开发的.

windows只能支持X平台。 无法run 在小型机、中型机、大型机上。 听不到大规模的系统在windows上的案例。 

不过对于一般规模的系统, 是没有关系。

企业生产系统,趋势是大集中处理,这样对单台机器的要求越来越高。
而互联网适合分布式,对单台机器的要求降低。

大机以下下的规模, win都没有问题.

况且, 数据库可以跑unix上, asp.net放win上,没有啥区别.

0
一千年前的人
一千年前的人

Java 芯片最终没有出现的原因是什么呢。

有没有胜者为王,败者为寇的 可能性呢?       要是java芯片真的出现了, 是不是该说 C码农, C++ 码农些, 不与时俱进, 哈哈 ,  开玩笑哈。

@中山野鬼

0
一千年前的人
一千年前的人

php 的开发效率和asp.net 相比, 哪个高些呢?

 

当然asp.net 有一个硬伤,无法run在linux, unix上。

在windows上缺少大型的应用案例(电信?金融?)。核心的系统都还在Unix-like系统上?

ms收购hotmail后, 想把hotmail从Unix-like系统(好像是FreeBSD)  迁移到windows上, 费了老大劲了, 最后还是有少数机器依旧使用Unix-like系统。  见 吴军博士的《浪潮之巅》。

mark35
mark35
当时hotmail换成NT之后曾经大面积当过一次机。后来逐步解决才全换成win系了
宏哥
宏哥
如果都是弱类型,应该差不多. 我觉得熟练的话. 强类型和弱类型有些区别,其他区别不大.
0
泡不烂的凉粉
泡不烂的凉粉

JAVA只是一种语言。 java虚拟机方式运行只是一种方式。

我认同java虚拟机方式。但仅java语言来说。并不觉得会有多大变革。不会独霸一方。

javascript 在web前端应用可以说目前是独霸的。其他脚本语言似乎还没有可以替代他位置的。

返回顶部
顶部