【 在 pker(我要那天再挡不住我眼) 的大作中提到: 】<br>: 说实话，这种破玩意最多2天就做完了，<br>: 还聊什么核心，模块。<br>: 给个大概吧，抛玉引砖 :D<br>: #1<br>: DB/tables：<br>: users(基本信息)<br>: userR(用户相关信息，夫妻，子女等等，联合报税)<br>: userExt（拓展信息，商家，个人等等）<br>: years(年份相关数据数据)<br>: Formulas(各种规则) ...................<br>
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】 两天需求分析都没完成呢吧？ 各种数据的数据类型能定下来？输入的default value? 用户如果是做生意的，国际生意的，炒股的，... 说实话，这种破玩意最多2天就做完了， 还聊什么核心，模块。 给个大概吧，抛玉引砖 :D #1 DB/tables： users(基本信息) userR(用户相关信息，夫妻，子女等等，联合报税) ...................
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 哥们，估计你是在MS之类的养老公司混的吧。 现在这种小项目，不需要团队协作的，谁还花2天写需求啊。 当然2天有点夸张了，一星期应该可以搞定。 Agile Agile Agile 重要的事情说三遍。 这种规模的软件，先上个FS的码农2，3天写完。 然后看看IRS或者找个会计所弄批数据过来TDD，搞定。 然后泡妞看片打游戏3星期，交货！
【 在 nowhere7 (折腾) 的大作中提到: 】 请教什么是FS的码农？
【 在 lukecn (luke) 的大作中提到: 】 税务的规则经常变，至少是微调。 所以想定义一个规则库，每年只需要更新规则，然后软件根据规则的semantatics（不 是syntax），自动生成各种计算规则。 目的很简单，就是报税软件能自我更新，不要把每年的维护更新变成一项体力活。 请高手指教。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】 Java 或者c#。 我假设你这是做东西卖的，不是自用的。 也不是做slides出去吹效果的。 经常要自己改的程序才需要 表达功能强大的。 程序需要更改的频率越高，越需要 表达能力强大的语言。我天天改算法，所以需要表达能力强 速度又快的。但是商业软件，尤其是业务逻辑复杂的， 按你这个来bbs找答案的水平， 我个人的浅见，一定是c#,java最好。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 说实话，这种破玩意最多2天就做完了， 还聊什么核心，模块。 给个大概吧，抛玉引砖 :D #1 DB/tables： users(基本信息) userR(用户相关信息，夫妻，子女等等，联合报税) userExt（拓展信息，商家，个人等等） years(年份相关数据数据) Formulas(各种规则) ...................
【 在 wwzz (一辈子当码工) 的大作中提到: 】 真牛逼， 3个星期能搞定？美国五十个州，每个州税法都不一样，要把需求搞定，至少 几个月。
【 在 lukecn (luke) 的大作中提到: 】 谢谢回复。抱歉我写得不够详细，误导你了。 请看我顶楼的更新。
【 在 walkrandom (walkrandom) 的大作中提到: 】 都是if then的判断。满嘴都是苦胆味。 把if then抽出来也没有帮助。因为一旦加进去，你也不知道会影响其他的if then。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 我只是举例，实际情况TDD， 从最简单或最复杂的例子开发，然后调整。 比如： 隔壁老王， W2:100K 1099:50K State:CA Married: True Donation: 1k Loan Tax: 10k ...................
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 按照楼主需求，这些规则公式都属于变量。 所以我设计的时候把这些东西直接放公式table里面， 也可以放xml之类的里面， 这部分不是开发需求，是用户自定义的。
【 在 lukecn (luke) 的大作中提到: 】 ****************************** 这部分不是开发需求，是用户自定义的 ****************************** 我问大家的，就是怎么做这一部分。 至于具体的计算，如你所说，小学三年级的算术而已。
【 在 wwzz (一辈子当码工) 的大作中提到: 】 基于复杂的税法，我不觉得你能开发出用户可以自定义的 module.
【 在 wwzz (一辈子当码工) 的大作中提到: 】 你交过税吗？
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 这问题不会太麻烦，就是把限制性的语言转化为数学公式。 leetcode上有几道类似的题说的就是这个， 具体实现肯定要花点时间。 说到底就是解释器， 就像你在c#里面打 int y=2x+1; 解释器读进去执行， 你要做的是同样的事情，只是比它简单。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 都是找会计师，不太懂税，请批判指点。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 我们做事要明确目标，这种傻瓜软件肯定是针对简单用户的， 要用到复杂税法的，肯定是雇佣会计师甚至团队。 overkill是软件开发的一个大问题。
【 在 lukecn (luke) 的大作中提到: 】 我说过要做针对简单用户的傻瓜软件吗？ UI界面可能很傻瓜，但这和“简单”是两码事情。 我的目标就是要实现复杂的税法规则，而不是做简单运算。 所以才在这里请教，因为我的知识结构陈旧，20多年前就离开大学了。想在这里跟大家 学习下最新的进展。 其实我心里大概也有一些概念，不过我先不说，免得限制了大家的思路。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 从商业运作来说，我认为可盈利的方式就是 #1 第一笔钱 做一个简单不复杂，UI炒鸡方便的报税软件， 满足大部分普通用户需求。 #2 第二笔钱 对于复杂，大客户，提供相关行业专业会计团队， 从中抽成 #3 第三笔钱 形成自己的专业会计团队，提供专业方案卖钱。
【 在 lukecn (luke) 的大作中提到: 】 我算是懂吧，有什么问题， 你可以找我，共同探讨。 起码，你多了一个验证会计师是否靠谱的途径。
【 在 xyz14 (xyz14) 的大作中提到: 】 想得太简单了。tax设计很多domain knowledge的。一个最浅显的问题，为什么要用你 这个而不是turbo tax 哦人hrblock？你有什么他们没有的？
【 在 lukecn (luke) 的大作中提到: 】 您误会了，我没打算要用户自定义。 每年，由我来定义（经过抽象的规则），核心模块会做semantics parsing, 生成相关 的计算规则，从而生成新一年的软件版本。 简单说就是，我不想每年都修改代码，来适应税务规则的微小调整，这种我称之为”体 力劳动“。
【 在 wwzz (一辈子当码工) 的大作中提到: 】 你要把联邦税加上50个州税每年的变化，从一般人都看不懂的英语解释，转化成电脑能 够parse的规则，我觉得这个难度不是一般的高
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 我只是作为一个码农回答他的问题而已， 其他的随便说说。 你说的问题是市场，推广的人要考虑的， 这个往深了没有底的，也不可能真的花多少精力下去的。 我不知道遇见多少一拍大腿出个idea的人， 大概结果如下 #1 一部分人说过就忘了， #2 一部分就是上网问问然后就丢一边了， ...................
【 在 lukecn (luke) 的大作中提到: 】 我不客气地说一句，能砸锅卖铁请你做软件的，他的失败是完全可以预期的。 你可能coding很快，可能会玩一些fancy的东西，但是，你敲键盘的速度，远远高于大 脑进行严肃思考的速度。
【 在 lukecn (luke) 的大作中提到: 】 期待高手现身。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 戳中你这种穷逼老狗的要害了，急眼了 你就是一个穷逼老狗，一把年纪了也没做成什么事情。 十足一个loser，这几天脑发热了想做个软件。 结果发现自己很傻逼已经跟不上形势了，又他妈的没钱。 所以跑到论坛上来问。 瞧你这种傻逼像，老子回答你那么多，不感谢一下，还他妈的忽悠， 知道你为啥老狗一条了还没钱吗？ 不是你脑残傻逼，而是你做人有问题，懂吧， 你这辈子也就一个傻逼。 别再网上BB说你多有钱多有背景啥的了，吃屎去吧， ...................
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 期待你妈逼，你这种老狗这辈子也不会有出息了，老loser一个，滚！
【 在 lukecn (luke) 的大作中提到: 】 请围观疯狗现身，呵呵。
【 在 lukecn (luke) 的大作中提到: 】 这是我的帖子，该消失的是你。 不要脏了我的帖子。 我深刻怀疑，高手就是因为你的存在，都不屑于在这里现身。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 老狗，下次想免费咨询的时候客气点， 你这个账号我关注了，见一次骂一次。 换个账号再来吧， 记得拉完屎擦屁股，别直接抹你自己脸上。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 脏你妈逼，穷老狗。 哥最喜欢就是抽你这种不要脸的老狗， 明明没钱想免费咨询，还非要装得自己多高大上， 见一次打一次。
【 在 lukecn (luke) 的大作中提到: 】 税务的规则经常变，至少是微调。 所以想定义一个规则库，每年只需要更新规则，然后软件根据规则的semantatics（不 是syntax），自动生成各种计算规则。 目的很简单，就是报税软件能自我更新，不要把每年的维护更新变成一项体力活。 请高手指教。 ######################################################## 我想实现的软件能够“重新生成自己”。 简单说，每年都会根据本年度报税规则的微调，重新产生运算逻辑。 所以，业务逻辑（报税规则）的定义，需要经过抽象。抽象后的规则独立于软件之外（ 数据库，xml，json，甚至纯文本均可）。每年只需要更新这些抽象的规则。 ...................
【 在 wdong (万事休) 的大作中提到: 】 用visual basic最好。
【 在 laoqintow (lqt) 的大作中提到: 】 这个有想法意思。不知楼主所提的“规则”具体指的是什么？是税法规定吗？ 个人感觉商业前景不小。 pker所指的软件开发工作量可能不包括这些规则，所以相对而言是有点微不足道。感觉 用什么开发语言无所谓，用一个熟悉的即可。三年也许够了？ 如需找一个语言表达规则，则需对规则有详细了解，才能判断语言是否合适。有谁对税 规详细了解吗？ 也许可以自创一种语言或数据结构定义，系统内部自用，随着对税规了解的深入，不断 完善
【 在 lukecn (luke) 的大作中提到: 】 谢谢回复。 我说的”规则“，是有关税法的，但是要经过抽象，不是具体规则，而是用来产生运算 规则。 因为具体规则年年会变，软件每年的更新，就会变成重体力劳动。 例如，加拿大有政党提出，以后炒卖房产，不再算个人的capital gain，而是business income。 试想，如果这条政策成真，软件的更改不是很麻烦？ 另一个例子，加拿大夫妻联合报税抵扣这件事情，已经改了两次，不排除保守党上台后 再改一次。如果软件不能自己生成逻辑，这样的修改就没有尽头。
【 在 a9 (嗯) 的大作中提到: 】 放心吧，你这软件做不出来 business
【 在 dachouchou (大脚豆) 的大作中提到: 】 你装逼过猛了。讲真，你的智商不足以在一个月内能理解商业逻辑。 你也就写个hello world什么的混吃等死。
【 在 bihai (学得不好) 的大作中提到: 】 你能不能举个例子？没有例子，就像你说红色，他想的是蓝色 我说的例子，是具体的，把税法的一条说出来，然后你要做的中间的那个东西是什么形 式的说出来，最后编程要做什么 business
【 在 lukecn (luke) 的大作中提到: 】 谢谢回复，我举个例子。 IRS有个PFIC-compliant report的规定，简单说，针对美国纳税居民申报持有外国基金 的税务处理,对应的FORM 8621。因为跨境居住的美加居民比较多，所以这个问题还是比 较常见的。 我当然可以把目前的规则HARD CODING到代码里。 但是，关于加拿大的RESP账户，一直存在争议。如果IRS改变主意了，承认RESP和RRSP 具有同样地位，RESP不再属于PFIC了，软件该怎么办呢？ 我当然可以打开EMACS，一行一行改代码。 然后，IRS又改变注意了，承认加拿大的TFSA也具有同样地位。 然后，IRS又承认欧洲的某个国家的基金不是PFIC了（因为其主要投资于美国）。 ...................
【 在 xyz14 (xyz14) 的大作中提到: 】 读懂税法的难度高于alphago下围棋。就这么简单。不要再浪费时间了。 RRSP
【 在 bihai (学得不好) 的大作中提到: 】 不如让政府规定税法的时候就用编程语言来描述。 当年国防部要供货商提供芯片，用语言描述总是不准确，然后发明了一个语言叫VHDL。 RRSP
【 在 lukecn (luke) 的大作中提到: 】 呵呵，时代问题，毕竟税法的历史，比编程语言悠久得多。 不过我读税法的时候，感觉逻辑是相当清晰的。 一旦你习惯了其语言风格，就会发现，其实挺简单的。 这种法律文书的特点就是，"不说人话“， 本来非常common sense的东西，它总要用复 杂拗口的方式说出来，宣称是为了严谨。 http://laws-lois.justice.gc.ca/PDF/I-3.3.pdf
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 Full Stack， 听完客户BB后， 能一个人出方案，然后自己分层，做数据库，写前后台，写UI的码农。
【 在 lukecn(luke) 的大作中提到: 】<br>: 呵呵，时代问题，毕竟税法的历史，比编程语言悠久得多。<br>: 不过我读税法的时候，感觉逻辑是相当清晰的。<br>: 一旦你习惯了其语言风格，就会发现，其实挺简单的。<br>: 这种法律文书的特点就是，"不说人话“， 本来非常common sense的东西，它总要用复<br>: 杂拗口的方式说出来，宣称是为了严谨。<br>: http://laws-lois.justice.gc.ca/PDF/I-3.3.pdf<br>
【 在 juky(juky) 的大作中提到: 】<br>: 实际上pker说的不错 不知道为啥生气了<br>: 你要的核心就是一个解释器<br>: 最复杂的情况 <br>: 解释器可以直接解读税法。哈哈<br>: 中间情况 <br>: 你解读税法 总结 然后解释器再解读你的总结<br>: 最简单的情况<br>: 你直接写code 或xml yml json<br>: 解释器（现成的）解读<br>: 总之。嘿嘿<br>
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】 法律的复杂性和软件的复杂性是类似的。 都是因为有人钻空子，所以补丁加补丁弄出来。 你看到了common sense工作的一面 没看到common sense不work的一面。 这点你都不明白，我看还是别做了。 呵呵，时代问题，毕竟税法的历史，比编程语言悠久得多。 不过我读税法的时候，感觉逻辑是相当清晰的。 一旦你习惯了其语言风格，就会发现，其实挺简单的。 这种法律文书的特点就是，"不说人话“， 本来非常common sense的东西，它总 ...................
【 在 lukecn (luke) 的大作中提到: 】 谢谢回复，您很靠谱，洞察了问题的复杂性。 不过我要乐观一些，不同if/then之间的关联性也是可以用规则描述的。 请问您推荐什么语言来实现这些if/then的定义（或者说"生成“更合适）？
【 在 lukecn (luke) 的大作中提到: 】 例如，加拿大有政党提出，以后炒卖房产，不再算个人的capital gain，而是business income。 试想，如果这条政策成真，软件的更改不是很麻烦？ 另一个例子，加拿大夫妻联合报税抵扣这件事情，已经改了两次，不排除保守党上台后 再改一次。如果软件不能自己生成逻辑，这样的修改就没有尽头。
【 在 sunshineboy (阳光男孩) 的大作中提到: 】 pker大牛 听您说话很有道理 咱虽不能至 心向往之。 不知道大牛有github否？ 想 过去瞻仰瞻仰 学习学习。。。p
【 在 lukecn(luke) 的大作中提到: 】 还是回到sematics parsing的话题吧。 想讨论税法的话，另外开贴吧。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】 你上来问语言选择。那么这个水平自己玩玩prototype 可以。 法律语言的机器处理我不看好你能做出来产品。 还是回到sematics parsing的话题吧。 想讨论税法的话，另外开贴吧。
【 在 lukecn (luke) 的大作中提到: 】 越说越岔开了，哪里有什么”法律语言的机器处理“呀。 前面有人拿alphago说事，我就举个例子，说明税法虽然繁复，但是有明确的逻辑，仅 此而已。 我只是想把税法的计算规则抽象一下而已，免得年年修改源代码。
【 在 echowuhao (echo) 的大作中提到: 】 我只是想把税法的计算规则抽象一下而已，免得年年修改源代码。 你先具体再抽象 把一年的搞出来，另一年在搞，第三年就知道咋抽象了。 一步到位，我不觉得现在的技术水平可以做到。 语言这没啥关系，如果你不知道哪个，Python。 Perl的话，我之前是靠Perl 吃饭的，不看好。
【 在 bihai (学得不好) 的大作中提到: 】 一看就是有经验的，我也支持这种先搞两年。 如果规则就是if/then，我支持用lua来写。但是无论怎么写，这些规则的代码都要每年 更新。这个想法我觉得不是创新。我觉得现在的那些可以用的网站和软件就是这样做的 。大不了规则是jar文件写的，每年下载一个新的，通过reflection可以调用。用DLL也 行，也可以每年更新逻辑，不改UI等其他部分。 如果规则是更高级的抽象，大概得定义一种税法语言了。
【 在 lukecn(luke) 的大作中提到: 】 大概知道怎么抽象税务方面的概念。 现在思考的问题是，选用合适的语言，对抽象后的概念，做semantics parsing。 首选是lisp family的成员。 python qt我会用来做UI，但不会用来做核心。
【 在 lukecn (luke) 的大作中提到: 】 我说说我的想法吧。 两个备选项。 一个是在lisp家族里选一个。 另一个是algol家族成员，先用perl，如果性能还过得去，就这么着了。如果性能不行 ，就用perl做prototyping，再用c实现。 我说的是核心模块，UI随便。为了跨平台，选用python+qt的可能比较大。
【 在 lukecn (luke) 的大作中提到: 】 大概知道怎么抽象税务方面的概念。 现在思考的问题是，选用合适的语言，对抽象后的概念，做semantics parsing。 首选是lisp family的成员。 python+qt我会用来做UI，但不会用来做核心。
【 在 laoqintow (lqt) 的大作中提到: 】 楼主所指： ------------------------ 专用的”symbolic table" ------------------------ 看看我理解得对不对。 假设税法大都永远不变，但仅税率不断在变。那么这个”symbolic table"只需记录税 率即可。每次改税率数值，软件不用变。这样楼主的目的就实现了。 但实际上，税率之外还有其他的逻辑也在变，那么这个”symbolic table"如也能记录 下这些变动的逻辑，当税法变化时，只需改变这个”symbolic table"，软件不用变。 这样楼主的目的也就实现了。 ...................
【 在 lukecn (luke) 的大作中提到: 】 没打算用软件去读税法（这个远超出我能编程的范畴）。解读自然语言这一步，目前还 是人来做比较靠谱。 我来读税法，根据我对税法的理解，去更新这个symbolic table。 symbolic table里不含任何程序逻辑，只是一套纯粹的自定义标记方法；这些标记经过 semantics parsing后，产生运算逻辑（税表里的加减乘除）。 我的问题是，用什么语言做semantics parsing？ 我的初步想法是lisp或者perl/c，想在这个论坛听到有价值的想法。 不是说c#/java不可以，但肯定不是一个好选择。
【 在 bihai (学得不好) 的大作中提到: 】 你先把symbolic table里面的内容给几个例子吧。请给出5个，和原来的税法的内容对 应起来。 产生逻辑的应该没有难度，比如用Java?因为java有很多开源的软件，我看你这个类似 编译程序，解释程序啥的，最适合解释你的symbolic table的内容了。
【 在 lukecn (luke) 的大作中提到: 】 首先，不是和税法的严格对应。其实，机械严格的对应这是我要避免的。 以加拿大税法为例，纳税人有不少于五个表示： individual（个人，工资收入） institutional(例如incorporated） combined（例如sole proprietorship的个人，工资收入和经营收入合并报税） non-atomic（例如partnership) fictional(例如trust） 为防止某人乱喷（不是针对你啊，呵呵），先说明： 这里不适用OO的方法，所以别再发表什么祖母类/继承之类的幼稚言论了。
【 在 Felomeng250 (飞龙猛将) 的大作中提到: 】 估计我是幼稚类的了
【 在 dracodoc (david) 的大作中提到: 】 你要的实际是一个DSL 所以就看DSL如何定义，然后用什么语言去实现这个DSL。 前面有个回帖已经说过了， 税法－人理解－DSL 抽象－语言实现 这几个环节哪个都不能少。人不能少因为AI做不到。DSL不能少因为任何编程语言都不 能直接适合这个任务。 DSL设计的足够好，能让人比较容易写抽象规则就是最大的胜利。
【 在 dracodoc (david) 的大作中提到: 】 DSL就是你问题的核心，根据DSL的需求选择语言实现。你问什么具体编程语言实际都偏 离原意，相当于用编程语言直接当DSL。 如果你一开始就写上那几条税法的例子至少大家知道你了解税法。但你原帖让人觉得是 既不懂税也不懂编程，简直是问问题失败的典型。 当然另一个方面招骂的帖子人气足，一个周到严谨的问题说不定没几个人回答。
【 在 lukecn (luke) 的大作中提到: 】 谢谢回复。 DSL(呵呵，我借用这个大词）当然是类似英语的一种标识法，和具体编程语言无关。: 请问，你建议用什么语言做semantics parsing? 我在lisp和perl之间犹豫，呵呵。 最怕听人说“什么语言都一样”这种话，语言可能没有高下之分，但肯定有不同的适用 领域。 关于说话方式，没办法了，老派的人，从小就知道要谦虚，和那些写了几行C#就自觉天 下无双的年轻人没法比。
【 在 lukecn (luke) 的大作中提到: 】和那些写了几行C#就自觉天下无双的年轻人没法比。
【 在 pker (我要那天再挡不住我眼) 的大作中提到: 】 和无知又年老的人补一句，哥用C写过游戏，用C++写过病毒。 用C#不过是这是一个能以最低付出获取最大利益的语言。 你们这些老东西，一辈子就钻一个眼里， 从来没从哲学/人生高度看过全局， 整天和孔乙己一样嘲笑别人不会写茴的四种写法， 因为除了这个，你们再无放在桌面上的东西了。 除了编程以外，哥再指点你一把人生： 人来这个世界上是为了快乐，不是为了工作，也不是为了创业， 就像哥现在说你，也是哥的众多娱乐方式之一。 和那些写了几行C#就自觉天下无双的年轻人没法比。
【 在 Simeone (迭戈 西蒙尼) 的大作中提到: 】 卧槽，“人来这个世界上是为了快乐”忒牛叉了，几句话话糙理不糙。兄弟你在哪里， 有机会一起喝酒吹吹牛B行不？
所以想定义一个规则库，每年只需要更新规则，然后软件根据规则的semantatics（不
是syntax），自动生成各种计算规则。
目的很简单，就是报税软件能自我更新，不要把每年的维护更新变成一项体力活。
请高手指教。
########################################################
我想实现的软件能够“重新生成自己”。
简单说，每年都会根据本年度报税规则的微调，重新产生运算逻辑。
所以，业务逻辑（报税规则）的定义，需要经过抽象。抽象后的规则独立于软件之外（数据库，xml，json，甚至纯文本均可）。每年只需要更新这些抽象的规则。
如果不经过高度的抽象，而定义具体的运算逻辑，每年的更新就会变成代码层面的体力劳动。
########################################################
每年，由我来定义（经过抽象的规则），核心模块会做semantics parsing, 生成相关
的计算规则，从而生成新一年的软件版本。
简单说就是，我不想每年都修改代码，来适应税务规则的微小调整，这种我称之为”体力劳动“。
########################################################
说说我的想法。开始不说，是怕影响大家的思路。
两个备选项。
一个是在lisp家族里选一个。
另一个是algol家族成员，先用perl，如果性能还过得去，就这么着了。如果性能不行
，就用perl做prototyping，再用c实现。
我说的是核心模块，UI随便。为了跨平台，选用python+qt的可能比较大。
粗略来说，perl的template toolkit可以“模拟”。把业务逻辑放在perl里，template toolkit只用来产生presentation logic.
这里的计算规则，可以类比presentation logic。
当然了，这只是个比方，肯定达不到我所期望的灵活性。
我假设你这是做东西卖的，不是自用的。
也不是做slides出去吹效果的。
经常要自己改的程序才需要
表达功能强大的。
程序需要更改的频率越高，越需要
表达能力强大的语言。我天天改算法，所以需要表达能力强
速度又快的。但是商业软件，尤其是业务逻辑复杂的，
按你这个来bbs找答案的水平，
我个人的浅见，一定是c#,java最好。
还聊什么核心，模块。
给个大概吧，抛玉引砖 :D
#1
DB/tables：
users(基本信息)
userR(用户相关信息，夫妻，子女等等，联合报税)
userExt（拓展信息，商家，个人等等）
years(年份相关数据数据)
Formulas(各种规则)
#2
核心只有一个，就是根据formula的文本解析成代码
类似对字符串"if(var1>std1),then var1=var*120"
#3
实现就是把所有的数据调出来后，喂进解析核心，
解析核心再导入公式出各种结果report。
功能实现上属于小学生级别，完全没有难度。
traffic处理方面也不存在难度，低流量。
唯一要注意点的就是加密解密，因为数据敏感。
如果web base，那就更要小心更小心。
身份验证方面可能也要注意下。
真的要做这种商用软件，唯一可以拉开差距的就是UI。
各种数据的数据类型能定下来？输入的default value?
用户如果是做生意的，国际生意的，炒股的，...
现在这种小项目，不需要团队协作的，谁还花2天写需求啊。
当然2天有点夸张了，一星期应该可以搞定。
Agile Agile Agile 重要的事情说三遍。
这种规模的软件，先上个FS的码农2，3天写完。
然后看看IRS或者找个会计所弄批数据过来TDD，搞定。
然后泡妞看片打游戏3星期，交货！
听完客户BB后，
能一个人出方案，然后自己分层，做数据库，写前后台，写UI的码农。
c#我可能用来做UI，desktop版本的软件用WIN FORM是最直接的，linux平台可能用
python+qt。
不过这个不是重点，现在只讨论核心，不用理会UI。
请看我顶楼的更新。
把if then抽出来也没有帮助。因为一旦加进去，你也不知道会影响其他的if then。
所以我设计的时候把这些东西直接放公式table里面，
也可以放xml之类的里面，
这部分不是开发需求，是用户自定义的。
负责解释formula里面的任何规则，
用什么语言写根本无所谓，
目测最方便是用python。
从最简单或最复杂的例子开发，然后调整。
比如：
隔壁老王，
W2:100K
1099:50K
State:CA
Married: True
Donation: 1k
Loan Tax: 10k
xxx Tax: 5k
规则部分：
Tax=W2*(federal%+CA_state%)-married%-donation-loanTax%...
然后#1解释器负责解释规则公式动态生成计算公式，
数据传递给#1生成的计算公式，出结果。
raw结果可以做成report，那就不是核心的东西了。
我只是写个最简单的，大概就这样
这部分不是开发需求，是用户自定义的
******************************
我问大家的，就是怎么做这一部分。
至于具体的计算，如你所说，小学三年级的算术而已。
不过我要乐观一些，不同if/then之间的关联性也是可以用规则描述的。
请问您推荐什么语言来实现这些if/then的定义（或者说"生成“更合适）？
每年，由我来定义（经过抽象的规则），核心模块会做semantics parsing, 生成相关
的计算规则，从而生成新一年的软件版本。
简单说就是，我不想每年都修改代码，来适应税务规则的微小调整，这种我称之为”体力劳动“。
leetcode上有几道类似的题说的就是这个，
具体实现肯定要花点时间。
说到底就是解释器，
就像你在c#里面打 int y=2x+1;
解释器读进去执行，
你要做的是同样的事情，只是比它简单。
要用到复杂税法的，肯定是雇佣会计师甚至团队。
overkill是软件开发的一个大问题。
#1 第一笔钱
做一个简单不复杂，UI炒鸡方便的报税软件，
满足大部分普通用户需求。
#2 第二笔钱
对于复杂，大客户，提供相关行业专业会计团队，
从中抽成
#3 第三笔钱
形成自己的专业会计团队，提供专业方案卖钱。
请问，您推荐用什么语言来实现这个解释器？
起码，你多了一个验证会计师是否靠谱的途径。
UI界面可能很傻瓜，但这和“简单”是两码事情。
我的目标就是要实现复杂的税法规则，而不是做简单运算。
所以才在这里请教，因为我的知识结构陈旧，20多年前就离开大学了。想在这里跟大家学习下最新的进展。
其实我心里大概也有一些概念，不过我先不说，免得限制了大家的思路。
这个而不是turbo tax 哦人hrblock？你有什么他们没有的？
我自己也有很多各种古怪的项目在run。
我回答你问题只是回答，没其他想法。
其他的随便说说。
你说的问题是市场，推广的人要考虑的，
这个往深了没有底的，也不可能真的花多少精力下去的。
我不知道遇见多少一拍大腿出个idea的人，
大概结果如下
#1
一部分人说过就忘了，
#2
一部分就是上网问问然后就丢一边了，
#3
也有觉得自己多牛逼，白手套狼的忽悠别人帮他做，
这种往往是给你画个蛋糕，说他有多少关系，多少背景，
然后忽悠你给他低价做。
对这种人我就一句话，你他妈的还没我有钱，连个市场价格的码农都请不起
你他妈的也好意思忽悠我，滚你妈一边去。
#4
有些还真的砸锅卖铁去做的，我有些客户就这样，
自己省吃俭用，但是按市场价开发费用一分不少交过来，
不跟你废话其他未来大蛋糕。
这种人我从心里是尊敬他们的，
但是现实是残酷的，大部分这种人到最后除了一个失败的创业经验啥都没。
这么说吧，只要做出一个州的，后面的就好办了，呵呵。
semantics parsing/code generation，本质上和写编译器是一样的，当然要简单一些
，因为税务规则毕竟是个有限集合。
但是似乎这里的人只知道c#/java。
期待高手现身。
你可能coding很快，可能会玩一些fancy的东西，但是，你敲键盘的速度，远远高于大
脑进行严肃思考的速度。
你就是一个穷逼老狗，一把年纪了也没做成什么事情。
十足一个loser，这几天脑发热了想做个软件。
结果发现自己很傻逼已经跟不上形势了，又他妈的没钱。
所以跑到论坛上来问。
瞧你这种傻逼像，老子回答你那么多，不感谢一下，还他妈的忽悠，
知道你为啥老狗一条了还没钱吗？
不是你脑残傻逼，而是你做人有问题，懂吧，
你这辈子也就一个傻逼。
别再网上BB说你多有钱多有背景啥的了，吃屎去吧，
有钱有势有脑子的人早就自己在run了。
不可能像你个傻逼一样，别人给点意见，还说就知道c# java
就知道你妈逼懂吗，问人问题还那么不谦虚，老狗一条，
赶快早点死了，免得浪费空气粮食。
最他妈的烦的就是你这种没钱还BB装蒜的老狗。
不要脏了我的帖子。
我深刻怀疑，高手就是因为你的存在，都不屑于在这里现身。
你这个账号我关注了，见一次骂一次。
换个账号再来吧，
记得拉完屎擦屁股，别直接抹你自己脸上。
哥最喜欢就是抽你这种不要脸的老狗，
明明没钱想免费咨询，还非要装得自己多高大上，
见一次打一次。
我自己就是程序员出身，不会找你这种无知的蠢货咨询。
而且，还是疯狗+蠢货。
瞧你这种傻逼像，老子回答你那么多，不感谢一下，还他妈的忽悠，
知道你为啥老狗一条了还没钱吗？
****************
我忽悠你什么了？你自己不知趣，喋喋不休地暴露你的无知和狂妄。
也许有人曾经忽悠你做项目，我可没有。
从你第一次的回复，我就知道你有多愚蠢了。
****************
别再网上BB说你多有钱多有背景啥的了，吃屎去吧，
有钱有势有脑子的人早就自己在run了。
****************
你神经错乱了吧，我什么时候说”有钱有背景“了。
两个备选项。
一个是在lisp家族里选一个。
另一个是algol家族成员，先用perl，如果性能还过得去，就这么着了。如果性能不行
，就用perl做prototyping，再用c实现。
我说的是核心模块，UI随便。为了跨平台，选用python+qt的可能比较大。
个人感觉商业前景不小。
pker所指的软件开发工作量可能不包括这些规则，所以相对而言是有点微不足道。感觉用什么开发语言无所谓，用一个熟悉的即可。三年也许够了？
如需找一个语言表达规则，则需对规则有详细了解，才能判断语言是否合适。有谁对税规详细了解吗？
也许可以自创一种语言或数据结构定义，系统内部自用，随着对税规了解的深入，不断完善
我说的”规则“，是有关税法的，但是要经过抽象，不是具体规则，而是用来产生运算规则。
因为具体规则年年会变，软件每年的更新，就会变成重体力劳动。
例如，加拿大有政党提出，以后炒卖房产，不再算个人的capital gain，而是business income。
试想，如果这条政策成真，软件的更改不是很麻烦？
另一个例子，加拿大夫妻联合报税抵扣这件事情，已经改了两次，不排除保守党上台后再改一次。如果软件不能自己生成逻辑，这样的修改就没有尽头。
你也就写个hello world什么的混吃等死。
哪种编程语言，并不是核心问题。这个项目在局部范围可能可以做到，但是要完全的正确目前暂时无解。
这傻逼的需求主要是对TAX规则进行解析，不存在商业逻辑问题。
还有写hello world能混吃等死的
比写平衡二叉树混吃等死的智商高不是一点点。
我说的例子，是具体的，把税法的一条说出来，然后你要做的中间的那个东西是什么形式的说出来，最后编程要做什么
IRS有个PFIC-compliant report的规定，简单说，针对美国纳税居民申报持有外国基金的税务处理,对应的FORM 8621。因为跨境居住的美加居民比较多，所以这个问题还是比较常见的。
我当然可以把目前的规则HARD CODING到代码里。
但是，关于加拿大的RESP账户，一直存在争议。如果IRS改变主意了，承认RESP和RRSP
具有同样地位，RESP不再属于PFIC了，软件该怎么办呢？
我当然可以打开EMACS，一行一行改代码。
然后，IRS又改变注意了，承认加拿大的TFSA也具有同样地位。
然后，IRS又承认欧洲的某个国家的基金不是PFIC了（因为其主要投资于美国）。
然后，IRS又承认百慕大的某个基金不是PFIC了。
然后。。。。。
可是我不想这么做，不想把每年的软件更新变成一项体力劳动。
所以，我想把税法的具体规则抽象出来，用一种类似简单英语的表示方法，存在JSON里。
每年开春，我就根据IRS的新规则，更新一下这个JSON文本，然后软件会对其做
semantics parsing，产生新的运算规则，并生成新的版本。
我发帖的目的，就是想请问这个做parsing的软件，有什么更好的选择？
（我目前想到的是lisp family，或者Perl/C).
这只是个例子，如果仅限于此，问题是可以通过template和regex解决的。
而税法包罗万象，各种因素交叉作用，复杂度远高于此，必须通过semantics parsing
才能真正避免hard coding.
我解释清楚了吗？
当年国防部要供货商提供芯片，用语言描述总是不准确，然后发明了一个语言叫VHDL。
不过，你拿税法和围棋相比，太夸张了.
我读过加拿大的税法，逻辑条理清晰.http://laws-lois.justice.gc.ca/PDF/I-3.3.pdf
不过我读税法的时候，感觉逻辑是相当清晰的。
一旦你习惯了其语言风格，就会发现，其实挺简单的。
这种法律文书的特点就是，"不说人话“， 本来非常common sense的东西，它总要用复杂拗口的方式说出来，宣称是为了严谨。
http://laws-lois.justice.gc.ca/PDF/I-3.3.pdf
你要的核心就是一个解释器
最复杂的情况
解释器可以直接解读税法。哈哈
中间情况
你解读税法 总结 然后解释器再解读你的总结
最简单的情况
你直接写code 或xml yml json
解释器（现成的）解读
总之。嘿嘿
都是因为有人钻空子，所以补丁加补丁弄出来。
你看到了common sense工作的一面
没看到common sense不work的一面。
这点你都不明白，我看还是别做了。
但是pker对问题的难度可能估计过低了。
最简单的算账问题。
有个问题我以前做过，例如几十张表，按元统
计和按万元统计的不同口径，会破坏A B=C
这样的关系。那么就会出乱子。
这种问题最后只能问用户如何trade off。
你问任何一个炒股的，都会对TD这种大
券商的统计有个人意见。这里不好，那里不好。
这是因为大券商出的东西是平均需求的。
就是说对一个需求的开发，会产生新的需求。
会一拖再拖。
想讨论税法的话，另外开贴吧。
客户最后把逻辑全部放到了sql的stored procedure。
前台直接通数据库。没有用任何语言。牛逼吧。
为什么了？
因为SQL developer比较便宜。
所以很多传统行业都用stored procedure。
所以，会计这一行现在没法disrupt。
因为税法天天变。即使一个SQL developer，也不一定比养个会计便宜。
等十年以后，AI发达到可以自己读书写逻辑。会计就会被马工取代了。
你说的这2个例子，其实就是看设计/抽象的功力了。
比如说房地产收益，可以抽象成收益，
至于是按个人还是按商业走，算是收益的类型，
每种类型针对不同扣税比例%，复杂一点可以针对不同的公式。
如果这样走的话，你代码部分就不用改，只是改一个收益类型。
夫妻联合保税这种也可以抽象成类似coupon code的做法，
每年一个code，每个code针对不提供比例，或者公式。
商业逻辑我不懂，但是任何商业应用开发，就是一个抽得上去，收得回来的问题。
你这个小破软件，规则再复杂，
你抽象抽得好，祖母级别的class写得好，配合relationship关联，后面就代码维护就
省力。
但是凡事都有好的一面，必然也有坏的。
你抽象也要抽到某个平衡点，抽过头了，自己下面集成的时候累死，
比如抽象到尽头，那就是语言本身了。
语言没什么太多区别，
有些本身native带各种功能的，
有些framework支持多的，
开发起来没区别。
再说现在这世道，作为一个码农，还要纠结语言，只能说你学习能力太慢了。
哥刚起床给你说几句，有用没用你自己想想，
哥现在要出门冲浪去了，晚上回来再看看你这怂人有啥说的。
这葵花板块至少一半码农的技术能甩我几条街。
我只是好管闲事，不管自己水平如何，都喜欢给人出出主意，顺便刷脸装个逼
很惭愧的说，之前一直在用c#，啥东西都放tfs
至于github，空有一个账号
法律语言的机器处理我不看好你能做出来产品。
前面有人拿alphago说事，我就举个例子，说明税法虽然繁复，但是有明确的逻辑，仅
此而已。
我只是想把税法的计算规则抽象一下而已，免得年年修改源代码。
你先具体再抽象
把一年的搞出来，另一年在搞，第三年就知道咋抽象了。
一步到位，我不觉得现在的技术水平可以做到。
语言这没啥关系，如果你不知道哪个，Python。
Perl的话，我之前是靠Perl 吃饭的，不看好。
现在思考的问题是，选用合适的语言，对抽象后的概念，做semantics parsing。
首选是lisp family的成员。
python+qt我会用来做UI，但不会用来做核心。
如果规则就是if/then，我支持用lua来写。但是无论怎么写，这些规则的代码都要每年更新。这个想法我觉得不是创新。我觉得现在的那些可以用的网站和软件就是这样做的。大不了规则是jar文件写的，每年下载一个新的，通过reflection可以调用。用DLL也行，也可以每年更新逻辑，不改UI等其他部分。
如果规则是更高级的抽象，大概得定义一种税法语言了。
本质上，我要的是semantics parsing。
我不愿意用"税法标记语言“ 这种 ”大词“（低调，低调，呵呵），不过你既然提到
了，我想要来定义税法规则的，就是一套专用的”symbolic table"。
每年更新的”规则代码“，我需要系统自动生成（我只需要在symbolic table做很少的改动）。
否则，每年的更新就变成了体力劳动。
坦率来说，做一个只能处理简单税务情况的报税软件，完全没有意义（无论是技术上的，还是商业上的）。在这一点上，我和某个喜欢骂人的ID意见是一致的。
Python根基不稳
有道理。
上面楼主贴的加拿大税法，3164页，英法双语。所以英文版约1600页。有可能通读后，用它几年，辅之以几本好点的教科书，领悟形成一个合适的抽象框架。想来大部分纳税人的需求以及相关税规是就可以用合适的数据结构或语言来描述了。
相比之下，美国所得税法约75000页。通读怕是不现实，一个人一生能读几页专业书？
哪怕小学课本也算。现在AI/ML软件水平怕也还不够。估计以现在软件水平，只能将税
规逻辑分割成小块，逐个击破。
如果人都搞不懂这些税规逻辑，现在的软件水平估计也难以实现。
统江湖了。
所以就看DSL如何定义，然后用什么语言去实现这个DSL。
前面有个回帖已经说过了，
税法－人理解－DSL 抽象－语言实现
这几个环节哪个都不能少。人不能少因为AI做不到。DSL不能少因为任何编程语言都不
能直接适合这个任务。
DSL设计的足够好，能让人比较容易写抽象规则就是最大的胜利。
------------------------
专用的”symbolic table"
------------------------
看看我理解得对不对。
假设税法大都永远不变，但仅税率不断在变。那么这个”symbolic table"只需记录税
率即可。每次改税率数值，软件不用变。这样楼主的目的就实现了。
但实际上，税率之外还有其他的逻辑也在变，那么这个”symbolic table"如也能记录
下这些变动的逻辑，当税法变化时，只需改变这个”symbolic table"，软件不用变。
这样楼主的目的也就实现了。
楼主是想用软件去读税法，再填入这个”symbolic table"，还是这个”symbolic
table"本身就是一些软件片段（如某种script language，楼主想选一个合适的）？
我来读税法，根据我对税法的理解，去更新这个symbolic table。
symbolic table里不含任何程序逻辑，只是一套纯粹的自定义标记方法；这些标记经过semantics parsing后，产生运算逻辑（税表里的加减乘除）。
我的问题是，用什么语言做semantics parsing？
我的初步想法是lisp或者perl/c，想在这个论坛听到有价值的想法。
不是说c#/java不可以，但肯定不是一个好选择。
Perl
regexp：：grammar
或者 marpar
各种语言都有类似的
跟你说了 一开始 完全没必要搞这个 先手动弄好再说
应起来。
产生逻辑的应该没有难度，比如用Java?因为java有很多开源的软件，我看你这个类似
编译程序，解释程序啥的，最适合解释你的symbolic table的内容了。
以加拿大税法为例，纳税人有不少于五个表示：
individual（个人，工资收入）
institutional(例如incorporated）
combined（例如sole proprietorship的个人，工资收入和经营收入合并报税）
non-atomic（例如partnership)
fictional(例如trust）
为防止某人乱喷（不是针对你啊，呵呵），先说明：
这里不适用OO的方法，所以别再发表什么祖母类/继承之类的幼稚言论了。
不过我如果一开始多用几个“大词”，也许就不用有人进来胡喷骂人了。
如果你一开始就写上那几条税法的例子至少大家知道你了解税法。但你原帖让人觉得是既不懂税也不懂编程，简直是问问题失败的典型。
当然另一个方面招骂的帖子人气足，一个周到严谨的问题说不定没几个人回答。
DSL(呵呵，我借用这个大词）当然是类似英语的一种标识法，和具体编程语言无关。
请问，你建议用什么语言做semantics parsing?
我在lisp和perl之间犹豫，呵呵。
最怕听人说“什么语言都一样”这种话，语言可能没有高下之分，但肯定有不同的适用领域。
关于说话方式，没办法了，老派的人，从小就知道要谦虚，和那些写了几行C#就自觉天下无双的年轻人没法比。
你这样的年纪一把，成就啥都没的老人基本都这个德行，
说不起，一说就急眼，急了就摆出一副倚老卖老的德行，
摇摇头叹气说，现在的年轻人如何如何，
也不想想自己为啥那么一把年纪了还被比自己年纪小的说。
之前论坛有个叫wei叫兽的，也是这德行，
我也追着骂了他很久，并不是说他的技术好不好，而是那种嘴脸实在让人厌恶。
要么你猛如吕布，天下无双，
要么就谦虚一点，
别除了年龄大啥都没，还摆出一副历经沧桑，博览天下众生的嘴脸。
实在让人反胃。
哥也不是什么年轻人，哥有些同龄的同学朋友和90，95后共事，
动不动就感叹现在年轻人如何不懂事，如何自私。
哥都教育他们，我们爸妈这代人也这么看我们，
但是社会一直进步，记住，年轻人永远比我们更厉害，更有远见。
不要用自己的生长环境经历去衡量年轻人。
用C#不过是这是一个能以最低付出获取最大利益的语言。
你们这些老东西，一辈子就钻一个眼里，
从来没从哲学/人生高度看过全局，
整天和孔乙己一样嘲笑别人不会写茴的四种写法，
因为除了这个，你们再无放在桌面上的东西了。
除了编程以外，哥再指点你一把人生：
人来这个世界上是为了快乐，不是为了工作，也不是为了创业，
就像哥现在说你，也是哥的众多娱乐方式之一。