g****t
发帖数: 31659 | 1 这几天一直在考虑python的working flow for my own usage。
本版问了很多问题，也问了很多同事。再次感谢之前参与讨论和
回答问题的各位朋友。我的目的是赚产值，利润。
那么现在总结一下。分享给大家。欢迎批评指正。
勿上封面，主页,头条。本贴已转去侦探版保存。
先说结论：
--------------------------------------------------------------
反正现在我的结论就是要两套代码。一套Jupyter或者knitr/Rmarkdown
生成。一套按把前面的代码修改补充，封装，重新安排组织，
用sublime做。
--------------------------------------------------------------
1.
我个人认为，这一两年来，python/R的崛起是因为jupyter notebook和
R markdown等等类似的tool。很多场合下，太好用了。对编程倒没什么，
主要是宣传利器。
2.
我开始不知道literate programming这个概念。
因为我有Mathematica的经验，所以理解jupyter的坑。Jupyter最大的问题是
不同的cell可以以不同的顺序evaluation。那这很容易跑乱。XYZ三段代码，
你按照ZYX执行，那就是不同的程序了。而且没办法版本管理。
我当初Mathematica写毕业论文，就老出这个问题。
最后我的解决办法就是永远只是顺序执行cell。
那么这时候我意识到，我其实只需要一个支持好的格式的heavily注释的工具
就行了。既然你永远都是顺序执行cell。那就等于代码加注释。最多多写一些
plt.plot(xxx), print(xxx)插入中间结果。
然后查到了Docco, org-mode, ....等等这些工具。
这些工具可以混排 丰富的注释-程序-程序的结果。
最后发现这就是克努奇的literate programming。
可以说从Mathematica和Jupyter, Rmarkdown的思考，
我自行发现了这个系统的哲学和其中的道理。
3.
有了这个基础，我可以进不一思考。
克努奇的literate programming也对也不对。
我自己分析了以下对我自己的价值和原理。
a.市面上大多数的literate programming不支持程序块的顺序重排。
Rmarkdown不行。但是Mathematica, Jupyter可以对程序块改变次序执行。
leo可以。其他的不行。
b.literate programming按克努奇的说法是，instead of 教电脑
干什么，说明为什么人让电脑干什么。这样甚至可以取代unit test。
我不这么看。我认为这个文档和code,code的结果混排的好处在于容易
卖东西。
有的算法容易用code的片段，以及片段的结果来解释，有的算法容易用
文字来解释。这就要求混合起来的可执行。
我个人观点：
literate programming = 天生的销售员利器。
4.
那么回到coding。现在就有一个矛盾。
按照
(A)销售逻辑或者slides 逻辑，也就是人类的装B逻辑来组织代码，
(B)还是按照电脑语言的实现逻辑，性能逻辑来组织代码？
这两者是互动的。因为你选一个A和B之间的trade off。
那么为了解释这个trade off,这又是一个逻辑，然后你就进入了AA,AB,ABA,...
这个问题literate programming没有解决。
有人说literate programming是有害的。其实说的很对。因为有的程序是
60ms定生死的。或者逻辑差一点，后面会引起严重的维护困难和后果。
对这个问题，我也没有答案，也没找到tool。现在这方面的讨论都是各执一端。
那么我换个脑子想一下。既然不能一次性解决问题。那不如找个中间点。
所以现在认为的最好的答案就是：
写两套代码，
(A)一套是literate programming的。
(B)一套是从literate programming里面自己tangle出来的，可以高效
被电脑执行的代码。
我希望达到这样的目的，A,B所需的工作量可能是只写一套的1.2倍。
但是这20% 的额外功夫是完全值得的。且不说对代码质量的提高，
只说销售，花20% 的时间弄销售或者内部communication是很便宜的。
酒香也怕巷子深。要让老印服气，首先要理解老印的智力...
------
反正现在我的结论就是要两套代码。一套Jupyter或者knitr/Rmarkdown
生成。一套按把前面的代码修改补充，封装，重新安排组织，
用sublime做。
------
<回头有空再补充资料链接，以及其他研究> |
w********m
发帖数: 1137 | |
w***g
发帖数: 5958 | 3 楼主应该是scientist.
【在 w********m 的大作中提到】
: 你是data scientist吧
|
w*****g
发帖数: 16352 | 4 data scientist才有逼格！
★ 发自iPhone App: ChineseWeb 13
【在 w***g 的大作中提到】
: 楼主应该是scientist.
|
g****t
发帖数: 31659 | 5 你俩啥关系？
【在 w*****g 的大作中提到】
: data scientist才有逼格！
:
: ★ 发自iPhone App: ChineseWeb 13
|
n******7
发帖数: 12463 | 6 我也在关心类似的问题，先mark
Rmarkdown/ipython notebook确实有用，展示利器 |
g****t
发帖数: 31659 | 7 忽悠利器！
【在 n******7 的大作中提到】
: 我也在关心类似的问题，先mark
: Rmarkdown/ipython notebook确实有用，展示利器
|
l******n
发帖数: 9344 | 8 作demo, poc的首选，特别是配合R的library,做些简单的interactive的visualization
，卖相很不错
【在 g****t 的大作中提到】
: 忽悠利器！
|
e*******o
发帖数: 4654 | 9 主要是能搞成网页 js空前发展
甩其它gui 一大截
【在 n******7 的大作中提到】
: 我也在关心类似的问题，先mark
: Rmarkdown/ipython notebook确实有用，展示利器
|
e****t
发帖数: 17914 | |
|
|
g****t
发帖数: 31659 | 11 我个人的结论是：
literate programming不能完成任务。不管什么tool都一样。
只能是做两个版本。一个是literate programming的，面向人的。
一个是面向机器的。
当然，大牛是可以一个版本完成任务的。
然而我认为，单独做一个literate programming的版本在很多情况下
是划算的。本身多数产品的功夫其实是在卖。
【在 e****t 的大作中提到】
: Emacs org-mode啊
|
g****t
发帖数: 31659 | 12 I saved some useful quotes from HN here:
My previous employer (a subdivision of a global top ten defence company)
used literate programming.
The project I worked on was a decade-long piece for a consortium of defence
departments from various countries. We wrote in objective-C, targeting
Windows and Linux. All code was written in a noweb-style markup, such that a
top level of a code section would look something like this:
<>
<>
and so on, and each of those variously break out into smaller chunks
<>
<>
<>
<>
The layout of the chunks often ended up matching functions in the source
code and other such code constructs, but that wasn't by design; the
intention of the chunks was to tell a sensible story of design for the human
to understand. Some groups of chunks would get commentary, discussing at a
high level the design that they were meeting.
Ultimately, the actual code of a bottom-level chunk would be written with
accompanying text commentary. Commentary, though, not like the kind of
comments you put inside the code. These were sections of proper prose going
above each chunk (at the bottom level, chunks were pretty small and modular)
. They would be more a discussion of the purpose of this section of the code
, with some design (and sometimes diagrams) bundled with it. When the text
was munged, a beautiful pdf document containing all the code and all the
commentary laid out in a sensible order was created for humans to read, and
the source code was also created for the compiler to eat. The only time
anyone looked directly at the source code was to check that the munging was
working properly, and when debugging; there was no point working directly on
a source code file, of course, because the next time you munged the
literate text the source code would be newly written from that.
It worked. It worked well. But it demanded discipline. Code reviews were
essential (and mandatory), but every code review was thus as much a design
review as a code review, and the text and diagrams were being reviewed as
much as the design; it wasn't enough to just write good code - the text had
to make it easy for someone fresh to it to understand the design and layout
of the code.
The chunks helped a lot. If you had a chunk you'd called <
hardware>>, that's all you'd put in it. There was no sneaking not-quite-
relevant code in. The top-level design was easy to see in how the chunks
were laid out. If you found that you couldn't quite fit what was needed into
something, the design needed revisiting.
It forced us to keep things clean, modular and simple. It meant doing
everything took longer the first time, but at the point of actually writing
the code, the coder had a really good picture of exactly what it had to do
and exactly where it fitted in to the grander scheme. There was little
revisiting or rewriting, and usually the first version written was the last
version written. It also made debugging a lot easier.
Over the four years I was working there, we made a number of deliveries to
the customers for testing and integration, and as I recall they never found
a single bug (which is not to say it was bug free, but they never did
anything with it that we hadn't planned for and tested). The testing was
likewise very solid and very thorough (tests were rightly based on the
requirements and the interfaces as designed), but I like to think that the
literate programming style enforced a high quality of code (and it certainly
meant that the code did meet the design, which did meet the requirements).
Of course, we did have the massive advantage that the requirements were set
clearly, in advance, and if they changed it was slowly and with plenty of
warning. If you've not worked with requirements like that, you might be
surprised just how solid you can make the code when you know before touching
the keyboard for the first time exactly what the finished product is meant
to do.
Why don't I see it elsewhere? I suspect lots of people have simply never
considered coding in a literate style - never knew it existed.
If forces a change to how a lot of people code. Big design, up front. Many
projects, especially small projects (by which I mean less than a year from
initial ideas to having something in the hands of customers) in which the
final product simply isn't known in advance (and thus any design is expected
to change, a lot, quickly) are probably not suited - the extra drag
literate programming would put on it would lengthen the time of iterative
periods.
It required a lot of discipline, at lots of levels. It goes against the
still popular narrative of some genius coder banging out something as fast
as he can think it. Every change beyond the trivial has to be reviewed, and
reviewed properly. All our reviews were done on the printed PDFs, marked up
with pen. Front sheets stapled to them, listing code comments which the
coder either dealt with or, in discussion, they agreed with the reviewer
that the comment would be withdrawn. A really good days' work might be a
half-dozen code reviews for some other coders, and touching your own
keyboard only to print out the PDFs. Programmers who gathered a reputation
for doing really good thorough reviews with good comments and the ability to
critique people's code without offending anyone's precious sensibilities (
we've all met them; people who seem to lose their sense of objectivity
completely when it comes to their own code) were in demand, and it was a
valued and recognised skill (being an ace at code reviews should be
something we all want to put on our CVs, but I suspect a lot of employers
basically never see it there) - I have definitely worked in some places in
which, if a coder isn't typing, they're seen as not working, so management
would have to be properly on board. I don't think literate programming is
incompatible with the original agile manifesto, but I think it wouldn't
survive in what that seems to have turned into.
【在 g****t 的大作中提到】
: 我个人的结论是：
: literate programming不能完成任务。不管什么tool都一样。
: 只能是做两个版本。一个是literate programming的，面向人的。
: 一个是面向机器的。
: 当然，大牛是可以一个版本完成任务的。
: 然而我认为，单独做一个literate programming的版本在很多情况下
: 是划算的。本身多数产品的功夫其实是在卖。
|
g****t
发帖数: 31659 | 13 大半年过去了。实践结果给大家汇报下。
这个文学编程的理论还是很靠谱的。
没有什么害处，没有坑，不洗脑，无毒。
既然Rstudio，Jupyter notebook越来越流行。
文学编程现在也算一个社会潮流。如果是研究性
质的软件，非常合适。
但是切记用emacs，vi。
Rstudio，Jupyter notebook一来功能不行，二来肯定
会放毒的。
我现在写这些研究性质的代码。就是一张纸铺开，
最底下version 1，然后改来改去，往上面填别的试错。
这样每次打开文件，第一行是最新的版本。
我觉得喜欢灌水的老同志们，一般文学和编程都挺擅长。
可以一试。
【在 g****t 的大作中提到】
: 这几天一直在考虑python的working flow for my own usage。
: 本版问了很多问题，也问了很多同事。再次感谢之前参与讨论和
: 回答问题的各位朋友。我的目的是赚产值，利润。
: 那么现在总结一下。分享给大家。欢迎批评指正。
: 勿上封面，主页,头条。本贴已转去侦探版保存。
: 先说结论：
: --------------------------------------------------------------
: 反正现在我的结论就是要两套代码。一套Jupyter或者knitr/Rmarkdown
: 生成。一套按把前面的代码修改补充，封装，重新安排组织，
: 用sublime做。
|
c******n
发帖数: 16666 | 14 哎。。兴致勃勃看了这么多正要大干一场
然后
----
但是切记用emacs，vi。
----
没IDE我这么懒的人没法活啊
【在 g****t 的大作中提到】
: 大半年过去了。实践结果给大家汇报下。
: 这个文学编程的理论还是很靠谱的。
: 没有什么害处，没有坑，不洗脑，无毒。
: 既然Rstudio，Jupyter notebook越来越流行。
: 文学编程现在也算一个社会潮流。如果是研究性
: 质的软件，非常合适。
: 但是切记用emacs，vi。
: Rstudio，Jupyter notebook一来功能不行，二来肯定
: 会放毒的。
: 我现在写这些研究性质的代码。就是一张纸铺开，
|
g****t
发帖数: 31659 | 15 锁定不强的IDE应该也还可以。公平的讲，
Rstudio，jupyter notebook现在还是挺健康的。
如果不使用超过一年.另外你是前端专家，自己改改jupyter notebook应该也行。
【在 c******n 的大作中提到】
: 哎。。兴致勃勃看了这么多正要大干一场
: 然后
: ----
: 但是切记用emacs，vi。
: ----
: 没IDE我这么懒的人没法活啊
|
c******n
发帖数: 16666 | 16 真不是专家
这个notebook看上去不错啊 而且iterate programming这个感觉和我现在一个自动生成
newsletter的小项目思路很吻合啊。。
我们这转行的星宿派 没有点学术基础就是容易自己瞎造轮子
我得好好研究这个
【在 g****t 的大作中提到】
: 锁定不强的IDE应该也还可以。公平的讲，
: Rstudio，jupyter notebook现在还是挺健康的。
: 如果不使用超过一年.另外你是前端专家，自己改改jupyter notebook应该也行。
|
d******c
发帖数: 2407 | 17 1. 我个人非常喜欢interactive programming,用惯了R，再回到java, python，各种别
扭。能够在当前环境下查看每个对象，进行各种操作，这样能尽量测试和保证我的code
达到我想要的结果。如果是个编译语言，需要写一大段然后执行，然后看输出结果，想
看中间数据除非debug或者各种打印，但都不如直接停在中间状态交互执行。
2. jupyter notebook特别适合于展示，也有交互性，但在编程本身上作为IDE还是差了
很多。其基本设计局限也多，没法版本控制。最近试了一次还让我输入token，大为扫
兴。
3. RStudio现在有notebook mode，很接近jupyter notebook的inline显示效果，而且
能够版本控制。
RMarkdown的chunk可以随便调整顺序执行啊。另外你可以在RMarkdown里写notes，最后
批量执行可以把代码提取出来存成脚本。
我现在各种R code都是先在RMarkdown里写，有大量的notes，注释，reference，不同
的chunk放不同功能或者版本，成熟之后提取出来。RMarkdown哪怕就是给自己看也很方
便，比在注释里写notes强太多了。 |
g****t
发帖数: 31659 | 18 我现在是Emacs org-mode加其他coding mode,
逢山开路，遇水搭桥，自造tool。
传统debug可以快速看到函数内包起来的中间变量x的值，
断点的值等等。但是看不到x vs running index的图。就是说
Debug信息的可视化不支持。to my best knowledge,我也不知道哪家的debug支持可视
化调试信息。
Notebook调试非常不方便。函数包装起来的变量看不到。
所以我自己造了个tool.起一个新的python专门可视化的看
调试信息。缺点是原来的python和这个调试的python 是用
文本文件交换信息的,速度不行。但对我帮助还是挺大的。下一步我计划改进本体
python和调试python之间别的交换信息办法。
: 1. 我个人非常喜欢interactive programming,用惯了R，再回到java,
python，
各种别
: 扭。能够在当前环境下查看每个对象，进行各种操作，这样能尽量测试和
保证我
的code
: 达到我想要的结果。如果是个编译语言，需要写一大段然后执行，然后看
输出结
果，想
: 看中间数据除非debug或者各种打印，但都不如直接停在中间状态交互执
行。
: 2. jupyter notebook特别适合于展示，也有交互性，但在编程本身上作
为IDE还
是差了
: 很多。其基本设计局限也多，没法版本控制。最近试了一次还让我输入
token，
大为扫
: 兴。
: 3. RStudio现在有notebook mode，很接近jupyter notebook的inline显
示效果
，而且
: 能够版本控制。
: RMarkdown的chunk可以随便调整顺序执行啊。另外你可以在RMarkdown里
写notes
，最后
【在 d******c 的大作中提到】
: 1. 我个人非常喜欢interactive programming,用惯了R，再回到java, python，各种别
: 扭。能够在当前环境下查看每个对象，进行各种操作，这样能尽量测试和保证我的code
: 达到我想要的结果。如果是个编译语言，需要写一大段然后执行，然后看输出结果，想
: 看中间数据除非debug或者各种打印，但都不如直接停在中间状态交互执行。
: 2. jupyter notebook特别适合于展示，也有交互性，但在编程本身上作为IDE还是差了
: 很多。其基本设计局限也多，没法版本控制。最近试了一次还让我输入token，大为扫
: 兴。
: 3. RStudio现在有notebook mode，很接近jupyter notebook的inline显示效果，而且
: 能够版本控制。
: RMarkdown的chunk可以随便调整顺序执行啊。另外你可以在RMarkdown里写notes，最后
|
g****t
发帖数: 31659 | 19 另外我不换顺序执行代码块。因为那样一旦出错很难调试。我原来写过很多
Mathematica,教训深重。
如果有时间我会写个emacs tool, log下代码块执行顺序。
不然不会考虑换执行顺序。
另外我不搞版本控制。我自己写了个tool,一键存当前文件到备份目录，并且把文件名
改为带有当前时间的文件名。
所有的修改痕迹都会保留下来。目前为止还不错。
: 我现在是Emacs org-mode加其他coding mode,
: 逢山开路，遇水搭桥，自造tool。
: 传统debug可以快速看到函数内包起来的中间变量x的值，
: 断点等等。但是看不到x vs running index的图。就是说
: Debug信息的可视化不支持。to my best knowledge,我也不知道哪家的debug支
持可视
: 化调试信息。
: Notebook调试非常不方便。函数包装起来的变量看不到。
: 所以我自己造了个tool.起一个新的python专门可视化的看
: 调试信息。缺点是原来的python和这个调试的python 是用
: Log文本文件交换信息的,速度不行。但对我帮助还是挺大的。下一步我计划改进
本体
【在 g****t 的大作中提到】
: 我现在是Emacs org-mode加其他coding mode,
: 逢山开路，遇水搭桥，自造tool。
: 传统debug可以快速看到函数内包起来的中间变量x的值，
: 断点的值等等。但是看不到x vs running index的图。就是说
: Debug信息的可视化不支持。to my best knowledge,我也不知道哪家的debug支持可视
: 化调试信息。
: Notebook调试非常不方便。函数包装起来的变量看不到。
: 所以我自己造了个tool.起一个新的python专门可视化的看
: 调试信息。缺点是原来的python和这个调试的python 是用
: 文本文件交换信息的,速度不行。但对我帮助还是挺大的。下一步我计划改进本体
|
w********m
发帖数: 1137 | |
|
|
g****t
发帖数: 31659 | 21 克努奇有文章。
Literate programming
: 比较弱，看了半天没看懂你们要干什么
【在 w********m 的大作中提到】
: 比较弱，看了半天没看懂你们要干什么
|
p****o
发帖数: 1340 | 22 我也试图用jupyter，但是没有发现它有什么特别的地方。而且觉得这种方法和我的思
维方式格格不入，所以也就转回去继续用我的vim。就像你说的，执行顺序，和版本的
问题根本没法控制。
但是你推荐用emacs或者vi来做literate programming，你可以具体说说你的想法吗？
【在 g****t 的大作中提到】
: 大半年过去了。实践结果给大家汇报下。
: 这个文学编程的理论还是很靠谱的。
: 没有什么害处，没有坑，不洗脑，无毒。
: 既然Rstudio，Jupyter notebook越来越流行。
: 文学编程现在也算一个社会潮流。如果是研究性
: 质的软件，非常合适。
: 但是切记用emacs，vi。
: Rstudio，Jupyter notebook一来功能不行，二来肯定
: 会放毒的。
: 我现在写这些研究性质的代码。就是一张纸铺开，
|
g****t
发帖数: 31659 | 23 我现在算法相关的程序还是两个literature programming
文件。
一个是最后的executable document,
是给别人看HTML 单个文件，图base64放进去，
这样手机Email方便看。
这个要修美观。最开始我以为interactive提是必要的，
写了好多plotly的wrapper。后来发现不是专家
没人有功夫缩放你的图。所以就是静态图。
一个是自己不断的trial and error.做研究定算法。
我开一个org mode文件，从version 1开始，
然后一层层改上去，最高处会是version 100
改各种算法变种。
中间会记录自己的想法，实现效果，
成败如何。
有一个table of contents.
我有个一键备份文件和时间戳的Elise.
在一个org-mode文件里，我会用不同语言
不同程序间有时候用org 变量传数据。有时候用
Windows clipboard
现在我编程项目的组织模型是一张纸，
上面写有自然语言，和几种不同编程语言。
记录不同的想法和效果。我很少跳转出去。
全屏幕都是白的，以及一点语法高亮。
Emacs lisp可以选中两个数字坐标定下来的region,
进行读写操作，还可以变成不可见的。这几个基本的原
子操作足够自动生成很多code.
用编辑器的程序自动写常用的程序段，这点对效率
帮助很大。研究阶段无需考虑往更高层封装这类reuse。
: 我也试图用jupyter，但是没有发现它有什么特别的地方。而且觉得这种方法和
我的思
: 维方式格格不入，所以也就转回去继续用我的vim。就像你说的，执行顺序，和
版本的
: 问题根本没法控制。
: 但是你推荐用emacs或者vi来做literate programming，你可以具体说说你的想
法吗？
【在 p****o 的大作中提到】
: 我也试图用jupyter，但是没有发现它有什么特别的地方。而且觉得这种方法和我的思
: 维方式格格不入，所以也就转回去继续用我的vim。就像你说的，执行顺序，和版本的
: 问题根本没法控制。
: 但是你推荐用emacs或者vi来做literate programming，你可以具体说说你的想法吗？
|
p****o
发帖数: 1340 | 24 谢谢！看来你的方法和我平时做的很不一样。让我慢慢思考思考，实验一下再来问问题。
【在 g****t 的大作中提到】
: 我现在算法相关的程序还是两个literature programming
: 文件。
: 一个是最后的executable document,
: 是给别人看HTML 单个文件，图base64放进去，
: 这样手机Email方便看。
: 这个要修美观。最开始我以为interactive提是必要的，
: 写了好多plotly的wrapper。后来发现不是专家
: 没人有功夫缩放你的图。所以就是静态图。
: 一个是自己不断的trial and error.做研究定算法。
: 我开一个org mode文件，从version 1开始，
|
c******r
发帖数: 512 | 25 谢谢好文。 有用knime的吗？ 有经验的给讲讲？
: 谢谢！看来你的方法和我平时做的很不一样。让我慢慢思考思考，实验一下再来
问问题。
【在 p****o 的大作中提到】
: 谢谢！看来你的方法和我平时做的很不一样。让我慢慢思考思考，实验一下再来问问题。
|
c*******v
发帖数: 2599 | 26 knime你说的是这个吗？
https://www.knime.org/blog/to-code-or-not-to-code-is-that-the-question
我看了下这就是抄simulink啊。每个方块里面都是无状态的。
思路是靠谱的既然Simulink成熟很久了。
simulink我的经验：
和for－loop C转换是挺麻烦的。调试不是很方便。
【在 c******r 的大作中提到】
: 谢谢好文。 有用knime的吗？ 有经验的给讲讲？
:
:
: 谢谢！看来你的方法和我平时做的很不一样。让我慢慢思考思考，实验一下再来
: 问问题。
:
|
c******r
发帖数: 512 | 27 knime基本就是个data science workflow system。 虽然可以写loop， 基本不靠谱。
价值在于现在各种工具太多， manual都读不过来。 knime把几乎所有工具集成到一个
IDE， 想用那个click， default 参数就好了， 跑起来再调。share给同事也方便。
: knime你说的是这个吗？
: https://www.knime.org/blog/to-code-or-not-to-code-is-that-the-question
: 我看了下这就是抄simulink啊。每个方块里面都是无状态的。
: 思路是靠谱的既然Simulink成熟很久了。
: simulink我的经验：
: 和for－loop C转换是挺麻烦的。调试不是很方便。
【在 c*******v 的大作中提到】
: knime你说的是这个吗？
: https://www.knime.org/blog/to-code-or-not-to-code-is-that-the-question
: 我看了下这就是抄simulink啊。每个方块里面都是无状态的。
: 思路是靠谱的既然Simulink成熟很久了。
: simulink我的经验：
: 和for－loop C转换是挺麻烦的。调试不是很方便。
|
c*******v
发帖数: 2599 | 28 Knime不知道
Simulink图形语言改成c在汽车上实现我写过。
非常麻烦。
FP如果要decouple成for loop是很困难的手艺活。
: knime基本就是个data science workflow system。 虽然可以写loop， 基本
不靠谱。
: 价值在于现在各种工具太多， manual都读不过来。 knime把几乎所有工具集成
到一个
: IDE， 想用那个click， default 参数就好了， 跑起来再调。share给同事也方
便。
【在 c******r 的大作中提到】
: knime基本就是个data science workflow system。 虽然可以写loop， 基本不靠谱。
: 价值在于现在各种工具太多， manual都读不过来。 knime把几乎所有工具集成到一个
: IDE， 想用那个click， default 参数就好了， 跑起来再调。share给同事也方便。
:
:
: knime你说的是这个吗？
:
: https://www.knime.org/blog/to-code-or-not-to-code-is-that-the-question
:
: 我看了下这就是抄simulink啊。每个方块里面都是无状态的。
:
: 思路是靠谱的既然Simulink成熟很久了。
:
: simulink我的经验：
:
: 和for－loop C转换是挺麻烦的。调试不是很方便。
|
c******r
发帖数: 512 | 29 knime workflow node， 大概相当于code chunk，很粗。 到了loop这种， 就应该是
在每个node里面用Java， Python之类的写了。
前面有人提了， Jupyter是demo利器， 不过真用， 一旦流程不是线性的， 很坑。
knime提供一个可视的dag.
: Knime不知道
: Simulink图形语言改成c在汽车上实现我写过。
: 非常麻烦。
: FP如果要decouple成for loop是很困难的手艺活。
: 不靠谱。
: 到一个
: 便。
【在 c*******v 的大作中提到】
: Knime不知道
: Simulink图形语言改成c在汽车上实现我写过。
: 非常麻烦。
: FP如果要decouple成for loop是很困难的手艺活。
:
:
: knime基本就是个data science workflow system。 虽然可以写loop， 基本
: 不靠谱。
:
: 价值在于现在各种工具太多， manual都读不过来。 knime把几乎所有工具集成
: 到一个
:
: IDE， 想用那个click， default 参数就好了， 跑起来再调。share给同事也方
|
g****t
发帖数: 31659 | |
|
|
m******r
发帖数: 1033 | |
m******r
发帖数: 1033 | |
g****t
发帖数: 31659 | 33 Literature programming之实践证据。有三本有一定实用性的书。
1. lcc compiler, david Hanson
2. http://www.pbr-book.org/
3. c interface, David Hanson
可见，此法可以写比较大的项目。
【在 g****t 的大作中提到】
: 这几天一直在考虑python的working flow for my own usage。
: 本版问了很多问题，也问了很多同事。再次感谢之前参与讨论和
: 回答问题的各位朋友。我的目的是赚产值，利润。
: 那么现在总结一下。分享给大家。欢迎批评指正。
: 勿上封面，主页,头条。本贴已转去侦探版保存。
: 先说结论：
: --------------------------------------------------------------
: 反正现在我的结论就是要两套代码。一套Jupyter或者knitr/Rmarkdown
: 生成。一套按把前面的代码修改补充，封装，重新安排组织，
: 用sublime做。
|
