5 ms·

The piece argues that "[c]oding, like writing, is a mechanical act". It's certainly not the intent of the learn to code movement to teach typing skills! This st

The piece argues that "[c]oding, like writing, is a mechanical act". It's certainly not the intent of the learn to code movement to teach typing skills! This statement seems to grossly misrepresent what people mean when they say "learn to code". To learn to code is to learn to model systems. Programs are built from components -- abstractions -- and good programmers know a wide variety of abstractions and understand how to combine them to achieve the desired effect. A good program is one that accurately models the phenomena of interest, whether that phenomena is something as simple as "display the user's profile" or a complex simulation like a game. Now I would agree that many of the current curriculums are terrible, and teach no great insight into modelling. But that is the fault of the curriculum designers -- often people who have neither great experience in teaching or in programming. That doesn't mean there isn't good work being done, such as the Program by Design team (http://www.programbydesign.org/ http://www.programbydesign.org/). In short, I think the blog post builds a straw man argument. I agree it absolutely belts crap out of that straw man, but that is beside the point.

puranjay 12y ago
English major here. I'm currently learning how to code as part of a bootcamp called (surprise surprise) "Coding is the New Literacy". One of the things this program hammers in early is fundamental programming principles like OOP. A lot of MOOCs skirt around these topics, forcing you to 'build' non-functional apps first. I've taken those courses and learned nothing of real value. This program, where I've been forced to learn algorithms, OOP, etc. has been of much higher value. It's been harder, but I feel like I'm actually learning the fundamental principles of programming. I'll echo your sentiments: to learn how to program is to learn how to model systems.
- acron0 12y ago
  I am trying to read between the lines of your comment and I _think_ you get this but I'm going to spell it out anyway: "...fundamental programming principles like OOP." The key word here is "like". OOP is actually falling out of favor as a successful way to express models. Make sure you investigate alternatives to OOP (functional, procedural etc). As a graduate of OOP myself, it's interesting and exciting to approach different paradigms. Experience tells me that the best practices obsess over what things "do" rather than what things "are" (which is a fluffy concept at best). Anyway, tit for tat, YMMV. Glad you're doing something though.
  - robotkilla 12y ago
    How do you figure OOP is falling out of favor? I've seen a few arguments on HN (the old OOP vs FP discussion) but do you actually expect the trend to continue to the point that no one really uses OOP anymore? Highly doubtful. And which specific part of the industry is OOP slipping into obscurity?
    - makeitsuckless 12y ago
      It's just the HN hipster logic that confuses "successful" with "fashionable within a vary tiny echo chamber".
    - noelwelsh 12y ago
      FWIW, in my corner of the world (Scala, big data, web services) functional is very much the way things are going. It's a much better fit to the problem domain since all these systems very much look like pipelines. E.g. a web service is a function from request to respone. Big data applications are just applying some function over (possibly streaming) data. It's happening on the front-end as well, with things like React.
      - e12e 12y ago
        Might be worth remembering that OOP was born out of a need to model the real world (SIMUlation LAnguage). I don't think it's a surprise that functions are a good way to work with mathematical models (that is, after all, how we do math). For the front end, it's my understanding that event-passing systems are still used quite heavily -- which can also be considered OOP (message passing). Modelling a car as a sub-class of vehicle etc -- makes most sense when you're modelling real-world objects.
        TuringTest 12y ago
        You may be interested in the Actor Model [1] computation style. When used for programming, it looks like a programming paradigm where functional and object-oriented styles are neatly supported and blended without any impedance mismatches. Most code is written in a functional style, but there are abstractions that encapsulate state changes and make it work together with the mostly declarative functions. There are at least a couple of Coursera lectures teaching this style (one about programming paradigms, the other about reactive programming), it's worth giving it a look. [1] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model
- dragonwriter 12y ago
  > One of the things this program hammers in early is fundamental programming principles like OOP OOP is not a fundamental programming principle. Its a recently popular programming paradigm. The idea that OOP is a fundamental programming principle is a harmful concept to internalize (though lots of programmers trained in the last ~20-25 years have internalized it.)
  - jimbokun 12y ago
    OOP is a fine way to model many kinds of systems. It's not the only way, and it's not always the best way. But I think you do a disservice to the English major you are replying to by suggesting he or she is learning something "harmful" to their future development. I'm not saying your point is invalid or incorrect. I just think someone new to programming will be best served by learning how to write useful programs in one paradigm, before exploring multiple paradigms, or worrying about whether they are using the "right" one. I would say the same thing to someone being taught the functional paradigm as a beginner. It will make more sense to compare with other paradigms in the future, once you have some mastery of one paradigm.
    - dragonwriter 12y ago
      I didn't say (and don't believe) that learning OOP is harmful, I said internalizing the idea that OOP is a fundamental principle of programming is harmful.
  - puranjay 12y ago
    What would you say are fundamental programming principles? Genuine question. Right now, for instance, I'm learning about different data structures. Recently, I learned about different sorting algorithms. Would you say these are fundamental to understanding programming?
    - SilasX 12y ago
      Principles would be stuff in the form of "You should do things this way to end up with a better product, regardless of paradigm". Of the top of my head would be things like: - Modularity/Separation of concerns: The different functions a program needs to accomplish should be uncoupled as much as logically possible, to the point where you could easily swap out one with another way of accomplishing the same objective without affecting anything else. - Don't repeat yourself: Any time you're writing nearly the same thing over and over, that whole pattern should be abstracted away. - "I've only proven it correct, not run it.": You should be able to test the software in an environment that shows you what it would do, without affecting the thing you really want to operate on. - Write in a way that other humans can easily understand what you're doing. (e.g. name variables after what they're being used for, write comments help the code make sense and convey any tradeoffs)
- peterfirefly 12y ago
  > fundamental programming principles like OOP Learn you a Haskell for great good instead. Functions and types are fundamental. OOP not so much. Computation is fundamental, state not so much. Higher-order functions are not quite fundamental (depending on your point of view) but pretty close.
TuringTest 12y ago
This means we needn't fully specify a system to get started, we can simply craft new pieces as we go. We end up exploring the system as we create it and don't have to get a "complete" model to gain value. This is an essential part of the article, and why the author has a valid point. The problem with most current approaches to programming is that they don't provide good support for this partial, incremental way to build models - either your abstractions are fully developed, or they don't work at all and the program crashes during execution; there is no middle ground. Professional developers eventually learn how to build systems incrementally through testing (by building placeholders for yet-to-build components) and debugging (by exploring how the program behaves under different inputs), but these tools are complex and not really part of the programming language, and thus not adequate for basic literacy. Excel and Hypercard fall out of this requirement for perfect modelling, allowing partial execution of parts of the program, and intermixing data with the code that works on it, lowering the abstraction barrier; thus these tools work better for exploratory modelling than conventional programming languages, which keep data and commands wholly separate and require an exact specification to work. They have shortcomings, but the article is right that a tool for the wide public needs to reduce the level of formalism required to build models, and that "the computer revolution" based on that "lightweight modelling" approach has yet to come. There is an emerging movement for "live programming" that has created environments closer to that approach. This is still in its early stages, though we think we're finally close to achieve that vision. *Edit: format

puranjay 12y ago

English major here. I'm currently learning how to code as part of a bootcamp called (surprise surprise) "Coding is the New Literacy". One of the things this program hammers in early is fundamental programming principles like OOP. A lot of MOOCs skirt around these topics, forcing you to 'build' non-functional apps first. I've taken those courses and learned nothing of real value. This program, where I've been forced to learn algorithms, OOP, etc. has been of much higher value. It's been harder, but I feel like I'm actually learning the fundamental principles of programming. I'll echo your sentiments: to learn how to program is to learn how to model systems.

acron0 12y ago
I am trying to read between the lines of your comment and I _think_ you get this but I'm going to spell it out anyway: "...fundamental programming principles like OOP." The key word here is "like". OOP is actually falling out of favor as a successful way to express models. Make sure you investigate alternatives to OOP (functional, procedural etc). As a graduate of OOP myself, it's interesting and exciting to approach different paradigms. Experience tells me that the best practices obsess over what things "do" rather than what things "are" (which is a fluffy concept at best). Anyway, tit for tat, YMMV. Glad you're doing something though.
- robotkilla 12y ago
  How do you figure OOP is falling out of favor? I've seen a few arguments on HN (the old OOP vs FP discussion) but do you actually expect the trend to continue to the point that no one really uses OOP anymore? Highly doubtful. And which specific part of the industry is OOP slipping into obscurity?
  - makeitsuckless 12y ago
    It's just the HN hipster logic that confuses "successful" with "fashionable within a vary tiny echo chamber".
  - noelwelsh 12y ago
    FWIW, in my corner of the world (Scala, big data, web services) functional is very much the way things are going. It's a much better fit to the problem domain since all these systems very much look like pipelines. E.g. a web service is a function from request to respone. Big data applications are just applying some function over (possibly streaming) data. It's happening on the front-end as well, with things like React.
    - e12e 12y ago
      Might be worth remembering that OOP was born out of a need to model the real world (SIMUlation LAnguage). I don't think it's a surprise that functions are a good way to work with mathematical models (that is, after all, how we do math). For the front end, it's my understanding that event-passing systems are still used quite heavily -- which can also be considered OOP (message passing). Modelling a car as a sub-class of vehicle etc -- makes most sense when you're modelling real-world objects.
      - TuringTest 12y ago
        You may be interested in the Actor Model [1] computation style. When used for programming, it looks like a programming paradigm where functional and object-oriented styles are neatly supported and blended without any impedance mismatches. Most code is written in a functional style, but there are abstractions that encapsulate state changes and make it work together with the mostly declarative functions. There are at least a couple of Coursera lectures teaching this style (one about programming paradigms, the other about reactive programming), it's worth giving it a look. [1] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model
dragonwriter 12y ago
> One of the things this program hammers in early is fundamental programming principles like OOP OOP is not a fundamental programming principle. Its a recently popular programming paradigm. The idea that OOP is a fundamental programming principle is a harmful concept to internalize (though lots of programmers trained in the last ~20-25 years have internalized it.)
- jimbokun 12y ago
  OOP is a fine way to model many kinds of systems. It's not the only way, and it's not always the best way. But I think you do a disservice to the English major you are replying to by suggesting he or she is learning something "harmful" to their future development. I'm not saying your point is invalid or incorrect. I just think someone new to programming will be best served by learning how to write useful programs in one paradigm, before exploring multiple paradigms, or worrying about whether they are using the "right" one. I would say the same thing to someone being taught the functional paradigm as a beginner. It will make more sense to compare with other paradigms in the future, once you have some mastery of one paradigm.
  - dragonwriter 12y ago
    I didn't say (and don't believe) that learning OOP is harmful, I said internalizing the idea that OOP is a fundamental principle of programming is harmful.
- puranjay 12y ago
  What would you say are fundamental programming principles? Genuine question. Right now, for instance, I'm learning about different data structures. Recently, I learned about different sorting algorithms. Would you say these are fundamental to understanding programming?
  - SilasX 12y ago
    Principles would be stuff in the form of "You should do things this way to end up with a better product, regardless of paradigm". Of the top of my head would be things like: - Modularity/Separation of concerns: The different functions a program needs to accomplish should be uncoupled as much as logically possible, to the point where you could easily swap out one with another way of accomplishing the same objective without affecting anything else. - Don't repeat yourself: Any time you're writing nearly the same thing over and over, that whole pattern should be abstracted away. - "I've only proven it correct, not run it.": You should be able to test the software in an environment that shows you what it would do, without affecting the thing you really want to operate on. - Write in a way that other humans can easily understand what you're doing. (e.g. name variables after what they're being used for, write comments help the code make sense and convey any tradeoffs)
peterfirefly 12y ago
> fundamental programming principles like OOP Learn you a Haskell for great good instead. Functions and types are fundamental. OOP not so much. Computation is fundamental, state not so much. Higher-order functions are not quite fundamental (depending on your point of view) but pretty close.

TuringTest 12y ago

This means we needn't fully specify a system to get started, we can simply craft new pieces as we go. We end up exploring the system as we create it and don't have to get a "complete" model to gain value. This is an essential part of the article, and why the author has a valid point. The problem with most current approaches to programming is that they don't provide good support for this partial, incremental way to build models - either your abstractions are fully developed, or they don't work at all and the program crashes during execution; there is no middle ground. Professional developers eventually learn how to build systems incrementally through testing (by building placeholders for yet-to-build components) and debugging (by exploring how the program behaves under different inputs), but these tools are complex and not really part of the programming language, and thus not adequate for basic literacy. Excel and Hypercard fall out of this requirement for perfect modelling, allowing partial execution of parts of the program, and intermixing data with the code that works on it, lowering the abstraction barrier; thus these tools work better for exploratory modelling than conventional programming languages, which keep data and commands wholly separate and require an exact specification to work. They have shortcomings, but the article is right that a tool for the wide public needs to reduce the level of formalism required to build models, and that "the computer revolution" based on that "lightweight modelling" approach has yet to come. There is an emerging movement for "live programming" that has created environments closer to that approach. This is still in its early stages, though we think we're finally close to achieve that vision. *Edit: format