V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 1 页 / 共 92 页
回复总数  1830
1  2  3  4  5  6  7  8  9  10 ... 92  
211 天前
回复了 anson2017 创建的主题 健康 北漂五年程序员|颈椎病、腰突康复指南
@anson2017 绝对卧床休息时作死活动加重了……
215 天前
回复了 shanhuse 创建的主题 程序员 计算机专业最重要一门课程是哪个?
扯什么算法甚至什么数据结构的,叉出去:
https://www.bilibili.com/read/cv26671044
至于什么编译原理,只配在评论区里被黑:
https://space.bilibili.com/2816/search/dynamic?keyword=%E7%BC%96%E8%AF%91%E5%8E%9F%E7%90%86
纠结组成原理的,麻烦选会教育清楚你 1 字节不一定等于 8 位的( byte 不是 octet )。
别的大都应该没存在感和有被提起的必要。
215 天前
回复了 shanhuse 创建的主题 程序员 计算机专业最重要一门课程是哪个?
限定一门课,只可能是 MIT6.001 ,不过早就绝版了。后继课程完全不是一个档次可以直接无视。
基本上任何别的课程,合格自学者应该都能脑补出来并且可替代课程很多,要是纠结了基本得反省一下是不是自学能力有待改进。
说英语的,反省一下入学前的基础。
看你管啥叫轻薄。
我初代 ROG G14 当年直接天猫旗舰店里 8+32GB 加满的,顶配带灯 1.5W 。这个比上面有提到的加到 40G 的无畏应该还轻点。不过日常还是 SB2 远程过去,屏幕和键盘/触摸板手感还是有差距。
……这货最坑的是 CPU 风扇坏了巨响,最近消停了没管,会有概率降频。
215 天前
回复了 anson2017 创建的主题 健康 北漂五年程序员|颈椎病、腰突康复指南
躺了 3 年+,不积极锻炼,一样明显改善。
(本来就是因为锻炼太狠躺的
2006 年 Windows Mobile 上用 OneNote(.pwi),之后就没特意用过什么笔记软件。基本都是过度设计,功能需求实现不直接,残,麻烦。
对我来说大多数时候纯文本编辑器够用。自用一版 Markdown 编辑器( https://github.com/FrankHB/MdCharm ),不过最近懒了,写 md 都直接拖进 VS 甚至 Kate (只看源码)。
要同步就 git/rsync 。
@dcsuibian @idealhs 想简单了,powershell 和 pwsh 微妙不兼容,测试版本都烦。而且在 Windows 上 COMSPEC 默认仍然是 cmd ,用 native 语言互操作几乎不可能可靠测试(就算无视 cmd 这玩意儿 UCRT fallback 都是写死的问题)。虽然其它 shell 也有版本和兼容性问题,但测试起来明显简单。
这还不说得多学不同的东西。虽然学语言不难,但受限还是个性价比问题:没能明显更好地满足需求为什么非得学不同的?凭空多出兼容性包袱。
更糟糕的问题我上面早就提过:跨平台项目同时用多种 shell ,凭空多出来 powershell 特供的 bug ,还得用户倒霉。
@iorilu 相信我,至少目前 bash 跨平台总体成本比 powershell 低得多,无非 Windows/macOS 用户得多安装个运行时而已,这是只有一次性的部署代价。而且你 powershell 想要用不过时的特性就是 Windows 都一样得另外装 pwsh ,明显比 bash 吃亏。虽然传统 shell 写起来确实更恶心但就算 pwsh 也不是都省事,要干活比 powershell 熟练工好找多了,怕翻车至少也有 ShellCheck 。
@PTLin 多几种其实不是直接问题。上古的 cons pair 限制个别元素就能造出 list monad ,用比较现代一点的说法,决定限制的 unit predicate 是 null?;中古一点的 string 同样也是个 monad ,unit pred 是 string-null? 。其实吧,传统数学上 list 和 string 可以就是一回事。那为什么不嫌弃 string 和 list 共存冗余呢?因为 string 好歹有复杂度 hint 表明适合不同场景(激进一点的还有 encoding 甚至 SSO 之类的假设,但把本属于 text 的东西混同 string 有过度设计的问题,这又是另一回事了)。这个意义上 string 是具有更多实现假设的 list 又确实不都能替代 string ,这种不同层次上的冗余适应新的需求,其实不难接受。
问题是引入的目的和过程。新增的抽象如果没有提供更详细的假设提升到接口的含义,而仅仅是为了给不完善的旧有抽象擦屁股,但被擦屁股的东西又因为兼容性之类的原因没法被彻底替代而只能共存,这样缝合的下场自然不会让用户舒服了。
为什么说 null 是多余的呢?因为 nullable type 历史上本来就是实现偷懒( null pointer )的结果上反向臆造的抽象。要从需求侧讲,没什么和 Maybe 区分的必要,反倒是传统实现习惯(比如死板的错误处理)导致使用者体验很尴尬。相比之下,C++一样也有 optional<T&>不能随便和 T*等价的历史包袱,这里思想包袱就体现得更明显,因为 nullptr 并没有 Java 一样被迫弄得到处都是的存在感,兼容性问题本该不是借口。
@lisongeee null 就是个阉割版的 Optional ,而且明显更祖宗。
Optional 本身本来也不是太大的问题(起码回避起来比起无处不在的 null 来说容易多了),问题是 null 这祖宗干不掉,又另外加上 Optional ,本该是同一种目的凭空多出来不同的不兼容的表达方式乃至于扭曲目的本身(不顾历史,强行为现状洗地而寻找不同的用例场合),混起来效果就很感人了。
没有明显低估或者高估,市场反应大抵是合理的。
学习性价比偏低。对已经会用传统 shell 的正经用户可能还会多赠烦恼。
https://www.v2ex.com/t/838173#r_11433315
既然把能被 AI 替代的程序员单独拎出来说,那是挺丢人的。
能被所有人容忍的 bug 通常来自需求分析不充分和设计缺陷,让只能负责个别阶段的工程师严格避免这类 bug (比如通过形式化方法)的确可能是比较困难的。
而单纯转化设计到实现阶段的体力活冒失引起的 bug 就不配相提并论。单纯程序员身份引起的 bug 都属于此类。
虽然原文坐着好像也没这个自觉——程序员当然不可能是被 AI 最后代替的。
奇怪的是,有很多人明明干着比程序员高级复杂的工作,偏偏自贬身份,何苦呢?被 AI 还是 leader pua 惯了?
typo ,function prototype → function ,刚拿来教育过输入法顺便记住了。
https://cplusplus.github.io/LWG/issue2240
顺便,现在要不是有(眼)熟(的)人提问或者太蠢的提案我都懒得出山。正巧有个例子:
https://github.com/cplusplus/CWG/issues/304
CWG member 写的东西都这个质量,CWG chair 对此毫无敏感性,除了直接拿 bug 往脸上砸我懒得指点怎么改了。
会提案了不起?不好意思,耻与为伍。

@llwwbb7 而且我也没见你有提什么案啊。你在说风凉话以外,除了继续显摆你的低能,还有啥?
@llwwbb7 所以你到底在 bb 什么?你没有提案经历,那总该带点有想象力的脑子吧?想象不出来别人怎么提案还脑补?
或者你不带脑子,带眼睛了吧?没看我直接提了问题甚至自带了 patch 放置几年都不鸟的情况都有,阁下该如何应对?

> 我在让你提提案,提提案没有可操作性是吗?
你在让我?你说啥别人就啥,你配?
我评价你说风凉话给了充分理由,你就好意思无理取闹?
我说 JTC1/SC22/WG21 一堆提案质量甚至都不配被我评价,咋地,有意见?说实话被 adotped 东西质量都不咋地。我提过连 block scope 和 function prototype scope 都拎不清的 LWG (这居然 editor 都没看出来)以后说实话都没兴趣提案了。
你 go 还有质量?更呵呵。一个 spec 里睁眼说瞎话分不清 variable 和 object 的反智设计没被挂婊污染理论 CS 教学都够给你面子了,非要哪壶不开提哪壶?

> 你属于”核心利益相关者“又怎么样? go 是开源免费的,go team 又不欠你的,你给 go 做过什么贡献?
你碍找我了,不找骂?居然还好意思让我替你们擦屁股?
说实话你这种还不算离谱的,也不是 go team 专门差遣我来骂的吧。刚好现在有个 xc 老哥日常,引用一下:

[quote]
很多不懂软件开发为何物的 sb
>> 找点会的也不难啊 最起码不要这么直接
很难 因为不愿意给高薪
应届生都嫌贵 用一年都想办法开掉
应届生上来直接干活 设计接口
全都是屎
没人带
所以你能在信创 xx 里面见到各种操屁眼设计
比如上次说的 启动进程会验证 so 签名 但是 dlopen 的不行
比如上次说的 要我们用 usbkey 的 signtool 给 deb 签名 但是 这 sb 工具必须人工操作 不能集成进 ci
但凡写过三个月程序 都干不出这操屁眼的事
还有某 os 在系统关键组件里依赖上了 protobuf ,换句话说 你想用新版本都用不了
符号打架
换句话说 你想用新版本 porotbuf 就得绕开那个系统组件
也就是说你必须得把自己的程序拆成多进程的
那傻逼好像是在 dbus 的什么地方依赖了 protobuf 还是 gtk 忘了
总之正常脑子肯定干不出这事
最近我们可能还要适配申威 我连编译器长啥样都没见过
再加上我们大傻逼客户端用了 go ,天知道 go 有没有申威版本
每天都四菜一汤,原料都是屎
[/quote]

可见倒不是特别在挂 go ,不过 go 肯定是垫底的保留项目之一。
更重要的,按你的笑话逻辑,你不给 protobuf/gtk/...做贡献,同样不能婊了,还得为垃圾设计感恩戴德感谢多出活来赏饭吃?

> 搞笑,你又生产了什么比废物强的东西拿出来看看?你没浪费市场资源?怎么不先把你自己诛了?
你甚至是连废物不废物都找不出来,就别来充内行了。
就人身批评这招你都不配,因为找不到业界周知的 target 。

> 少在那自我感觉良好了,你还”实质性技术论点“,你那么有技术论点你去提提案啊?
实质性技术论点就是某些欠婊的垃圾就是选型失败,浪费人时间只是被挂婊算是好了。
我还是比较文明的。要你这德行真到相关一线开发受害者面前搞不好物理被撕都不奇怪。劝你谨言慎行。
看你对成功的定义。
你似乎只在乎商业市场?
然而产品是否成功,并不一定看“市场”的反馈,因为产品服务的用户不来自市场。
一般地,能解决真实需求的实际问题的产品就是好产品。我写的代码有不少用于我日常工作效率提升,就算产品规格稀烂,那也不是失败的。而且因为没有产品和销售职能的额外成本,成功得比商业产品更加纯粹。
如果你非得认为你只能作为产品的生产者而不能同时是享受产品好处的消费者,那你可能不得不失败。
TS 适应性比较广,这几个里最不容易因为风口转换的原因被淘汰,其它几个不仅是现在的生态环境没可比性,未来也基本没可能能有相提并论的市场规模。
不过做好卷的准备。
@llwwbb7 搞笑了,这文原作者就是明确表达不满,然后我补充一下为什么不满的原因以及作者说的并非个例,而你又在说啥?不但扯没点实际可操作性的风凉话,似乎还想表达别人不配不满?那我只能说,我有充分立场说我也看不惯,是因为我本业界绝大多数用户都更深入参与有关工作,属于核心利益相关者,如果我不配说这个那么 v2 的 99.9%以上用户怕是都不配。而你看不惯……怪了,你是业内核心人士还是什么知名人物,算老几?还什么开源社区什么 fork ,你去 fork 出个东西人家自动会鸟你?
还有你阅读理解有问题。我的确是看不起 go ,因为 go 设计在理论上就是垃圾,但这里本就没说这个话题(原文说的主要是实用性缺陷),而且原作者后来鼓吹的 Rust 实际上也没强哪去,所以其实我没怎么提。我重点鄙视的就是某些人生产工程废物,占着茅坑不拉屎,浪费市场资源,人人得而诛之。你有意见,是不是想被一起吊起来拷打?然而尴尬的是你这里看来只有废话,没表达什么技术观点,更别提能被评价的和 go team 干活类似的实际贡献啊……连被吊起来的资格都成问题。
退一万步讲,这篇文章作者见识再有限,至少比你这种大声嚷嚷“我就是看不惯”,然后通篇实质性技术论点都没表达半个强不知哪去了。
1  2  3  4  5  6  7  8  9  10 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1012 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 19:52 · PVG 03:52 · LAX 12:52 · JFK 15:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.