David Benedetto为CSTA撰写了一篇关于计算思维的博客，让我对计算思维有了新的认识（感谢Shuchi Grover，他的推文吸引了我）。

http://advocate.csteachers.org/2019/02/27/situated-computational-thinking/

David说：

我认为计算思维的定义是一个很好的起点，计算思维是表征问题及其解决方案所涉及的思维过程，从而使解决方案能够以一种由信息加工媒介有效执行的形式来表示。”（Cuny，Snyder，Wing，2010）。

他逐渐形成了这一立场, 像Shuchi一样 ,提出了计算思维的两种定义。

这意味着什么？我认为，对于如何定义计算思维，我们有两个明确的选择。

（A）限制计算思维的含义。这是完全合理的，对于大多数实际目的来说可能是必要的。然而，这也带来了我们对计算思维认识的碎片化的必然结果。不同的学科/领域将有不同的计算思维。我们会这样做，但我们应该尝试理解我们施加的限制，以及施加它们的后果。 （B）打破我们对计算思维的概念。我认为科学界（至少是那些正在研究计算思维结构及其在现实文化环境中如何发挥作用的人）应该这样做，这样我们就可以探索如何在各种背景中理解和实践计算思维，并将其用于各种各样的目的。

作为一名研究人员，我更赞成前者 - 让我们精确地定义计算思维。大卫关心的是关于计算思维的社会背景。人们想要把许多事情都称为计算思维。我们能提出一个计算思维的定义来连接这些吗？ 这代表了计算思维在特定学科的用途，它的定义是否足够好以至于我们可以实际测量它的某些内容呢？

还有许多其他“思维”声称可以为学生提供关键技能。正如 耶鲁大学这篇有趣的文章 指出的那样，海军上将Grace Hopper可能更多地支持“数学思维”而不是“计算思维”。 诸如“分解”或“抽象”之类的技能包含在计算思维的许多定义中（例如这篇博客），而且在计算中确实需要这些技能。但这些技能最初属于数学、工程和科学，我认为这些学科的教师可能更适合教授这些技能并衡量它们。计算可以在学习分解和抽象方面发挥重要作用，但这些技能并不只属于计算或计算思维类。那么，计算的独特之处是什么呢？

人机交互与计算思维之间的张力#

在我生活的计算机科学方面，我的研究领域是人机交互。我在CHI, DIS, CSCW, VL/HCC和UIST上发表过文章。Cuny，Snyder和Wing的定义很难让我与人机交互研究员协调一致。人机交互研究的目的是为了“表征问题及其解决方案，从而使解决方案能够以一种由信息加工媒介有效执行的形式来表示。”以将用户必须学习的知识最小化，人机交互正试图让用户更容易用计算机思考他们想要考虑的事情。计算思维是关于你需要用计算机思考什么的思维。

在过去几周的博客中，我一直在探索特定任务的编程语言的概念。在3月初我们举办的一个参与式设计会议上，我惊讶地发现，教师可以用Vega-Lite（交互式图形的语法）做多少社会研究。Sarah Chasin、Helena和Rousillon的合作绝对令人震惊，因为人们不需要训练就能取得如此大的成就。Hariharan Subramonyam给我发了一篇关于终端用户编程以及如何最小化终端用户开始编程所花费的精力的精彩文章:https://www.inkandswitch.com/end-user-programming.html。 正如我在 SIGCSE 2019主题演讲中谈到的那样， 启动程序：代数和Scratch的大部分使用实际上都依赖于少量的计算概念。即使是少量的计算也有表达和学习的能力。

2009年Michael Mateas写了一篇文章，影响了我的思考。我在博客上写道：“总会有摩擦。”迈克尔看了看1961年Alan Perlis的演讲(我经常谈论和写作这个话题)，尤其是与Peter Elias的对话。Elias认为，学生不应该学习编程——计算机应该学习理解我们。Perlis和Mateas都不认可，他们觉得计算机永远无法完全理解我们。人类可以顺利沟通，但是计算机不能。人机交互始终存在着挑战。人机之间总会有摩擦，而管理摩擦是人类的工作。

计算思维的新定义#

所以，这是我对计算思维的新看法：摩擦。让我们采用最初的Cuny，Snyder和Wing的定义 - 计算思维是构建问题的框架，以便计算机能够解决这些问题。围绕特定任务的编程语言的工作向我们表明，我们可以让用户为了使用编程来解决他们的问题而必须学习的知识变得非常少。

为了满足Alan Kay关于生成性的观点，我们想教一些计算方面的东西，因为它们为我们提供了思维的新杠杆。我们想教一些有用的东西，但不是那些仅仅因为我们糟糕的用户界面就必须教的东西。

计算思维的一个最小定义:我们必须学习的东西，以便与计算机沟通我们的任务。它应该很小，我们学习的部分应该是生成性的，对新问题和新思维有用。其他一切都应该通过良好的用户界面来消除。

你不必仅仅为了使用编程语言来帮助你学习而去掌握抽象和分解。我们的社会研究教师修改了交互式图形项目，犯了错误(每一个错误)并从中恢复过来，尝试他们自己发现的新事物——所有这些都在10- 20分钟内完成。他们已经有了解决问题的能力。他们不需要任何“计算问题解决技巧”。他们当然没有学习任何能在10分钟内抽象和分解的特殊计算能力。他们已经掌握了足够的编程知识来学习。如果我们能够消除使用计算机来学习其他东西时对特定技能的需求，我们也应该这样做。

这与David Weintrop和Uri Wilesnky的定义相吻合——这是实际使用计算机技术的科学家和工程师的计算实践。他们的定义特别强大，因为它是基于经验的。他们询问计算机科学家和工程师实际上在做什么。Weintrop和Wilesnky的参与者希望完成他们的工作，而不是为了编程本身。因此，他们使用计算的最小子集为他们的思维和任务买单。

我喜欢这个定义，因为它是令人梦寐以求的。当下有很多东西需要你必须学会使用计算机来解决问题。Philip Guo最近在密歇根大学举行了一次演讲(类似于他在威斯康星大学举办的演讲)，描述了数据科学家如何成为系统管理员来管理所有不同的软件包和数据库以完成他们的工作。这是一个问题，而不是计算思维。这是需要处理的东西。我们能让计算思维变得有多小?

9个评论#

1.#

我一直试图解释的一个问题是，恶意软件的普遍性，以及助长这种情况的潜在盲目性。你的这篇文章让我想起了这一点。一方面，恶意软件涉及到对计算系统缺陷的深入的技术洞察，这些缺陷是由物理限制、仓促地满足最后期限等原因造成的，这似乎是大多数人难以理解的。另一方面，恶意软件的后果是不必要的资源使用——时间、带宽等，系统趋向于不可用。在人机交互方面，这似乎需要汇总统计信息—计数器、图表等。在网络环境中(大多数计算,如今都是联网的)这些东西应该反映网络活动,应该可以从“上游”设备以及我们使用的机器中获得(设计使我们可以比较事物并查看计数本身何时被篡改，或者计数是显示恶意软件感染的迹象)。在我看来，这类系统设计的有用类比包括:复式簿记、校验、和疼痛生理学以及早期预警系统。当然，人们很容易对这些问题无动于衷——几十年来，我们基本上忽略了这些东西，为什么它现在突然成为一个问题?(但这是一个问题，因为我们一直希望，如果我们能够恰当地处理系统的任意一些细节，它就会消失，但忽视了这一点，就永远无法解决很多问题。)不管怎么说……不是你真正想说的，但也不是完全脱离主题……无论如何...不是你真正得到的，但并没有完全脱离它，或者...

2.#

我认为，对于教学和课程来说，一个更简单、更直接的指导性问题是“什么时候应该容易，什么时候应该困难?”无端的困难不会促进成长，但是需要真正构建和重构一个人的思维的想法将需要大量的工作。如果我们的教育目标包括让学习者的耳朵之间产生巨大的差异——而不仅仅是用外部工具来扩大——那么“重要的困难”就一定不能避免。正如伟大的教育家Tim Gallwey所指出的那样:“困难不一定等于痛苦，仅仅是你处理‘困难’的方式，就能在很大程度上决定你感受到多少‘痛苦’。”处理后者是真正的教育者、课程设计人员、教师和用户界面设计人员的很大一部分工作。一个很大的错误是试图通过去除重要的困难区域来消除痛苦。这不仅抑制了增长，还教会了我们一些经常“反增长”的东西。这种错误总是由那些主要寻求早期成功的学习者所犯，最终并没有导致超出阈值的学习，从而在思维、行为和理解方面产生质的变化，即“吉他英雄”形式的反教育。

3.#

也许你开始从数学的角度来考虑……语法和用法的细节……逗号、分号、内置特性的名称等等，这些都不重要，应该尽量减少这些方面的困难。还有一个更深层次的(更具数学性)计算思维，可以通过最小化表面困难的例子来暗示。

4.#

我昨天尝试发表这条评论，但因为某种原因似乎没有成功。重写介绍，重写简介，这样WP就不会拒绝说我已经发布了这个…虽然关于管理和减少摩擦的部分是有意义的，但基于专业实践的计算思维定义却没有。学生们经常试图学习专业人士已经学到并超越了的东西（因此不会出现在明确的常规练习中）。 在Bootstrap：Physics中，我们的目标是教授计算建模。在学习物理概念的背景下，学生进行（实验）观察，然后用代码编写一个基于函数的模型来捕捉该概念的动态。然后，他们可以使用自己的计算模型来进行测试、模拟、探索和预测，并将结果与其他物理模型的结果进行对比。 一个正在实践的工程师/科学家通常想要的只是模拟预测结果的能力。这表明只教学生如何使用模拟软件来匹配所需的练习。但在我们的例子中，学生的任务是学习计算的概念基础。这项任务从根本上不同于专业人士的需求（专业人员希望在他们还是学生时就学到这一点）。 我对你的定义的担忧是它忽略了某些现象的计算性解释/描述。在这里通过计算来教导人机交互观点并非是严格意义上的“需要”，但是这对非计算机科学领域中的人来说是有价值的。排除计算建模的定义抛出了太多的东西。（你的论点仍然适用于教授开发和使用计算模型的工具，但这是另外一个问题）

5.#

谢谢，卡蒂。我同意你的观点，但这并不是来自这里。我打算为其他几个场所重写这个故事，所以我会确保在下一次迭代中让它更清晰。如果我们正在为专业人士及其任务进行设计，那么为专业实践设计特定任务的编程语言是有意义的。在为学习者设计时，他们参与的是他们应该学习的活动 - 学习是“任务”的一部分。这就是以学习者为中心的设计的明确理念(Soloway, Hay, Quintana, me)。我们也认识到专业人士有一套适合自己的术语，但学习这些术语是学生学习任务的明确部分。

6.#

因此我喜欢将计算思维定义为“摩擦”的想法，但是我不相信你的新定义，因为它似乎排除了只想编写程序的人，“因为”……他们想创造一些很酷的东西，帮助他们完成个人项目等等。更不用说它限制了科学家和工程师。我更喜欢“分布式认知”（la Hutchins）模型：计算机什么时候可以帮助我解决问题（什么时候它会带来更多的痛苦而不是帮助）我怎样才能将问题转移到机器上？如果我必须添加10个数字，我可能会手动完成。但如果我有100个数字并需要额外的统计数据，我将求助于一个应用程序。如果一个文件中已经有1000个数字，我将编写一个程序来执行此操作。这一切都是为了了解什么是正确的工具以及何时使用它。我希望世界能够达到这样的程度：人们通过谷歌会找到“什么工具可以解决这个问题”并且会出现一系列答案 - 每个都是一个潜在的独立计算工具/环境/语言/什么和一系列问题（多少数据，你什么时候需要答案，熟悉R等等。）引导你找到合适的工具。这就是计算思维！

7.#

几乎所有关于计算思维的定义，以及源于Wing最初定义的所有定义都是关于解决问题的。我正在使用的Cuny，Snyder和Wing定义，计算思维是在计算机上解决问题所需的知识，同样属于同一谱系。仅仅因为你想要创造一些东西就是编程的一个很好的理由 - 但这不是计算思维。将所有与计算相关的东西都投入到同一个“计算思维”箱中会导致无法定义和无法测试的混乱。

8.#

我不是想把所有的东西都扔进计算思维里 - 只是用计算机作为解决问题的工具（即使“问题”是创造艺术......）。我不认为这与期望工程师知道正确的公式/组件/工具来解决问题有任何不同（当然这可能是计算性的），或医生知道在手术室使用哪种工具（也可能是计算性的）。我们已经拥有大量的计算工具来帮助人们解决问题 - 我们没有的是让人们了解它们然后轻松使用它们的一个好方法（我的先验知识是什么以及我如何充分利用这些知识）。这就是我喜欢你们的社会研究参与式设计的原因 - 教师想知道什么，找到答案的最佳方法是什么。我开始和我的老师一起探索谷歌Studio, Tableau等数据可视化工具(使用真实世界的数据集)，看看我们能找到什么。这是计算思维吗?我认为它是——我们正在使用计算工具和功能从原始数据中提取知识。我们在解决问题吗?也许....

9.#

我想我们意见一致，知道使用什么工具是解决问题的一部分。在这个定义中，我所做的是把责任放在作为工具开发人员的我们身上。为了使用该工具，领域专家应该了解的关于计算的知识越少越好。如果我们说“这是一个与你的问题相匹配的工具目录，而且大多数这些工具只需要几小时的时间来学习如何使用它们。”，我们就不会对任何人有所帮助。相反，我们应该说，“这是满足你需求的n种工具，每种工具都可在10分钟内使用。”我想我们可以做到这一点，在这10分钟里 - 你正在学习计算思维。