- 主题:喜讯！KiCAD 6.0正式发布了！
rt，版主们不趁机搞个撒积分冲十大的活动吗？
--
FROM 183.192.12.*
为甚要如此冲动?
【 在 nlgdczm (xxx) 的大作中提到: 】
: rt，版主们不趁机搞个撒积分冲十大的活动吗？
--
FROM 120.244.220.*
不支持Win7，如之奈何？
【 在 nlgdczm (xxx) 的大作中提到: 】
: rt，版主们不趁机搞个撒积分冲十大的活动吗？
--
FROM 222.90.31.*
赞，喜迎py 3. Netlist 是不是没了
【 在 nlgdczm 的大作中提到: 】
: rt，版主们不趁机搞个撒积分冲十大的活动吗？
--
FROM 198.135.57.*
netlist在kicad6里在底层就彻底干掉了。
当然你一定要导入导出netlist也不是不可以，类似与导入其他eda做的设计一样了。
【 在 oddman 的大作中提到: 】
: 赞，喜迎py 3. Netlist 是不是没了
--
FROM 180.158.54.*
装了6,确实被从流程里移除了，转移到菜单里了
【 在 lvsoft 的大作中提到: 】
: netlist在kicad6里在底层就彻底干掉了。
: 当然你一定要导入导出netlist也不是不可以，类似与导入其他eda做的设计一样了。
:
--
FROM 216.250.255.*
要导出netlist不需要命令行。
python在kicad里面以前的地位是用来做第三方插件的。
以后python会在里面占据越来越重要的主体地位。
其实我是不太认同很多老软件的设计思路的。比如kicad，比如linuxcnc。
都tm喜欢用c++这种复杂难驾驭的语言。弄了半天事情没做多少，麻烦倒是制造了一堆。
我一向的观点，python搞定一切，python搞不定的部分c搞定一切就行了。
搞c++的人老是喜欢追求毫无意义的zero abstraction，把简单问题复杂化，这算是一种病。
【 在 StrongLeg 的大作中提到: 】
: py3的作用是？
: 能不能用命令行导出netlist？
:
: ...................
--
FROM 180.158.54.*
老外发布版本也挑选日子吗？圣诞节这天，不管怎样，庆祝一下
--
FROM 125.33.198.*
如果KICAD以后想往大型化工业上发展，必须现在就坚持C/C++啊，毕竟效率在那里摆着。
用python除非就是想在圈子里小打小闹
【 在 lvsoft 的大作中提到: 】
: 要导出netlist不需要命令行。
: python在kicad里面以前的地位是用来做第三方插件的。
: 以后python会在里面占据越来越重要的主体地位。
: ...................
--
FROM 180.116.89.*
这个就是为啥很多非cs领域的工具进化太慢，进化速度远低于cs领域很多软件的根源...
这个观点是非常常见的偏见：Python比c慢100到1000倍，因为效率不行所以注定干不了大事等等...
作为engineer需要专注系统的平衡，更合理的思维是Python比c慢1000倍不重要，重要的是这带来了什么问题，以及这个代价换来了什么，能否抵消这些损失，是否有远超损失的收益。
在二八效应下，一个系统CPU intensive的部分代码量通常是不大的，这块hot spot用c写就行了。所以我前面说了Python搞不定的地方一切用c搞定。事实上这就是kicad的进化方向。只不过kicad一开始就是纯c++的，现在c++比重还太高，此外c++并不是最适合跟Python打配合的语言。
其实现在很多工作的主体都是类似Python这样的脚本语言承担的，c/c++更像是上时代汇编的地位，变得越来越低层化原子化了。语言进化的趋势应该是提升描述能力，提升人写代码的效率，而不是去追求让代码执行的更快，后者是编译器的事情。比如ai领域极端追求执行效率，然而执行逻辑都是用Python描述的。
当然，Python在大型工程里也是有它的问题的，但不在执行效率这块，主要是大型软件系统的管理方面。但管理的问题其实也不是技术问题，更像是不同语言原生的习惯带来的风格差异问题。Python一样有超过100万行规模的大规模项目，只不过这个时候Python的灵活性优势也失去的差不多了就是...
【 在 dismoon 的大作中提到: 】
: 如果KICAD以后想往大型化工业上发展，必须现在就坚持C/C++啊，毕竟效率在那里摆着。
: 用python除非就是想在圈子里小打小闹
:
--
FROM 39.144.40.*