3 ms·

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 pro

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.

TeMPOraL 12y ago
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.
- lispm 12y ago
  > 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.
  - TuringTest 12y ago
    > 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.

TeMPOraL 12y ago

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.

lispm 12y ago
> 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.
- TuringTest 12y ago
  > 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.