市场最下层存在着最本质，最难以解决的特征。
有了好的方案，怎么迅速从最下层发展到最上层，值得研究
有了好的方案，怎么迅速从最下层发展到最上层，值得研究
2018/04/20
2014/12/19
a library vs a framework
・your code call libraries ,frameoworks call your code
・framework==>Don't call us, we'll call you
framework
===>
Frameworks are not the cure for all programming
problems. Putting aside today's awesome state of
development, you should always remember how
frameworks were created a few years ago. Most of them
were more or less unoptimized junk created by one guy to
help him speed up his development process, without much
care for documentation, elegance, ease of use, or even
readability of his code. Then another group of guys took
this code and bloated it with a patchwork of extra
functionalities barely consistent with the original code.
Then it became apparent that this whole lot needs a solid
cleanup in order to be usable, but this would mean either
rewriting it from scratch or packaging code in additional
wrapper classes, further increasing its unnecessary
complexity.
Of course, today the disorganized origin of frameworks is
not as evident as before because the quality of code has
risen considerably. But still, that's why most beefed-up
frameworks have performance issues. That's why they are
39
www.it-ebooks.info
not always easy to learn. And that's why new ones emerge
to cover up weaknesses of older ones. And finally that's
why major frameworks provide completely rewritten 2.0
versions, which address all previously mentioned
problems.
・framework==>Don't call us, we'll call you
framework
===>
Frameworks are not the cure for all programming
problems. Putting aside today's awesome state of
development, you should always remember how
frameworks were created a few years ago. Most of them
were more or less unoptimized junk created by one guy to
help him speed up his development process, without much
care for documentation, elegance, ease of use, or even
readability of his code. Then another group of guys took
this code and bloated it with a patchwork of extra
functionalities barely consistent with the original code.
Then it became apparent that this whole lot needs a solid
cleanup in order to be usable, but this would mean either
rewriting it from scratch or packaging code in additional
wrapper classes, further increasing its unnecessary
complexity.
Of course, today the disorganized origin of frameworks is
not as evident as before because the quality of code has
risen considerably. But still, that's why most beefed-up
frameworks have performance issues. That's why they are
39
www.it-ebooks.info
not always easy to learn. And that's why new ones emerge
to cover up weaknesses of older ones. And finally that's
why major frameworks provide completely rewritten 2.0
versions, which address all previously mentioned
problems.
2014/06/24
ファンクションパラメータの哲学
＝＝＞必要な行為結果だけ取る。その人も要らない。
＝＞オブジェクト＝＝＞動作＝＝＞結果
。。。。
将函数作为参数传递并不仅仅出于技术上的考量。对软件设计来说，这其实是个哲学问题。想想这样的场景：在index文件中，我们可以将router对象传递进去，服务器随后可以调用这个对象的route函数。
就像这样，我们传递一个东西，然后服务器利用这个东西来完成一些事。嗨那个叫路由的东西，能帮我把这个路由一下吗？
但是服务器其实不需要这样的东西。它只需要把事情做完就行，其实为了把事情做完，你根本不需要东西，你需要的是动作。也就是说，你不需要名词，你需要动词。
理解了这个概念里最核心、最基本的思想转换后，我自然而然地理解了函数编程。
java オブジェクト指向 デメリット
所有使用Java的人都喜欢“用例”，所以让我们以一个用例开始吧：倒垃圾。就像这样：“Johnny，快去倒垃圾，他都快溢出来了！”
我们的生活也同时充斥着各种“名词”。我们吃“名词”（食物），我们从商店买“名词”（商品），我们坐在“名词”（凳子）上。 “名词”（石头）可能会忽 然砸到你头上，在你的“名词”（头）上弄一个“名词”（大包）。 名词即事物，想想没有了事物我们会怎样？ 但他们仅仅只是事物，比如： 意味着结束或者 结束本身，或者一些贵重物品，或者我们周围经常看到的事物的名字。 这是一座建筑，那是一个石头。任何一个小孩子都能指出名词，仅此而已。 发生在名词身 上的 “变化”才是最有趣的事情。
变化需要动作。 动作是生活的调料。 动作甚至给了调料以调料！ 毕竟除非你“吃”它，你是不会感到香这种味道的。 名词也许无处不在，但是生活一直在变并一直有趣的功劳还是在于动词、
当然，除了名词和动词，我们还有形容词，介词，代词，冠词，连词，语气词，和许许多多其他让我们构造有趣语言的词汇。 它们都在语言中扮演着自己的角色，而且每一个都很重要。 如果它们哪一个不存在了的话，那是挺遗憾的事情。
变化需要动作。 动作是生活的调料。 动作甚至给了调料以调料！ 毕竟除非你“吃”它，你是不会感到香这种味道的。 名词也许无处不在，但是生活一直在变并一直有趣的功劳还是在于动词、
当然，除了名词和动词，我们还有形容词，介词，代词，冠词，连词，语气词，和许许多多其他让我们构造有趣语言的词汇。 它们都在语言中扮演着自己的角色，而且每一个都很重要。 如果它们哪一个不存在了的话，那是挺遗憾的事情。
面向对象
StateManager.getConsiderationSetter(“Noun Oriented Thinking”, State.HARMFUL).run()或者， 正如外面的世界所说，“面向名词的思考是有害的”
面向对象的编程把名词放到首位，但是我们为什么非得把名词捧上神坛以至于让语句变的如此啰嗦哪？ 为什么一种语句成分的低位非得高于另外一种？这并不是好 像面向对象的编程突然使得动词的低位降低，正如我们认为的那样。 这是一种奇怪的认识的扭曲。 正如我的朋友 Jacob Gabrielso一次说到， 提倡面向对象的编程好比提倡面向裤子的穿衣方式。
StateManager.getConsiderationSetter(“Noun Oriented Thinking”, State.HARMFUL).run()或者， 正如外面的世界所说，“面向名词的思考是有害的”
面向对象的编程把名词放到首位，但是我们为什么非得把名词捧上神坛以至于让语句变的如此啰嗦哪？ 为什么一种语句成分的低位非得高于另外一种？这并不是好 像面向对象的编程突然使得动词的低位降低，正如我们认为的那样。 这是一种奇怪的认识的扭曲。 正如我的朋友 Jacob Gabrielso一次说到， 提倡面向对象的编程好比提倡面向裤子的穿衣方式。
类是Java中唯一提供的建模的工具。 所以当一个新的想法出现在你脑海的时候，你不得不重塑它，包装它，甚至弄碎它直到它变成一个名词， 即使它开始是一个动作，过程，或者任何其他不是“物”的概念。
我似乎回到了8,9年前一帮搞Perl的家伙对我说的：“伙计，并不是所有的东西都是对象的。”
很奇怪，Java似乎是主流面向对象语言中唯一一个完全以名词为中心的语言。 在Python或者Ruby中，你不会找到 AbstractProxyMediator，NotificationStrategyFactory或者其他类似的东西。 为什么在Java中它们满 地都是？ 我敢打赌这是原因出在了动词的身上。 Python，Ruby，JavaScript，Perl当然，还有所有的函数式编程语言允许你声明并传 递函数而不用用类包装它。Java没有理由不简单地添加第一类函数并最终实现一个成熟的，没有扭曲的可以让人自由运用动词来实现他们想法的世界。 实际上，有一个基于JVM叫 做 The Nice programming language 的语言实现了一个非常类似Java的语法， 并包含了一个非常具有表现力的实现了使用 动词方式：独立函数。 而Java强制你用Callback，Ruunable或其他匿名接口来包装它为一个类以便于调用。
Sun公司甚至没有打破他们一切函数都必须被类拥有的信条。 任何匿名的函数都会具有一个隐式的this指针指向定义它的类；问题解决了。
我似乎回到了8,9年前一帮搞Perl的家伙对我说的：“伙计，并不是所有的东西都是对象的。”
很奇怪，Java似乎是主流面向对象语言中唯一一个完全以名词为中心的语言。 在Python或者Ruby中，你不会找到 AbstractProxyMediator，NotificationStrategyFactory或者其他类似的东西。 为什么在Java中它们满 地都是？ 我敢打赌这是原因出在了动词的身上。 Python，Ruby，JavaScript，Perl当然，还有所有的函数式编程语言允许你声明并传 递函数而不用用类包装它。Java没有理由不简单地添加第一类函数并最终实现一个成熟的，没有扭曲的可以让人自由运用动词来实现他们想法的世界。 实际上，有一个基于JVM叫 做 The Nice programming language 的语言实现了一个非常类似Java的语法， 并包含了一个非常具有表现力的实现了使用 动词方式：独立函数。 而Java强制你用Callback，Ruunable或其他匿名接口来包装它为一个类以便于调用。
Sun公司甚至没有打破他们一切函数都必须被类拥有的信条。 任何匿名的函数都会具有一个隐式的this指针指向定义它的类；问题解决了。