t****a
发帖数: 1212 | 1 这是Knuth在84年提出的编程方式。
http://en.wikipedia.org/wiki/Literate_programming#Further_readi
我是个data scientist, 坚持这种编程方式已经有3年了。我使用过的literature
programming语言中包有R, python, lisp, clojure, sql, graphviz等。现在在使用的
literature programming tool是emacs org-mode+babel。自我感觉，这种方式刚开始
很难上手，习惯了以后，大大提高了我的工作效率。
这确实是一种很少人使用的技术。
有哪位朋友愿意讨论讨论经验，心得么？ |
g*****g
发帖数: 34805 | 2 IMHO, the quality of code is determined by test coverage, not documentation.
It's an interesting idea but I doubt it's efficient.
【在 t****a 的大作中提到】
: 这是Knuth在84年提出的编程方式。
: http://en.wikipedia.org/wiki/Literate_programming#Further_readi
: 我是个data scientist, 坚持这种编程方式已经有3年了。我使用过的literature
: programming语言中包有R, python, lisp, clojure, sql, graphviz等。现在在使用的
: literature programming tool是emacs org-mode+babel。自我感觉，这种方式刚开始
: 很难上手，习惯了以后，大大提高了我的工作效率。
: 这确实是一种很少人使用的技术。
: 有哪位朋友愿意讨论讨论经验，心得么？
|
t****a
发帖数: 1212 | 3 呵呵，大牛果然对这个话题有兴趣:)
我完全同意你说的test对code的重要性。通过test是以事实证明程序的质量。
我也能理解很多朋友对这种方法的质疑。毕竟它从提出开始有30年了，目前为止没有大
规模应用。可是我们知道很多学术概念到应用之间会相隔很久。比如OO的概念是60年代
就提出的。80年代C++出现之后才开始逐渐开始大规模应用。
Literature Programming (LP)的过程，就我的体会，更象是设计的过程，而且把设计
贯穿了整个编程序的始终。它强迫我在写程序之前仔细思考描述程序的逻辑，在整个项
目中的地位等。
在网上我看到了很多对LP的质疑，其中一种质疑是，程序并不是论文，不能够按照文章
的形式来组织程序逻辑。这里就问了一个很好的问题：程序究竟是以什么形式组织的？
文章又是以什么形式组织的？两者有相似之处么？
在我看来，两者都采用的是数据结构中的LIST(散列表)形式来组织。论文分为章，节，
小节，段落；程序也可以分为不同的逻辑分块，每个逻辑分块又分为各个小块，上层的
逻辑分块调用下层的逻辑小块，其中也存在交叉调用，就好像一篇论文内部的交叉引用
。从这个意义上说，LP的过程是自顶向下的设计过程。
支持我的论点的，经典的例子就是java里包的树状结构。
事实上，LP并不反对test case。我认为test就应该算作整个LP中的一个重要的章节:)
LP的优点，是它可以使用包括语言在内的各种方式来帮助／强迫程序设计师在code前进
行设计。同时生成高质量的文档，对于维护程序非常有价值。有些朋友觉得javadoc就
是个很好的LP工具，可在我看来，它不强迫先设计后写的过程，同时生成的文档又有诸
多限制（比如它只能支持文字），因此不能算作LP工具。
目前LP的局限之处是缺乏足够的工具来帮助程序员高效率的做LP。我曾尝试过一些不同
的工具，最后感觉emacs中的org-mode和org-babel配合一些自己写的emacs lisp宏对我
很合适。
Knuth有一本关于LP的书，我才刚刚开了个头，里面我相信会看到他的非常有价值的建
议。
非常欢迎各位朋友来讨论这个问题，我们相互提高。
documentation.
【在 g*****g 的大作中提到】
: IMHO, the quality of code is determined by test coverage, not documentation.
: It's an interesting idea but I doubt it's efficient.
|
t****a
发帖数: 1212 | |
r*g
发帖数: 3159 | 5 你写程序是自己算东西作报告用还是做产品用？
做工程做产品的，对这个不感兴趣吧。
【在 t****a 的大作中提到】
: 呵呵，大牛果然对这个话题有兴趣:)
: 我完全同意你说的test对code的重要性。通过test是以事实证明程序的质量。
: 我也能理解很多朋友对这种方法的质疑。毕竟它从提出开始有30年了，目前为止没有大
: 规模应用。可是我们知道很多学术概念到应用之间会相隔很久。比如OO的概念是60年代
: 就提出的。80年代C++出现之后才开始逐渐开始大规模应用。
: Literature Programming (LP)的过程，就我的体会，更象是设计的过程，而且把设计
: 贯穿了整个编程序的始终。它强迫我在写程序之前仔细思考描述程序的逻辑，在整个项
: 目中的地位等。
: 在网上我看到了很多对LP的质疑，其中一种质疑是，程序并不是论文，不能够按照文章
: 的形式来组织程序逻辑。这里就问了一个很好的问题：程序究竟是以什么形式组织的？
|
t****a
发帖数: 1212 | 6 做工程做产品的 -> 对这个不感兴趣吧。
不好意思，我没看懂。请问你的逻辑是？
【在 r*g 的大作中提到】
: 你写程序是自己算东西作报告用还是做产品用？
: 做工程做产品的，对这个不感兴趣吧。
|
X****r
发帖数: 3557 | 7 改变足够数量的程序员的编程习惯很不容易，就象一个势垒。我不觉得它有足够的动能
冲过这个势垒。
比如说我是一个程序员，我看到这种编程方式，但除非我能说服我们整个项目切换到这
种新的编程方式，否则我就不可能应用它。然而，没有实际的项目实例/数据支持，光
靠“我觉得”是无法论证切换所带来的好处会大于包括所有人花时间去学习适应新的编
程方式在内的开销的。
要打破这个循环，这种新的编程方式不仅要被足够多的人知道，也要给使用者足够的利
益来吸引新的使用者，这就是动能。而相应的势垒，就是一个普通程序员需要多大的努
力来理解接受这种编程方式。在我看来，literate programming 的势垒很高而动能不
足，多半是永远也不会成为主流的编程方式之一了。虽然它本身的确很有意思。
【在 t****a 的大作中提到】
: 这是Knuth在84年提出的编程方式。
: http://en.wikipedia.org/wiki/Literate_programming#Further_readi
: 我是个data scientist, 坚持这种编程方式已经有3年了。我使用过的literature
: programming语言中包有R, python, lisp, clojure, sql, graphviz等。现在在使用的
: literature programming tool是emacs org-mode+babel。自我感觉，这种方式刚开始
: 很难上手，习惯了以后，大大提高了我的工作效率。
: 这确实是一种很少人使用的技术。
: 有哪位朋友愿意讨论讨论经验，心得么？
|
m********5
发帖数: 17667 | 8 习惯是王道，改变习惯的成本相对于带来的好处太高=>实际工程中没有意义
同样的例子有Make,本身设计有大量缺陷，但是用的人很多，太广泛，新的替代太多，
无法形成一个大家都喜欢的替代者；结果就是大家还是用Make...
【在 t****a 的大作中提到】
: 做工程做产品的 -> 对这个不感兴趣吧。
: 不好意思，我没看懂。请问你的逻辑是？
|
m********5
发帖数: 17667 | 9 关键还是优势不明显
实际好处很少
【在 X****r 的大作中提到】
: 改变足够数量的程序员的编程习惯很不容易，就象一个势垒。我不觉得它有足够的动能
: 冲过这个势垒。
: 比如说我是一个程序员，我看到这种编程方式，但除非我能说服我们整个项目切换到这
: 种新的编程方式，否则我就不可能应用它。然而，没有实际的项目实例/数据支持，光
: 靠“我觉得”是无法论证切换所带来的好处会大于包括所有人花时间去学习适应新的编
: 程方式在内的开销的。
: 要打破这个循环，这种新的编程方式不仅要被足够多的人知道，也要给使用者足够的利
: 益来吸引新的使用者，这就是动能。而相应的势垒，就是一个普通程序员需要多大的努
: 力来理解接受这种编程方式。在我看来，literate programming 的势垒很高而动能不
: 足，多半是永远也不会成为主流的编程方式之一了。虽然它本身的确很有意思。
|
t****a
发帖数: 1212 | 10 说的很有道理...在一个团队中，除非大家都会这样并且支持才能够推行。
我是独立工作的，所以才得到了自由去探索尝试。
至于好坏，只能说我的经验告诉我它对我很有价值，而且价值很大。我不知道它是否适
合其他程序员。只有等待时间来说话了。
【在 X****r 的大作中提到】
: 改变足够数量的程序员的编程习惯很不容易，就象一个势垒。我不觉得它有足够的动能
: 冲过这个势垒。
: 比如说我是一个程序员，我看到这种编程方式，但除非我能说服我们整个项目切换到这
: 种新的编程方式，否则我就不可能应用它。然而，没有实际的项目实例/数据支持，光
: 靠“我觉得”是无法论证切换所带来的好处会大于包括所有人花时间去学习适应新的编
: 程方式在内的开销的。
: 要打破这个循环，这种新的编程方式不仅要被足够多的人知道，也要给使用者足够的利
: 益来吸引新的使用者，这就是动能。而相应的势垒，就是一个普通程序员需要多大的努
: 力来理解接受这种编程方式。在我看来，literate programming 的势垒很高而动能不
: 足，多半是永远也不会成为主流的编程方式之一了。虽然它本身的确很有意思。
|
|
|
t****a
发帖数: 1212 | 11 我觉得make挺好的... 真的。可能因为我用的不多。能告诉我他的主要设计缺陷在哪里
么？
【在 m********5 的大作中提到】
: 习惯是王道，改变习惯的成本相对于带来的好处太高=>实际工程中没有意义
: 同样的例子有Make,本身设计有大量缺陷，但是用的人很多，太广泛，新的替代太多，
: 无法形成一个大家都喜欢的替代者；结果就是大家还是用Make...
|
m********5
发帖数: 17667 | 12 搜 What’s Wrong With GNU make?
同样的例子其实屡见不鲜的
比如以前硬件中大家喜欢用很 buggy的老芯片，其实主要是因为各种bug大家都清楚，
有很多code都专门为bug做了patch, 要换新的片子反而可能造成工程进度推后。
【在 t****a 的大作中提到】
: 我觉得make挺好的... 真的。可能因为我用的不多。能告诉我他的主要设计缺陷在哪里
: 么？
|
g*****g
发帖数: 34805 | 13 Check how Ant/Ivy and Maven work and you'll get how Make is flawed.
In fact, I've seen many C++ teams using Ant to replace Make.
【在 t****a 的大作中提到】
: 我觉得make挺好的... 真的。可能因为我用的不多。能告诉我他的主要设计缺陷在哪里
: 么？
|
t****a
发帖数: 1212 | 14 大概大家不喜欢make的数据结构... plan text是没有list简洁...
不过我也不自己写make的，太费力气了，通常都是用script造出一个make file来。
【在 g*****g 的大作中提到】
: Check how Ant/Ivy and Maven work and you'll get how Make is flawed.
: In fact, I've seen many C++ teams using Ant to replace Make.
|
d**********x
发帖数: 4083 | 15 恩
现在makefile基本都用脚本生成了
我在想以后生成makefile的脚本会不会再用脚本生成。。。
【在 t****a 的大作中提到】
: 大概大家不喜欢make的数据结构... plan text是没有list简洁...
: 不过我也不自己写make的，太费力气了，通常都是用script造出一个make file来。
|
g*****g
发帖数: 34805 | 16 Dependency management, cross-platform Independence, continuous integration
among others, which may or may not be important for the project.
Structured data lead to abstraction and tools. Like Jenkins and tons of
plugins that do things like test coverage, static code analysis to find
potential bugs.
【在 d**********x 的大作中提到】
: 恩
: 现在makefile基本都用脚本生成了
: 我在想以后生成makefile的脚本会不会再用脚本生成。。。
|
m********5
发帖数: 17667 | 17 我们组现在都用cmake
但是注意了，各个组之间还是没法通用，感觉有几个组就有几个build tools在用,通用
的还是只有出来的makefile
【在 t****a 的大作中提到】
: 大概大家不喜欢make的数据结构... plan text是没有list简洁...
: 不过我也不自己写make的，太费力气了，通常都是用script造出一个make file来。
|
