2008-04-03
一门天生就能损害人眼视力的语言->Erlang
关键字: erlang
一门天生就能损害人眼视力的语言->Erlang
受javaEye综合技术版的熏陶,受某位大牛:“Erlang下一个java语言“文章的蛊惑,
学起了函数式编程思想,学起了Erlang。
学习开始于“Getting Started With Erlang”,仅寥寥4小时就学完了,算是入了门,
当时的体会是:函数式编程也就这样,简单之极,搞来搞去都是list、tuple,函数传来传去、套来套去。
入门的顺利促使了进一步学习的冲动,但是越了解越是觉得在受罪。
Ok,憋了20多天啦,常常有想砸死Erlang(恶狼)的冲动。。。
我起初只是对Erlang语言本身及它的编译器实现感兴趣,
一切的不爽都来自于看Erlang语言编译器源码的过程:
故事从compiler/src目录开始,
用自个写的小程序纺计了compiler/src目录下的所有文件的行数,还不到4万行,哇!这么牛X。
找到了切入点:compile.erl
看到了如下代码:
眼睛第一次随着“->” “并发/并行“起来,
Ok,经过一阵拐弯抹角之后总算找到了词法分析的源文件stdlib/src/erl_scan.erl,
要是你看过上面的代码后眼睛还是立体的,试试下面:
好的,接着得转到语法分析啦,找啊找,找到了源头yecc(parsetools/src/yecc.erl)
这回想让你体会一下Erlang的List Comprehensions:
再快一点,跳到compiler/src/v3_core.erl超前体验一下为各类括号找配偶的“乐趣”
累了,先说这么多,有反对的,下回眼睛休息好了继续砸死Erlang(恶狼)
最后给个Erlang让人超级傻眼的例子(你认为输出是什么?):
受javaEye综合技术版的熏陶,受某位大牛:“Erlang下一个java语言“文章的蛊惑,
学起了函数式编程思想,学起了Erlang。
学习开始于“Getting Started With Erlang”,仅寥寥4小时就学完了,算是入了门,
当时的体会是:函数式编程也就这样,简单之极,搞来搞去都是list、tuple,函数传来传去、套来套去。
入门的顺利促使了进一步学习的冲动,但是越了解越是觉得在受罪。
Ok,憋了20多天啦,常常有想砸死Erlang(恶狼)的冲动。。。
我起初只是对Erlang语言本身及它的编译器实现感兴趣,
一切的不爽都来自于看Erlang语言编译器源码的过程:
故事从compiler/src目录开始,
用自个写的小程序纺计了compiler/src目录下的所有文件的行数,还不到4万行,哇!这么牛X。
找到了切入点:compile.erl
看到了如下代码:
expand_opt(basic_validation, Os) ->
[no_code_generation,to_pp,binary|Os];
expand_opt(strong_validation, Os) ->
[no_code_generation,to_kernel,binary|Os];
expand_opt(report, Os) ->
[report_errors,report_warnings|Os];
expand_opt(return, Os) ->
[return_errors,return_warnings|Os];
expand_opt(r10, Os) ->
[no_stack_trimming,no_topt,no_binaries,no_gc_bifs,no_constant_pool|Os];
expand_opt(r11, Os) ->
[no_stack_trimming,no_binaries,no_constant_pool|Os];
expand_opt({debug_info_key,_}=O, Os) ->
[encrypt_debug_info,O|Os];
expand_opt(no_binaries=O, Os) ->
%%Turn off the entire type optimization pass.
[no_topt,O|Os];
expand_opt(no_float_opt, Os) ->
%%Turn off the entire type optimization pass.
[no_topt|Os];
expand_opt(O, Os) -> [O|Os].
眼睛第一次随着“->” “并发/并行“起来,
Ok,经过一阵拐弯抹角之后总算找到了词法分析的源文件stdlib/src/erl_scan.erl,
要是你看过上面的代码后眼睛还是立体的,试试下面:
sub_scan_escape([O1,O2,O3|Cs], [Fun|Stack], Toks, Pos, State, Errors)
when O1 >= $0, O1 =< $7, O2 >= $0, O2 =< $7, O3 >= $0, O3 =< $7 ->
Val = (O1*8 + O2)*8 + O3 - 73*$0,
Fun([Val|Cs], Stack, Toks, Pos, State, Errors);
sub_scan_escape([O1,O2]=Cs, Stack, Toks, Pos, State, Errors)
when O1 >= $0, O1 =< $7, O2 >= $0, O2 =< $7 ->
more(Cs, Stack, Toks, Pos, State, Errors, fun sub_scan_escape/6);
sub_scan_escape([O1,O2|Cs], [Fun|Stack], Toks, Pos, State, Errors)
when O1 >= $0, O1 =< $7, O2 >= $0, O2 =< $7 ->
Val = (O1*8 + O2) - 9*$0,
Fun([Val|Cs], Stack, Toks, Pos, State, Errors);
sub_scan_escape([O1]=Cs, Stack, Toks, Pos, State, Errors)
when O1 >= $0, O1 =< $7 ->
more(Cs, Stack, Toks, Pos, State, Errors, fun sub_scan_escape/6);
sub_scan_escape([O1|Cs], [Fun|Stack], Toks, Pos, State, Errors)
when O1 >= $0, O1 =< $7 ->
Val = O1 - $0,
Fun([Val|Cs], Stack, Toks, Pos, State, Errors);
%% \^X -> CTL-X
sub_scan_escape([$^,C|Cs], [Fun|Stack], Toks, Pos, State, Errors) ->
Val = C band 31,
Fun([Val|Cs], Stack, Toks, Pos, State, Errors);
sub_scan_escape([$^]=Cs, Stack, Toks, Pos, State, Errors) ->
more(Cs, Stack, Toks, Pos, State, Errors, fun sub_scan_escape/6);
sub_scan_escape([$^|Eof], [Fun|Stack], Toks, Pos, State, Errors) ->
Fun(Eof, Stack, Toks, Pos, State, Errors);
%% \NL (backslash newline)
sub_scan_escape([$\n|Cs],[Fun|Stack], Toks, Pos, State, Errors) ->
Fun([nl|Cs], Stack, Toks, Pos, State, Errors);
%% \X - familiar escape sequences
sub_scan_escape([C|Cs], [Fun|Stack], Toks, Pos, State, Errors) ->
Val = escape_char(C),
Fun([Val|Cs], Stack, Toks, Pos, State, Errors);
%%
sub_scan_escape([], Stack, Toks, Pos, State, Errors) ->
more([], Stack, Toks, Pos, State, Errors, fun sub_scan_escape/6);
sub_scan_escape(Eof, [Fun|Stack], Toks, Pos, State, Errors) ->
Fun(Eof, Stack, Toks, Pos, State, Errors).
好的,接着得转到语法分析啦,找啊找,找到了源头yecc(parsetools/src/yecc.erl)
这回想让你体会一下Erlang的List Comprehensions:
find_user_code(ParseActions, St) ->
[#user_code{state = State,
terminal = Terminal,
funname = inlined_function_name(State, Terminal),
action = Action} ||
{State, La_actions} <- ParseActions,
{Action, Terminals, RuleNmbr, NmbrOfDaughters}
<- find_user_code2(La_actions),
case tokens(RuleNmbr, St) of
[{var, _, '__1'}] -> NmbrOfDaughters =/= 1;
_ -> true
end,
Terminal <- Terminals].
再快一点,跳到compiler/src/v3_core.erl超前体验一下为各类括号找配偶的“乐趣”
gexpr_test({atom,L,true}, Bools, St0) ->
{#c_literal{anno=lineno_anno(L, St0),val=true},[],Bools,St0};
gexpr_test({atom,L,false}, Bools, St0) ->
{#c_literal{anno=lineno_anno(L, St0),val=false},[],Bools,St0};
gexpr_test(E0, Bools0, St0) ->
{E1,Eps0,St1} = expr(E0, St0),
%% Generate "top-level" test and argument calls.
case E1 of
#icall{anno=Anno,module=#c_literal{val=erlang},name=#c_literal{val=N},args=As} ->
Ar = length(As),
case erl_internal:type_test(N, Ar) orelse
erl_internal:comp_op(N, Ar) of
true -> {E1,Eps0,Bools0,St1};
false ->
Lanno = Anno#a.anno,
{New,St2} = new_var(Lanno, St1),
Bools = [New|Bools0],
{#icall{anno=Anno, %Must have an #a{}
module=#c_literal{anno=Lanno,val=erlang},
name=#c_literal{anno=Lanno,val='=:='},
args=[New,#c_literal{anno=Lanno,val=true}]},
Eps0 ++ [#iset{anno=Anno,var=New,arg=E1}],Bools,St2}
end;
_ ->
Anno = get_ianno(E1),
Lanno = get_lineno_anno(E1),
case core_lib:is_simple(E1) of
true ->
Bools = [E1|Bools0],
{#icall{anno=Anno, %Must have an #a{}
module=#c_literal{anno=Lanno,val=erlang},
name=#c_literal{anno=Lanno,val='=:='},
args=[E1,#c_literal{anno=Lanno,val=true}]},Eps0,Bools,St1};
false ->
{New,St2} = new_var(Lanno, St1),
Bools = [New|Bools0],
{#icall{anno=Anno, %Must have an #a{}
module=#c_literal{anno=Lanno,val=erlang},
name=#c_literal{anno=Lanno,val='=:='},
args=[New,#c_literal{anno=Lanno,val=true}]},
Eps0 ++ [#iset{anno=Anno,var=New,arg=E1}],Bools,St2}
end
end.
累了,先说这么多,有反对的,下回眼睛休息好了继续砸死Erlang(恶狼)
最后给个Erlang让人超级傻眼的例子(你认为输出是什么?):
-module(record_test).
-export([test/0]).
-record(rec,{f1,f2}).
test()->
Rec2=#rec{f1=2,f2=3},
test2(Rec2),
io:fwrite("Rec2=~p ~n",[Rec2]),
F1=2,
F2=ets:new(rec_f2, [set]),
Rec3 = #rec{f1 =F1, f2=F2},
ets:insert(Rec3#rec.f2, {10}),
io:fwrite("Rec3#rec.f2=~p ~n",[ets:tab2list(Rec3#rec.f2)]),
test3(Rec3),
io:fwrite("Rec3#rec.f2=~p ~n",[ets:tab2list(Rec3#rec.f2)]),
io:fwrite("Rec3=~p ~n",[Rec3]).
test2(Rec)->
Rec#rec{f1=20,f2=30}.
test3(Rec)->
Rec#rec{f1=20,f2=ets:insert(Rec#rec.f2, {30})}.
评论
agile_boy
2008-04-21
coolmenu 写道
emacs 磨练一下还是不错的,我现在就用emacs写 erlang/scheme这些程序 ,erlware有个erlang的增强版的erlang-mode,挺好用的
emacs 的翻屏应该是 Ctl+v/Alt+v吧。
emacs用熟了,还是不错的。
Trustno1
2008-04-15
dcaoyuan 写道
Trustno1 写道
pi1ot 写道
这个scala关于并行的特性好像不明显
有Actor和Message Passing.但是基于Java Thread pool.
我觉得它有type interference不做STM是浪费了,而在JVM上搞Message passing又是吃力不讨好的事情.所以我觉得这个语言在并行/并发方面是搞错方向了.
Scala的Actor有两种实现,一种是每个Actor基于一个自己的thread,另一种是基于Events的与Erlang类似的自己管理的轻量Actor,后者可以支持成千上万个并行的Actors。
基于Thread的Actor是对JVM thread的良好封装,而基于Events的Actor则提供了很好的伸缩性,你可以按照自己的需要选取其中一种。
我的意思是,JVM这种VM架构本质上不适合Message Passing和Actor这种模型.所以Scala只能依靠Thread Pool+event driven来模拟Actor模型,使用event driven后果就是在concurrency上用户代码的执行会干预调度,更重要的事是无法将代码平滑的迁移到parallelism更不用说distribute.
我在另外一个帖子里也说过了,现在很多语言在面对multi-core的问题上都存在比较大的方向问题,把Concurrency和Parallelism等同起来.在multi-core上真正有意义的是Parallelism而不是concurrency.在Parallelism上,搞对方向是一个很重要的问题.这里的方向不仅仅是编程模型上是否方便解决问题,更重要的是底层的VM架构和上层语义上是否搞对方向.你选择什么样的VM,上层适用的语义模型会随之而改变,语义模型的改变直接就导致编程模型的改变,或者反过来说也正确你要选择什么样的编程模型你就要选择什么样的语义模型,什么样的语义模型就会会决定什么样的VM模型.比如说JVM或者CLR这种VM,上层的语义就天生应该选择static,strong并且支持type inference的类型系统,这样就可以像Haskell那样依靠编译器静态分析,支持STM+continuation.而你要选择Erlang那样的编程模型,那么你最好就应该选择dynamic type+FP,这样就可以使用支持hybrid Heap的VM.
而我之所以欣赏Erlang,并不是因为他是一个FP语言,而是它从上层的编程模型到语义模型到VM模型配合的严丝合缝,而在其他语言上很少有看到这一点,Haskell可以算另外一个,C#可以算半个.
所以Robbin在隔壁问我,那些动态语言在Parallelism上有希望.我说,在我看来除了Erlang之外,搞对方向的也就只有MS一家而已,C#现在俨然是半个Haskell了.而其他的语言在我看来这些语言要么是在先天不足的VM上架了一套完全不合适的编程模型(比如Ruby+reactor),要么是在一个正确的VM上做出了一错误的决定(比如Scala).
引用
Erlang这门语言在创建时受了Prolog的影响,第一个runtime好像还是在Prolog上写的。在语法上也受了Prolog的影响。Armstrong也承认Erlang的语法不那么modern,但是erlang的语义还是很有价值的,有劲的人把haskell的语法移植过来啊,编译成erlang instruction来跑。
如上所述,我觉得Haskell的那种non-strict语义并不适合Erlang VM.Haskell和Erlang是完全两种不同的方向.在Haskell上我觉得最大的亮点就是并行规约.
如果有空的话,可以看看这篇papaer,我觉得写得非常不错,可以特别关注一下2.2和2.3节,用Monadic+CPS的方式整合Thread model和Event Model.它可以依靠Haskell compiler把Monad语法包装的continuation分析成Thread调度器执行的system trace call tree.Thread首先会从Tree的入口开始遍历,当每次遍历一个节点就对该节点进行force 求值,如果节点所需要的事件达到那么Thread主动进入continuation drive指令代码,而这些非节点上的代码最大的特性就是可以在multi-core上进行并行规约,这种规约一直进行到下一个Event节点等待由lazy evaluation来等待未知的事件并且将当前的continuation移出Thread.当event到来的时候则可以有机会让event来主动把当前的continuation push到thread里继续往下执行.
这种模型需要完全建立在对Moand静态类型的分析上的.Monad类型把IO和computation完全分开了.System trace call tree的节点都是天然无法并行的IO代码,而除了这些节点之外的continuation则可以进行并行规约.也就是说这种模型把Task driven的并行模型转化成了Concurrency+Instruction driven Parallelism的并行模型.
FP提供并行规约,Monad提供静态分析,STM+CPS提供concurrency,这套东西无论从编程模型还是语义模型还是底层的VM,对Concurrncy和Parallelism来说,恐怕是我目前为止看到最漂亮的的最完美的整合.甚至Erlang的模型都无法与之相比,Erlang没有强类型系统,也就是导致了它无法自动decompose computation,当然并行规约我觉得还是可以做的.
至于在Scala Actor那种换汤不换药的空架子下,在接收到event以后程序员仍然要关心如何把代码切分成足够小的代码片,仍然要关心这些代码片是否能够真正调度到multi-core下进行并行处理.这也是我说Scala没有搞对方向的原因,一个强大的类型系统只是为了提供编程上的遍历而忽略对程序的静态分析可谓是舍本逐末,买椟还珠.至于Ruby,Python这些当红语言,dynamic的类型系统就当然就根本无法做到编译器静态分析了,而其本身是一个imperative语言,即无法进行并行规约,又享受不了Erlang VM那种模型带来的性能优势可谓是鸡肋,其未来的作用可能只是像APP Engine中那样的插件语言的形式存在.
bigpanda
2008-04-15
这个帖子居然有七页了。
Erlang这门语言在创建时受了Prolog的影响,第一个runtime好像还是在Prolog上写的。在语法上也受了Prolog的影响。Armstrong也承认Erlang的语法不那么modern,但是erlang的语义还是很有价值的,有劲的人把haskell的语法移植过来啊,编译成erlang instruction来跑。
Erlang这门语言在创建时受了Prolog的影响,第一个runtime好像还是在Prolog上写的。在语法上也受了Prolog的影响。Armstrong也承认Erlang的语法不那么modern,但是erlang的语义还是很有价值的,有劲的人把haskell的语法移植过来啊,编译成erlang instruction来跑。
JAVA_ED
2008-04-15
我觉得真正损害眼睛的是
几k行的macro define
上W行的C语言的数据字典dbdict 全是0x1f0d4c这种
那才真叫痛苦啊
几k行的macro define
上W行的C语言的数据字典dbdict 全是0x1f0d4c这种
那才真叫痛苦啊
dcaoyuan
2008-04-14
Trustno1 写道
pi1ot 写道
这个scala关于并行的特性好像不明显
有Actor和Message Passing.但是基于Java Thread pool.
我觉得它有type interference不做STM是浪费了,而在JVM上搞Message passing又是吃力不讨好的事情.所以我觉得这个语言在并行/并发方面是搞错方向了.
Scala的Actor有两种实现,一种是每个Actor基于一个自己的thread,另一种是基于Events的与Erlang类似的自己管理的轻量Actor,后者可以支持成千上万个并行的Actors。
基于Thread的Actor是对JVM thread的良好封装,而基于Events的Actor则提供了很好的伸缩性,你可以按照自己的需要选取其中一种。
myxex
2008-04-14
不说什么太高深的东西,如果只是看LZ给出的代码,还是比较容易看得懂的,逻辑相当清晰。PS:刚看了一个星期的erlang,之前没有接触过FP语言。
yatwql
2008-04-14
随便翻看了一下scala的文档,似乎只有Scala By Example的chapter17里头提及了一些concurrency的咚咚,讲得也不多,过几天有空再瞧瞧个详细.
toostupid
2008-04-14
我觉得函数式语言的代码的源码看不得,
看函数的定义就可以了,源码没办法去深究...
看函数的定义就可以了,源码没办法去深究...
Trustno1
2008-04-14
pi1ot 写道
这个scala关于并行的特性好像不明显
有Actor和Message Passing.但是基于Java Thread pool.
我觉得它有type interference不做STM是浪费了,而在JVM上搞Message passing又是吃力不讨好的事情.所以我觉得这个语言在并行/并发方面是搞错方向了.
pi1ot
2008-04-14
这个scala关于并行的特性好像不明显
Eastsun
2008-04-14
yatwql 写道
比较好奇dcaoyuan所谈的scala语言,为何会觉得比Ruby更有前途呢
相对Ruby,Scala有几个明显优点:
1.Scala是静态类型的,就是说很多bug在编译阶段就可以发现
2.Scala是编译为bytecode的,并且二进制与JAVA的class兼容
3.Scala的性能非常好,接近原生JAVA语言的效率(据说是Groovy的100多倍).
至于其它,Scala的语法简洁明了,并且是完全面向对象&支持函数式编程.
我刚接触Scala几天,除了上面说的外,最吸引我的是Scala有"JAVA的感觉".
这里有一篇文章为什么选择Scala?
yatwql
2008-04-14
比较好奇dcaoyuan所谈的scala语言,为何会觉得比Ruby更有前途呢
Trustno1
2008-04-13
dcaoyuan 写道
Trustno1 写道
引用
记得我说过,OO是粒子,FP是波,当然这是一种粗略的说法,但OO/FP之争其实是古老问题的延续,它可以追溯到赫拉克利特的“人不能两次踏进同一条河流”和芝诺的阿基里斯追龟说,飞箭静止说。
莫有那么夸张吧
呢各问题我想过很久,上面现在是我的观点。
我不知道你有没有看过别人打过麻将或者扑克.麻将手会为每一张坏牌寻找“原因”——而且让我佩服不已的是他们每次都能找到,尽管在我们这种无关的旁观者看来那完全是随机事件.
dcaoyuan
2008-04-13
Trustno1 写道
引用
记得我说过,OO是粒子,FP是波,当然这是一种粗略的说法,但OO/FP之争其实是古老问题的延续,它可以追溯到赫拉克利特的“人不能两次踏进同一条河流”和芝诺的阿基里斯追龟说,飞箭静止说。
莫有那么夸张吧
呢各问题我想过很久,上面现在是我的观点。
Trustno1
2008-04-13
引用
记得我说过,OO是粒子,FP是波,当然这是一种粗略的说法,但OO/FP之争其实是古老问题的延续,它可以追溯到赫拉克利特的“人不能两次踏进同一条河流”和芝诺的阿基里斯追龟说,飞箭静止说。
莫有那么夸张吧
dcaoyuan
2008-04-13
1、Erlang损害视力吗?
开始学一门语法风格不一样的语言时,这是一个习惯问题,就是说等你学了一段时间,眼睛开始习惯语言的范式后,就会象看你习惯的C/Java一样一目了然了。这跟我们刚开始学英文是一样的,如果你能一目十行看英文了,那些abc就不会损害视力了。
我个人的经验,一门新语言,最好学了、用了三个月后再做评价。
2、FP/OO
我一直觉得FP/OO是事物的统一的两个方面,离开了任何一面,对事物的描绘能力都不是完整的,记得我说过,OO是粒子,FP是波,当然这是一种粗略的说法,但OO/FP之争其实是古老问题的延续,它可以追溯到赫拉克利特的“人不能两次踏进同一条河流”和芝诺的阿基里斯追龟说,飞箭静止说。这里不想展开说,但文化传统中天生具备辩证能力的东方人比较不会说出要么FP、要么OO的极端的断语。
3、Erlang的并行/并发运算能力
Erlang在语言层面就考虑了并行/并发问题,从浅的层面说,就是任何具备/需要状态的运算粒度从一开始就可以包装成微进程并独立运行,进程间同步、通讯的主要手段是异步消息传递,这样可以大大简化并行/并发问题,代价是进程间的通讯没有直接调用的手段,性能方面会有影响,但通过合适地划分运算粒度,或者说,把问题分解成可以并行/不需要并行的部分,还是可以获得很好的性能。
说到底,任何一门语言都需要取舍、平衡,这是人描绘事物的能力有限、而事物本身的内涵无限这对本质矛盾的结果。多年前我有过一个结论:事物本身是完整、自恰的,但人看问题则必须辩证地看。
4、ErlyBird
首先,我今年41岁,论坛的朋友估计都可以叫我大叔。
ErlyBird下一个版本会完全重写,但我还是坚持实现一个自己的parser,而不是用Erlang自己的。索引性能会大大提高,整个感觉应该会比得上Ruby for NetBeans。不过我现在正在写Scala for NetBeans,Scala语法比Erlang复杂很多,IDE更难写,但我最近有了一些进展,为Scala也新写了一个Parser。语言的IDE支持最重要的一块是Parser,但各种语言的编译器不是为IDE所写的,所以通常不适合IDE使用(javac除外,新的javac是跟NetBeans开发团队一起弄的),自己写Parser的好处是现在我可以很快为任何一门语言实现IDE支持,因为越来越多代码可以重用。
5、Scala
顺便说一下Scala,Scala是OO/FP混合地较好的语言,我认为它比Ruby更有前途,也比Erlang会更大众,你可以这样看:
Scala = Java + Ruby + Erlang
但Scala的特性非常丰富,一上来会觉得不好下手,但你可以先从你熟悉的OO方式和Java语法入手,慢慢学习和掌握其他的特性。
开始学一门语法风格不一样的语言时,这是一个习惯问题,就是说等你学了一段时间,眼睛开始习惯语言的范式后,就会象看你习惯的C/Java一样一目了然了。这跟我们刚开始学英文是一样的,如果你能一目十行看英文了,那些abc就不会损害视力了。
我个人的经验,一门新语言,最好学了、用了三个月后再做评价。
2、FP/OO
我一直觉得FP/OO是事物的统一的两个方面,离开了任何一面,对事物的描绘能力都不是完整的,记得我说过,OO是粒子,FP是波,当然这是一种粗略的说法,但OO/FP之争其实是古老问题的延续,它可以追溯到赫拉克利特的“人不能两次踏进同一条河流”和芝诺的阿基里斯追龟说,飞箭静止说。这里不想展开说,但文化传统中天生具备辩证能力的东方人比较不会说出要么FP、要么OO的极端的断语。
3、Erlang的并行/并发运算能力
Erlang在语言层面就考虑了并行/并发问题,从浅的层面说,就是任何具备/需要状态的运算粒度从一开始就可以包装成微进程并独立运行,进程间同步、通讯的主要手段是异步消息传递,这样可以大大简化并行/并发问题,代价是进程间的通讯没有直接调用的手段,性能方面会有影响,但通过合适地划分运算粒度,或者说,把问题分解成可以并行/不需要并行的部分,还是可以获得很好的性能。
说到底,任何一门语言都需要取舍、平衡,这是人描绘事物的能力有限、而事物本身的内涵无限这对本质矛盾的结果。多年前我有过一个结论:事物本身是完整、自恰的,但人看问题则必须辩证地看。
4、ErlyBird
首先,我今年41岁,论坛的朋友估计都可以叫我大叔。
ErlyBird下一个版本会完全重写,但我还是坚持实现一个自己的parser,而不是用Erlang自己的。索引性能会大大提高,整个感觉应该会比得上Ruby for NetBeans。不过我现在正在写Scala for NetBeans,Scala语法比Erlang复杂很多,IDE更难写,但我最近有了一些进展,为Scala也新写了一个Parser。语言的IDE支持最重要的一块是Parser,但各种语言的编译器不是为IDE所写的,所以通常不适合IDE使用(javac除外,新的javac是跟NetBeans开发团队一起弄的),自己写Parser的好处是现在我可以很快为任何一门语言实现IDE支持,因为越来越多代码可以重用。
5、Scala
顺便说一下Scala,Scala是OO/FP混合地较好的语言,我认为它比Ruby更有前途,也比Erlang会更大众,你可以这样看:
Scala = Java + Ruby + Erlang
但Scala的特性非常丰富,一上来会觉得不好下手,但你可以先从你熟悉的OO方式和Java语法入手,慢慢学习和掌握其他的特性。
Trustno1
2008-04-09
Elminster 写道
FP 和并行快成了 T1 的尾巴踩不得了 ……
关键的是,软件方面除了这两个和算法之外,都无甚可研究了亚.软件工程?设计模式?这不都是trival的问题么?
Elminster 写道
老实说多核并行的前景虽然美好,但有一个大问题要先解决:在 PC 上,什么样的应用需要这么强大的计算能力?如果更强的计算能力只对搞服务器应用或者科学计算那堆人有价值,那么 FP 和并行只怕还会继续像今天一样阳春白雪下去。事实上,我自己的体会,多核目前最大的好处不在于单个程序能够跑多快,而是你可以同时在机器上跑多个不同的程序而不会打架争夺 CPU。后面这一项,不需要改变什么,我们就已经有了。
你把问题限制在desktop上,那当然没啥可说的.问题是现在desktop已经越来越没落了亚,这不就是你去狗狗山落草的一大缘由么?说起来,你那投名状找的怎么样了?
另外,我觉得你说的这个问题,倒是Java 7Fork/join和OpenMP这种Data Driven 并行所会面临的问题.
Elminster
2008-04-09
FP 和并行快成了 T1 的尾巴踩不得了 ……
老实说多核并行的前景虽然美好,但有一个大问题要先解决:在 PC 上,什么样的应用需要这么强大的计算能力?如果更强的计算能力只对搞服务器应用或者科学计算那堆人有价值,那么 FP 和并行只怕还会继续像今天一样阳春白雪下去。事实上,我自己的体会,多核目前最大的好处不在于单个程序能够跑多快,而是你可以同时在机器上跑多个不同的程序而不会打架争夺 CPU。后面这一项,不需要改变什么,我们就已经有了。
老实说多核并行的前景虽然美好,但有一个大问题要先解决:在 PC 上,什么样的应用需要这么强大的计算能力?如果更强的计算能力只对搞服务器应用或者科学计算那堆人有价值,那么 FP 和并行只怕还会继续像今天一样阳春白雪下去。事实上,我自己的体会,多核目前最大的好处不在于单个程序能够跑多快,而是你可以同时在机器上跑多个不同的程序而不会打架争夺 CPU。后面这一项,不需要改变什么,我们就已经有了。
femto
2008-04-09
潜力贴留名。
自言200801达达可以再发表一些看法,
我还是比较赞同你的观点的。
自言200801达达可以再发表一些看法,
我还是比较赞同你的观点的。
ray_linn
2008-04-08
Trustno1 写道
再转一篇Burton Smith on channel 9
这个人现在是Microsoft的technical fellow,原来是Cray(有谁还记得这个传奇般的公司?)的chief scientist他现在在Microsoft主要做parallel方面的工作。Channel 9的视频在这里:
http://channel9.msdn.com/Showpost.aspx?postid=382639
除了讲parallelism,最后还将了一些Microsoft杂七杂八的事情。在技术方面,我记录的东西如:
(1)随着hardware的发展,parallel programming goes mainstream。
(2)最开始,supercomputing是指IBM的mainframe(通用);后来发展成vector machine(专用),再后来使用distributed message passing(更专用)。今天,我们要研究的是general purpose的parallel programming,这也是Microsoft要解决的问题。
(3)80年代是研究general purpose的parallel programming的黄金年代,虽然没有什么成果,但是我们还是可以从他们那里学到一些的东西。
(4)与architecture相比,语言更重要。先有了新的语言,然后会有高效的运行这个语言的architecture出现。
(5)不能在现有的语言上小修小补,需要revolution,而且这个变化将永远改变我们的编程风格。。(双手双脚同意)
(6)共享变量很有用,加上需要对task做dyanmic load balance,share memory的architecture在很长的时间里,还是非常非常重要的。虽然,在这个环境下做prallel很危险,很麻烦。
(7)funtional language很好很强大,但是没有mutable state,很难使用。(双手双脚同意)
(8)transactional memory很好很强大,提供atomic/isolate。
(9)functional language+transcational memory将会无比好,无比强大,这位fellow认为这个应该发展的方向。(看来一坨坨的Haskell牛人都在MS插队落户了)
(10)应该使用high level programming language来做parallel,提高productivity,争取让每个人都可以做parallel programming
这个人现在是Microsoft的technical fellow,原来是Cray(有谁还记得这个传奇般的公司?)的chief scientist他现在在Microsoft主要做parallel方面的工作。Channel 9的视频在这里:
http://channel9.msdn.com/Showpost.aspx?postid=382639
除了讲parallelism,最后还将了一些Microsoft杂七杂八的事情。在技术方面,我记录的东西如:
(1)随着hardware的发展,parallel programming goes mainstream。
(2)最开始,supercomputing是指IBM的mainframe(通用);后来发展成vector machine(专用),再后来使用distributed message passing(更专用)。今天,我们要研究的是general purpose的parallel programming,这也是Microsoft要解决的问题。
(3)80年代是研究general purpose的parallel programming的黄金年代,虽然没有什么成果,但是我们还是可以从他们那里学到一些的东西。
(4)与architecture相比,语言更重要。先有了新的语言,然后会有高效的运行这个语言的architecture出现。
(5)不能在现有的语言上小修小补,需要revolution,而且这个变化将永远改变我们的编程风格。。(双手双脚同意)
(6)共享变量很有用,加上需要对task做dyanmic load balance,share memory的architecture在很长的时间里,还是非常非常重要的。虽然,在这个环境下做prallel很危险,很麻烦。
(7)funtional language很好很强大,但是没有mutable state,很难使用。(双手双脚同意)
(8)transactional memory很好很强大,提供atomic/isolate。
(9)functional language+transcational memory将会无比好,无比强大,这位fellow认为这个应该发展的方向。(看来一坨坨的Haskell牛人都在MS插队落户了)
(10)应该使用high level programming language来做parallel,提高productivity,争取让每个人都可以做parallel programming
PLINQ,我介绍过了
- 浏览: 1191 次
- 性别:

- 来自: 美丽的桂林

- 详细资料
搜索本博客
最近加入圈子
最新评论
-
一门天生就能损害人眼视力 ...
coolmenu 写道emacs 磨练一下还是不错的,我现在就用emacs写 e ...
-- by agile_boy -
某一电信软件系统的荒唐事 ...
移动投诉处理还是很严肃的,
-- by realreal2000 -
某一电信软件系统的荒唐事 ...
广西电信。 寒一个。。。 公司正在上广西全省的boss
-- by ma.bin -
一门天生就能损害人眼视力 ...
dcaoyuan 写道Trustno1 写道pi1ot 写道这个scala关于并 ...
-- by Trustno1 -
一门天生就能损害人眼视力 ...
这个帖子居然有七页了。 Erlang这门语言在创建时受了Prolog的影响,第 ...
-- by bigpanda






评论排行榜