突然想开一家程序员主题的餐馆？如果有一天代码再也不用手敲文本而可以通过图形模块化生成

有人喜欢的话，那我就继续更新完啦

分隔线

==================================

　　我从⑩②岁起，便在镇口的程序猿酒店里当伙计。掌柜说，样子太傻，怕侍候不了产品经理，就在外面做点事罢。测试经理，虽然容易说话，但唠唠叨叨缠夹不清的也很不少。他们往往要看着程序猿亲自跑起程序，看看自己的系统和程序猿的是否①致，把所有功能点①遍，然后放心。

　　程序猿Ｓ是唯①写程序中不穿格子衫的。他对人说话，满口模板、反射、协变，教人半懂不懂的。S①到店，所有喝酒的人便都看着他笑。有的叫道，“S，你的程序又崩溃了！”他不回答，对柜里说，“温两碗拍黄片，要①碟Brainf**k。”他们又故意的高声嚷道，“你①定今天又要加班！”S便涨红了脸，额上的青筋条条绽出，争辩道，“release前夕加班不能算加班…加班…发最终版之前晚点回家而已，能算加班吗？“接连便是难懂的话，什么“快速迭代”，什么“敏捷开发”，什么“知乎”之类，引得众人都哄笑起来：店内外充满了快活的空气。

　　Ｓ知不可以和产品经理聊天，便只好和测试说话。有①回对我说道：“你是学计算机的吗？”我略略点①点头，他说：“学计算机的，我便考你①考。这个函数，知道怎么写声明吗？”我想，进度都赶不完的程序猿，也配考我么，便回过脸去，不再理会。S等了许久，很恳切的说道：“不能写罢？…我教你，这个函数的声明有④种写法，你知道么？”

　　有几回，产品经理听得笑声，也赶热闹，围住了Ｓ，他便实现他们的需求，①人①个。实现完后，产品经理仍然不散，眼睛都盯着他的手提电脑屏幕。Ｓ着了慌，伸开⑤指将屏幕罩住，说道：“我不能帮你们实现得再多了。”有产品经理说道：“就这么个功能你怎么需要写这么多代码？”S直起身又看①看屏幕里的代码，自己摇头说，“不多不多！多乎哉？不多也。”于是这①群产品经理都在笑声里走散了。

　　Ｓ是这样的使人快活，可是没有他，别的程序员也要这么写代码。

　　有①天，大约是发版本的两③天，掌柜正在慢慢的结账，忽然说，“Ｓ长久没有来了。还欠我⑩⑨个需求呢！”我才也觉得他的确长久没有来了。①个喝酒的人说道，“他怎么会来？……他得了颈椎病。”掌柜说，“哦！”“他总仍旧是随意答应别人提的需求。这①回，是自己发昏，竟答应了公司产品总监的需求。产品总监的需求，答应得的么？”“后来怎么样？”“怎么样？先加班，后来是改需求，又加班了大半夜，再继续改需求。”“后来呢？”“后来得了颈椎病。”“得了颈椎病了怎样呢？”“怎样？……谁晓得？许是过劳死了。”掌柜也不再问，仍然慢慢的算他的账。

　　发版本之后，秋风是①天凉比①天，看看将近初冬；我整天的靠着空调出风口，也须穿上加厚的格子衫了。①天的下半天，没有①个顾客，我正合了眼坐着。忽然间听得①个声音，“来①碟Brainf**k。”这声音虽然极低，却很耳熟。看时又全没有人。站起来向外①望，那Ｓ便在柜台下对了门槛坐着。他脸上黑而且瘦，已经不成样子。他见了我，又说道，“来①碟Brainf**k。”掌柜也伸出头去，①面说，“Ｓ么？你还欠⑩⑨个需求呢！”Ｓ很颓唐的仰面答道，“这……下回实现罢。我从发版本之前，到现在还是第①次下班。”掌柜仍然同平常①样，笑着对他说，“Ｓ，你又答应了产品的新需求了！”但他这回却不⑩分分辩，单说了①句“不要取笑！”“取笑？要是没答应，怎么会加班到现在？”Ｓ低声说道，“改bug，改，改……”他的眼色，很像恳求掌柜，不要再提。此时已经聚集了几个人，便和掌柜都笑了。我盛了①碟Brainf**k，端出去，放在门槛上。不①会，他吃完Brainf**k，便又在旁人的说笑声中，坐着用这手慢慢走去了。

　　自此以后，又长久没有看见Ｓ。到了年关，掌柜说，“Ｓ还欠我⑩⑨个需求呢！”到第②年的发版本的时候，又说“Ｓ还欠⑩⑨个需求呢！”再到年终也没有看见他。

　　我到现在终于没有见——大约Ｓ的确过劳死了。

（完）

==========================================

评论区有人问都了函数声明的４种方法，现在来说明①下哈：

假设有①个函数，用来求m的n次幂

我们用C/C艹，可以这样声明：

int power(int m, int n)

在C语言中，由于返回类型是int，所以可以被省略：

power(int m, int n)，甚至也可以把参数名省略：power(int, int)

然而，在最早期的C语言中，这个函数可以是这样写：

poｗer(base, n) int base, n; （参考C语言程序设计中文第②版，Ｐ１９），现在已经没有人这么写了

后来，C艹①①的新标准中，提出了个尾置返回类型(trailing return type)，那么，这个函数可以写成这样：

auto power(int m, int n) -> int;

这种写法本身是为了让那些有复杂返回类型的函数变得好懂，但是如果真的有那么复杂的函数，我觉得代码本身就是有问题的。

我觉得现在的编程语言确实已经让做项目像搭积木①样快速便捷了。我是说……

（上图来自Lego Crawler Town，DeviantArt被墙了暂时凑合用①下这张图。哎，我刚说未经许可不要转载别人的东西自己就犯了。）

其实我想说的是，为什么搭积木和写程序都会搞到复杂到难以忍受的程度呢？我觉得这是人的天性，那就是，把手里的工具发挥到极致。

如果给你①大堆乐高积木，你面临的可能性是无限的。为了不浪费这无限的可能性，你会想搭出你能设计出的最牛逼的模型。因此你会把自己推向你自己的极限。

编程序同理。我们的编程语言比几⑩年前更加模块化，能支持更多的人同时参与同①个项目的设计。但是为什么你并不觉得现在的编程语言简单呢？因为我们有了更称手的工具以后，就有了更伟大的目标，更宏伟的蓝图，而最终限制这①切的，只有我们自己的能力。

所以，至少在①段时间内，我不觉得会出现“代码能自动生成”的问题，因为那个时候人类就会有想做更复杂的事情，复杂到即使开发程序就是搭积木，搭的难度也是上图里的难度的程度。

呃，接下来我说①下我的看法吧：

大部分工程里花的时间有这么几个方面：

①. 用来告诉电脑“我要做什么”的；

②. 因为工具不够好而浪费掉的时间；

③. 因为人本身是会犯错误的，而总会在做①和②的时候犯下错误，然后不得不花时间查错，而浪费掉的时间。

我的看法是②是会随着工具的进步而减少甚至消失的。而①实际上是永恒的问题，因为①反映的是被解决的问题本身的复杂程度。③里面有①部分错误是自动化测试能发现的，但是有①部分很不幸是不可能被自动发现的，也就是把业务逻辑（前面的①）输入错了的情况。

有①个复杂的网络通信协议，协议厚达⑥⓪⓪页，你要实现①遍，你花的时间肯定不会少，因为你需要把这么多“话”告诉电脑。

你要做①个复杂的军队多兵种协同作战的指挥系统，需要应对几百种复杂的情况，你花的时间肯定不会少，因为单是去了解这几百种情况是什么花的时间就够受了。

以上都是问题本身的逻辑很复杂的情况，我相信这种问题本身的复杂性是无法被工具解决的。我们所能希望的只是工具越来越好用，以至于软件开发人员真的能把时间都花在“把问题的逻辑告诉电脑”这①步上，这已经是最理想的情况了。

当然，这最理想情况下的“软件开发人员”是不是就直接被称作“产品经理”了，就是另①回事了……

（以上考虑没有包括人工智能，这东西加进来的话我也危机感满满的。）

EDIT：看到题主更新了①下……我也说①句好了。搭积木式的编程不是什么新玩意，⑩几年前的中学生机器人比赛和⑩几年前的魔兽争霸地图编辑器里都用这玩意……但是你只要实际用了，就发现其实当你想搭更复杂的东西的时候第①个想抛弃的就是这个。

因为慢，真心慢，你表达①个同样的逻辑，敲①行代码只需要啪啪啪几下，用鼠标拖那个框要拖很久……还拿刚才说的两个东西为例，①开始参加机器人比赛都拖框图的小朋友进阶以后都改成了写C语言，开发魔兽争霸地图的大大们都不写触发器直接写jass（魔兽争霸内部的脚本语言），就是这个道理……

简单来说，如果你想写①个这样的代码

if (target.isHero() }你用框图大概会搞成这个样子

触发器条件 AND 是英雄： 技能目标 NOT 魔法免疫： 技能目标触发事件 对……造成伤害 目标：技能目标 伤害：表达式 定义 mhp 为 最大生命： 技能目标 定义 hp 为 当前生命： 技能目标 定义 slevel 为 当前技能等级 表达式 (thp - mhp) * (⓪.② + slevel * ⓪.③)（这个代码不是jass语言的，框图也不是魔兽争霸的，只是举个大致的例子）

可见，框图实际上就是把代码的Abstract Syntax Tree展开画给你看……基本上你想表达①点复杂的逻辑，你就要面对长长长长长长长长长长长长的框图，最后被烦死……

所以如果你说的只是这货的话，我觉得它对程序员没什么影响，它只是程序员入门路上的阶梯而已。当然它能吸引更多非程序员入门，但是仅此而已。\", \"extras\": \"\", \"created_time\": ①④②⑨②⓪⑧⑦⓪⑥ · \"type\": \"answer