Python和Ruby中Web编程的协同程序或延续。为什么不呢？

Question

问题是：为什么continuations（Ruby）和coroutines（Python）没有更广泛地用于Web编程？

服务器端web编程由于请求之间保持状态的问题而变得困难。两个优雅且相关的解决方案是continuations（在Scheme、Ruby和Smalltalk中可以找到）和coroutines（在Python和Go中可以找到）。在

brucetate在他的《超越Java（O'Reilly，2005）中谈到rubyonrails和Seaside是Web编程中令人兴奋的新发展。对我来说，Seaside是真正的突破：使用Smalltalk continuations，Seaside使编写复杂的请求/响应序列变得非常容易。在

我知道在Tornado中使用Python协同程序，并将其扭曲以减少回调，但与在单个协同程序中编写视图/控制器来处理完成在线购买的一系列HTTP请求相比，这有点低级。在

我想知道为什么这些在纸上看起来很好的想法没有在Python和Ruby中得到更广泛的应用。只是文化问题吗？在这些语言中实现的设施限制？或者，在Web开发环境中，这些方法是否存在根本缺陷？

Answer 1

我使用过Seaside和continuations是开发客户机-服务器Web应用程序的一个漂亮的模型。它们简化了我不敢相信的传统客户机/服务器应用程序 为什么没有其他语言在做这件事。在

但不幸的是，webapps已经不像以前那样了。 现在使用ajax，不再只请求一个页面，而是在不同的时间有多个请求。这就是为什么延续不再像以前那样有用了。在

甚至aviberyant（Seaside的原作者）也说过，在ajax下，使回调更容易（事件驱动编程）比继续更重要。在

更多信息，请看下面的quora讨论： http://www.quora.com/Whats-the-best-continuation-based-web-framework

Answer 2

你的应用程序应该写在continuation/coroutines框架上，以及支持库上。对于初学者来说，这不是一个简单的模型。 还有一些更简单的框架，比如gevent，它提供了同样的可能性来制作绿色线程，并且由于monkey补丁的缘故，更容易使用。在

Answer 3

主要是因为非技术原因。了解Seaside甚至Smalltalk的人数很少，因此没有大量廉价程序员可以雇佣。因此，知道如何安装和维护海边系统的服务提供商的数量也很少。在