自然语言形式的DSL

whs860603

在“浅谈OpenResty未来的发展”视频里春哥提到应该找到一种最适合描述业务逻辑的DSL来描述业务通过编译器生成各种编程语言的代码/机器码，目前我所接触到的大多是通过word文档形式提供的需求设计文档，如果要进行这方面的一些尝试，根据春哥的经验，需要考虑哪些方面，从哪些地方下手呢？可能的话，能不能把你在大会上提到的例子讲的更详细一些？

agentzh

Hello!

2016-01-15 20:10 GMT-08:00 王海生:
> 在“浅谈OpenResty未来的发展”视频里春哥提到应该找到一种最适合描述业务逻辑的DSL来描述业务
> 通过编译器生成各种编程语言的代码/机器码，目前我所接触到的大多是通过word文档形式提供的需求
> 设计文档，如果要进行这方面的一些尝试，根据春哥的经验，需要考虑哪些方面，从哪些地方下手呢？可能的话，能不能把你在大会上提到的例子讲的更详细一些？
>

业务语言不一定是使用自然语言最好哈。因为自然语言通常不够精确。当然，如果你觉得自然语言的某一个子集足够精确，显然你也可以直接去解析它。比如一些编写良好的手册里的列表和表格之类。

这里的技术前提是，作为输入的描述（不论是何种语言）已经包含有足够多足够精确的信息，可以用于自动构造业务系统的全部或主要部分，那就可行。一般来说，同一类的业务模型都有自己最适合的记法和语言。不同类的模型一般有不同的最合适的表示方法和描述方法。最合适的语言和记法经常可以反映模型本身的属性和特点。

Regards,
-agentzh

zoom.quiet

2016-04-27 16:27 GMT-05:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 2016-01-15 20:10 GMT-08:00 王海生:
>> 在“浅谈OpenResty未来的发展”视频里春哥提到应该找到一种最适合描述业务逻辑的DSL来描述业务
>> 通过编译器生成各种编程语言的代码/机器码，目前我所接触到的大多是通过word文档形式提供的需求
>> 设计文档，如果要进行这方面的一些尝试，根据春哥的经验，需要考虑哪些方面，从哪些地方下手呢？可能的话，能不能把你在大会上提到的例子讲的更详细一些？
>>
>
> 业务语言不一定是使用自然语言最好哈。因为自然语言通常不够精确。当然，如果你觉得自然语言的某一个子集足够精确，显然你也可以直接去解析它。比如一些编写良好的手册里的列表和表格之类。
>

推荐学习一下 RML 已经在这一领域推广了有小20年了,
并且有足够丰富的生态链,
使用 word 进行需求描述的,可能只有中国公司...

> 这里的技术前提是，作为输入的描述（不论是何种语言）已经包含有足够多足够精确的信息，可以用于自动构造业务系统的全部或主要部分，那就可行。一般来说，同一类的业务模型都有自己最适合的记法和语言。不同类的模型一般有不同的最合适的表示方法和描述方法。最合适的语言和记法经常可以反映模型本身的属性和特点。
>
> Regards,
> -agentzh
>
> --
> -- 
Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

agentzh

Hello!

2016-04-27 14:30 GMT-07:00 Zoom.Quiet:
> 推荐学习一下 RML 已经在这一领域推广了有小20年了,
> 并且有足够丰富的生态链,
> 使用 word 进行需求描述的,可能只有中国公司...
>

我看了一眼 RML，我自己不太喜欢。我其实说的 DSL 是像 SQL 那样的。SQL 是关系型模型的表达力强大的 DSL :)

Regards,
-agentzh

zoom.quiet

2016-04-27 16:35 GMT-05:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 2016-04-27 14:30 GMT-07:00 Zoom.Quiet:
>> 推荐学习一下 RML 已经在这一领域推广了有小20年了,
>> 并且有足够丰富的生态链,
>> 使用 word 进行需求描述的,可能只有中国公司...
>>
>
> 我看了一眼 RML，我自己不太喜欢。我其实说的 DSL 是像 SQL 那样的。SQL 是关系型模型的表达力强大的 DSL :)
>

RML~ 嗯哼, 俺说错了,
应该是 UML, IBM 收购的统一模型描述语言,
现在没有人直接用了,只是用其发明的一系列图元...

SQL 的确是有数字自洽气质的 DSL,
问题在, 基本上所有产品经理即使有数学素养,也没有那个时间来进行逻辑严密的描述...
所以,以文字为基础的 DSL 如果不能强制用图形的方式来表述,
总是引发各种结构性内部崩溃...
哈, 所以, 解析 Graphivz 的图形脚本来完成应用生成,
可能是更加自然的...
因为 PM 同时有了可以向上汇报的系统框架图

> Regards,
> -agentzh
>
> --
> -- 
Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

agentzh

Hello!

2016-04-27 15:12 GMT-07:00 Zoom.Quiet:
> RML~ 嗯哼, 俺说错了,
> 应该是 UML, IBM 收购的统一模型描述语言,
> 现在没有人直接用了,只是用其发明的一系列图元...
>

UML 感觉适合给人看，适合作为机器的输出，而不是作为机器的输入。比如我大学时曾经给 perl 写过一个
UML::Class::Simple 的模块，从 perl 面向对象库生成 UML 类图，确实也用到了 Graphviz:

    https://metacpan.org/pod/UML::Class::Simple

其实我们这里关心的是既适合给人看又适合给机器看的表示方法。所以过于依赖人类直观的方式并不适用，因为机器的“直观”跟人类很不一样，嘿嘿。

> SQL 的确是有数字自洽气质的 DSL,
> 问题在, 基本上所有产品经理即使有数学素养,也没有那个时间来进行逻辑严密的描述...
> 所以,以文字为基础的 DSL 如果不能强制用图形的方式来表述,
> 总是引发各种结构性内部崩溃...

其实，我多年前在雅虎中国时用第一代的 OpenResty 建立的搜索平台，就是允许产品经理直接在 web UI 上面写类似 SQL 的
DSL 来自己 DIY 新的搜索小产品的。嘿嘿。效果好极了，工程师至多 review 一下就直接推送上线了 :)

当然了，SQL 只是一个例子，而且我觉得是一个成功的例子。我想说的是，其实自然语言不一定是最合适的业务语言。虽然可能大多数人第一反映是使用自然语言。某些场景下，严格定义的自然语言的某个子集可能是非常合适的。其实语言是和抽象方式密切相关的，语言从某种意义上其实决定了思维的方式和边界。从好的抽象方式倒推语言，在实践中可能反而更加容易。

> 哈, 所以, 解析 Graphivz 的图形脚本来完成应用生成,
> 可能是更加自然的...
> 因为 PM 同时有了可以向上汇报的系统框架图
>

感觉不太靠谱，因为 Graphviz 的脚本是面向点线图的，而不是直接面向高层逻辑，中间隔了一层抽象，有效性会大打折扣。个人看法哈。

Regards,
-agentzh