编程语言与软件工程2016cs.ucr.edu
非程序员解决编程问题的研究
Study of non-programmers' solutions to programming problems
进阶 · 约 45 分钟读完前置知识:编程基础、编程语言范式、HCI/可用性研究基础
导读
这篇论文研究非程序员如何理解和解决编程问题,并从他们的解法中归纳出偏好:事件驱动逻辑、用集合代替循环、用过去时而非状态变量来描述状态变化。作者据此讨论这些直觉对编程语言与范式设计的启发。
HN 关注点:非程序员的自然表达能否为编程语言带来新范式,以及“像程序员一样思考”究竟难在哪里、代码复杂度是否才是更大的问题。
HN 评论精选
这几条评论里:支持 1 补充 2 亲历 1
补充归纳论文三点,并设想编译器如何把过去时条件编译为时间戳变量。
对我而言三大要点是:事件驱动逻辑、用集合代替循环、用过去时而非状态。事件和类 LINQ 查询已经足够流行,最后一点很有意思。尤其在对象主要通过事件交互的环境里,查询对象的“过去”似乎可行:天真做法是保存所有事件再查询匹配;更合理的是把“最近十秒内吃过能量豆”这类过去时条件改写成时间戳比较,由编译器引入并维护相应变量。
jtolmar查看英文原文
Top three takeaways for me: event-based logic, sets instead of loops, and using past tense instead of state. Events and linq-like queries are popular enough, that last one is interesting. Especially in an environment where you mostly interact with objects via events, I think querying an object's past sounds pretty doable. Naively we could hold on to all events ever and query for one that matches what we're talking about. Less stupidly, these past tenses are usually in forms like "if this happened recently" or "if this happened ever" which a compiler could rewrite into a variable that the relevant event sets. So, the compiler sees "if Pacman ate a power pellet within the last ten seconds" in whatever syntax it accepts. It goes to Pacman's "eat power pellet" function and appends code to set Pacman's last-power-pellet-eaten variable, which it has to introduce. The original conditional gets rewritten in terms of timestamp comparison.
亲历认为编程思维可训练,真正的问题是代码复杂难读。
作为较晚转行做程序员的人,我的看法是:上过几门 CS 课并大量编程后,“像程序员一样思考”并不难掌握。真正让我惊讶的是很多代码复杂、绕、长且难读;对非程序员或新手看似简单的任务会写进大量代码,而且很多代码写得和设计得很糟。教授说读代码时间多于写代码,确实如此。
ZanyProgrammer查看英文原文
My perspective, as someone who came relatively later to programming as a career, is that the skill of "thinking like a programmer" isn't too hard to acquire once you've taken a few college CS classes and started to simply program a lot. Rather, what I'm constantly amazed at (and maybe its because I'm working in stereotypical enterprisey environments?) is how complex, convoluted, long and hard to follow a lot of code is. So much code goes into what to a non programmer or novice would seem like a fairly simple task. And so much code is really horribly written and designed and implemented. Its very much true what your professors say about how you'll spend more time reading code than writing it. Anyways, I'm sure my perspective as both a junior dev and a late career switcher is somewhat biased, but there you have it.
支持认可论文,并主张语言设计应转向满足人的表达需求,倾向函数式/声明式。
作为一个在 CS 教育上有明确立场的人,我本以为会讨厌这篇论文,但没有;它有些很好的观点,我很喜欢“非程序员可能指向新范式”的想法。如今语言发展的问题已不是无法构建满足需求的语言——对明确规格大体可以——而是对话从“如何满足机器”转向“机器如何满足我的编程需求”。支持函数式和声明式编程。
jbclements查看英文原文
As someone with a definite and well-established viewpoint on CS education, I sort of expected to hate this paper... but I didn't. I thought it made some excellent points, and I very much liked the idea that people not trained as programmers might be able to point us toward new paradigms. At this point in the development of programming languages, the problem is not really that we can't build languages that do what you want; by and large, for unambiguous specifications (and yes, that is a big qualifier), we can. At this point, then, the conversation shifts from "how can I meet the machine's needs?" to "how can the machine meet my (programming) needs?" Another analogy: we're no longer just stone-age people looking for a rock that doesn't shatter when we hit things with it; we're can shape our rocks now, and we're trying to figure out what shape allows us to hit things hard without cutting our hands. Go, functional and declarative programming! Oops, I gave it away. Sorry.
补充编程本质是无歧义逻辑开发,自然语言适合模糊可调整场景但有局限。
我认为编程核心是把概念(如 Pac-Man 在迷宫中移动)转化为无歧义逻辑;表达语言影响结果,但能否开发出逻辑才区分程序员与非程序员。这不是贬义:自然语言加模糊思维在很多场景很好,因为隐含上下文可消歧且人可现场处理意外;很多问题只需快速指定、90% 情况可用、其余可调整。但复杂到难以自然语言描述,或数据/时间约束不允许人处理意外时,就需预先精确无歧义的逻辑。
Deregibus查看英文原文
I feel that at its core programming is about taking a conceptual idea (e.g. pac-man moving around a maze) and determining the unambiguous logic that describes it. The language used to express that description has a significant effect on the end result, but it's the ability to develop the logic in the first place that really separates "programmers" from "non-programmers". "Non-programmer" isn't meant as a slight. This style of problem solving works great a significant portion of the time. Natural languages can describe a solution to a lot of problems very concisely because a) there's a lot of implicit context that clears up many of the potential ambiguities, and b) you're typically present and available to handle any unexpected situations that may arise. For many problems, the best solution is one that can be specified quickly, will work 90% of the time, and can be easily adjusted for most of the other 10% of the time. Natural languages and fuzzier thinking work great for this. But this approach doesn't work well for problems where the solution is either too complex too be easily described using natural language, or situations where data sizes or time constraints make it unfeasible for you to be available to handle unexpected situations. In this case the solution requires all of the logic to be precise, unambiguous, and developed up front. It's a different way of thinking than what has typically been asked of humanity, and natural languages are pretty poor at expressing that logic. I think the paper has some good points, but I'm not sure how much you can really draw from it other than verification that natural-style problem solving doesn't work well for the type of problems that are typically solved by programming. If you asked a bunch of experienced programmers to write programs that will tell you how to "go to the store and buy me some milk", you'd probably get similar results about how the programs didn't handle the many different unexpected situations that might occur in such a simple task.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2016Hacker News 讨论帖342 分 · 170 评
同领域还值得读
Google 的软件工程(2017)
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践,包括其单一代码库(monorepo)、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程,并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur:编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出:编程的本质不是写代码或文档,而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0:Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库,涵盖其核心算法模块(优化、积分、插值、线性代数等)、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史(1979)
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL(编程语言史)会议撰写的回顾文章,讲述 Lisp 的起源、设计动机与早期演进,文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用:以 ndarray 为中心,通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选