charlie21

与其说 “能加钱解决的问题都不是问题”
不如说 “能加钱解决的问题，加钱反而不是最好的解决方案”

有些解决问题的解决方案
其实是创造问题、创造更大的问题
但是只要人们把 “更大的问题” 说成不是问题
那么问题就真的解决了

vscode 用 electron 就很注意节省内存，在 1G 内存的电脑上运行是一点都不卡
但你指望所有人都向 vscode 开发人员看齐吗？

有心无力的人很多
无心无力的人更多
有心有力的人很少，但应该更多

无心无力的人说，用 xxx 本身就是为了短平快上手难度低平台通用性好 ...

当然了，大家也要吃饭，哪有那么多时间去注意节省内存！！！加内存就能解决的问题，居然想省钱，有毛病啊真是穷人屁事多呢

2 天前

回复了 Chad0000 创建的主题 › 奇思妙想 › 关于铁路的买票问题，我有一个点子不知该不该讲

lz 提出的做法是，火车的 “不需要停车” 的车厢直接走人，让火车的 “需要停车” 的车厢停下
现实的做法是，火车整个停下，火车站增加可停泊的火车数量（增加站台数量）来让人们 “智能地” 去到自己的车厢里

也就是说，lz 说的这个已经不是那种 “必须整个停下” 的火车了。也就是，这是一种新型火车 + 新型火车站 + 新型火车调度机制 + ... + （最后绕了一大圈子）新型火车票，基于新型火车票故而买票问题解决了

也就是说 lz 已经直说了：买票问题的解决是，而新型火车票 need support from (aka consume) 新型火车调度机制 + 新型火车站 + 新型火车 + 一个新型系统，这是一个系统解决问题的思路而且提出的新系统和老系统的兼容性是 0 。

2 天前

回复了 Chad0000 创建的主题 › 奇思妙想 › 关于铁路的买票问题，我有一个点子不知该不该讲

火车票载客量大、火车票价格低，综合起来让单人票价低到当前这个程度，这完全不足以促进当局在火车出行整体方案的层次上，做出任何变革。

有什么变革的动力呢？ lz 这个方案让火车运营成本更高了，本来停靠 5 分钟就可以开车的事情，人们上下车都来不及，现在居然还要解锁车厢至少得停靠 10 分钟吧，而若每个站停靠的时间翻倍，则整个全国铁路运行时刻表都得变得更紧凑（但 lz 可肯定说，技术发展本身就蕴含着必将让高成本的东西变成低成本，你可以 AI 智能安排先下车的人自动坐在靠近车门的座位 + 每一站停车时候让整车厢的人们换一次座位这就能 .... ）

2 天前

回复了 keyboardCat 创建的主题 › 程序员 › vue 学了两个月了还不会，是否不太适合前端这条路

vue 社区没有做任何心智模型方面的倡导，这是它的失败之处：它把自己当 jquery 了，但 client side SPA 的复杂度摆在那里。这方面：
可以看看经典 GUI 模式 MVC
可以看看 MDN 的一个 vue guide
https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_getting_started
然后看看 react guide 甚至看看 MVC 在 react 里的应用什么的（虽然是错的）
最终能找到设计模式 / 心智模型方面的感觉：写起来更快

3 天前

回复了 visonme 创建的主题 › 问与答 › 说说你坚持学英语理由

向下兼容一种落后的语言、文化、思想。

5 天前

回复了 FlyingBackscratc 创建的主题 › 职场话题 › 应届生找不到工作的话有没有什么非编程类的工作能做的？有没有生活经验丰富的老哥给点建议

先入行，然后等就业环境差的时候苟着，等就业环境好的时候高升或跳槽。

你这科班想远离的行业，恰好是很多素人还想入行

5 天前

回复了 LeeReamond 创建的主题 › 生活 › 出差落地接风宴有感，为什么很多男人 30 岁后开始中年发福

男人身材发福变猪咯，最后就是红猪

6 天前

回复了 ChrisFreeMan 创建的主题 › 程序员 › 推上看到的今天的热门讨论关于独立开发是否更适合 JavaScript 而不是 TypeScript

穷人说，鱼翅不好吃。

6 天前

回复了 cjban 创建的主题 › 职场话题 › offer 怎么选？出国还是国内央企？

两个 offer 是给谁的？是给一个女人 or 给一个男人？

7 天前

回复了 cxhello 创建的主题 › Ruby on Rails › Ruby on Rails 国内使用情况

从头到尾写，不必考虑历史代码 / 现有业务逻辑，这是业务逻辑复杂度低

往老代码上堆加新代码 / 新业务逻辑，就会复杂，这是业务逻辑复杂度高

业务逻辑复杂度的高低决定了能用时间的多少。只要业务逻辑复杂度低，那么没有什么可能出错的地方，用任何技术栈都会很快的，因为这就是一个简单项目（从零建站用 java spring boot 也可以很快）

业务逻辑复杂度高的，就会消耗多的时间去处理业务逻辑本身的问题（即使用 ror 也会慢）

» charlie21 创建的更多回复