V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 53 页 / 共 92 页
回复总数  1830
1 ... 49  50  51  52  53  54  55  56  57  58 ... 92  
2019-08-26 17:01:41 +08:00
回复了 sunjourney 创建的主题 程序员 真・编程从娃娃抓起
其实往大了说,这个问题非常微妙。
一般地,所谓的编程能力,可以概括为使用现有可编程性的设施完成表达满足特定需求的程序的能力。
一般人可能同时具有其中的一部分能力,但不具有另一部分。我把这样的能力排除出工程能力——这样的能力本质上和工程专业性无关(虽然也许和经验有关)。其中有一部分确实是吃天赋的也不容易传授的,因此不是人人都容易会的技能。只不过,职业上习惯水平扩展能解决问题就不强调这类技能了,所以会被忽视,但这不意味这样的差距就不存在,哪怕是非常小的细节。
像 @youxiachai 提到“打奥赛的”(我理解为信息学奥赛,NOI/IOI 这类,如果说的是 Peter Dimov 这样 IMO 拿牌的另说),从细节就可以看出其中大部分人在一些编程的技能上是很不长进的。
例如有的 OI 撸 C++ 的会知道糊 __gnu_cxx 之类的开洞来偷懒——因为 OI 限定了环境,使用这些东西的问题相对不是很明显。不过,如果反思自己用的是“什么样的 C++ ”,就会发现一些问题。——这个下面讨论。
一个类似的出现在专业工程人士上的例子是 FreeType2 这个主要用 C 实现并且保证 ISO C conformance 的项目在 2016 年才修复不当使用下划线起始接大写字母的标识符和使用双下划线标识符的问题。(应该不用质疑这些作者的工程上的专业性,从 API 维护质量和工程过程看这应该是个星球上最专业的几个 C 项目之一,至少比什么 stb 之流好多了。)
这个问题的技术原理是,不当使用带有 __ 这样的标识符,在 C 和 C++ 都会引起未定义行为(不清楚这意味着什么的,最好别说自己了解 C 和 C++ )。所以如果不是自己实现标准库或编译器之类的东西,这就是 [编程上] 错误的。——这是使用 C 和 C++ 编程的常识问题,而在不经他人提醒的前提下 [意识到] 这个问题的能力,属于编程能力的一种。因为,这个问题的一般形式是:“究竟依赖了什么样的编程设施才能给完成编程任务提供基本的保证?”这个问题中,语言提供的可移植性是语言的 spec 保证的。而找到具体的依据(翻 spec )以及改正现有错误的效率,才体现出一部分工程能力。
和一些标榜 C/C++ 却不说清楚具体依赖的项目代码中 __ 满天飞作者却仍然没意识到问题相比,FreeType2 维护者的编程水准显然也不算太差——他们好歹终于注意到了。
退回到一些 C++ OI 选手上的例子,不经提醒,他们很可能不会注意到为什么在 OI 环境中恰巧能用这样的不可移植东西——或者一知半解而去用导致脱离他们使用 OI C++ 方言而改用“真正”的 C++ 会被坑的理由。这就是缺失编程能力的一个方面的体现。
至于 OI 选手在给定时间和资源限制内准确确定可行算法解决问题之类的技能,这属于 OI 环境下的业务逻辑,和编程水平没有直接关系。使用代码实现这些算法虽然是编程能力的体现,但考虑到 OI 使用的语言都相当烂大街,这个能力其实相当大路货,一般人就算会遇到门槛,也主要是算法这种业务逻辑方面理解和经验上的问题,不大会是因为编程水平拙计的问题。
而在业务领域提升到提供可编程环境(例如,发明语言和提供语言实现)之前,要把这类业务上的东西和编程类比所谓哪个更强,是没啥意义的。
2019-08-26 16:23:19 +08:00
回复了 sunjourney 创建的主题 程序员 真・编程从娃娃抓起
@no1xsyzy 讨论这类问题其实有个很麻烦的地方:大多数人,不管是不是业内的,确实不太好确认理解一致:什么算编程?
于是为了避免麻烦(以及某种节目效果),跟一般人讨论“编程”默认就不得不放低要求到某种相当低的程度(比如说,堆 API 调用的就算)。这类任务是有兴趣的正常人花些精力都能会的程度,就要求投入时间不要求有天赋,自然没什么难的。
要是拔高门槛,比如重新造语言实现造体系结构,又没几个人会,能讨论的人就少太多了,比较起来一样也没啥差距,所以干脆还是算了。
至于选择 API 的业务问题和工程问题难不难?其实也有类似的门槛不同的问题。只不过实际要能体现作用的最低门槛的业务和工程问题通常还是比最低门槛的编程问题难的。
(比如说有清晰的文档参考,写个配置文件也显然是编程问题吧……然而摊上所谓的少儿编程,这显然还算不上最简单了。而能说得上业务和工程的“问题”,大概并没有糊这样个配置文件容易。)
没解锁 bl 的机器,都不好意思浪费时间折腾……
(还好我解锁码申请得早
2019-08-26 03:17:18 +08:00
回复了 sunjourney 创建的主题 程序员 真・编程从娃娃抓起
@sunjourney 别太看得起别人。讲道理,就算去掉年龄限制,这站里能扯清楚什么是“变量”的估计也没几个……
知道差不多都在同一条起跑线上,就不用计较那么多了。
@GeruzoniAnsasu 宏还真可以是一大坨本质啊,魔改一下糊上 lexical scoping 再兼容 applicative order evaluation,搞几个 primitive,加个 symbol/eval,你之前理解的就差不多了出来了……
当然基础要求有点高,要证 Church-Rosser property 什么的小学生来讲确实不太能搞得动,不过知道长什么样应该不是太有理解障碍。
像 C++ 这种连个 hygienic macro 都蘑菇几十年屙不出来的玩意儿是没排面的。(坐等 Herb Sutter 撞南墙。)
没能把 C++ 修好还是别反刍什么本质了吧,只能感到直觉退化了啊。
至于数据结构?糊屎?跟编程啥关系(
@chocotan 概念错误……少儿不少儿真的有差么……
2019-08-25 22:53:36 +08:00
回复了 zhiwoda123 创建的主题 程序员 有没有玩过 qt 的
@ipwx 还有啊,“你只能用 MSVC ”?× ——这是乐观过头了。
实际不少情况是只能用特定版本的被支持的 MSVC,直到甩掉这整坨屎。
说个实际案例吧。
几年前给人糊一坨 Pro/E 之类的插件,本来 VS2010 用得好好的,然后因为只给 lib 就要愣是要 VS2008,更可笑的是还只能用 libcmt 没法上 msvcrt ……最后一坨用 MSBuild 的 sln 还要拖一坨魔改过的 nmake,一台 2G 的穷酸开发机上同时开两个 VS 和一坨客户程序联调,那酸爽。。。
说 MSVC 是标准是吧……那这里到底是 VC2010 是标准还是 VC2008 是标准呢?用 MSBuild 是标准呢,还是 nmake 是标准呢?(现在 nuget 一过气,又可以一起纠结 vcpkg 和 conan 了……)
倒不是说不用 MSVC 就一定能避免这种问题,问题是别的替代实现真没那么多乱七八糟需要 version lock-in 的东西。
而且不管怎么说这种问题就算主要不是 MSVC 而是依赖项的发行商的问题,也实在没法认为是靠谱的表现吧。
2019-08-25 22:41:54 +08:00
回复了 zhiwoda123 创建的主题 程序员 有没有玩过 qt 的
编辑框抽风漏了。
“,这不是常识么。”

“把能填的坑填过了,或者至少评估过填坑的难度,再讨论靠谱程度。到处都有人在用又不保证你自己的和别人普遍的用例中能满足需求,这不是常识么。”
2019-08-25 22:38:05 +08:00
回复了 zhiwoda123 创建的主题 程序员 有没有玩过 qt 的
@ipwx MSVC 自己(而不是有强迫症的 MSVC 用户)有能称得上 Windows 下的标准的东西?有多少东西找得到跟实现准确匹配的文档? ABI 都没敢全说清楚吧?
同等功能同等质量的实现,没源码比起有源码的就是残次品;都有源码的,依赖特定实现导致兼容性更差的更残废。既然已经在一部分实现上废了,能给全文档让人脑补逆向出源码也差强人意,逼用户从二进制逆向出来才能弄清楚实际干了坨什么的,就别好意思标榜靠谱了。然而讲个笑话,关于 MSVC 的一些东西,看 LLVM 的材料都可能比 MS 家的靠谱……再讲个笑话,直到近几年前升级 MSVC 还会 break ABI。还有一堆笑话,msvcrt 和 ucrt ……
,这不是常识么。
这还就只是人力可以做到的逆向。升级个编译器版本多出来一坨 ICE,没源码人肉修编译器试试?
除了谁都做不到的,没能力折腾好就认,跟信任几毛钱关系。
还有,别家工具链不管是 conformance 还是 compatibility 很多情况就是库拙计的问题,cl 前端整个烂了那么多年,bug-to-bug compatible to MSVC 的东西,有源码看都能发现普遍更不靠谱。
2019-08-25 18:29:06 +08:00
回复了 zhiwoda123 创建的主题 程序员 有没有玩过 qt 的
@ipwx 都是 bug 一坨坨,看不到源码我没法修的怎么就更靠谱了?
2019-08-25 18:08:33 +08:00
回复了 litanyue 创建的主题 程序员 有没有一本书能够通俗易懂的介绍计算机专业?
计算机专业暂且不论,但是做软件的经常有一件和计算机专业关系不直接的活就是像 LZ 这样和客户唠嗑然后提问——这叫做需求分析(虽然并没做完
2019-08-25 17:58:39 +08:00
回复了 sunjourney 创建的主题 程序员 真・编程从娃娃抓起
天赋?怕不都一样是负的……
理解命令和 for 循环之类的是坨浪费时间的 five 就那么难么……
别搞出一坨基本常识都稀里糊涂的歪嘴和尚就万事大吉了。
https://stackoverflow.com/questions/19132
https://stackoverflow.com/questions/1050222
2019-08-14 03:04:37 +08:00
回复了 leishi1313 创建的主题 程序员 大家有什么独到的 dotfiles 管理方案吗
如果你的真正的目的是就只是管理(或者仅仅是部署) dotfiles,看楼上。
如果你的真正的目的是管理一般意义上每用户应用配置,恭喜你,还没有发现个好用的专用工具,你可以自己糊项目了。(模板之类……手贱写错呵呵呵。)原因是不同应用的配置格式不保证通用,管理 dotfiles 的方案不清楚具体配置的语义,只能对分组归类比较靠谱;要好用基本也得对特定的配置进行优化,这不比维护普通的包更省事,所以没啥人会去想做。(注册表是屎,但这里还真微粒子般存在地高明了那么一点点……)
现实我对单纯的配置基本上直接 git 不会有太难维护的问题,嫌麻烦(我不会)大不了用 wrapper (但要把版本控制有意 abstract away 掉的东西是不是符合目的,自己考虑)。配置中带逻辑的,专门链到 $HOME 外当作正经的私有项目定制。
2019-08-14 02:29:58 +08:00
回复了 yuyueMJ 创建的主题 程序员 程序员如何入门项目管理?
书倒是不少,一大坨砖,但你都要直接上了……还是抱人大腿跟着糊吧。
只是注意点关掉还好了,有的代理软件甚至都不提供关掉的选项,每次掉了重连还自动设置一遍,这就很 zz 了……
2019-08-14 02:21:41 +08:00
回复了 lqucool 创建的主题 程序员 公司部分工资发现金,不给工资条,怎么收集证据?
录音套话。
说起来倒是不怕你反讹没付钱么。
这个****就很有灵性了……
先甭管迭代不迭代,有 log 再说吧,否则 bug 哪来的甩锅都不方便。
2019-08-13 14:58:03 +08:00
回复了 tlriavsihd 创建的主题 职场话题 跳槽的时候大厂背景真的是硬通货
@FancyKing ……
我倒是拿 bug 糊脸过微软、红帽写编译器的……
2019-08-13 14:55:56 +08:00
回复了 tlriavsihd 创建的主题 职场话题 跳槽的时候大厂背景真的是硬通货
@Sothoth 看成有 500 强东……
2019-08-13 14:21:35 +08:00
回复了 pythonee 创建的主题 程序员 有没有程序员界的李永乐老师?
@echo314 我没否认过好的老师普遍上的重要,不过根本上这因人而异,跟学的内容也有关系。
你得承认客观的限制:越是高层次的知识,越不容易找到靠谱的老师,反过来对脱离老师学习的要求更高(除非你非得觉得找不到老师就不学了)。
学校的话题,是你带起来的完全是另一回事。我指出的是学校好不好跟教学靠谱的老师没什么必然联系,也就是说其实就跟这个话题基本无关。
我现在要另外补充的观点是,对于这个行业不那么高层次的知识,其实资源也不少,大多数学习者也不特别需要在乎老师了……虽然想要靠谱的老师指导一点都没错,不过是不是得考虑一下到底是谁向谁来出让教师资源呢?
2019-08-13 14:13:38 +08:00
回复了 pythonee 创建的主题 程序员 有没有程序员界的李永乐老师?
@lisicong 谭的屁股问题就不说了(坊间流传的《彭德怀反党反社会主义反对毛主席言行一百例》《邓小平反党反社会主义反对毛主席言行一百例》云云),你的个人观感倒也没什么改变的必要,但是你至少应当清楚,你的观点的传播,是会引起利益冲突的。
理由很简单:“个人觉得写的挺好的”会给“写的挺好的”带来偏差,劣币淘汰良币。考虑到谭的某著作在仍在更新的中文书籍的销量中仅次于《新华字典》,“谎话说多了就是真理”的群众基础没法现实地无视。
——而且,实际上我就是没见过谁用这货入对门过。有入对门的,基本上要么把这坨当黑历史,要么回过头直接清算了。
某些回护阮一峰之流的,相比之下自然还没这么大的影响问题;不过有些问题的内涵,看来还是一致的。
延伸阅读:《丁肇中的“无知”与何祚庥的“无所不知”》。
2019-08-13 13:57:03 +08:00
回复了 pythonee 创建的主题 程序员 有没有程序员界的李永乐老师?
某些经问题实际上也没啥讨论的意义 https://www.v2ex.com/t/343634。
1 ... 49  50  51  52  53  54  55  56  57  58 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   932 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 23:12 · PVG 07:12 · LAX 16:12 · JFK 19:12
Developed with CodeLauncher
♥ Do have faith in what you're doing.