Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Parent Full thread

I have to partially disagree with Chris here on two aspects.

First of all, programming indeed seems to be a fundamental thing, on the level of reading, writing and arithmetics. It gives you new classes of mental tools that allow you to think thoughts previously unthinkable.

People sometimes say it's very arrogant of some programmers to think they have something important to say in fields of biology, physics, philosophy, etc. But it's not arrogance. There are important insights in CS shining light on every other branch of science that are often noticed by people related to programming and CS fields because no one else is trained to think in this fundamental new way.

But I strongly agree with Chris on one thing here - this is not what you get in those "Teach Children to Code" programs. Those will teach you how to become a frontend developer in a year and earn good money, which honestly doesn't require you to think at all. It's a trained-monkey level thing. They took what was supposed to be an idea about education and turned it into something that's about money and career.

I think Bret Victor did the best summary of why current "teach kids to code" movement is just total bullshit.

http://worrydream.com/MeanwhileAtCodeOrg/

Second - modeling. I agree with the sentiment that it's modeling that's (one of) fundamental thing(s). But it can't just be any modeling. Because typical "modeling" of today is that diagram your chief marketer drew on a whiteboard that conveys exactly zero knowledge (or even negative knowledge, if you count in confusion it caused). Typical "modeling" gets you UML diagrams, which we all know are most useful as padding at the bottom of the trash can, so there's something to absorb coffee from the cup that you just have thrown away.

The modeling that programming is about is careful and very precise expression of concepts. It's like that saying goes - "if you want to really understand something, teach it to someone; but if you want to really, really comprehend it, teach a computer to do it". Computers are unforgiving - either you exactly understand what you're doing and can express it precisely, or it doesn't work. There's no room for error or hand-waving around difficult concepts that people do when explaining things to one another.

So modeling may be the new literacy, but this must be careful and precise modeling.

The modeling that programming is about is careful and very precise expression of concepts. It's like that saying goes - "if you want to really understand something, teach it to someone; but if you want to really, really comprehend it, teach a computer to do it".

This is all well and true for scientific modelling, where you want to achieve an exact depiction of how nature works. But for more social undertakes I believe that level of exactness is overkill and brings unnecessary complexity.

After all, society members have been able to collaborate in numerous projects that don't need that level of accuracy, well before (and after) the widespread adoption of scientific reasoning. Most social activities simply don't need such precision and can advance with an amount of ambiguity and implicit knowledge, with which a computer would choke.

In such environments, people could still benefit from modelling through computers in a way focused not in precision, but in semi-automation of routine tasks.

Where computer programs need that every possible case is taken into account in the model and handled with precission, a system that handled well the common cases and delegated outliers and exceptions to human supervision could greatly improve those social enterprises without requiring that those involved learn how to express their thoughts with scientific meticulousness.

Alas, modern programming languages are not adequate to support that semi-structured way to modelling, but I think we are closer than ever to build a tool that can allow end users to build domain-specific abstractions without learning to create imperative programs or learn how computers work internally - the ideas to make this happen are floating around with strength for some time.

> This is all well and true for scientific modelling, where you want to achieve an exact depiction of how nature works. But for more social undertakes I believe that level of exactness is overkill and brings unnecessary complexity. (...) Most social activities simply don't need such precision and can advance with an amount of ambiguity and implicit knowledge, with which a computer would choke.

This reminds me of a common misconception that computers are about precision as opposed to ambiguity. It's not true - computers handle ambiguity well, but force you to be precise about what is ambiguous and in what way ;). We've invented probability theory to deal with uncertainity in a proper manner.

Of course, most social activities work fine with handwaving anything we're not sure or don't understand - but well, humans do have this skill and it's not going away. What programming does is it complements that skill with an ability to be precise about uncertainity when you need to.

> Alas, modern programming languages are not adequate to support that semi-structured way to modelling, but I think we are closer than ever to build a tool that can allow end users to build domain-specific abstractions without learning to create imperative programs or learn how computers work internally - the ideas to make this happen are floating around with strength for some time.

I agree, though I don't think we can get there without teaching people the essence of programming. Syntax peculiarities don't really matter, but the basic ideas are so fundamental, they're probably more fundamental to reality than physics. I believe you need to have an intuitive grasp on computation to be effective even with that semi-structured modelling - because not everything we know from today's programming is working around machine-imposed constraints; some of it is actually touching the very fabric of reality.

  I agree, though I don't think we can get there without 
  teaching people the essence of programming.

That's probably true. Though what is "the essence of programming" IMHO is quite different from what most developers think when they talk about "teaching programming" to the general public; it should have little to do with how to represent computations in available computer hardware, and everything to do with building domain-specific languages that represent interesting concepts - for people who don't like computers nor want to understand how they're built.

As others have pointed out in this thread, what is truly essential is the nature of modelling, i.e. building abstractions from constituent parts, either in bottom-up or top-down fashion. And as the original article says, an essential property is being able to build working parts of the system without needing to complete the whole of it before execution.

  I believe you need to have an intuitive grasp on
  computation to be effective even with that 
  semi-structured modelling

True, but again what developers usually think of computation (building a tree-like program that is executed at runtime with a specific dataset) is not what is needed by the general public.

Research in End-User Development, watching real people use experimental IDEs for non-programmers, have found that systems based on rewrite rules are easy to grasp.

Also image-based environments like Smalltalk and "live" programming -where the whole system is seen as a single collection of data and always-running code- that reacts to changes instantly is also simpler to understand than the standard write-compile-execute cycle, and better adapted to exploratory programming.

I agree with everything you wrote. Those essential skills have little to do with what we as programmers do every day at work. Also people seem to rediscover them in many different ways - look at things that are made in Minecraft or Dwarf Fortress, for example. There's lot of application of those concepts in something that doesn't involve writing code directly.

> Also image-based environments like Smalltalk and "live" programming -where the whole system is seen as a single collection of data and always-running code- that reacts to changes instantly is also simpler to understand than the standard write-compile-execute cycle, and better adapted to exploratory programming.

As someone in love with Lisp, I endorse this message.

> simpler to understand than the standard write-compile-execute cycle

well, you'll hear different things about that. Some say the exact opposite, since understanding the program then depends on the large amount of state of a running system. In contrast, the write-compile-execute-cycle is more controlled, since the state building is being controlled as part of starting the program.

> understanding the program then depends on the large amount of state of a running system

Fair enough. But a system based on declarative functional language should largely avoid that problem, as all state has to be made explicit, and all interactions with state are represented locally.

But that's why we have Aglie and NoSQL. Modelling was just slowing us down. :)

> But that's why we have Aglie and NoSQL. Thinking was just slowing us down. :)

FTFY ;).

non trivial front end stuff does involve systems modeling in the sense mentioned in the article. Just saying ;)

Of course it does, as non-trivial anything development. It's just not what people are being taught, and more importantly - they're being taught things for a wrong reason. "Teach kids to code" was supposed to be about making them smarter, allowing them to think in ways they previously couldn't. Not about preparing them for a lucrative career.

You know, basic alphabetization also does not teach kids to think in any way. And does not even prepare them for a lucrative career either.

If your criticism is that those programs do no go far enough, I can agree with that. But they have to start somewhere, and that somewhere must be easy and basic.

Fair enough. My criticism is that they focus on the wrong thing. They turn into vocational training. It's a different goal, even if the beginnings look the same. We don't need everyone to be a developer - but we could use everyone understanding concepts related to computation.

Reply on news.ycombinator.com