haskell在生产环境的生产力到底如何？ - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

haskell在生产环境的生产力到底如何？

haskell在生产环境的生产力到底如何？# Programming - 葵花宝典

s*k2014-11-27 08:11

1 楼

用的6寸的方模儿~
额。。。先总结下失败的地方
第一，原方子是用的六寸圆模，而我使用6存方模，显然6寸方比6寸圆要大，所以蛋糕
会太矮，而且我的破烤箱有倾斜，导致受热不均，，哎。。。
第二，淋浆用的巧克力我用的72%的dark c 而原方子是普通dark~所以我的蛋糕表面最
后会变成脆的巧克力 = =。。这个还OK啦。。算另外一种风格了。。
第三，没有合适的东西盛放。。最后就用的盘子。。以至于最后蛋糕是翘翘的 = =。。
有点破坏造型。。不过还OK。。
第四，对蛋糕熟度掌握不够，有点烤过头了。
这个蛋糕我做了还蛮久的。因为只有手动打蛋器。。打发蛋白打到手软 = =。。。
不过还是挺享受的。。HOHO~~~
奔张丑照。。挺丑的。。呜呜。。

t*o2014-11-27 08:11

2 楼

我最近开time warner cable和AT&T family plan,他们用equifax查我的信用记录，都
没找到。不是我的信用记录有问题，而是他们通过网络查我记录，系统没法返回我的记
录。而接着我收到equifax给我的alert email说有一个inquiry. 吃了一个hard结果还
没查到记录。
我想打equifax客服问问是什么原因。
在他们官网上找了一个电话，打过去全是电脑留言，没法找到活人。
请大牛给一个电话，告诉我怎么才能找到活人？

f*y2014-11-27 08:11

3 楼

请教个问题。小孩公民，平时在国内。暑假过来上summer camp，大概70来天。买什么
保险才能免于obamacare的tax penalty。查了半天，好像市场上的short time
insurance不qualify。

m*u2014-11-27 08:11

4 楼

☆─────────────────────────────────────☆
justlilac (一只想做白骨精的猪) 于 (Sun Jan 11 02:42:23 2009) 提到:
要买的赶紧。。。我已经通知了少数陶粉。。。
☆─────────────────────────────────────☆
Miata (黑猫警长) 于 (Sun Jan 11 02:43:49 2009) 提到:
这个要顶
☆─────────────────────────────────────☆
hhbao (很黑很黑的白) 于 (Sun Jan 11 02:44:20 2009) 提到:
在168转了半天居然无视老干妈的飘过~~~
☆─────────────────────────────────────☆
venny (小茶*很财迷的点着伪币) 于 (Sun Jan 11 02:44:23 2009) 提到:
大伙儿给我留点儿，我还得拿回SD倒卖呢
☆─────────────────────────────────────☆
victor

j*32014-11-27 08:11

5 楼

很奇怪。

p*t2014-11-27 08:11

6 楼

发信人: aaaty (阿提 - Hardcore Flash Hater), 信区: Apple
标题: Re: 感叹购物版联想采购愈热，北美销量继续下跌
发信站: BBS 未名空间站 (Fri Feb 5 02:51:38 2010, 美东)
简单地说吧
最近苹果MBP降价，但是做工上，大家都觉得是更好了哦，这个unibody确实是做工感官
非凡。玻璃屏幕和trackpad也是档次的代表。你也知道高档餐馆用玻璃器皿较多，低端
餐馆用塑料较多吧，这个就是材质的第一感官档次就不同。
Lenovo也是降价了，也许降价幅度更多一些吧，就算，但是反应确实是做工变差，材料
变差，质量变差哦。

p*22014-11-27 08:11

7 楼

是很高还是一般？

p*62014-11-27 08:11

8 楼

zan

t*o2014-11-27 08:11

9 楼

ding a !!!

【在 t*******o 的大作中提到】

: 我最近开time warner cable和AT&T family plan,他们用equifax查我的信用记录，都
: 没找到。不是我的信用记录有问题，而是他们通过网络查我记录，系统没法返回我的记
: 录。而接着我收到equifax给我的alert email说有一个inquiry. 吃了一个hard结果还
: 没查到记录。
: 我想打equifax客服问问是什么原因。
: 在他们官网上找了一个电话，打过去全是电脑留言，没法找到活人。
: 请大牛给一个电话，告诉我怎么才能找到活人？

Y*e2014-11-27 08:11

10 楼

风水不好 :)

【在 j******3 的大作中提到】

: 很奇怪。

p*t2014-11-27 08:11

11 楼

我看名媛已经差不多了

【在 p****t 的大作中提到】

: 发信人: aaaty (阿提 - Hardcore Flash Hater), 信区: Apple
: 标题: Re: 感叹购物版联想采购愈热，北美销量继续下跌
: 发信站: BBS 未名空间站 (Fri Feb 5 02:51:38 2010, 美东)
: 简单地说吧
: 最近苹果MBP降价，但是做工上，大家都觉得是更好了哦，这个unibody确实是做工感官
: 非凡。玻璃屏幕和trackpad也是档次的代表。你也知道高档餐馆用玻璃器皿较多，低端
: 餐馆用塑料较多吧，这个就是材质的第一感官档次就不同。
: Lenovo也是降价了，也许降价幅度更多一些吧，就算，但是反应确实是做工变差，材料
: 变差，质量变差哦。

p*22014-11-27 08:11

12 楼

还有就是有好的rest framework吗

【在 p*****2 的大作中提到】

: 是很高还是一般？

y*k2014-11-27 08:11

13 楼

脆的巧克力皮很赞的

t*o2014-11-27 08:11

14 楼

请教达人

【在 t*******o 的大作中提到】

: ding a !!!

j*32014-11-27 08:11

15 楼

两次了，希望没第三次。

【在 Y****e 的大作中提到】

: 风水不好 :)

n*y2014-11-27 08:11

16 楼

这个人脑子没问题吧，可悲啊

d*e2014-11-27 08:11

17 楼

yeosd, wrap, snap

【在 p*****2 的大作中提到】

: 还有就是有好的rest framework吗

p*o2014-11-27 08:11

18 楼

zan!蛋糕做的总失败的我真是羡慕你哈！

A*e2014-11-27 08:11

19 楼

没啥，放啊放的就习惯了。

【在 j******3 的大作中提到】

: 很奇怪。

c*72014-11-27 08:11

20 楼

现在我有点不敢看他的发言，让我莫名地起腻，一阵阵犯恶......

【在 p****t 的大作中提到】

p*22014-11-27 08:11

21 楼

貌似scotty更好？

【在 d******e 的大作中提到】

: yeosd, wrap, snap

s*k2014-11-27 08:11

22 楼

额。。。话说这是我第一次做蛋糕。。
觉得还有很多地方做的不到位~~~~
今儿一会儿再做个别的试试

k*n2014-11-27 08:11

23 楼

这个到底是男果轮还是女果轮？
文字不男不女的

【在 p****t 的大作中提到】

w*p2014-11-27 08:11

24 楼

i wrote something to parse logs and then do something else, the log files is
less than 10k lines and it's slow like hell, optimized compiled code is way
slower than Perl. Not to mention that "functional" statement doesn't look
easier to read than perl.
I know that I'm hit by its lazy evaluation, and I tried to use foldr or
foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
quickly. This is quite bad compared to my experience with Standard ML, which
produced code much faster than perl, and was what I have expected for
compiled code.

c*h2014-11-27 08:11

25 楼

可见名媛是为了装作有在高档餐馆用餐的感觉。。。

【在 p****t 的大作中提到】

d*e2014-11-27 08:11

26 楼

Haskell‘s default string implemention is linked list. it is extremely slow.

is
way
which

【在 w******p 的大作中提到】

: i wrote something to parse logs and then do something else, the log files is
: less than 10k lines and it's slow like hell, optimized compiled code is way
: slower than Perl. Not to mention that "functional" statement doesn't look
: easier to read than perl.
: I know that I'm hit by its lazy evaluation, and I tried to use foldr or
: foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
: quickly. This is quite bad compared to my experience with Standard ML, which
: produced code much faster than perl, and was what I have expected for
: compiled code.

d*e2014-11-27 08:11

27 楼

没用过。二爷可以试试？

【在 p*****2 的大作中提到】

: 貌似scotty更好？

w*p2014-11-27 08:11

28 楼

In Standard ML I also treat them as linked list, using explode/implode,
still much faster.
Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
t use lazy eval at all.

slow.

【在 d******e 的大作中提到】

: Haskell‘s default string implemention is linked list. it is extremely slow.
:
: is
: way
: which

w*g2014-11-27 08:11

29 楼

lazy eval是为了写所谓漂亮的functional代码引入的伪问题。
lazy eval起作用的前提就是写了实际上不会被运行到的代码。
imperative programming里面很少有写了不用的代码。

don'

【在 w******p 的大作中提到】

: In Standard ML I also treat them as linked list, using explode/implode,
: still much faster.
: Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
: t use lazy eval at all.
:
: slow.

w*p2014-11-27 08:11

30 楼

I think lazy eval is okay, but it shouldn't be the default, whoever want to
have lazy eval just do their own thunks, and with any language that supports
pointer/reference.
By making it the default really confuses people about performance, and
invents problem that wasn't there before.
However, lazy eval seems essential for Haskell because it wants to be "pure"
, in that the function parameter evaluation orders doesn't matter for
deterministic calculations, and at the same time save duplicated evaluations
like calculation "a+b" twice in square(a+b) => (a+b) * (a+b), therefore
making a pointer/thunk for "a+b" calculation and don't do it unless needed.
Yes, Haskell is "powerful" because of this, it can implement cool things
like if_then_else with short circuits with a function -- that other
languages like lisp/ml/java/c/etc cannot do -- they all have to eval all
args before calling a function and therefore cannot short circuit. But in
the end, how useful is lazy eval other showing off with cool tricks?

a*e2014-11-27 08:11

31 楼

我最喜欢这类问题了，你方便贴一下代码么？

is
way
which

【在 w******p 的大作中提到】

a*e2014-11-27 08:11

32 楼

lazy vs strict 这个问题，基本的 facts 都总结在这两个文章里面：
http://existentialtype.wordpress.com/2011/04/24/the-real-point-
第一篇是 Bob Harper 写的，学过 SML 的应该都知道他吧，估计没有人比他更痛恨
Haskell 了，呵呵。文章讲到的都很有道理，没讲到的我觉得应该是故意略过了。所以
要看第二篇。
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evalu
第二篇是 Lennart Augustsson 写的，早期 Haskell 的重要功臣之一，他在 Standard
Chartered 写的内部用的 mu haskell 是 strict by default。他这个文章讲了几点
laziness 的好处，就算是 Harper 也不好反驳。

don'

【在 w******p 的大作中提到】

w*p2014-11-27 08:11

33 楼

sure here's the code, i want to get a map from the log lines, with the 2nd
or 3rd record as key. You see that I try to make it quicker by only getting
first 30 chars of each line because I know that the keys cannot be too long,
and I filter out empty lines and short lines with less than 50 words. In
practice the `isInfixOf` filtering did speed up the parsing by about 1x or
2x.
parseLog candidates = readFile "records" >>= buf ->
return $ foldl' (accu -> x->
let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in (x!!1,v):(x!!2,v):accu
) [] $ filter (x->length x>50) $ map words $ filter (line->
any (c->((' ':c)++" ") `isInfixOf` (take 30 line)
) candidates
) $ lines buf
above code is much harder to read and much slower than perl's simple
(split)[1,2,29,27,32,33,49]

【在 a*****e 的大作中提到】

: 我最喜欢这类问题了，你方便贴一下代码么？
:
: is
: way
: which

a*e2014-11-27 08:11

34 楼

你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情，以下是 Haskell
程序：
main = parse >>= mapM_ (putStrLn . show)
parse = readFile "records" >>= return . concat . map (takeOut . words) .
lines
where
takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in [(x!!1,v), (x!!2,v)]
以下是 Perl 程序：
my $filename = "records";
open (my $fh, $filename)
or die ("could not open file '$filename'");
while (my $row = ) {
my @x = (split(/ /, $row))[1,2,29,27,32,33,49];
print "($x[1], @x)\n";
print "($x[2], @x)\n";
}
基本上做的是同一件事情。我用 100K 行输入，perl 2秒，haskell 4秒。
考虑到 Haskell 用的是 default String，这个 performance not too shabby.
如果用 ByteString，就和 perl 速度一样。而且 Haskell 里面 !! 还是在用 linked
list 而 Perl 里面取下标是数组。
而且无论你用什么语言，想要优化，总是有空间。
我的意思是，上面那个 Haskell 程序效率方面完全可以接受，一行程序也不难读。

getting
long,

【在 w******p 的大作中提到】

: sure here's the code, i want to get a map from the log lines, with the 2nd
: or 3rd record as key. You see that I try to make it quicker by only getting
: first 30 chars of each line because I know that the keys cannot be too long,
: and I filter out empty lines and short lines with less than 50 words. In
: practice the `isInfixOf` filtering did speed up the parsing by about 1x or
: 2x.
: parseLog candidates = readFile "records" >>= buf ->
: return $ foldl' (accu -> x->
: let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in (x!!1,v):(x!!2,v):accu

w*p2014-11-27 08:11

35 楼

your input is definitely different than mine, my log lines are all very long
, thousands of chars each line.
with Perl I don't need to do the filtering to check if the search candidates
are within the first 30 chars, with Haskell I have to make code much more
lengthy and harder to read to try to be on par with Perl.
同样的事情 for me is to get my result as soon as could be operating on my
long log-line files, perl one line vs. Haskell multi-line ugliness I had to
do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
力, be it coding speed or code execution speed.
with SML I don't need to do that ugly filtering and it's faster than perl.
make no mistake I like Haskell because it broadens one's horizon.
One more bad thing about Haskell though: its code must be formatted with
proper indentation, like Python but much worse than Python, Python's is much
simpler rule, Haskell's is much more unpredictable. Whenever I just do a
simple thing like changing a function name to be longer, the indentation
breaks and I had to adjust every freaking lines in the function manually! If
Python indentation annoys people, Haskell's is just pure pure evil. With
Emacs I can simply press tab to make Python indentation right, I tried 3
Emacs haskell plugins, none can make it right all the time.

Haskell

【在 a*****e 的大作中提到】

: 你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情，以下是 Haskell
: 程序：
: main = parse >>= mapM_ (putStrLn . show)
: parse = readFile "records" >>= return . concat . map (takeOut . words) .
: lines
: where
: takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in [(x!!1,v), (x!!2,v)]
: 以下是 Perl 程序：
: my $filename = "records";

a*e2014-11-27 08:11

36 楼

重点在于要用 ByteString，而不是你那个 30 字符 prefix match 的优化（而且吧，
你那个优化其实效率很差，因为你还在用 list）。你不能指望 linked list 和 Perl
或者 SML 的 array based String 一个效率。
至于缩进，我觉得你还是没理解它的设计要素，我从来没有遇到过你说的手工改动多行
的情况。如果实在不喜欢，可以直接用 { 和 } 和 ; 然后就和写 C 一样了，完全不需
要理会缩进规则。GHC 编译器里面有不少代码都是这种格式写的，也没什么啊

long
candidates
to

【在 w******p 的大作中提到】

: your input is definitely different than mine, my log lines are all very long
: , thousands of chars each line.
: with Perl I don't need to do the filtering to check if the search candidates
: are within the first 30 chars, with Haskell I have to make code much more
: lengthy and harder to read to try to be on par with Perl.
: 同样的事情 for me is to get my result as soon as could be operating on my
: long log-line files, perl one line vs. Haskell multi-line ugliness I had to
: do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
: 力, be it coding speed or code execution speed.
: with SML I don't need to do that ugly filtering and it's faster than perl.

w*p2014-11-27 08:11

37 楼

ByteString 好像不好用啊，读zip文件得用Data.ByteString.Lazy，但是用的是GHC.
Word.Word8,跟Char转换挺费劲的，我需要一个统一的interface既能读一般文件，又能
读zip文件，Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容，看来
haskell是kill time利器啊

a*e2014-11-27 08:11

38 楼

绝对的 kill time 利器 :-)
ByteString.Lazy 和 ByteString.Lazy.Char8 怎么会不兼容呢，后者是为前者提供向
Char 转化的工具（直接 truncate），但是操作的结果和对象可都是 ByteString.Lazy
啊。所以你用 Codec.Archive.Zip 读写的 ByteString.Lazy.ByteString 类型的值，
直接用 ByteString.Lazy.Char8 里面的函数操作即可。
不过说实在话，我不知道你为什么喜欢用 Char，直接用 Word8 并没有很不方便。
尤其是 String literal 可以直接使用 {-# LANGUAGE OverloadedStrings #-}
如果你说的是 ByteString 和 [Char] 之间转换，只需要用到 ByteStirng.Lazy.Char8
.pack 和 unpack 两个函数，其它不需要考虑。如果你需要 UTF8 编码转换，用 utf8-
string 这个库。

【在 w******p 的大作中提到】

: ByteString 好像不好用啊，读zip文件得用Data.ByteString.Lazy，但是用的是GHC.
: Word.Word8,跟Char转换挺费劲的，我需要一个统一的interface既能读一般文件，又能
: 读zip文件，Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容，看来
: haskell是kill time利器啊

w*p2014-11-27 08:11

39 楼

谢谢高手解答，不过我得去看看别的啥透透气去，过几天再来看haskell吧，想提高提
高效率这么多trick