A path tracer is a classic classroom project example. I really do not think knowing how to write one is even remotely related to "knowing a programming language" at least in the way it's expected in a professional setting
Writing programs requires an education. You can sort of fake it with training, if you're a machine that can train on a billion examples and reliably retain something from each one, without understanding any of them.
A fundamental problem with how we teach programming is that we focus on writing, instead of reading, software. To borrow terminology from the language arts; we don't focus enough on reading comprehension.
I used to be more involved in the educational space–I used to teach college-level classes and also participate/organize/mentor coding spaces for young adults–and I don't think there is anything inherently wrong with the way that we teach programming.
I have come to believe, after years of teaching, that you cannot _teach_ curiosity, but you can help create environments that foster a students desire to learn and explore. As such, the point of education is to expose and empower children (people, really) to have the tools they need to explore and discover the things that they _want_ to understand and master. You really can't _make_ someone enjoy "x", where "x" is the passion of the teacher.
Programming, to me, is like writing, painting, or mathematics. In so much that it is a multi-faceted discipline. Coding is to writing as typing is to penmanship. There are _many_ reasons to write; from jotting down a grocery list to writing an epic novel, just as there are many reasons to code; from bulk automation/text transformation to diving into deep artificial intelligence. Just as there are many reasons to paint, and many reasons to do math. The "how" is dependent on the "why".
Most people don't learn to mix oil paint simply for the joys of mixing oil paints, most people don't learn penmanship simply because they long to see a well formed letterform. Few people learn the how to take the functional derivative, simply because. It's a means to an end; they learn to do it because they need to express something _else_.
I don't expect every child in my english classes to go on to write a great non-fiction masterpiece or an epic novel. In fact, most of them wont, but I _do_ think its important that they are exposed to the fundamental skills involved; penmanship, vocabulary, basic composition, in the event they _do_ want to write, or code, or compute, or paint, or whatever...
I think "school" is exposure to the mechanics, and individuals who desire more will seek out the rest.
I think what a lot of instructors fail at is they don't give students a working example of how something works. Sure you're not really going to learn, but what's the point of me having a half-assed assignment that isn't useful for me referencing a couple years down the road?
The simple best way to program is exposure, and a lot of it. Not these boring petty tasks we do. They're logic puzzles and not much else. Showing someone how everything works from start to finish in creating a website with a specified framework helps tremendously. Or how to work with low level C programming making practical applications.
For myself personally I developed a method of TODO's with some of what my lead taught me mixed in. My lead doesn't like redundant code, but said "working code is better than no code." So what I did is made one type of TODO that means "this code sucks or should very much be revised." Another one I have is "talk to my lead." With those, I don't address it with my lead unless we already have a meeting and it'll be quick, or I compound enough of them to devote an actual meeting regarding them.
Overall it has helped me stay organized, and it keeps me from annoying my lead. So what I'd add is, a system for people to make their own notetaking is vital when learning. If you don't have that or arent willing to take the initiative to do that, personally I think coding is not for you.
I think it should be taught in school, but it shouldn't
be forced on students; sorry, but some of your programming
books are 600 pages of absolute boredom. I've wondered for
years why computer programming books are so terribly written. It's not a crime to include diagrams, and highlight
the really important concepts. I would like to see a Hacakathon for writers of programming books. The shortest
book that got across the material would Win!
I think programming has to be taught just like writing is taught. Its so generally useful. Everyone has something going on in their lives that they can write a script to do, if they only knew they could even do such a thing. Too many people don't realize what these computers can really do for them beyond the four walls of the gui and software made by someone else, and its kinda sad.
If you want to write programs without really having a clue, that's fine and educational for most purposes, just not if you're hacking your personal vehicle, pacemaker, or nuclear reactor.
As someone who learned to program in my 30s (spent my 20s as a professional musician) I can't agree more. The book that was recommended to me was K&R, which I found so dry as to be impossible to read through. The first book I really used was C++ in 21 Days, which has you writing working programs from...well, from day 1.
I always thought the reason for this problem in teaching programming is that what you need to know when switching to a new language is totally different from what you need to know when you don't know how to program. If you already know how to program, the first thing you need to know is the syntax: data types, iterators, etc. It's like being a carpenter and going to a new shop -- what are the tools? But if you don't know how to use the tools, being told the torque on an impact wrench is completely useless information. Not only is it useless, it's easy to look up, and therefore a waste of time to teach.
I now help teach the Boston Python Workshop, a weekend workshop for non-developer women and their friends. We do cover loops and data types on Saturday morning, but then all afternoon is projects -- building programs that cheat at scrabble, access twitter, and draw colored grids.
I totally understand why experienced programmers teach the way they do -- it's what they'd want to know. But the focus should not be on the language, it should be on the skill of how to program regardless of language. And yes, that's really hard to teach.
Many young people don't know history, science, other languages, or even the grammar of their native language. That is why we teach.
The "ecosystem" of programming languages is healthy. There are many options, some to master, some to consider. But not knowing how to use a tool -- especially a widely-used and powerful tool -- is no badge of honour or discernment.
I definitely see what you're saying. I think many people come to programming with the mindset that it's just like math. Memorize the formulas and the rules, and then get the right answer. So they just want somebody to teach them the formula so they can memorize it. But that's just not how writing software works.
> I teach introductory programming to college freshmen. We usually spend the first few classes talking about, writing, and refining algorithms in clear and simple English before we even start talking about the programming language they're to learn.
Explaining algorithms to someone in clear and simple English will enable them to understand those algorithms, but a computer does not understand English. To 'write' an algorithm for a computer to perform, you need to code.
My experience has been similar. A good coding style for teaching, when the reader doesn't yet recognise the building blocks of a language or their idiomatic usage, is often very different to a good coding style for professional use, when the reader can be assumed to understand the concepts and idioms already.
> But I still don't see how something like this could be anything but a net positive.
The student will construct their own knowledge of programming by some learning process. This tool has an effect on that process, as has every tool. It could, for example, let some students construct an understanding of a variable that makes it harder to start learning about, say, memoization in dynamic programming. (This is just an conjectured example, mind)
I don't say it will, and I do have to say that the visualization given is quite nice and sound. But because we, as experienced programmers, like a tool because it visualizes how we think about programming and program execution, that does not mean that this is transferable in a similar way to novice programmers. As a high school computer science teacher I have been growing more and more worried about so called anti-didactic inversion in programming education. Especially at lower levels of education.
In programming education, we often use professional programming tools with professional programming languages and professional measures of programming quality. When students are learning to become professional programmers, this is a good idea. But is it as good an idea for teaching programming to those who do not want to become professional programmers. Or for those who are learning programming as a basic skill (like math, language, etc)?
Your stereotype may or may not be true. I'm self-taught, my degree is in Aerospace Engineering. But I was curious about how the author(s) of a BASIC interpreter knew what to put in the language so that I could write a little program to determine bending moments in Harpoon anti-ship missiles. I started with the CS part, and ended up having to learn programming concepts along the way.
There is a big issue with teaching to code and that is if you want it to scale and have teachers introduce kids to coding, you have to make sure that the material taught is very in line with core requirements. Computer science and coding curriculum is not set in stone yet, but where it's going covers the most common language constructs of today, like loops, conditionals and procedural coding. It is a stretch to show how learning to create dataflow programs maps to procedural understanding and algorithms. Moreover, there's very few general purpose dataflow environments that are widely accepted in computer science, and so learning dataflow won't necessarily ease the transition for students to later learn modern programming languages.
TL;DR For a layperson, the association between dataflow and 'real coding' is very weak. For a programmer on the other hand, the association may be less weak, but the skill may nonetheless not be applicable to most real world applications.
reply