V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 4 页 / 共 92 页
回复总数  1830
1  2  3  4  5  6  7  8  9  10 ... 92  
2022-12-18 16:14:08 +08:00
回复了 closedevice 创建的主题 程序员 [求助] 我好像再也没学会另外一门编程语言!
@lmshl 又不是重写,改改局部特性,跟改库 API 没多少区别。
会难改的八成是原始设计的错,不见得轮得到显示出用户的菜。
2022-12-18 12:36:57 +08:00
回复了 kyrre 创建的主题 程序员 白嫖的 XShell 被公司禁掉,大家有啥推荐的没?
MobaXTerm 还行吧,不过我这没什么特意对付 SSH 的必要。MSYS2/WSL 上 SSH 都没什么压力,无非多配个终端模拟器。
现在习惯 ConEmu ,有些时候兼容有点问题,而且代码稀烂搞得我每次更新都得折腾一堆才能 makepkg ( github/FrankHB/ConEmu ),不过功能基本算是够用了。
Windows Terminal 对我来说不大够用。

@msg7086 只是应付主机名,其实自己写个脚本都行……
@systemcall 不止 gal ,rm 系也流行,还有一堆汉化扔 GitHub 上的……像 amemei.github.io 之类。
2022-12-18 12:10:22 +08:00
回复了 yazinnnn 创建的主题 Java 2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?
@Slurp 你什么玩意儿啊,“你谁”都带复读的?是自知被怼你行你上的价值都没有,就只能表达对婊人有意见了?还是就那么想凑热闹?不好意思啊,你跟上面那个一样没 contribution ,骗我婊空气?
就算真有什么东西,这段时间想挨婊还得排队,想提高优先级,先把你这年龄还没这里任何一个项目时间长的马甲扔了,上大号放 issue 吧。要是嫌弃效率不够,顺带把你钦点的“多少人”at 过来陪你挨个儿 biu ?
2022-12-17 05:00:01 +08:00
回复了 yazinnnn 创建的主题 Java 2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?
@zzzzzzZ 你谁啊,自我感觉良好有资格钦定什么巨婴,难道是我看漏了的自闭了二三十年的老古董?
说实话,要不是 Luca Cardelli 之流的吨位的,怕还没资格被我婊谢谢,我也确实不知道你有什么适合被挂的 contribution 。
光看所谓对“语法糖”的理解就暴露了要不是纯纯水货,要么就是语文水平有大病直接没看明白上面对口嗨“语法糖”的直球嘲讽。
我再多黑下,基本上所有 Algol-like 的语言(就凭 C 的那坨宏),还没资格来碰瓷语法糖的话题,因为它们的用户连生产正经的“语法”(比如上面提过的 Scheme 的 syntax )都做不到。遥想当年 Herb Sutter 搞什么 metaclasses ,几年过去了折腾出了个啥?
Java ?更加是空气都没有。多饥不择食才管你这玩意儿混饭吃啊……
哦,工程?姑且就当 Java 的设计还有些利用价值而不只是反面教材好了……行,JLS 的写作风格不方便二次开发我看着不爽,你给重写个?
你这张口 PL 闭口直落代码的格局就约等于没有。等懂了这方面工程主要是写文档而不是什么代码再装熟吧,OK ?
2022-12-17 04:41:36 +08:00
回复了 yazinnnn 创建的主题 Java 2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?
@aguesuka 对通用语言来说 type system 不是必须的,因为完全可以允许用户对语言的一部分规则进行元编程来改进语言,至少把 typecheker 做成库。(效果另说。)

或者说,如果一个语言的语义强到蕴含了 type system ,它就不那么通用,因为这部分规则原则上无法通过破坏 typing 的方式改变。

根本理由是语言的设计者没资格保证比任何用户都清楚用户需要什么样的 type system 。于是越是强大的 type system ,对越是清楚该怎么对付 type system 的用户来说越鸡肋。

至于 Kotlin ,成也 Java ,败也 Java 。Kotlin Native 大概不会成气候。这语言里没什么的新的和现有历史包袱有代差的导致非它不行的东西。
2022-12-15 12:10:58 +08:00
回复了 yazinnnn 创建的主题 Java 2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?
@Leviathann 应该不用怀疑水平差距,react 那坨不理解 PFP 是基本别打算会用得顺的。
虽然这不代表 react 更顶用。

@kwh 可以看懂一些 Android app 的实现以及自己写。现阶段新项目用 Java 可能会被鄙视。
另外 Dart 乱缝合特性的问题比 Kotlin 严重,只是表面上语法看起来更 Java 点。

@dcsuibian 难道不是会越好奇怎么那么多那么弱鸡的山寨语言也意思好被发明出来么。

@urnoob 看到那什么都往语法糖里装的用户就想笑。
保守估计这些用户中 90%以上既不懂什么叫语法(syntax),也不懂什么叫糖,经常性地混淆语义特性甚至把盐当做糖,
考虑到现有 PL 教学质量的垃圾,基本上语法糖这个词就是会自己实现语法糖的用户才顶用。
比如 Scheme 的卫生宏写成 API 就叫 syntax ,作为一线特性能轻易简化实现做出糖味,所以合格的 Scheme 的用户没有不会语法糖的。
如果 C/C++ ,那么得熟练用(不卫生的)宏提供 API 才会实现糖。但是语言规范中是不是糖的东西就未必理解的对了。
——比如说,C 的 E[p] 和 *(E + p) 因为语言规则钦定等价而能原地变换,这个明确是语法糖(虽然基本没什么甜度);而 C++ lambda-expression 因为一些 unspecified 的语义性质(比如 layout )不可能用等价的方式确保能用 C++ 或者外挂预处理阶段一对一翻译实现,所以就不是 C++ 的糖,不少半吊子 C++ 用户即便会玩宏也不理解这一点。
——(更何况很多用户根本就没意识到,C++ 里什么能叫 syntax 都是个问题。)
至于 Java 之流的所谓后端语言就更是笑话了,不仅没熟练看会 JLS 之类 spec 的要求就能上岗,语言里连宏那么弱鸡的造糖设施都没有。这样的用户,不到有本事自己发明语言自己实现的程度,何德何能脑补得清楚什么叫语法糖?

@matrix67 “语法简单”就算了。
没有天赋一眼看穿文法设计的毛病也没自己独自写过严格符合 spec 要求的 parser 的,还是不要误导别人的好。
最简单地:C 的 syntax 都不是 CFG 能完整表示的。而且 normative 里的东西甚至还不都是 formal 的(像嵌套 if 这种)。
汇编五花八门的就更跳了。
另外别忘了 C 和一般汇编器还都是能预处理的。

@zzzzzzZ 也不反省反省为什么会争得起来。
不就是到处水货还好意思逃避优劣标准?到底谁是巨婴?谁在制造巨婴?

@yazinnnn paulg 其实挺水的,不过爆杀巨婴是绰绰有余了。
起码会去思考这个问题。

@aguesuka 我怀疑还是有那么些思考的,否则不会那么容易理解翻车的地方取得一致。
只不过这种思考大致上的效果就是把 ISO C“编译”成谭浩强 C 这样自以为可以熟悉的劣等方言。
顺便,我是把代码使用的语言还原成λvC-derived calculi 来 reasoning 的,而且效率足够到让人看不出实现,所以足够应付陷阱——绝大多数语言作者还没这本事构造出这种方式处理起来麻烦的场景塞到语言设计里。
这也导致我天然鄙视 Java 之流非得多绕弯弯才能翻译得干净( reduce 到λvC ,不需要 PFP )的语言。不过,考虑到设计缺陷的客观性,这也基本上不算是偏见了。
不过,我同时看不惯所有类型规则不可由用户自定义编程的静态类型语言。(所以你所谓的“现代”语言的特征对我来说比较返祖。)
2022-12-15 12:09:29 +08:00
回复了 ggp1ot2 创建的主题 程序员 好奇大家吃饭时看什么下饭?
编译错误。
2022-12-01 20:07:52 +08:00
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
@KENNHI 你是写舒服了,但你也该想想你写的不是一次性 shell 面条代码,读者凭什么要就受到你随心所欲的鸟气?
特别是这种可读性问题中的绝大部分本应能避免,至少在语言设计者面前毫无技术难度。那么非得设计成跟读者体验过不去,就是自以为是地作恶了。
而且你得知道你花相近的时间精力同样写得舒服的不同语言的代码,读者被坑的程度不都是一样的,所以自然应当有针对性批判来区分语言在这里的好坏,不是有什么变通就能无所谓了。
至于 js 那种读写都呵呵的就算了。
另外,Java 是明显的脱离 IDE 虽然不是不能写但写起来体验扭曲的语言(一些地方废话实在太多)的极端代表。这是另一个不务正业的问题:逃避语言自身的设计对可用性和易用性的提升,甩锅给外部工具。
须知,IDE 的初衷是帮助提升不同开发产出形式的不同工具之间的集成效率,而不是给你语言自身特性设计不足来擦屁股用的。Java 在用不用 IDE 的体验上造成了离谱的用户体验分裂,这点就够让人质疑当正经的通用高级编程语言的资格。(要是再极端下去,就易语言那种非得用 IDE 画表格算了……)
2022-11-30 14:20:09 +08:00
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
既然可读性有没有所谓都会成问题,再提个更一般的现象好了。

其实平心而论,只有 py 式缩进实际并不会浪费我多少阅读源代码的时间,毕竟就算真的要做 semantic transformation 也完全是 one-pass 的,比 Lisp 宏都省事多了(不过 Lisp 宏我真不用傻乎乎去这么理解)。
关键问题是,隐含一个前提:我得假定我看的代码(至少在语法上)是对的。
尽管搞错缩进实在是很低级的问题,以至于这个假设绝大部分时候并不会被违反,存在这个假设本身就令我相当不爽。并且这种罕见性的低效用直接导致了不爽的升级。
——因为为了一个实际罕见的低级错误分支,我不得不在脑子里准备 fallback path ,继续跟 cache locality 过不去。
( Haskell 也有类似的问题,而且因为对一些上下文混用空白符的检查的缺乏,后果更严重,却反而导致了罕见性的弱化,某种意义上反而没那么恶心了——看,你学了这么多旮旯,也不是用不上嘛。而这类严重后果在 Python ,或者至少是鼓吹了 PEP-8 以后的 Python 中,并不那么显见。)

类似的强迫劣化人脑中语言实现的问题其实很普遍,不是 py 专利。
比如说 C 的声明符语法就被我认为是垃圾设计,除了人和机器的正确实现都麻烦而实际技术好处基本就是省纸这么个可笑的投入产出比(也是低效用的实例)外,它还暗示读者除了理解正确的语法规则,最好需要掌握次等的小聪明——所谓“右左法则”——才能去跟那些学得不到家(不知道正经的声明的形式语法)的 C 用户。这让交流更加困难不说,还嘲讽了正经学习语言规则的用户是傻子。
这里有个类似的罕见性技术细节:所谓右左法则其实绝大多数情况下是形式上正确的,能得到正确的分析结果。但是它依赖读者事先知道什么标识符未被声明,这是一个全局(至少一个翻译单元)的语义性质。于是为了保证正确,我不得不准备两套思路,脑补实现比编译器更复杂的算法——以便回溯出错误时,能和那些不懂形式语法的半吊子用户沟通。而编译器根本不需要鸟这套,照着正式的文法产生式直接实现 parser 就能几乎完全处理所有情况。(几乎是指 C 的文法设计上下文相关的例外,这是另外的糟粕。)
如果抛开罕见性,那么所谓的右左法则和谭浩强之流其实本质没什么区别,都是应当纯粹被鄙视的:鼓励放着正经规则不学,非得去做二道贩子,然后粉饰虚假的“简单”诱骗更多 noob 上当,搞烂整个用户群体。

Py 在这里有点不同就在于形式上由设计者背书,所以不会导致 py 意义上的技术错误。
但是当大量用户依赖 py 入门正经编程甚至理论计算机科学基础的时候,用户会不自觉地试图把 py 的局限性迁移到其它语言上照猫画虎,结果污染的远不只是 py 用户这个群体。
这个客观现象导致我即便无所谓 py 的设计和个别人的口味,也不得不面对这些不论是有意还是无意强迫我把智商下限拉低才配和他们交流的敌人了。
(虽然其实这里有资格到我需要特地婊的大约只有 MIT 的 6.01 。GvR 这种连个 PTC 都要 feel educated 的实在不配。)
2022-11-30 13:52:07 +08:00
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
@KENNHI 复制的最后一段就是怼借口有 IDE 拉屎恶心读者的。何必凑上来对号入座呢?真要 write-only 舒服怎么不 Perl ?连 IDE 都无关紧要了。
(虽然 py 的 IDE 其实历来不怎么样,不过这里是次要的。)
2022-11-30 06:56:41 +08:00
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
复制粘贴一遍回复:

除非你只用一个空格,缩进用空格就是逻辑上扯蛋的,总是无法避免在源文件编码层次上允许光标卡进缩进内部出现“半个缩进”的破坏不变量奇葩状态,跟 malloc 到处乱飞找不到 free 的破烂代码本质上是同种的可恶。顺带还没事 bloat 一下源代码。
虽然(水平)制表符在语义上也不那么适合缩进,但至少没这种低级问题,在许多语言的基本字符集内也没别的得选的。于是高下立判。
注意在根本上,前缀空格干的活是对齐。虽然缩进可以提示对齐,插入缩进跟缩进的理由逻辑上完全是两码事。
至于可读性,py 式缩进直接干掉了 free form 语法允许具有的上下文无关性,分析这坨玩意儿现实就没法只是 parser 的事(想用 parser 做对会极其扭曲),基本只能加语义预处理,又是个不适合机器又不适合熟练的人类阅读者的奇葩设计,纯属没事找事的自以为是了。另一方面,无法局部调整缩进导致传统纸质书那样的分页排版在换页处的可读性极其看脸,一不小心跨页就得数缩进,怎么看都比用括号直接从视觉上显式辅助定位恶心得多。
相对来说,写起来可能还能用 IDE 和结构化编辑器(现在还基本是空气)解决,没读起来那么严重。但是要把这个混淆成可读性,心智多少有些问题。

@youdoit yaml 的垃圾程度比缩进大得多。
@rozbo 共存?试试 Haskell ?
在你显然对被迫记忆上下文相关的缩进的语义(虽然技术上被钦定为语法)没什么经验的时候,姑且还是给你一些反悔的机会吧。
@jones2000 把立法选举之类的忽悠上网,看谁来断。来就恐怖分子呗。
当然,可以白名单嘛……
@netabare 把被公认怀疑成中心的夹了就是。(什么陶片放逐……
中本聪润物细无声,直接搞得没人能有效栽赃他是骗子。头部矿场和交易所要能老实自裁的话也没类似的问题了。对不老实配合的,自然需要外力代替。只是很遗憾,这方面机制一直很弱。
但是这跟现在瞎放水的哪个更没下限,还真不那么好说,因为·对两种头部玩家的道德上的要求本来就是不同的·。
结果还有意义的就剩谁来夹谁的问题了。
@Danswerme 理论上不过是鼓吹信用就是生产力的一种表现罢了。
现在更直接的问题是你以为能叫生产力的大部分东西都过剩了,而纠正资源错配的机制严重不足。所以这对理性人来说自然是个好的投机方向。
提高生产力?你咋不说改进分配呢……莫得前途。
2022-11-29 17:24:05 +08:00
回复了 zero47 创建的主题 程序员 Smartgit 终生版国区 869,到手 1023 值得入吗?
@wanmyj “已经没什么需求做不到了”……什么学姐台词。
敢加上支持 cvs/svn/hg/bzr/fossil...么。还有 hg-git 之类的。
要是光说原生,实际上那么多个插件之类的我都没发现打得过乌龟 hg 的。( SourceTree 勉勉强强。)
再光说 git ,支持干净 git replace 了吗?然后 git filter-repo ?
……其实吧,git bash 的部署方式就经常是个槽点,我要不想 bash 呢?或者我 Windows 上想要 MSYS2 ucrt64 又不想 bloat 呢?
@JohnBull 这哪来的设计初衷?又哪看出了 OP 要的是配置文件的功能?
照你的说法是不是 Windows 系统属性里设置环境变量的界面也是违反初衷,该改用配置文件?
(要是非得把注册表当配置文件,行吧,当我没说。)
2022-11-23 21:18:29 +08:00
回复了 JohnBull 创建的主题 程序员 最近有人提“国产”,我也说说我的感受,抛砖引玉
@opentrade 写文档不是文化,而是工程师的本职工作。文档是标准化工程流程的主要接口和交付物之一,不管这个文档会不会交付到客户手上。
至于实现产品的反而不需要是工程师,甚至未必是人——比如 copilot 都能凑数。
2022-11-11 12:27:13 +08:00
回复了 idguardoffline 创建的主题 信息安全 分享两篇文章:开源密码管理器更安全吗?
第二篇文章中“密码管理器存储主密码”是个词不达意的错误翻译。
原文相关段落:
Some applications stored the entered master password in plaintext or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily circumvent the crypto algorithm altogether and thereby gain access to all of the user’s data.
很显然如何存储和访问都有更明确的限定。

不过,TeamSIK 的这个说法也是有问题的。
现实中最显著不安全因素来自用户对系统错误的安全假设,而替用户定义什么叫 security 是造成这个现象的原因之一。
具体来说,原文中隐含假定理想的密码管理器总是应当且能够保证不泄漏敏感信息,给用户以错觉认为密码管理器能提供保密保证,然而这就是体系上的重要潜在漏洞——仅仅是方便方案提供者甩锅而无助于实际确保安全性。另一个更常见的可比的例子是鉴权者无原则要求强口令的密钥策略,导致不少用户倾向于以不安全的方式另行储存密码,凭空增加攻击侧信道,反而引起更大的风险(讽刺的是,密码管理器在一定程度上就是为了应对这种问题而被发明的)。

安全系统想要达到的一个主要根本目标是:让理解安全的用户得到预期的安全属性。获取用户数据并不总破坏这种属性,例如考虑用户可以极低成本地有意投毒而愚弄攻击者。
当然,极端的安全系统玩家可以不在乎这种密码管理器的限制问题(若有,也可以自己实现密码管理器,这至少发明现实可靠的加密算法容易得多)。而对大多数密码管理器的用户,他们仅仅需要一种把密钥视为最需要避免泄密的数据而容易访问的方案。但这个意义上,如何存储主密码也不是什么大不了的问题了——尽管用明文、硬编码加密的代码和真正的密码(cipher)具有密码学强度上的显著不同,攻击者一旦获知主密码就可以访问所有敏感数据的这点不会有差异——注意主密码可以被密码管理器“存储”阶段前截获。要修补这里的缺陷,需要用 2FA 等方式代替单一的固定口令。不过,这又增加了使用的困难,削弱易用性和灵活性,而在另一方面同样可能增加前述的风险。
作为实用解决方案,密码管理器应当把容易做的事情做好,而不是妄图面面俱到。这个意义下,花费较小的代价而明确减少显著的风险的设计是“好”的——包括避免使用明文存储主密码。但是,鉴于密码管理器不是入侵检测系统也不需要实现访问权限控制,它的“管理”行为并没有在字面上必须提供对主密码的反泄密存储保护(作为和用户的接口约定),即便退到这个地步,不合理的主密码存储方案仍然是个实现质量(QoI) 问题,而不是所谓的 security vulnerability 。真正的漏洞直至用户错误地信任密码管理器会提供这种保密才会形成——尽管这种错误信任非常普遍,远甚于这里强调的对开源密码管理器的无原则的信任。

另一个更现实的例子是 Chrome 通过明文保存密码: https://www.v2ex.com/t/872745 。这里,Chrome 的实现也不算是严格的安全漏洞,因为一个应用程序假定一个多用户宿主系统提供正确实现的访问控制是合理的,对文件系统的访问控制的正确实现是宿主系统的职责,正确利用系统提供的访问控制排除非预期访问是用户的职责,两者都不是 Chrome 需要关心的本职工作,所以 Chrome 的维护者的确有理由拒绝承认这是功能缺陷。但是,无论是宿主实现的安全性不可保证(乃至不可审计),还是用户普遍缺乏安全意识的现实,都使不确定的攻击更容易实现,因此这里的 QoI 问题相比 Firefox 等替代,无疑是足够显著的了。
2022-11-04 20:12:24 +08:00
回复了 pdog18 创建的主题 Node.js 为啥 js 引用其他文件的函数相对来说要麻烦一些?
@wdwwtzy C:?
1  2  3  4  5  6  7  8  9  10 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5541 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 49ms · UTC 06:38 · PVG 14:38 · LAX 23:38 · JFK 02:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.