主题：【原创】编程心得 -- 荆棘探兴

技术变化快，而理论变化缓慢。编程语言细节及一些库函数使用印成书比较浪费。

而是......你大概没有读原代码的痛苦历程，在没有设计书情况下，读历代前辈来自不同国家的程序员们留下源代码的时候......古怪的用法层出不穷

这东西所带来的价值抵不上它所引起的复杂度。

候捷翻译的也可以

就是当处理

for (...) {

s = s + s0;

}

连续内存搬迁的效率问题

题目没写清楚，完全可以写出一段实际运行很差的但是符合出题要求的代码。最好出题时注明一下不用考虑。否则一个有能力的程序员会很难受。

而不是等着别人提要求。你愿意和一个不长脑子，推一下走一步的人共事吗？

我在另一篇文章里提出了参考答案，有兴趣的话可以对照一下看看我们各有什么不足：

http://www.ccthere.com/article/1693075

Haskell 语言，纯函数式编程。

我98年买到一本影印的C 语言，好像是清华出的，20多块钱。第一本读完的英文书。

最早接触是小学在图书馆看的 Basic ， 然后就是 C, Pascal, C++, VB 都作为课外兴趣在看。

后来沉迷过一段时间的Java ， 直到看到Python和Lisp 之后。现在是专职的Python程序员。在linux服务端下，一个好处是可以接触各种脚本，也有机会涉猎些非主流的东西。这里隆重推荐两个我眼中最美的语言：

1. 纯FP 的 Haskell

2. 纯OO 的 Smalltalk ， Smalltalk 因为 Seaside 框架而老树开新花了（如同 RoR 推热了Ruby一样）

这个主要还是学习方法问题。

平时都可以看到有些人，学起东西来就是比别人快，为啥人家能那么快呢？

很简单，人家知道自己在干什么，有什么需求，人家学一个东西不是先找教科书，而是先看看自己需要什么，然后到工具箱里面找找看那些适合自己需求，找到了之后，再根据自己需求琢磨工具的使用方式，有哪些独特之处。这个过程充满了探索的乐趣，把学习这个痛苦的过程演变成了有趣的探险，事情就容易多、有效多了。

从需求的高度来看工具，工具的方方面面一览无遗。

而从工具的角度来看需求，则是管中窥豹，看一眼是一眼。

所以，学一门语言，先看其语言来源于何种需求，对这种需求如何满足，而不是先看其hello world的写法。

可是，搞数值计算，为何用java？这也太低效了吧。

明显错误是没看到，做题目没问题，但是不实用。

1.你把string分成char, uchar16, uchar32之后，做是好做了，用就不好用了。实际应该在string内部统一，考虑效率，用utf8是个好办法

2.你的string没有留buffer,也没有内存对齐，如果实际有很多append(ch),内存拷贝效率很低。书上说就算一次append一行的话，搬350k文件实际要实际搬50G。

实际的串类我倒真写过，头文件10k,源90k，整100k，花了整1个星期。