@james122333 需求

@HolmLoh

然而即便是如此扩展能力也是差强人意
只是从难写变成还可以 一个特殊虚求基本上就趴了 或者绞尽脑汁费脑力体力才想出

另外 java 框架是目前觉得最麻烦的

以前我也觉得不要造轮子 现在觉得深入研究轮子如何使用简直是找罪受 然后解决的问题就那么一点 很多产物压根不用户友好的 很多原因造成这样的结果 对这类成果的基本上只有刻意过度设计的想法 花费很多时间在无意义的癥结点上 对于工作上的顺利并无帮助

这需求可以

其实还会特地複杂化方案 为了市占又心不甘情不愿 写好分享不然就乾脆不分享看来是很少见的事

@mikaelson

写更优雅的脚本

git 确实比较复杂 所以有人一直在问图形化工具 但如果熟悉命令行其实也还可以 这种工具到一定程度其实用起来没差很大 会基本的已经足够使用 git 就两个卖点一个分支一个本地 commit 一个分支不同实现与需求实作中然后要改其他分支的东西更崩溃 怕一不小心操作错误就重来了 这时候手动操作也未必不可
分支多合起来能不能正常是问题没错

因为同个 ip 就是 I==$1 会判断正确
话说这脚本写的不是一般的差 效能差又不优雅

@Austaras
这是地图炮吗？
不过果然就是政治问题

@jiyinyiyong
然而除了类型他还是可以做很多其它无语的事情 全都限定的话一下子就被需求考倒
不过有志气 的确没完美语言就是 自建起码很舒畅

@wunonglin
语言会进化 脚本也可以做很多事情
并不是有类型才能做工程 语言特性发挥的好以及不複杂化问题及解方才是工程顺利因素
能达成这个目的做工程有何不可

@wunonglin
类型有带来好处也有坏处 坏处大于好处的时候就是不可维护性 弱类型同理 说到底还是看人如何使用

@BoringTu
必须得说实话搂 语言特性与可维护性本来就没有必然关联 惯不惯而已 都有长处和短处
有政治因素或利益考量照样难以维护
也觉得 oop 有点走火入魔 而弱类型能实现强类型本身就归功于弱类型特性 弱类型加上"简单"数据结构个人觉得还是可以的

为了这主题... 个人的话也比较喜欢弱型别 强型别的语言就算工具再怎么成熟动态性也是不能比的
至于多人协作 这完全就是人习惯好不好的状况 强型别照样可以写的一坨难以维护的代码 转型问题、因物件特性带来的耦合都是很麻烦的 很容易造成历史问题 接手项目两种语言会有不同的问题点
这到最后一切就是根源政治没错 我都觉得自己用的最舒畅 独孤九剑