@sumhat  第四张图识别为“性感”的概率是4成多一点，也算是不错的缓解鉴黄师工作的结果。不过据说这些图用美图秀秀啊什么的挑一下色调或者光照，就会识别不出来。

非常感谢以上回复。最后找到了 blueprints 是怎么用的。

总结一下，我正在做一个 restful 的 api server。

`app.py` 里面 是这么初始化的。

```
from app.v0.likes import likes

def configure_app():
flask_app = Flask(__name__)
flask_app.register_blueprint(likes, url_prefix='/api/v0/likes')
return flask_app
```

然后 `likes.py` 里面就可以自己定义各种 url 了

```
from flask.blueprints import Blueprint


likes = Blueprint('likes', __name__)


@likes.route('/<comic_id>', methods=['POST'])
def likes_comic_post(comic_id):
pass
```

这样访问路径就是 `/api/v0/likes`

@asj
你说得很对， scala 就是这样的。纯函数式的 Haskell 有时也会让我有这种感觉。

@evolighting
我也觉得 Go 除了是 Google 以及 C语言的合作发明者搞出来的，有光环之外，真没觉得有惊艳的感觉。
当然 Go 的有些概念还是挺有启发性的。

所有通过简化语言基础设施，来达到简化问题目的的编程语言，最终都是南辕北辙。
Java 是这样，Go 在我看来也很像是这样。

看完之后突然觉得，王垠在自尊心和自我的强烈程度上，和我非常相似。
因为我很轻易就理解他曾经的处境了。

当然啦，我觉得期望、要求任意一个别人尊重你真的是很幼稚的。
即使你做到像马云那种程度的大多数民众眼中的超级成功的企业家，一样会有人觉得不值得尊重的，例如本屌。

居然“阿里旗下”这个还敢拿出来作为招人的……？

@jun4rui 其实不是面向对象不行，而是写 Java 的时候很多东西没去细想，想尽可能简单，所以就挖了很多没法填得坑。发明 Java 的时候注意了很多数据管理，数据很OO，但是对“计算”的本质并没有做 OO 分析…… 所以就坑了。

再分享一下，我自己批判或者审视一门编程语言的一般思路，以感谢这么多位捧场。

我觉得一门语言绝对不仅仅是工具。
我认为，在编程的领域来说能称为工具的，应该说是思想，编程语言是思想的一个“现象”而已。我的意思是，编程思想是本质，编程语言是现象。

为什么可以这么说呢，你看看，其实很多编程语言，例如自称是OO的语言，都是可以共享相同的原则的。譬如 依赖倒置原则啊，Liskov 替换原则啊什么的。又譬如自称函数式编程的语言，都喜欢不变性啊，尾递归优化啊，代数数据类型啊，lambda啊这种东西。

如果编程语言之间可以拥有那么多的共同思想，显然把他们归类在"工具"这个范畴，是不够准确的。情形就好像：人和猿类，大家都有四肢五官，仅仅归类为哺乳类是很不准确的，猪也是哺乳类，但你指望猪能用手偷桃子你就要傻眼了。

正名这件事情是很重要的，不然脑子里面有一个不正确的印象，就没法把事情说清楚了。回到编程语言的话题，编程语言为什么不仅仅是工具呢。

在我们使用工具的时候，我们会预设一个用途，然后选定一个工具，挖土用铲，施加打击用锤。我们在解决编程问题的时候，也会预估编程问题的类型和范围，选定合适的技术（注意我的用词是“技术”），通常技术确定了，那么才会去敲定用一门或者多门语言解决问题。从这个角度来说，语言确实是很像工具。

但很可惜，语言不像工具的地方在于，工具是被动受人主观控制的，而语言不是。
语言有社区、有生态、有其他编程人员反过来会控制你或者对你施加影响。更加糟糕的情况是，当你使用一门糟糕的语言，反过来被糟糕的社区、生态、和糟糕的程序员等等，干扰的话。你就明白为什么编程语言不仅仅是工具。

最重要的是，这些东西会干扰你的思想，导致你做出一些你本来不设想会做的事情。C++程序员应该会很有体会的就是，假如你的同事不是特别精通模板，于是你设计的很多基础设施你就不得不花更多的心思精心去包装使之看起来不是那么可怕，或者甚至就不使用偏特化之类的特性了。你写的C++代码带有C++11 feature，那么你就不能指望在几年没关过机的Linux 上编译通过了。
工具不应该是这样的，工具不趁手，可能你想都不想就换其他了。

C++至少还是有向下兼容的能力，新的不行我用旧的方法还是可以挺过去的。但如果是语言向上不能，那么你就要吐血了。譬如 GCC 用 C 来写编译器，他可能从来没想过有朝一日IDE是要深度介入编译器前端的。用 C 的于是傻眼了，实在很难把控这么复杂的交互，只好逐步转C++，我猜测这是 GCC 转 C++ 的原因。

戏肉来了。我还是要批判 Java 的，别想再在 Java 语言封闭的世界里面继续图样图森破了。

要批判一门语言，就是要看他的编程思想能否自圆其说，这是最基本的。如果自相矛盾，那么不用玩了。

什么叫自圆其说，譬如说，Java 认为一切都是对象，没问题，在Java 里面确实所有的东西都是 Object，并且整个语言提供了这样的设施来实现这个思想。譬如你的方法返回的是一个 int，你想把int 放进容器里面是不行的，你要box 这个int。假如Java 不是这么做（其实我宁愿他不这么做），那么你在容器里面取出一个东西的时候，你就不能指望可以 toString（Object类的方法），也没办法GC了。

大多数能够流行起来的编程语言都是能自圆其说的。所以要看第二个层次，编程语言的思想和设计能解决什么程度的现实中的问题。

在这个层次上，Java 就不太妙了。Java 说一切都是对象，对象都是有生命周期的。他在JVM 的世界里做的很好，因为JVM 的GC确实很不错。但是去到JVM外的世界就有点麻烦了。简单的例子，文件是不是对象，连接是不是对象，所是不是对象？都是，但是这些东西的生命周期结束，指望用GC来自动关闭是会出事的。所以，Java 里面开始要有一些手动关闭的东西。所以，指望这些东西跟普通对象一样可以传来传去不用担心资源问题，有点变的不真实。

当然，C# 也有这种问题，所有带有GC 的语言都会面临这样的问题。
但是，C#的设计者一早就知道会有这样的问题，所以他们有 using。直到 Java 7 才有类似功能的语法糖。

又因为 Java 认为一切都是对象，所以他们认为泛型也是可以用对象来解决的，所以Java 开发者们很开心的有了一堆类型擦除的泛型容器。

还是因为 Java 认为一切都是对象，所以他们认为数据查询这种事情，应该是一种具体的对象提供的对外接口问题而不是语言要解决的问题。所以 Java 的开发者很开心地用各种 ORM 框架发起数据库查询，然后依然很开心地，用嵌套循环语句来查询自家树状数据结构中的对象。什么？你认为这不是一个问题而是两个问题？好吧，当我没说。

最后，因为 Java 认为程序员们已经有这么多的对象了，所以加班加点也不怕找不到对象了。 XD
当然 Java 还成功地使你们认为这不是同一个问题，是社会大环境问题，是公司管理问题，是自己能力的问题，总之不是Java 的问题。所以，不准别人诋毁心目中神圣无比，为你带来工作机会带来收入的Java！

啊哈哈哈哈哈。你不加班谁加班啊，活该！

@FrankHB

没必要把精力用来回复那种人。
当然，如果你对他的回复特别有感觉，不吐不快，这种情况除外。

请让我向你的分析致敬。
我来总结一下，目前为止在这篇帖子里面各种回复的人的逻辑吧（如果回复是有逻辑的话）。

1. 资格逻辑
我说：Java语言不好。Java 语言这里不好，那里不好
他说：你是谁，你有资格吗？你做过什么牛逼的东西？

这种人呢，有不懂言论自由精神的可能，也有可能是纯粹是来发泄的。他们的基本逻辑就是，你说的什么都不对，除非我服了你（by 作品 或者名声）。

这种根本不是就是论事的，没有必要理会。


2. 语言炮逻辑
我说：Java语言不好。Java 语言这里不好，那里不好。
他说：你是语言炮。不要跟语言炮交流。

这种人其实也没什么不好。只不过他们的预设前提是：炮轰一门语言太哗众取宠，一门语言的设计肯定有可取的地方（政治正确但没有实际价值的废话）。

如果他是作为一个政治家，这样很高明，先质疑动机，进而歪曲整个意图，然后我就不用听你说了。
不过我作为一个写代码的，我也不想跟他们说话。


3.实用主义逻辑

我说：Java语言不好。Java 语言这里不好，那里不好。
他说：语言没有好坏，看应用场景。更进一步，你举的场景都是Java 不强的地方。

这种人其实也没什么不好。只不过他们预设的前提是：就算有不足的地方，你说出来也是没用的，因为你改不了，或者说因为你不是语言发明者，又或者是你又改不了这个生态。

实用主义者相对于语言炮逻辑，又好了一点点。但是从根本上没办法避免实用主义的另一面，就是短视和功利。

说句很抱歉的话，我确实在写编译器，想发明语言。就算我不写编译器不发明语言，我觉得这样的讨论至少可以帮助程序员设计好的库来解决问题。

既然你们都是能用就好的想法。道不同不相为谋，诸君请吧。



诸位，请对号入座吧，玩得开心点。哈哈啊哈哈

@FrankHB

我很确定自己暂时吃不透加入这个关键字会带来怎样的连锁反应。
至少有一点，加入 resumable 是不是真的那么“干净”，带有 resumable 修饰的函数类型怎么算。

最后就是，我也在弄一个fiber式网络库，我隐约觉得，令一个函数 yieldable 是有可能不用在 语言层面 hack 的

@FrankHB

我不喜欢这个提案……唉，其实是看他们越来越短视地加更多修饰符进入 C++，我是很心疼的。这个提案的目标本身还是积极的。

@zjengjie

是是是，你说得对。
写 Java 的人恐怕连查询数据集合都用不着，所以能够支持 Linq 之类的语言基础也是不用的。用 ORM 就够了，其他什么的永远都用不着。

不承认 Java 很渣我还可以理解，毕竟可能很多人以前是用 ASM。但是不承认无知有害我就不能理解了。

@laipogo 如果你已经找到了，那你就帖吧，它一直就是public 的。不需要我允许。

@monsabre1

我错了……一时手抖写了 C++语法…… 求轻砸

class DFA(object):

@chilledheart

不不不，我不是来秀 C++的优越感的，我很喜欢 C++ 这类的语言，很对我胃口。
但我还不是最满意，Rust 的话，最开始有跟过，后来变得太多，没时间跟下去了，但相信也不差。

我发这个贴是来专门打 Java 脸，以及打某些认为编程语言没有优秀低劣之分的人的脸的。或者说，某些人嘴里的语言炮（他们没说错）。

我觉得不承认语言之间确实有 优劣 之分的人，都没有找到正确的思维方式，我特喜欢打他们脸来为自己找找可怜的存在感……
（我这么说的话，那些不断揣测我是个 loser ，要求我上代码的人，是不是也很有满足感？哈哈哈哈，losers）

@hepin1989

我当然知道 Java 也可以实现 Coroutine 的效果，而且说实话 Coroutine 其实就是个闭包而已嘛。别说Java 会演进增强，这些库迟早或是现在会有的。你给大家普及了这个库，我也是第一次看到。

但是，我从来就没有说过 Java 不能实现 Coroutine 的效果，我也一直不否认 Java 能写出 Coroutine 效果的库。

我一直强调的事情是，Java 是一个很不好的语言，这门语言的设计以及其规范鼓励的写代码的方式，不是解决问题的正确方式或者是最好的方式。

既然我们已经在 Coroutine 这个问题上短兵交接，那么我们也不妨就这个话题继续下去，看看：

1. 原生支持 Coroutine 的语言是怎样解决某一类问题的
2. C++可以写出怎样的库解决上述问题的
3. Java 可以写出怎样库解决上述问题

要解决的问题是：
一个 DFA 模块或者类，初始化的时候输入一系列规则，运行的时候逐个输入字符，并且可以随时查询已经 parse 出来了哪些终结符，正在 parse 的符号串可能是什么类型的终结符。

1. python

class DFA: object
def __init__(self, rules):
pass

def input(self, ch):
# 在计算过程中用到的变量
status = calc_status()
yield type, status

使用：
DFA dfa_engine = DFA(rules)
while(not EOF):
type, status = dfa_engine.input(ch)

2. C++ 没有原生的 yield，但是，最起码， C++ 可以混编 ASM 保存函数栈以及寄存器内容，来实现 yield 的效果，具体实现看 boost::context。 更不用说 boost::coroutine 这个库了。

class DFA
{
public:
static void *caller_context_;
static void *input_context_;

// ... other members

public:
std::tuple<Type, Status> input(const char ch) {
// 需要 yield 的变量保存在一个 std::tuple<Type, status> 的指针中
void *yield_cont = ...;
jump_fcontext(&input_context, caller_context_...);
}
// other functions...
}


使用：

DFA dfa_engine(rules);
DFA::caller_context_ = make_fcontext(&parse ...)
DFA::input_context_ = make_fcontext(std::bind(DFA::input) ...)


void parse(..) {
while (!EOF)
{
yield_cont = jump_fcontext(&caller_context, input_context_);
}


可以看到，形式上，大概是跟 Python 的是差不多的。


3. Java 的，谁打算试试，请大家教我，我反正是好久没用 Java 了。


看这个例子并不是说，Java 的能不能做到 Coroutine 的效果，而是看：

实现的形式是不是足够 保持 问。题。的。原。型。

@hepin1989 Coroutine 跟并发一毛线关系都没有，甚至跟线程的关系都不大……当然啦，考虑到你可能真的只是个 Java 程序员，才会把 Coroutine 和并发、异步什么的一起来考虑。看来你根本没弄懂我说什么，算我看错人了……