妇女节就好，不过 op 看起来也只是单纯问个好而已，大概也不用太上纲上线（

祝女同胞妇女节快乐）

crud 大概只要和数据打交道都会遇到。
我个人而言讨厌后端大概是讨厌那套叠床架屋的企业级设计，讨厌明明可以用更优雅更安全的方式去保证算法的设计和一致性却非要用设计模式、getter/setter 还有连 lambda 和泛型都无法表示的 uml 之类的裹脚布来给程序员添加一大堆莫名其妙的心智负担。
相比之下前端圈至少对新技术更有接纳度，花活玩多了也不太搞出 3022 年还在尬吹 optional 和 stream 函数式设计的玩意。（虽然前端也有自己的问题就是了）
管理后台最大的问题就是不上不下吧，论技术，草台班子不可能比得过 m$、sap 之类的成熟架构，技术永远是次要地位，劣化的需求反过来又会把技术往更恶劣的方向推，然后一群人在 servlet 和 jdbc 上阻塞到死还如数家珍，看着心寒。

因为总有人不满足于一眼就看到天花板的未来。

iCloud, GitHub Pro, JetBrains Package, Typora, Affinity Package, icons8 Lunacy, Magnet

这流汗黄豆真应景😅

op 想做的，侧重于 DSL 还是解析呢？算是两个不同的方向了。前者是 Model Driven Engineering ，后者就是典型的造语言（即使是 DSL 原理也一致）。

前者的话更多关注于怎么样把具体的应用场景里面的 model 和 domain map 到语言上，关注于，如何去做 meta modeling ，如何提供语义清晰的 api ，如何做 text 、model 、运行时之间的转换，主要还是合理使用第三方工具而不是自己造轮子。当然基本的一些概念，比如不同的 eval 语义，还是需要了解的。

后者重点在造语言，比如说词法分析语法分析、类型检查和推导、代码生成甚至后期优化。这个也是不限于 DSL 的，或者说 DSL 其实一般不需要这个 approach 。

Model Design 这方面我不了解，感觉 op 可以找找看有没有一些学校的公开课件看一下，不过感觉这个领域也是那种比较老式的软科，可能有许多模糊的概念或者过时的工具，需要仔细甄别。

我的建议是 op 可以先考虑一下这个 DSL 是否一定要用造语言来实现，会不会有一些语言内置的语法已经可以表达出来。当然造语言最大的好处大概是可以灵活应对多变的具体场景了。

如果想好了要造 DSL ，可以优先考虑 antlr ，这是一个常用的 parser generator ，可以根据用户提供的文法来生成词法和语法分析器的骨骼，然后让用户自行填入编译器的具体实现。有几本书也是讨论这个的，然后 idea 里面有专门的语法树可视化的插件也很方便。不过我觉得首要的还是得理解一些关于 parser 和编程语言的基本概念了，比如 parser 的分类和不同类型的 parser 有哪些限制。

在这个基础上，op 可以进一步去考虑到底选哪个方向。

法国最大的互联网公司前 5 都是。

先去了再说+1

没记错的话上次楼主好像是叫人去外包公司和野鸡学校挂靠来赌 h1b 的。怎么又来推销加拿大了。

加拿大也许是个值得讨论的目的地，也有不少 local 有提到这个。

但楼主的背景让我感到怀疑。

很多人连老板 /公司 /自己都分不清楚。

要去弄明白别的概念，就更难了。

是，会影响。

又是 chatgpt 无脑吹。

这玩意出来了有人敢用吗。

数据库建模需要的安全性、对语义的准确分析，都荡然无存。

@MMMMMMMMMMMMMMMM +1 ，搞不懂都从哪来一大堆跟 closeAI 斗智斗勇还上了瘾的人

Kotlin ，然后回过头看 Java 不要再简单。

不想写 Java 也可以去学 Scala 或者 Clojure 。

程序员在群里帮人忙，大概跟律师给朋友科普法律常识或者举几个法条做例子，相当的情况。

免费或者用很低廉的价格接单确实是自贱的行为，不反驳。

但 op 用来论证「程序员就是廉价，律师是人精」的证明过程也不对劲吧？

且不说拿到需求就开始写本身也是大型项目里面的大忌了（哪个稍微大一点的项目不是先做各种分析、调查和设计的），在这之前也得先做预算和预估成本。

op 如果是想指责开源项目的话，那么开源项目更多是为了个人和团队的 visibility ，类比到律师上，大概相当于律师参加各种沙龙、会议跟各家公司套近乎发展自己的 networking 。只是表现方式不同而已。