Domain-Driven Design Europe · Published 2026-08-31

AI made me doubt everything about programming by Felienne Hermans - DDD Europe 2026

privateReview: unreviewedConfidence: high
artificial intelligenceprogramminglocalizationcomplexity biastheory buildingcomplexity-biasprogramming-cultureai-code-generationtheory-buildingdeveloper-toolinghuman-ai-collaboration
Open on YouTube ↗

Summary

Overview

  • Speaker: Felienne Hermans
  • Channel: Domain-Driven Design Europe
  • Main topic: How AI and Large Language Models challenge our understanding of programming, community identity, and the values we assign to complex versus simple software systems.
  • Purpose: To provoke critical reflection on software engineering culture, values, biases, and the impact of AI by drawing parallels with linguistics, history, and sociology. Felienne Hermans, Professor of Computer Science Education at VU Amsterdam and high school CS teacher, explores how the rise of AI and LLMs caused her to doubt everything about programming. Reflecting on her creation of Hedy (a localized programming language), she examines how the programming community values hard, complex technologies over accessible ones, mirrors parallels with historical biases like von Neumann's war involvement, and contrasts programming with practices like knitting and chess to question why we build what we build.

Topic Map

Falling out of love with Computer Science

  • Explanation: Felienne shares her journey from a young enthusiast amazed by computers to a professor experiencing an identity crisis due to AI and cultural shifts in the CS community.
  • Key claims:
    • Computing started as magic for young learners.
    • Recent AI advancements caused an identity crisis in computer science.
    • Spreadsheet programming was often dismissed as 'not real programming' by traditional developers.
  • Examples:
    • Learning basic from library books as a kid.
    • Presenting spreadsheet research at conferences and being told it is not real programming.
  • Terminology:
    • Computer Science
    • Spreadsheet programming
    • Turing complete
  • Why it matters: Highlights elitism and narrow definitions of 'real programming' within the tech community.

Localization and Hedy

  • Explanation: Discussing the creation of Hedy, a programming language designed for teaching and localized into multiple languages including Dutch, Spanish, Chinese, and Arabic.
  • Key claims:
    • Localization is crucial for making programming accessible worldwide.
    • Different languages have unique challenges, such as Arabic numerals vs Western Arabic numerals.
    • Building localization fostered pride and highlighted linguistic inclusivity.
  • Examples:
    • Creating Hedy (hedy.org) in Dutch and expanding to Spanish, Chinese, Hindi, and Arabic.
    • Facing unexpected challenges with Arabic numerals in programming syntax.
  • Terminology:
    • Hedy
    • Localization
    • Arabic numerals
    • Syntax error
  • Why it matters: Demonstrates that accessibility and inclusivity require more than English-centric engineering.

The value of Hard vs. Easy in Programming Culture

  • Explanation: Examining why the programming community values hard, complex tools (like C++, Haskell, Coq) while dismissing easy, accessible tools (like Excel, Hedy, PHP) and how this mirrors societal biases.
  • Key claims:
    • The programming community overvalues hard, complex tools and undervalues easy, accessible ones.
    • Making something easier is often perceived as taking away its value.
    • Comparing programming values to feminist epistemology and the sociology of science.
  • Examples:
    • Comparing Haskell and C++ (valued as hard/valuable) to Excel and Hedy (viewed as easy/less valuable).
    • The 2016 paper on glaciers, gender, and science.
  • Terminology:
    • Feminist epistemology
    • Complexity bias
    • Requirements engineering
  • Why it matters: Exposes how community values shape technological prestige and exclusion.

Historical Context: Von Neumann and the IEEE

  • Explanation: Reflecting on John von Neumann's dual legacy as a pioneer of computer architecture and a contributor to military applications like atomic bomb calculations and punch-card census systems for Nazi Germany.
  • Key claims:
    • Technology history is entangled with military and harmful applications.
    • John von Neumann received medals from IEEE and Nazi Germany for efficiency technologies used in harmful ways.
    • We often whitewash the historical origins of computing.
  • Examples:
    • IBM punch cards used to track Jewish populations and train schedules in Nazi Germany.
    • John von Neumann calculating the optimal detonation height of atomic bombs.
  • Terminology:
    • Von Neumann architecture
    • IEEE
    • Punch cards
  • Why it matters: Reminds us that technical brilliance does not guarantee moral or social alignment.

Chess, LLMs, and What Programming is For

  • Explanation: Analyzing the parallels between Deep Blue beating chess champions and the rise of LLMs, questioning whether programming should focus on human fulfillment or mere technical complexity.
  • Key claims:
    • After Deep Blue beat Kasparov, chess did not change fundamentally for human players; chess remains a human activity.
    • Herbert Simon predicted computer chess champions in 1956.
    • Programming is ultimately about making programmers happy and proud, not just solving problems efficiently.
  • Examples:
    • Deep Blue defeating Garry Kasparov in 1997.
    • Comparing programming to knitting as a craft of textile creation for people.
  • Terminology:
    • Deep Blue
    • Large Language Models (LLMs)
    • Artificial Intelligence
    • Knitting
  • Why it matters: Re-centers the purpose of programming around human agency, craft, and community rather than pure automation.

Key Points

Elitism in Programming

  • Explanation: The tech industry looks down on spreadsheets and beginner languages, labeling them as 'not real programming'.
  • Evidence: Reactions from conference attendees when Felienne discussed her research on spreadsheets.
  • Practical implication: We must broaden our definition of programming to include accessible tools used by domain experts.

Localization and Cultural Inclusivity

  • Explanation: Programming languages are predominantly English-centric, excluding non-English speakers and cultures.
  • Evidence: Challenges faced when implementing Hedy in Arabic, including differences in numeral systems.
  • Practical implication: Localization is essential for global software accessibility and digital equity.

The 'Hard = Valuable' Fallacy

  • Explanation: Developers tend to equate difficulty with value, dismissing simple or user-friendly solutions.
  • Evidence: The contrast between how complex languages (C++, Haskell) and easy tools (Excel, Hedy) are regarded in academia and industry.
  • Practical implication: Value should be measured by the human problems solved and accessibility provided, not just technical difficulty.

The Purpose of Programming

  • Explanation: Programming is not just about writing efficient code; it is a human craft akin to knitting, literature, or art.
  • Evidence: Peter Naur's theory building perspective and David Graeber's philosophical insights.
  • Practical implication: Focus on the human, creative, and collaborative aspects of software development.

Frameworks, Models & Processes

Programming as Theory Building (Peter Naur)

  • How it works: Programming is defined not merely as writing code, but as building a theory that allows people to understand, explain, and argue about complex domains.
  • Components:
    • Doing things intelligently
    • Explaining systems
    • Answering queries and arguing about code
  • When to use: When evaluating software design, team collaboration, and long-term maintainability.

Examples & Case Studies

Implementing Hedy in Arabic and encountering questions about Arabic numerals.

  • Illustrates: The complexity of cultural localization in programming languages beyond mere translation.
  • Lesson: True localization requires deep empathy and understanding of diverse linguistic traditions.

IBM punch cards being used in 1930s Nazi Germany for census and logistics.

  • Illustrates: The dark history and non-neutrality of early computing infrastructure.
  • Lesson: Technology is shaped by social factors and can be weaponized; technical progress is not inherently moral.

Deep Blue beating Garry Kasparov in chess in 1997.

  • Illustrates: Machines surpassing humans in specific rule-based domains without destroying the human practice of the game.
  • Lesson: Even when AI excels at a task, human culture and practice around it persist.

Actionable Takeaways

  • Immediate:
    • Reflect on your own biases regarding 'hard' versus 'easy' programming tools.
    • Consider accessibility and localization in your software design.
  • Strategic:
    • Acknowledge the historical and social embeddedness of technology.
    • Focus software engineering on human connection, understanding, and theory building rather than mere code output.
  • Questions to investigate:
    • What are the hidden social biases in our current AI hype cycle?
    • How can we make software engineering more welcoming to diverse perspectives?

Claims Worth Verifying

  • Caring about social change is the biggest factor for not studying Computer Science (Suret et al. 2017). (academic research citation)
  • Peter Naur's 1984 paper on 'Programming as Theory Building'. (historical software engineering concept)
  • Thomas J. Watson receiving a medal for collaboration with Nazi Germany in 1937 as reported by the New York Times. (historical fact)

Notable Quotes

"AI made me doubt everything about programming" (at 0:08) "The ultimate hidden truth of the world is that it is something that we make, and could just as easily make it different." (at 77:21)

Compressed Summary

  • AI and LLMs challenge traditional programming identity and practices.
  • The tech community suffers from complexity bias, undervaluing accessible tools like spreadsheets and Hedy.
  • Computing has a complex history tied to non-neutral social and military applications.
  • Programming is fundamentally about human theory building and craft, much like knitting or art.
  • Keywords: artificial intelligence, programming, localization, complexity bias, theory building
  • Core insight: Programming is not just about solving technical problems efficiently, but about human theory building, craft, and empathy in a world where technology is never neutral.

Core insights

6
Mental Modelhigh noveltymoderate evidence

The programming community systematically equates technical difficulty with value, so making a capability easier is experienced as a loss of prestige rather than a gain in accessibility.

Why it matters

AI tooling and agent frameworks are constantly attacked as 'not real engineering' precisely because they lower the skill floor. Teams that internalize this bias underinvest in high-leverage, low-complexity infrastructure and over-engineer to signal legitimacy.

Generalization

Whenever a technology reduces the effort required to achieve an outcome, the incumbent practitioner community will discount the outcome to defend the status signal embedded in the effort.

The programming community overvalues hard, complex tools and undervalues easy, accessible ones.
Open source video
Making something easier is often perceived as taking away its value.
Open source video
Mental Modelmedium noveltymoderate evidence

The Deep Blue precedent suggests that automating the competitive core of a human practice does not replace the practice: chess remained a human activity after a machine beat the world champion.

Why it matters

This is a concrete, dated counter-example to the assumption that AI coding capability means the disappearance of programming as a human discipline. It predicts a re-centering of human work around craft, intent, and community rather than raw code production.

Generalization

When a machine surpasses humans at a practice's measurable objective, the practice can survive by shifting its purpose from the score to the experience of participants.

After Deep Blue beat Kasparov, chess did not change fundamentally for human players; chess remains a human activity.
Open source video
Herbert Simon predicted computer chess champions in 1956.
Open source video
Mental Modelmedium noveltymoderate evidence

Programming is framed as theory building: the artifact is not code but the shared mental theory the code encodes, which means code emission (including by LLMs) can be separated from the durable engineering asset.

Why it matters

If code is a lossy byproduct of a theory, then AI-generated code without a maintained human theory is a maintenance liability regardless of how correct it looks. This argues for investing in intent capture, decision records, and shared understanding rather than only in generation throughput.

Generalization

Any pipeline that automates artifact production but not the underlying model held by humans degrades the system's ability to evolve the artifact.

Programming is ultimately about making programmers happy and proud, not just solving problems efficiently.
Open source video
Programming is defined not merely as writing code
Open source video
Mechanismhigh noveltymoderate evidence

Localization is a first-class engineering constraint, not a translation layer: numeral systems, scripts, and syntax assumptions embedded in a language or tool surface as unexpected technical failures.

Why it matters

The Arabic-versus-Western-Arabic numeral collision shows that locale assumptions live deep in parsing and token representation. LLM tokenizers and prompt templates inherit the same class of hidden assumptions and will fail silently for non-English, non-Latin-script users.

Generalization

Any layer that hardcodes a dominant language's notational conventions (digits, direction, delimiters) creates failure modes that only appear for excluded user populations.

Different languages have unique challenges, such as Arabic numerals vs Western Arabic numerals.
Open source video
Facing unexpected challenges with Arabic numerals in programming syntax.
Open source video
Mental Modelmedium noveltymoderate evidence

The definition of 'real programming' is socially enforced and excludes productive tools used by domain experts, such as spreadsheets, on prestige rather than capability grounds.

Why it matters

This predicts that end-user and domain-expert tooling built on AI will be similarly dismissed, and that the population of legitimate builders in an AI-native organization will expand beyond trained engineers. Tooling and review processes built only for engineers will not serve them.

Generalization

Gatekeeping definitions of a discipline are proxies for status, not measures of capability, and they lag the actual distribution of productive work.

Spreadsheet programming was often dismissed as 'not real programming' by traditional developers.
Open source video
We must broaden our definition of programming to include accessible tools used by domain experts.
Open source video
Failure Modemedium noveltymoderate evidence

Foundational computing figures and infrastructure have intertwined histories with military and harmful state applications, so provenance and technical brilliance are orthogonal to moral alignment.

Why it matters

For AI engineering, this is the argument that origin and lineage of a technology say nothing about whether its deployed use is aligned. Capability provenance is not a safety signal, and dual-use risk must be assessed at deployment, not inferred from pedigree.

Generalization

Capability quality and ethical alignment are independent axes; evaluating one does not inform the other.

John von Neumann received medals from IEEE and Nazi Germany for efficiency technologies used in harmful ways.
Open source video
Reminds us that technical brilliance does not guarantee moral or social alignment.
Open source video

Deep dives

5

Localization failures in LLM tokenizers, prompts, and tool-call parsers for non-Latin scripts and alternate numeral systems

Research question

How do LLM tokenizers and tool-call parsers produce silent failures for inputs containing non-Latin scripts and alternate numeral systems, and which failure classes are invisible to standard English-centric evaluations?

Why

The Arabic-versus-Western-Arabic numeral collision in Hedy is a concrete instance of hardcoded notational assumptions causing syntax-level failures. If LLM tooling inherits the same assumptions, it will fail silently for excluded user populations in ways translation cannot fix.

Different languages have unique challenges, such as Arabic numerals vs Western Arabic numerals.
Open source video
Facing unexpected challenges with Arabic numerals in programming syntax.
Open source video
Source video

Minimal human-held theory required for evolvable LLM-generated systems

Research question

What is the minimal human-held theory artifact (decision records, executable specifications, or equivalent) that must be maintained alongside LLM-generated code for the system to remain correctly evolvable by humans after generation?

Why

If code is a lossy encoding of a shared mental theory, then generation without theory capture produces systems that pass review but resist evolution. This specifies the durable engineering asset in an AI-native pipeline.

Programming is defined not merely as writing code
Open source video
Programming is ultimately about making programmers happy and proud, not just solving problems efficiently.
Open source video
Source video

Operational metrics that replace implementation difficulty as a value proxy for tools and AI components

Research question

What measurable criteria based on human problems solved and accessibility can replace complexity-based signals when selecting tools, abstractions, and AI components, and do they predict maintainability and adoption better than difficulty-based signals?

Why

The talk diagnoses the hard-equals-valuable fallacy but does not propose a replacement metric. Without an operational substitute, teams default to prestige-based selection and underinvest in high-leverage simple infrastructure.

The programming community overvalues hard, complex tools and undervalues easy, accessible ones.
Open source video
Making something easier is often perceived as taking away its value.
Open source video
Source video

Generalizing the Deep Blue precedent to programming as reflexive infrastructure

Research question

Does the post-Deep Blue re-definition of chess generalize to programming, given that programming is the tool used to build automating systems rather than a self-contained competitive game?

Why

This determines whether to expect a re-centering of human programming work around craft, intent, and community, or a more disruptive displacement. The answer shapes strategy for roles, skills, and review processes under heavy AI code generation.

After Deep Blue beat Kasparov, chess did not change fundamentally for human players; chess remains a human activity.
Open source video
Herbert Simon predicted computer chess champions in 1956.
Open source video
Source video

Deployment-time dual-use risk assessment independent of capability provenance

Research question

How should dual-use risk in AI systems be assessed at the point of deployment when capability provenance and technical brilliance provide no reliable alignment signal?

Why

The von Neumann example shows that technical quality and ethical alignment are independent axes. For AI engineering, this argues that safety and risk evaluation must be anchored at the point of use rather than inferred from lab pedigree or benchmark prestige.

John von Neumann received medals from IEEE and Nazi Germany for efficiency technologies used in harmful ways.
Open source video
Reminds us that technical brilliance does not guarantee moral or social alignment.
Open source video
Source video

Article ideas

4

Ease Is Not a Loss: Why AI Tooling Triggers the Prestige Reflex in Engineering

Resistance to AI coding tools is driven less by correctness or security concerns than by the status embedded in implementation difficulty; teams that mistake prestige for value systematically underinvest in high-leverage AI infrastructure.

Angle

Cultural critique grounded in the spreadsheet dismissal pattern and the Deep Blue precedent, arguing that engineering organizations should treat the prestige reflex as a measurable adoption risk rather than a technical objection.

Source video

Code Is Not the Deliverable: Theory Building in the Age of LLM Generation

LLM code generation without intent capture produces systems that pass review but resist evolution; the durable asset is the shared human theory encoded by the code, not the emitted artifact.

Angle

Applies Peter Naur-style theory building to AI code assistants, arguing that decision records and executable specifications must be maintained as first-class deliverables alongside generated code.

Source video

Your Tokenizer Is Not Localized: Silent Failures for Non-Latin Scripts

LLM tokenizers and prompt templates inherit hidden notational assumptions that produce silent failures for non-English, non-Latin-script users; these are parsing bugs, not translation gaps, and standard evaluations do not catch them.

Angle

Concrete failure-class analysis bridging Hedy's Arabic numeral collision to LLM tool-call parsing, with recommendations for locale-aware evaluation.

Source video

Spreadsheets Were Real Programming: How Gatekeeping Delays AI-Native Builders

The dismissal of spreadsheet programming as 'not real programming' predicts how domain-expert AI builders will be excluded; organizations that keep engineer-only review processes will miss the expanded builder population and its productivity gains.

Angle

Historical parallel to AI-native development, arguing that gatekeeping definitions are status proxies rather than capability measures and should be replaced with outcome-based inclusion criteria.

Source video

Project ideas

4

Locale Fuzz for LLM Toolcalls

beyond-evals

LLM tokenizers and tool-call parsers produce higher silent failure rates for inputs containing Eastern Arabic-Indic numerals and non-Latin scripts than for Western Arabic numerals and Latin script, and these failures are not surfaced as errors.

Proof of concept

Build a fuzzer that generates tool-call prompts and code snippets with numeral and script variations (Arabic-Indic digits, Devanagari, Hebrew RTL) and measures silent wrong outputs versus explicit errors across major LLM APIs.

Measurement

Silent failure rate per script and numeral system versus Latin baseline; proportion of failures caught by standard English-centric evals.

Source video

Theory Ledger

new

Maintaining a minimal human-held theory artifact (decision records plus executable specifications) alongside LLM-generated code increases the rate at which the system can be correctly evolved by humans after generation, compared to code-only handoff.

Proof of concept

Two teams implement the same feature with LLM generation; one maintains a theory ledger, the other receives only the generated code. Both then implement a novel change request; measure time, correctness, and regressions.

Measurement

Time to implement a novel change, correctness of the change, and count of regressions introduced.

Source video

Prestige Bias Audit

movement-lab

Engineering teams rate identical solutions as higher quality when presented with complexity-signaling language than with accessibility-signaling language, independent of function.

Proof of concept

Randomized survey with developers presenting two descriptions of functionally identical systems; one framed with complexity signals (e.g., custom C++ extension), the other with accessibility signals (e.g., spreadsheet macro). Measure perceived quality, maintainability, and adoption intent.

Measurement

Difference in Likert ratings and adoption intent between complexity-primed and accessibility-primed descriptions.

Source video

Provenance-Neutral Safety Gate

gatehouse

Assessing dual-use risk at the point of deployment with capability provenance hidden yields different risk classifications than assessments that include provenance or pedigree information.

Proof of concept

Give safety reviewers two versions of an AI system description, one with prestigious provenance and one with unknown provenance, and compare risk ratings and required mitigations.

Measurement

Difference in risk classification and required mitigations; inter-rater reliability across provenance conditions.

Source video

Architectural implications

3

Localization is treated as a surface concern rather than a structural property of a tool.

Before

Locale and script conventions are assumed to be English/Latin and handled (if at all) by a translation layer or UI strings.

After

Locale and notational conventions become explicit parameters of the language, parser, and tooling design, validated across numeral and script systems.

Consequence

Systems that ignore this will produce silent syntax-level failures for non-dominant-language users that cannot be fixed by translation.

Source video

Code is treated as the deliverable and the primary unit of review.

Before

Reviews, handoffs, and metrics center on the code artifact.

After

The artifact is treated as a lossy encoding of a human-held theory; when generation is automated, theory capture and transfer become the maintained asset.

Consequence

Organizations that automate code production without preserving intent and rationale accumulate unmaintainable systems that pass review.

Source video

Prestige is assigned to solutions by their implementation difficulty.

Before

Tool, language, and design choices are justified by complexity and the difficulty they signal.

After

Value is assigned by the human problem solved and the accessibility provided.

Consequence

This shifts what gets prototyped, funded, and kept in an AI-era stack toward simpler, higher-leverage abstractions.

Source video

Tradeoffs and failure modes

4

Accessibility versus prestige

Benefit

Lowering the barrier to entry broadens who can build and use the technology.

Cost or risk

The practitioner community devalues the tool and its creators, discouraging investment in the accessible path.

Making something easier is often perceived as taking away its value.
Open source video
Source video

Localization effort

Benefit

Localization enables worldwide access and inclusion for non-English users.

Cost or risk

Deep notational differences surface as unexpected syntax and parsing failures that are not visible in the dominant locale.

Facing unexpected challenges with Arabic numerals in programming syntax.
Open source video
Source video

Automating the core craft

Benefit

AI can take over the efficiency-oriented, problem-solving portion of programming.

Cost or risk

It triggers an identity crisis among practitioners whose value was anchored in that portion.

Recent AI advancements caused an identity crisis in computer science.
Open source video
Source video

Narrow definitions of programming

Benefit

A strict definition protects rigor and depth of expertise.

Cost or risk

It excludes productive domain-expert tooling such as spreadsheets from recognition and support.

Spreadsheet programming was often dismissed as 'not real programming' by traditional developers.
Open source video
Source video

Open questions

4

If technical difficulty is a poor proxy for value, what measurable criterion should replace it when selecting tools, abstractions, and AI components?

Why unresolved

The talk diagnoses the 'hard = valuable' fallacy but does not propose a replacement metric.

Research direction

Define and pilot value metrics based on human problems solved and accessibility, and test whether they predict maintainability and adoption better than complexity-based signals.

Source video

Does the Deep Blue precedent generalize to programming, given that programming is itself the tool used to build the automating systems?

Why unresolved

Chess is a self-contained competitive game; programming is reflexive infrastructure, so the analogy may break in ways the talk does not examine.

Research direction

Longitudinal study of how human roles and skill signals shift in teams with heavy AI code generation versus post-Deep Blue competitive chess.

Source video

What is the minimal human-held theory that must survive LLM code generation for the resulting system to remain evolvable?

Why unresolved

The theory-building framing is stated but not operationalized into a concrete artifact or process.

Research direction

Prototype and evaluate intent-capture artifacts (decision records, executable specifications) as the maintained deliverable alongside generated code.

Source video

How should localization constraints (numeral systems, scripts, direction) be handled in LLM tokenizers, prompts, and tool interfaces rather than only in end-user language design?

Why unresolved

The concrete failures cited come from a teaching language, not from LLM-based tooling, so the transfer is inferred rather than demonstrated.

Research direction

Benchmark tokenizer and tool-call behavior on non-Latin scripts and alternate numeral systems to find silent failure classes.

Source video

Key claims

8
opinionVerification not requested

The programming community overvalues hard, complex tools and undervalues easy, accessible ones.

Evidence

The programming community overvalues hard, complex tools and undervalues easy, accessible ones.

Source video
causalVerification needed

Perceiving an increase in ease as a loss of value is a recurring pattern in programming culture.

Evidence

Making something easier is often perceived as taking away its value.

Question

What evidence supports the claim that ease is systematically perceived as a loss of value across tooling communities?

Source video
comparativeVerification needed

Chess did not change fundamentally for human players after Deep Blue beat Kasparov.

Evidence

After Deep Blue beat Kasparov, chess did not change fundamentally for human players; chess remains a human activity.

Question

What measurable changes or non-changes in human chess participation occurred after 1997?

Source video
factualVerification needed

John von Neumann received medals from IEEE and Nazi Germany for efficiency technologies used in harmful ways.

Evidence

John von Neumann received medals from IEEE and Nazi Germany for efficiency technologies used in harmful ways.

Question

Which awards did von Neumann receive from IEEE and from German institutions, and for what work?

Source video
factualVerification needed

IBM punch cards were used to track Jewish populations and train schedules in Nazi Germany.

Evidence

IBM punch cards used to track Jewish populations and train schedules in Nazi Germany.

Question

What is the documented scope of IBM punch-card deployment in Nazi-era census and railway administration?

Source video
opinionVerification not requested

Programming is ultimately about making programmers happy and proud, not just solving problems efficiently.

Evidence

Programming is ultimately about making programmers happy and proud, not just solving problems efficiently.

Source video
factualVerification needed

Spreadsheet programming is dismissed as 'not real programming' by traditional developers.

Evidence

Spreadsheet programming was often dismissed as 'not real programming' by traditional developers.

Question

How frequently and in which venues does the dismissal of spreadsheet programming recur in professional communities?

Source video
factualVerification needed

Herbert Simon predicted computer chess champions in 1956.

Evidence

Herbert Simon predicted computer chess champions in 1956.

Question

In what 1956 publication or statement did Herbert Simon make this prediction?

Source video

Connections

5