感谢 Bob 的回答. 看上去 ReasonML 在国内的传播真的刚开始啊, 希望后面会越来越好.
另外也多谢 @Huxpro 从总部过来支持. 也欢迎其他过来参与和围观帖子的同学来关注以后的线上活动.
我是 Hongbo Zhang, 欢迎来问关于ReasonML/BuckleScript，函数式语言，还有静态类型系统的任何问题
muyi
#24
Mr. Zhang,您好。 期望与您探讨。
我们公司专注于国内某一大型行业的专业软件。 研发人员~1000，其中平台研发人员~100，产品研发~400，其他是项目定制。 除平台与产品比较集中，人员分散在全国团队中。
公司一直在使用JEE+OSGI基本后台架构，前端走过了从JQ到RAB(requiejs+angularjs+boostrap)的过程。 使用JQ时因为年代比较早，自己做的MVVM双向绑定，并包装各种通用组件和行业组件。因为需要考虑历史因素，现在是混合使用。
技术在互联网上奔跑，我们也必须时刻瞭望远方。
因此最近在研究python+django,ruby on rails，,NodeJs,React，ES6+， 跨平台前端开发等，就roaming到您这里来了。
也按照网上的例子，使用ReasonML编写了若干行代码（感觉一下），再转换成js运行。
感觉ReasonML也好，TypeScript也好，比较强调类型绑定（不知道理解正确否？）。但JS的最大优势是动态语言，异常灵活，当然其反面也是显而易见的，主要是参数约定比较自由，造成caller与callee之间不匹配而出现bug。 为了解决这个问题，很多公司，包括我们公司在完善文档与加强测试方面做文章，但也不容易，特别是大团队中，不断更新的团队中。
类型绑定可以解决这些问题，但也损失了一定的动态特性，还有与非类型绑定历史资产的集成问题。
软件开发方面，有TDD一说，测试驱动开发，有点用处，但也不是万能的，而且成本也不低。
本人有过CDD的想法，就是注释驱动开发。 在写一个类，一个方法前，先按照约定的格式，将各种组合场景以及预期结果写在注释中。 这样的注释既是使用说明书，也是测试用例。但因为各种原因，还只是想法而已。
最近看python，python也是动态语言，其实pyhon已经有了这个技术，注释就是测试用例并且可以自动测试这些用例。而且可以自动生成文档。
我的意思是，能否在您的编译器中，在如下方面增强：
- 允许JS的原生写法，动态类型 ，如果不太好处理的话，可以借助annotation标注。
- 如果能够实现1，则对于一些第三方库，不改造也可以与ReasonML共存，这可以解决目前开发者最大的担忧。
最后, 能否支持CDD，注释驱动开发，使用注释中的测试用例，自动单元测试，可以借鉴一下python的思路。
谢谢
ianva
#25
语法上能更优雅就好了，很多特性没必要靠近js，如果很多地方像 F# 到会更好看，比如 switch 这个括号真没必要
reason 的项目太少了，有些项目编码风格上还是类似 js 或者说 C 系的没有参照价值，有没有好的项目推荐。