C++的缺陷和D的缺陷
Huafeng Mo
http://blog.csdn.net/longshanks/archive/2007/10/13/1823298.aspx
来吧，都冲着我来，有仇的报仇，有冤的报冤，我准备好了。
刀枪不入，刀枪不入，刀枪不入，... :-P
--
反者道之动，弱者道之用
oldrev
first-class的。也就是说，把所有类型一视同仁。如果能够做到，那么这门语言
中，将只有类型这样一个first-class的概念，而不再分类。那这样得到的好处是
什么呢？就是灵活性、扩展性、简洁性。"
这是不是在说 C# 啊？呵呵。C++这般的 Native 语言当然也可以把 int 作为
std::Int 的别名，但是有一个很巨大的问题，那就是 struct 成员的对齐。
在 2007-10-13六的 17:01 +0800，Huafeng Mo写道：
--
Regards,
- Oldrev
oldrev
语意解析完全分开，不能有需要语意分析才能确定语法的情况出现，这也是D编译
速度快的原因之一。C++ 使用 <> 和 >> 造成了需要语意分析才能避免歧义的状况
出现，C++0x 解决了这个问题？ C++0x只是要求编译器解决这个问题 :)
多继承 versus interface+单继承 这又是一个口水仗的导火索，不过 D 多了一个
mixin，应该比 Java/C# 之类的灵活一点，就像从没人抱怨 Ruby 的单继承一样。
比较一下用多继承和模板+mixin实现 policy 手法:
class Foo : public PolicyA, public PolicyB ...
{
};
-or-
class Foo
{
mixin PolicyA;
mixin PolicyB;
...
}
模板还有一个附带的好处是不会产生 vtbl和RTTI，当你有很多小 Policy 的时候
就很有用。
concepts？C++还得等很长一段时间呐，先让 C++ 做做小白鼠好了。
操作符重载和 traits：
D已经有初步编译时反射了， 比如 __traits(allMember, T) 。虽然 opAdd_r 很
难看，但是 python 的更难看:)
一个不容易想到的副作用是采用函数签名的操作符重载对反射更加友好，而且便于
手工调用。
在 2007-10-13六的 17:01 +0800，Huafeng Mo写道：
--
Regards,
- Oldrev
Huafeng Mo
"C++创建时有一个宗旨：让用户定义类型象内置类型一样处理。这句话是非常
first-class的。也就是说，把所有类型一视同仁。如果能够做到，那么这门语言
中，将只有类型这样一个first-class的概念，而不再分类。那这样得到的好处是
什么呢？就是灵活性、扩展性、简洁性。"
这是不是在说 C# 啊？呵呵。C++这般的 Native 语言当然也可以把 int 作为
std::Int 的别名，但是有一个很巨大的问题，那就是 struct 成员的对齐。
C#象smalltalk、java那样，把类型等同于类，这是本末倒置。类是类型的一种，反过来不对
在 2007-10-13六的 17:01 +0800，Huafeng Mo写道：
> 休息天显得无聊，闷得慌。找个题目，以便引发一场论战 :)：
> http://blog.csdn.net/longshanks/archive/2007/10/13/1823298.aspx
>
> 来吧，都冲着我来，有仇的报仇，有冤的报冤，我准备好了。
> 刀枪不入，刀枪不入，刀枪不入，... :-P
>
> --
> 反者道之动，弱者道之用
> >
--
Regards,
- Oldrev
--
反者道之动，弱者道之用
yq chen
Huafeng Mo
--
反者道之动，弱者道之用
Huafeng Mo
Huafeng Mo
操作符重载和 traits：
D已经有初步编译时反射了， 比如 __traits(allMember, T) 。
我是希望D能有更完善的compile time reflection，我很铁不成钢啊。
虽然 opAdd_r 很难看，但是 python 的更难看:)
一个不容易想到的副作用是采用函数签名的操作符重载对反射更加友好，而且便于
手工调用。
在 2007-10-13六的 17:01 +0800，Huafeng Mo写道：
> 休息天显得无聊，闷得慌。找个题目，以便引发一场论战 :)：
> http://blog.csdn.net/longshanks/archive/2007/10/13/1823298.aspx
>
> 来吧，都冲着我来，有仇的报仇，有冤的报冤，我准备好了。
> 刀枪不入，刀枪不入，刀枪不入，... :-P
>
> --
> 反者道之动，弱者道之用
> >
--
Regards,
- Oldrev
--
反者道之动，弱者道之用
pongba
关于 <> 和 !() 的问题， D 的设计目标之一就是语法要 context-free，语法与
语意解析完全分开，不能有需要语意分析才能确定语法的情况出现，这也是D编译
速度快的原因之一。C++ 使用 <> 和 >> 造成了需要语意分析才能避免歧义的状况
出现，C++0x 解决了这个问题？ C++0x只是要求编译器解决这个问题 :)
我倒是认为，从长远来看，实现困难永远不应该成为抽象设计的绊脚石。因为现在的实现困难在以后也许就解决了，但抽象抽错了，以后再改就改不了了。一个例子是异常，异常最初的实现机制是很低效的，但异常这个抽象机制很好，很有用；后来用id表方案解决了实现的问题。另一个例子是IBM，IBM当时开发字处理软件的时候被内存限制和处理器速度绊住了手脚，很多好的设计都抛弃了。但微软就没有这么做，而是以设计为主。几年后处理器速度和内存迅速飙升，微软一炮打响。（注：是不是IBM vs. Microsoft记不清了，但记得是大嘴Joel讲的一个故事）。
具体到C++上面，编译器速度也许目前是一个问题，但也许几年之后，并发编译就使得这个问题根本无足轻重了。（当然，完全没有必要地将语言搞成NON-LR的也是不可取的）。
concepts？C++还得等很长一段时间呐，先让 C++ 做做小白鼠好了。
No, concept的小白鼠是STL，当年C++98就已经考虑加入concept了，因为经验问题没有加入，后来STL的经验充分表明concept的重要性，因此，concept早就是被实践证明的特性。现在只是填上这个缺口而已，并非冒进加入（甚至可以说都嫌晚了）。
操作符重载和 traits：
D已经有初步编译时反射了， 比如 __traits(allMember, T) 。虽然 opAdd_r 很
难看，但是 python 的更难看:)
这个逻辑... 难道说：有比A更难看的，所以A就好看？好看不好看的标准应该是从对用户（程序员）来说的易用性、学习曲线、直观性、表达力等方面来说的；而不是在各个语言实现之间作比较。就算A在所有语言实现之间是最好看的，也不代表它就好看。
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
oldrev
既然 D 的模板可以包含任何东西，那么能不能在语法上简化模板mixin呢，也就是
说，为什么不让类继承模板：
template PolicyA()
{
//some function & member
}
template PolicyB()
{
}
class Foo : PolicyA(), PolicyB()
{
}
这并不是真的继承，只是一个语法糖，简化 mixin，而且没有真正多继承的副作
用。
opinions?
在 2007-10-13六的 18:05 +0800，Huafeng Mo写道：
> 模板+mixin实现，典型的second-class特性实现first-class功能，不是什么好
--
Regards,
- Oldrev
oldrev
么：IDE、Lint、Doxygen.....，这些东西都需要语法解析。
concepts 实现的困难比较大，相当于添加一个新的类型系统，短时间内D应该不会
有。
operator+ 也不够优雅，最优雅的是 Ruby 的：
def +(x)
....
end
在 2007-10-13六的 18:11 +0800，pongba写道：
>
>
> On 10/14/07, oldrev <old...@gmail.com> wrote:
> 关于 <> 和 !() 的问题， D 的设计目标之一就是语法要
> context-free，语法与
> 语意解析完全分开，不能有需要语意分析才能确定语法的情况出现，这
> 也是D编译
> 速度快的原因之一。C++ 使用 <> 和 >> 造成了需要语意分析才能避免
> 歧义的状况
> 出现，C++0x 解决了这个问题？ C++0x只是要求编译器解决这个问
> 题 :)
>
> 我倒是认为，从长远来看，实现困难永远不应该成为抽象设计的绊脚石。因为现
> 在的实现困难在以后也许就解决了，但抽象抽错了，以后再改就改不了了。一个
> 例子是异常，异常最初的实现机制是很低效的，但异常这个抽象机制很好，很有
> 用；后来用id表方案解决了实现的问题。另一个例子是IBM，IBM当时开发字处理
> 软件的时候被内存限制和处理器速度绊住了手脚，很多好的设计都抛弃了。但微
> 软就没有这么做，而是以设计为主。几年后处理器速度和内存迅速飙升，微软一
> 炮打响。（注：是不是IBM vs. Microsoft记不清了，但记得是大嘴Joel讲的一
> 个故事）。
> 具体到C++上面，编译器速度也许目前是一个问题，但也许几年之后，并发编译
> 就使得这个问题根本无足轻重了。（当然，完全没有必要地将语言搞成NON-LR的
pongba
context-free 语法的问题不仅仅影响编译器，考虑一下除了编译器我们还需要什
么：IDE、Lint、Doxygen.....，这些东西都需要语法解析。
concepts 实现的困难比较大，相当于添加一个新的类型系统，短时间内D应该不会
有。
恰恰相反，concepts的实现难度很小，只要对模板实现系统稍作修改即可。详见concept的提案。
operator+ 也不够优雅，最优雅的是 Ruby 的：
def +(x)
....
end
Huafeng Mo
context-free 语法的问题不仅仅影响编译器，考虑一下除了编译器我们还需要什
么：IDE、Lint、Doxygen.....，这些东西都需要语法解析。
话是这么说，可难道D就不能想点变得办法吗
concepts 实现的困难比较大，相当于添加一个新的类型系统，短时间内D应该不会
有。
真的吗？首先conceptgcc已经实现，实现的程度八九不离十吧， 并没有听说有多么困难啊。其中很多部分都是重用原来模板的编译代码，并没有想象得那么可怕。
operator+ 也不够优雅，最优雅的是 Ruby 的：
def +(x)
....
end
本质上一回事。就差几个字符而已。
--
反者道之动，弱者道之用
Huafeng Mo
--
反者道之动，弱者道之用
Huafeng Mo
总的说起来，D还只是在一些细枝末节上打转转，没有走出革命性的一步，未能象C++在C中引入OOP和GP，甚至TMP那样翻天覆地。在07-10-13，Huafeng Mo < longsh...@gmail.com > 写道：在07-10-14， oldrev <old...@gmail.com> 写道：context-free 语法的问题不仅仅影响编译器，考虑一下除了编译器我们还需要什
么：IDE、Lint、Doxygen.....，这些东西都需要语法解析。
话是这么说，可难道D就不能想点变得办法吗concepts 实现的困难比较大，相当于添加一个新的类型系统，短时间内D应该不会
有。
真的吗？首先conceptgcc已经实现，实现的程度八九不离十吧， 并没有听说有多么困难啊。其中很多部分都是重用原来模板的编译代码，并没有想象得那么可怕。operator+ 也不够优雅，最优雅的是 Ruby 的：
def +(x)
....
end
本质上一回事。就差几个字符而已。
--
反者道之动，弱者道之用
--
反者道之动，弱者道之用
反者道之动，弱者道之用
red...@gmail.com
1. 你讲了很多的操作符重载, 我是基本不用的, 所以对我来说不存在问题.
如果是 C++ 下面, 要我找一个用的场合, 那么是 string.
2. 说到内置类型和用户定义类型一致性, 其实最有作用的是, 写 GP 程序, 例如
container 的时候, 可以同样强大地提供给内置类型和用户定义类型, 不像java
那样必须 boxing 才好
D 已经做到这点了. 至于算符重载那些问题, 起码对我影响很小.
3. 我目前的模块, 有将近8千行D 代码, 没有感觉到 ()! 给我带来多少困扰, 当
然, 这可能与我用的 ultraedit 和vim 都能够用不同的颜色显示它有关.
另外想找, * 可以是乘法, 可以是 deference, 可以是指针定义
p = (char *)(*pi * 3)
这样的语句, 你阅读起来若没有问题, 那我也不觉得 ()! 有很大问题.
4. 如果 mixin 可以配合某个语法, 对被mixin 的template 块自动调用构造函数,
我觉得不必多继承实现policy 差.
而且还有其他好处: policy 用多继承实现的时候, 各个policy 之间要调用功能,
必须传递自己的指针给对方, mixin
实际上省掉了这些代码, 初始化程序简单了很多, 很多时候, mixin part 的初始
化程序可以省掉.
目前根据我的实践看来, mixin 做policy 控制, 只是ctor, dtor 的时候麻烦些,
其他没有造成什么问题. D 广泛应用的话, 如果社区一直觉得mixin 处理policy
还不错, 这个方面应该会增强的.
5. 编译速度的问题:
从前刚尝试用 C++ 的时候, 编译速度比 C 慢了很多, 很讨厌, 转到用 C 实现
OOP 去了, 过了一些年, 机器速度比较快了, 编写OO 的 C++ 程序, 编译速度还马
马虎虎; 但是没有幸福多长时间, template 的使用又来到了, 这回的编译速度下
降得就更验证了. 听说 concepts 是的 C++ 编译速度下降的问题也非常严重.
现在 CPU 的主频进展已经缓慢了, core 增加将成为主要性能, 机器的 core 增加
对 C++ 的帮助如何呢 ? 按照编译器原理来看, 多核并发编译, 对同时编译多个
module 是非常有效的; 如果是编译同一个module, 由于编译都是需要从前到后进
行, 我不知道它怎么利用多个core, 即使能用, 符号表这个东西的访问, 同步冲突
会非常厉害. 这样, 即使以后我的机器有128 core, 但是我的程序是5个 .cpp,
include 了很多东西, 它能够用多少个core 编译 ? 我之前就有程序, 一个 .cpp
的编译时间都很够长.
如果 C++ 的大发展, 都伴随编译速度严重下降的话, core 增加用处又不大, 这个
编译速度, 嗯, 会让我觉得 C++ + com 还是好东西, 可以减小需要编译的东西,
template 就算了, 别用了.
D 几十倍的编译速度, 使得 编写/unitest/调整/unitest 的循环十分顺畅, 即使D
的语法和c++ 完全一样, 没有任何改进, 我也会用它.
6. D 还在发展初期, 如果不是其他用户的强烈请求, D2.0 还不会 folk 出来, 就
还没有 D1.0 stable 版本.
因此 concepts 不能说以后就一定没有, reflection 如果被以后 D 的典型应用强
烈要求的话, 也不会保证没有
7. D 的发展模式
C++ 基本上不采用任何导致不兼容的进化, 导致包袱越来越重, 迟早走不懂, D 不
是这样, 我宁愿接受版本大升级的时候的修改调试, 也不愿意让我写程序的时候,
要考虑n 多个陷进.
8. 我的看法, D 目前最大的问题
1. 库不够强, 不够大.
2. 尚未有足够工业强度的应用作为证明.
Huafeng Mo 写道:
red...@gmail.com
Huafeng Mo 写道:
不要误会，我说这话是希望D等够翻天覆地，让我郁闷已久的心情得到舒展。
在07-10-13，Huafeng Mo <longsh...@gmail.com> 写道：
总 的说起来，D还只是在一些细枝末节上打转转，没有走出革命性的一步，未能象C++在C中引入OOP和GP，甚至TMP那样翻天覆地。
Huafeng Mo
对我来说:
1. 你讲了很多的操作符重载, 我是基本不用的, 所以对我来说不存在问题.
如果是 C++ 下面, 要我找一个用的场合, 那么是 string.
操作符重载在很多方面有很强的应用。但是， 不少应用不用操作符重载也行，但用了更好。这取决于程序员的决断。我所说的是灵活性，系统级的语言要给使用者选择，即便使这种选择造成了语言实现上的困难。毕竟系统开发是一个宽泛的领域，语言是给各种各样的程序员用的，每个人都应当得到重视。
2. 说到内置类型和用户定义类型一致性, 其实最有作用的是, 写 GP 程序, 例如
container 的时候, 可以同样强大地提供给内置类型和用户定义类型, 不像java
那样必须 boxing 才好
D 已经做到这点了. 至于算符重载那些问题, 起码对我影响很小.
这不是一个概念，我所谓的类型一致性处理，可以理解为所有的类型都使用户定义类型，但其特性同现有语言中的内置类型一样。这是一种元编程的特性。
3. 我目前的模块, 有将近8千行D 代码, 没有感觉到 ()! 给我带来多少困扰, 当
然, 这可能与我用的 ultraedit 和vim 都能够用不同的颜色显示它有关.
另外想找, * 可以是乘法, 可以是 deference, 可以是指针定义
p = (char *)(*pi * 3)
这样的语句, 你阅读起来若没有问题, 那我也不觉得 ()! 有很大问题.
情人眼里出西施嘛。:)
4. 如果 mixin 可以配合某个语法, 对被mixin 的template 块自动调用构造函数,
我觉得不必多继承实现policy 差.
而且还有其他好处: policy 用多继承实现的时候, 各个policy 之间要调用功能,
必须传递自己的指针给对方, mixin
实际上省掉了这些代码, 初始化程序简单了很多, 很多时候, mixin part 的初始
化程序可以省掉.
目前根据我的实践看来, mixin 做policy 控制, 只是ctor, dtor 的时候麻烦些,
其他没有造成什么问题. D 广泛应用的话, 如果社区一直觉得mixin 处理policy
还不错, 这个方面应该会增强的.
还是那句话，first-class的需求，最好用first-class特性实现 。
5. 编译速度的问题:
从前刚尝试用 C++ 的时候, 编译速度比 C 慢了很多, 很讨厌, 转到用 C 实现
OOP 去了, 过了一些年, 机器速度比较快了, 编写OO 的 C++ 程序, 编译速度还马
马虎虎; 但是没有幸福多长时间, template 的使用又来到了, 这回的编译速度下
降得就更验证了. 听说 concepts 是的 C++ 编译速度下降的问题也非常严重.
现在 CPU 的主频进展已经缓慢了, core 增加将成为主要性能, 机器的 core 增加
对 C++ 的帮助如何呢 ? 按照编译器原理来看, 多核并发编译, 对同时编译多个
module 是非常有效的; 如果是编译同一个module, 由于编译都是需要从前到后进
行, 我不知道它怎么利用多个core, 即使能用, 符号表这个东西的访问, 同步冲突
会非常厉害. 这样, 即使以后我的机器有128 core, 但是我的程序是5个 .cpp,
include 了很多东西, 它能够用多少个core 编译 ? 我之前就有程序, 一个 .cpp
的编译时间都很够长.
如果 C++ 的大发展, 都伴随编译速度严重下降的话, core 增加用处又不大, 这个
编译速度, 嗯, 会让我觉得 C++ + com 还是好东西, 可以减小需要编译的东西,
template 就算了, 别用了.
D 几十倍的编译速度, 使得 编写/unitest/调整/unitest 的循环十分顺畅, 即使D
的语法和c++ 完全一样, 没有任何改进, 我也会用它.
我已经反复强调了，别老是拿C++坐标干，想想未来可能出现的新语言吧，这是D真正的对手。
6. D 还在发展初期, 如果不是其他用户的强烈请求, D2.0 还不会 folk 出来, 就
还没有 D1.0 stable 版本.
因此 concepts 不能说以后就一定没有, reflection 如果被以后 D 的典型应用强
烈要求的话, 也不会保证没有
这我没意见，希望快一些。
7. D 的发展模式
C++ 基本上不采用任何导致不兼容的进化, 导致包袱越来越重, 迟早走不懂, D 不
是这样, 我宁愿接受版本大升级的时候的修改调试, 也不愿意让我写程序的时候,
要考虑n 多个陷进.
所以，为了避免不兼容自己，D应该把眼光放远些。D还没标准化，一旦标准化兼容性就是个大问题。
8. 我的看法, D 目前最大的问题
1. 库不够强, 不够大.
2. 尚未有足够工业强度的应用作为证明.
再补充一点，捧着金饭碗讨饭。:)
Huafeng Mo 写道:
> 休息天显得无聊，闷得慌。找个题目，以便引发一场论战 :)：
> http://blog.csdn.net/longshanks/archive/2007/10/13/1823298.aspx
>
> 来吧，都冲着我来，有仇的报仇，有冤的报冤，我准备好了。
> 刀枪不入，刀枪不入，刀枪不入，... :-P
>
> --
> 反者道之动，弱者道之用
> >
--
反者道之动，弱者道之用
Atry
对我来说：
1. 重载运算符
我对重载运算符的需求在于自己定义一个领域特定语言。假如没有重载运算符， boost::spirit 用起来会吃力得多。
2. 要求用户类型和内置类型一致
这没意义。
3. 语法
!( )令我讨厌，如果有选择的话，我更宁愿看到 < > ，如果非要认为这对于编译器编写造成了困难，要求 !< >! 或者 |< >| 我都同意。总的来说，模板应该用一种不同的括号，但是非要用圆括号也没什么大不了的。当然，对 cast ，我的观点也一样，我更喜欢 static_cast< > ，不过这不是大问题。
4. 邪恶的 mixin
若非迫不得已，我不使用 mixin ，这跟宏没什么两样。 如果需要多个组成部分，我可以既不用多重继承，也不用 mixin 来实现，就用最简单朴素的 struct 作为成员。
5. 编译速度
作为一个用户，我对 D 的编译速度没什么可抱怨的。D 完胜 C 和 C++
6. 更多的特性？
我觉得运行时反射不是好东西， Java 很多框架滥用反射，会遭到天堑的。编译时反射， D 已经很强了，有一个 tupleof ，我觉得就已经很幸福了。而 concept 这玩意儿是好东西，但就算没有也能凑合着用。
7. D 的发展模式
同意 redsea
8. D 目前最大的问题：
a) 已有库都太烂。照搬 Java ，没有利用 D 的牛叉特性，令人失望。
b) 现有库太不稳定，太多 bug 。这个虽然是目前很讨厌的，不过却是可以原谅的，毕竟才刚开始嘛。
c) 库功能不够。这个反而是最不重要的，与其用一个烂库，还不如直接用 C 库，移植头文件很容易。
Atry
red...@gmail.com
对象中之类.
问题这是一个保守 gc, 会有内存无法释放掉, 同时不能重整内存, 这两个比较讨厌.
如果 D 能够获得较大的成功, 吸引更多的开发力量, 这应该能够期待有改进, 例
如多个不同实现的gc, 不能应用类型选择不同的 gc(论坛上讨论过的).
Atry 写道:
yq chen
，这一点让我反感。然后，感觉它的所有东西都是针对它所认为的C++的缺陷的改进，属于见招拆招的方式，看不出来自己的整体标志性的优点在那里。
XXX123
对我来说，C++任何缺陷都可以忍受，唯独编译速度不行，我机器又比较差，简直就是快速迭代的噩梦。就算多core编译能提高个几倍几十倍，那估计也要
好几年之后了。所以还是用D吧。
XXX123
yq chen 写道：
李扬
Huafeng Mo
--
反者道之动，弱者道之用
Huafeng Mo
oldrev
在 2007-10-13六的 21:26 +0800，Huafeng Mo写道：
--
Regards,
- Oldrev
Huafeng Mo
--
反者道之动，弱者道之用
red...@gmail.com
1. 接收 C++ 用户
现在从 tpci, google trends 看, 关注 C++ 的人都在持续减少, 这证明新开项目
用 C++ 肯定减少, 一部分公司在抛弃 C++, 因此, 不需要做得非常酷炫去抢死忠
C++ user, 只需要接收抛弃 C++ 的一部分项目组, 就可以有一定的市场份额了.
不过现在的成熟度, 接收不到什么像样的项目组, 倒吸引到许多个人在做尝试.
2. 接收 Java 用户(有可能不是全职 D 用户)
现在一部分 D 的用户来自 Java.
甚至 tango 开发组里面多个人是有 Java 背景的 --- 所以搞个tango 很有Java
味(Arty 语).
虽然 D 比起 C++, 不显得多酷多炫, 但是比起 Java 来, 那就强大啦, 如果某个
Java 组要写较低层的程序, 比起要学 C++, 恐怕他们更愿意学 D, 能处理低层,
比 Java 语言能力强, 同时有 gc, 有 native string, 有 interface, 还有
tango 库也很有熟悉的味道啊 :) , 很亲切的哦, 远远比大跳一步到 C++ 那边更安全.
不过这一些人, 如果来做 D open source 项目, 估计又是浓浓的 Java 味了.
以前曾经有几个 Javaer 开始对python 感兴趣, 一起做了一个 python 的open
source 项目, 结果python 社区有人去看了看, 结论是: 这是 python 吗? 我怎么
不认识? 是 Java 吧 ?
XXX123 写道:
oldrev
就一个ECMA标准，还算不上ISO。什么 python, ruby, perl 之类的语言没有什么
劳什子标准化不也活得挺好，而且生命力相当旺盛。反而是有 ISO 标准的 C/C
++/Ada 之类进步缓慢，固步自封。
在 2007-10-13六的 21:50 +0800，Huafeng Mo写道：
> 想要在业界站稳脚跟，没有iso标准是不行的。即便java、C#这类厂商独霸的语
> 言也不得不标准化。标准化是一种法律保障，可以防止语言变成一群混乱的方
--
Regards,
- Oldrev
red...@gmail.com
的codebase 开放给他们已经有一段时间, 不过似乎是这个月, 才定好名份 :)
Andrei 主要配合弄编译器, Brad 搞 phobos, 以及 phobos 和 tango 的兼容,
d2.0 中才有兼容 ---- 说法是, 搞兼容要动 phobos 和 tango 的底层, 包括
object, gc 等, 如果对 1.0 也这样搞, 就失去了 1.0 是 stable 的含义了.
oldrev 写道:
red...@gmail.com
的, 没有副作用的 feature 进不去 D 里面吗 ?
Andrei 近年对并行计算很感兴趣, 这也是 D 2.0 正在努力的一个地方.
red...@gmail.com 写道:
oldrev
用开放的开源项目开发方式，比如release计划、milestone/roadmap、版本分支管
理等等，最好还成立一个D基金会 :)，应该就可以打消大家使用D的顾虑了。
在 2007-10-13六的 22:09 +0800，red...@gmail.com写道：
red...@gmail.com
例如我见过这样的代码:
一个函数, 要返回一个 char [], 最后的代码大致如下:
mov eax, -1c[ebp]
mov edx, -20[ebp]
push eax
push edx
pop edx
pop eax
ret
这不浪费时间吗?
不过即使这样的代码, 在 language shootout 的上的成绩也不错, 证明以后的前
途大大地.
oldrev 写道:
oldrev
在 2007-10-13六的 22:27 +0800，red...@gmail.com写道：
XXX123
挖人，当然，有了好的语言特征，也不一定红。但既没有好的语言特性，也没有大公司的支持，那就肯定要沦为玩具了。Ruby搞了这么多年，还不是要靠足以
体现语言力量的rails来翻身。再说，Java出道时正逢网络爆炸，也是靠C/C++在网络编程方面的薄弱（复杂与缺少标准库）来推广的，但现今各种
语言各分天下，相关库和衍生技术，工具已经发展得很完备了，要让业界抛弃已有的经验储备，技术储备转到没有大厂商支持的语言，没有革命性的语言特性，恐
怕很难。祈祷一下D赶紧借着多核的东风秀一下吧。
PS：我觉得D从C/C++中比较好捞人，从Java中捞人......很难说啊。90%写Java程序的人除了无休止的接口封装外的都用不着或者根本
不想去接触Java虚拟机以外的东西；在中国估计有一半以上的Java使用者已经认为Java是世界上最完美的语言了，他们正巴不得虚拟机CPU尽快投
入使用呢。
> > 好几年之后了。所以还是用D吧。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
oldrev
D要想火，还需要一个完善而稳定的编译器和开发工具链，最重要要的一点是有一个杀手级的应用。
在 2007-10-13六的 07:34 -0700，XXX123写道：
--
Regards,
- Oldrev
XXX123
但就算是在开源社区，好的语言特性与成功的产品也是互补的吧？杀手级的应用在松散的开发模式下需要专家与高手的参与，但要凭空吸引那些不追求KISS的
专家与高手，那还得靠语言本身的较量啊。语言设计得越优雅，越具有前瞻性，那吸引高手们的几率就越高，开发出杀手级应用的可能也越大。
On 10月14日, 上午10时54分, oldrev <old...@gmail.com> wrote:
> 这年头，有一股很大的势力是无法忽略的，那就是开源社区。一门好的语言就算没有大公司支持，只要能让开源社区接受就是成功的，Perl和Ruby没大公司支持不 也挺好？再说好的语言发展到最后自然会有大公司支持，如同 python 之于 google。
> - Oldrev- 隐藏被引用文字 -
>
> - 显示引用的文字 -
yq chen
pongba
oldrev
重载应该可以避免丑陋的 opAdd_r，还可以享受C++自由函数式重载的好处：
struct Currency
{
private int m_value;
public static Currency opAdd(Currency lhs, Currency rhs) {
return Currency(lhs.m_value + rhs.m_value);
}
}
在 2007-10-13六的 18:10 +0800，Huafeng Mo写道：
> 操作符重载和 traits：
> D已经有初步编译时反射了， 比如 __traits(allMember, T) 。
>
> 我是希望D能有更完善的compile time reflection，我很铁不成钢啊。
>
> 虽然 opAdd_r 很难看，但是 python 的更难看:)
> 一个不容易想到的副作用是采用函数签名的操作符重载对反射更加友
> 好，而且便于
> 手工调用。
> 这倒是个好处。
>
>
> 在 2007-10-13六的 17:01 +0800，Huafeng Mo写道：
> > 休息天显得无聊，闷得慌。找个题目，以便引发一场论战 :)：
> >
> http://blog.csdn.net/longshanks/archive/2007/10/13/1823298.aspx
> >
> > 来吧，都冲着我来，有仇的报仇，有冤的报冤，我准备好了。
> > 刀枪不入，刀枪不入，刀枪不入，... :-P
> >
> > --
> > 反者道之动，弱者道之用
> > >
> --
>
> Regards,
> - Oldrev
>
>
>
>
> --
> 反者道之动，弱者道之用
> >
Huafeng Mo
.Net的ECMA和ISO标准叫做CLI，是CLR框架的子集。C#也有ISO标准。唯独没有称为ISO的是C++/CLI，只有ECMA标准。因为英国人不答应。
包括D在内的这些新型语言，还没有经历很长的日子。在长达近20年的时间里，C++也没有ISO标准，但随着应用的扩大，标准化显得格外紧迫。请想象一下，如果全世界的米原器不止一个，而且长度都不一样，那世界会怎样？标准化有两个条件，其一，被广泛使用；其二，标准不统一会造成伤害。对于语言来讲，第二个条件是天生满足的，剩下的就看第一个了。
python等语言的应用较封闭，也较简单。一个业界事实标准基本也够用了。但象D这样试图替代C++的语言而言，没有标准，业界是不会答应的。
换句话说，标准化也标志着语言的应用广泛性和重要性。一旦应用广泛了，很多重要的应用都依赖于这门语言，那么没有标准，将会有很大的问题。比如，编译器厂商可以随意修改语言的特性和实现，造成大量代码的不兼容。这种损害对于整个业界是不可接受的。等D的应用遍布天下，编译器层出不穷的时候，就会知道标准化的重要了。
还是赶早的好。
--
反者道之动，弱者道之用
Huafeng Mo
哦对了, 有 Andrei 配合 Walter 设计 D 语言, 各位 C++ fans 还认为 C++ 中好
的, 没有副作用的 feature 进不去 D 里面吗 ?
Andrei在C++标准委员会很受排挤，还是在D这里能够发挥作用。只是，C++中似乎没有什么特性是不带副作用的吧。
Andrei 近年对并行计算很感兴趣, 这也是 D 2.0 正在努力的一个地方.
C++的一干牛人中，很多都对并行感兴趣。象Bjarne本人，sutter（他的blog里，一半文章和并发有关） 等等。但是，我觉得C++的标准委员会似乎是"被迫"对并发感兴趣的。
Huafeng Mo
这句话还是倒过来说得比较好：Java的成功在于有大公司不遗余力的支持，以及设计理念够简单和够先进。:)
我算是看着java长大的。最初java是干嘛用的？最初的java叫oak，打算用在顶置盒上，后来顶置盒没搞成，倒是有了一种跨平台语言。最初sun打出的旗号是用java搞瘦客户端，把pc应用搞到web上。这不就是冲着微软来的吗。然后几年，发现失算，搞不倒ms。花了那么大力气，东西都得有出路吧，就让它搞应用开发吧。太简单了？那还不容易，往上加特性呗。于是，java的宣传改了，靶子改成了C++了。...
我倒不是怎么讨厌java本身，python比Java简单多了，也还是很喜欢。我是不喜欢sun的两面三刀，指鹿为马。（一样的，我不喜欢ms，同样的原因）。
--
反者道之动，弱者道之用
yq chen
不过python这种前后有双下划线的风格是全局的，一点儿都不突兀。不知道D是否也是这样？希望各位大牛回答一下。
red...@gmail.com
有操作系统多, 自己的编译器才能够配合吧?
看现在, 不说专有操作系统, 连老牌unix 都难混了, 有dmd 和 gdc 在这里, 看起
来编译器不会是能够卖钱的样子, 我估计这个局势会缓和得多.
拿 java 看, 除了 MS 这个惯犯, 其他家搞的 java 实现和编译器, 似乎也没有什
么闻名的不兼容事件吧 ?
Huafeng Mo 写道:
> 70年代到80年代早期，开发C++编译器的，也就Bjarne他们。可没过几年，好几
> 家开发商都挤进来做编译器。当时拿 ARM和TCPPPL的第一版当成事实标准。但是
> 随着C++的发展，这种局面造成的伤害已经出现，结果被迫开始标准化。当时遗
> 留下来的问题，至今还在影响 C++，比如ABI问题。我们在说的不是一个偏安一
> 隅的D，而是全面使用的D。
> .Net的ECMA和ISO标准叫做CLI，是CLR框架的子集。C#也有ISO标准。唯独没有称
Huafeng Mo
C++标准化太晚，大量既成事实使得C++标准的很多方面以"实现定义"草草带过，于是便造成现有的混乱局面。D应该吸取教训，以免重蹈覆辙。
--
反者道之动，弱者道之用
red...@gmail.com
挣钱? 好像不行.
支持更多平台? gdc 已经可以了.
做个不兼容的东西出来打击竞争对手? 这里似乎没有哪个值得打击的厂家.
Huafeng Mo 写道:
> 因为java早已标准化了，甚至在多数编译器实现之前就已经标准化了。java 90
> 年代初出现，95年前后开始推广，2000年前就完成标准化了。正是标准化，才使
pongba
我觉得Java的成功在于设计理念够简单和够先进，以及有大公司不遗余力的支持。特别是后者是D所缺乏的。因此D的发展就要做坏的打算，要靠语言特征来
挖人，当然，有了好的语言特征，也不一定红。但既没有好的语言特性，也没有大公司的支持，那就肯定要沦为玩具了。Ruby搞了这么多年，还不是要靠足以
体现语言力量的rails来翻身。再说，Java出道时正逢网络爆炸，也是靠C/C++在网络编程方面的薄弱（复杂与缺少标准库）来推广的，但现今各种
语言各分天下，相关库和衍生技术，工具已经发展得很完备了，要让业界抛弃已有的经验储备，技术储备转到没有大厂商支持的语言，没有革命性的语言特性，恐
怕很难。祈祷一下D赶紧借着多核的东风秀一下吧。
PS：我觉得D从C/C++中比较好捞人，从Java中捞人......很难说啊。90%写Java程序的人除了无休止的接口封装外的都用不着或者根本
不想去接触Java虚拟机以外的东西；在中国估计有一半以上的Java使用者已经认为Java是世界上最完美的语言了，他们正巴不得虚拟机CPU尽快投
入使用呢。
BTW. Ruby红起来是因为Rails？似乎之前也已经红了吧？我怎么有一个印象说ruby红是因为纯粹的语言魅力呢？:)
pongba
XXX123
> --
> 反者道之动，弱者道之用
XXX123
兴趣去搞。可出了个rails后，一下引发了媒体爆炸，无数眼球聚焦，搞web的人估计都在想"嗯，啥玩意比俺现在用的还效率高啊，肯定是吹牛，偶是高
手，去瞅瞅，然后揭穿它！"，ruby本来就有足够的魅力从其他语言那儿挖到人，这下可好，用户爆炸式增长啊。