Java是否应该停止增加新特性

争论:Java是否应该停止增加新特性

作者 Ryan Slobojan译者 曹云飞 发布于 2008年1月17日 下午8时13分

社区
Java
主题
语言,
社区,
变更

最近,关于Java平台的未来有许多辩论,有些人认为Java应该加入更多的特征,这样才能与C#、Ruby这样的语言竞争,另一些人认为应该保持Java的稳定,以免变的过于复杂以至于难以使用。Bruce Eckel认为应该彻底停止往Java中增加新特性,这引起了一场新的辩论。

在Bruce Eckel 的博文中,他说如果Java要保持主流地位,那么就需要停止进化。作为一种语言,Java已经“过于嘈杂”了,代码有些过分啰嗦(例如System.out.println())。Eckel认为Java泛型增加了复杂性,这已经引起了人们的关注,他还说明了他看到的Java的一个关键问题:

我们对于复杂性的唯一控制手段是抽象:隐藏不需要暴露的部分(分治法("divide and conquer")是一个变种)。在Java中的悖论是,复杂性问题的一个关键方面被忽略了:没有认识到代码可读性是重要的问题。好像IDE会为你写代 码,如果那样的话即使代码过分复杂也不是问题了。

[Joshua Bloch] 将关于复杂性的思想提升了一步。他说复杂 性不仅仅是指一个孤立的特定特征的复杂性,这种情况下复杂性通常是一目了然的。复杂性是指组合复杂性,这是当你将一个新特性与其他语言特性以任意可能的方式进行组合时所带来的复杂性。如果你没有从一开始就小心的设计,那么当你将一个新特性加入一种现存的语言中时,你无法控制该特性是怎样与其他现存特性进行 组合的。组合复杂性会产生恐怖的后果,特别是在加入了特性之后,这时再做任何事情都为时已晚。早餐结束后Josh说这类复杂性为Java的答疑解惑者提供 了丰富的素材,但是对于整个Java社区是有害的。

Eckel认为他自己是一个“特性上瘾者”,总是思考语言在新特性方面的进化,但是现在他质疑如果一个特性不能被正确的实现,该特性是否应该被去掉 (例如Java的泛型)。Eckel认为C和C++都非常稳定,Java也应该稳定而不是追逐新的语言特性或者试图跟随所有的市场冲动。有些人提出了打破 向后兼容性的想法,他们认为那些希望使用老特性的人们可以使用老版本的Java而不要升级到新版本。Eckel对于不惜一切代价维护向后兼容性的风险做了 警告:

如果由于向后不兼容而不能正确的插入特性,我们在语言变化的时候会受到很大束缚,Java现在的情形与C++相同。C++经常因 为它的设计受到批评,从C++标准委员会刚开始运转我就在其中工作,已经工作了8年,我看到了所有关于语言特性的辩论。这些语言特性不是变化无常的,而是 经过非常谨慎的而且深思熟虑的考量的结果。是向后兼容C语言产生了语言复杂性和困难性。一旦你在所有事情上都把自己与向后兼容绑定在一起,那么当你向语言 加入特性的时候必须做好语言被破坏的准备。如果Java不愿意打破向后兼容性,那么它就无法避免不打粮食的复杂性以及不完整的新特性实现。

Eckel认为新的语言是放置主要新特性的正确场所,Scala是“当前Java最好的退出策略”。他还认为Java唯一的出路是成为象C那样的工具语言,将来只应该清理并丰富现在不完整的库,把主要的语言变化(例如闭包)留给其他语言,而不是加入Java中。

Kevin Dangoor同意Eckel的观点,他说在需要向后兼容性的语言中加入新的特性也是笨拙的,他还指出在这一领域ECMAScript与Java有同样的问题。Dangoor还对于开发者始终要寻求新的、炫的特性来帮助项目的批判声音提出了质疑:

软件是思考的成果。其可锻性很强且新的思想很容易测试。通过互联网,新的思想和代码传播的很快很远,这是好事情。对于我来说,现 在开发软件比5、10、15、20年前要好的多。我看到许多闪光的事物飞过,而没有真正的使用过它们。但是我认为这些闪光的事物是非常重要的,其中包含了各种各样的思想,可以使用不同的工具将其应用于不同的场景。一些出自这些思想的实现成为了主流。

一般来说,人们不会转而使用所有从其身边 飞过的闪光的事物。有些人会认真的尝试这些事物,他们可能会成为成功的拓荒者或者遭受失败的痛苦而转向其他解决方案。如果有足够的人喜欢该思想并且推动它 的发展,那么该思想会成为主流。Rails是2004年闪光的新事物。毫无疑问,有一些早期的使用者遭受了痛苦,但是在那些岁月里,相对于使用其他工具的 人而言,更多的人因为使用Rails获得了非常高的生产率。不管最终有多少人接受了Rails,事实是自Rails出现以后,它的很多思想对工作产生了显 著的影响。

Cay Horstmann 同样认为应该减少对Java语法的关注,增加对Java中痛苦之处的关注。Horstmann援引了C++,指出Java解决了C++碰到的两个主要痛苦之处,内存管理和GUI/数据库的访问。

然而,Java现在需要解决它自己的痛苦之处:

  • 臃肿的代码 —— getter和setter方法,匿名类形式的事件监听器,可以由编译器推断出来的长的类型声明。
  • Web应用开发 —— 这很难,用复杂的而且动力不足的技术,例如JSP和JSF来开发web应用“就像用叉子来喝汤”。
  • 并发 —— “我不够聪明,不能满怀信心的说我编写的重要并发程序不会有死锁,不会有竞争条件。这就象我不够聪明,不能满怀信心的说我编写的重要C++程序不会有内存泄露或内存破坏”

其他观点:

  • Phillip Calçado认为Java应该固定而不是继续扩展,但是不同意关于Java本身难以阅读的说法,他说在创建Java的时候,它比当时的语言,例如C++易于阅读
  • Richard Relos认为 大多数Java代码不使用新的语言特性,增加新的特性仅仅分散了开发者的注意力,破坏了逻辑形式。
  • Ian Cooper探讨了C#的问题,他质疑C#是否已经到达了收益递减的点,他同意主要新特性的去处应该是一个新语言
  • Giovani Salvador担心如果Java不再增加新特性,它会过时,那么Java开发者会变成“恐龙”

你如何看待这个问题?

查看英文原文:Debate: Should the Java language stop adding new features?

该系统主要是为了解决行业研究在提取公司财务数据以及进行财务数据分析时过于繁琐的问题。由于目前金融业使用wind较多,故本系统暂时采用了wind接口,通过自动化从wind提取相关公司财务数据并自动进行财务分析, 最后会将得到的结果以excel的形式输出到本地。 功能特点 提取数据。该系统目前主要整合了wind的python API接口,通过设定初始时间结束时间及公司代码名称,就可以直接通过wind的API提取财务数据。 覆盖全方位财务分析指标 盈利能力 毛利率 经营利润率(EBIT/net revenue) 净利率 ROA ROE ROIC(投入资本回报率) 销售费用率 管理费用率 财务费用率 销售期间费用率(三费加上研发/营业收入) 营运能力 总资产周转率(turnover=net revenue/assets) 固定资产周转率(net revenue/average net fixed assets) 营运资本周转率(net revenue/average working capital,here WC=current assets-current liabilities) 应收账款周转天数 应付账款周转天数 存货周转天数 营业周期(Operating cacle=应收账款周转天数+存货周转天数) 现金循环周期,又名净营业周期(Cash conversion cycle=应收账款周转天数+存货周转天数-应付账款周转天数) 流动性 流动比率(current ratio):流动资产/流动负债 速冻比率(quick ratio):(流动资产-存货)/流动负债 现金比率(Cash ratio):(现金+交易性金融资产)/流动负债 偿债能力 有息负债/净资产 有息负债/总资产 利息保障倍数(EBIT/Interest) 货币资金加上交易性金融资产/有息负债 货币资金/有息负债 估值水平 PE PB PE历史分位数 PB历史分位数 现金流数据 CFO/revenue CFO/average total assets CFO/average total equity CFO/operating income CF0/net income (CFO-perferred dividends)/weighted average number of common shares CFO/total debt(这里采用有息负债) CFO/cash paid for long-term assets(固定资产投资) CFO/cash long-term debt repayment CFO/dividend paid CFO/cash outflows from investing and financing activities (CFO+interest paid+taxes paid)/interest paid 信用水平 Z-score 成长性 营业收入同比 营业利润同比 净利润同比 归母净利润同比 扣非归母净利润同比 CFO同比
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值