59

I am the author of the article. The point is to simplify the model of computation, not to match flow charts. This is for mixed-ability 12 year olds, and when I say mixed, I mean some still add single digit numbers using their fingers. Flow charts work because you can easily jump to another point in the program. This is not software engineering. I want them ...


17

Why do you learn about bits and bytes if modern languages, with good reason, abstract from it? Why do we learn to program in assembler if modern languages, for good reason, abstract from it? Why do we learn bare-metal imperative programming if object oriented languages, with good reason, encapsulate it? Why do we learn C even though C++ offers much better ...


12

Don't teach it if you want Programmers (know what they're doing). Do teach it if you want Computer Scientists (know why they're doing it). Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore goto; they'll never need to know ...


10

Neither is always better, and both have their strengths. The idea of scoring higher marks as a criteria for better is going to be unpredictable without knowing who is granting those marks. Someone who is heavily in favor of one style over the other may grant higher marks to low quality uses of their favored style than they would to high quality answers in ...


9

I teach them within assembly code. Otherwise, I mention them within my Java class when I teach their modern-day analogues, break and continue. This is late in my AP course, after the AP test is over. I present the two statements as restricted versions of JMP (that's the 6502 Assembly syntax for goto), and I then follow up with two questions. They get to ...


9

I think the goto is sorely maligned. When Edsger Dijkstra wrote his famous letter in 1968, high level languages were not the same as they are today, and the goto could easily be abused. In my early days learning FORTRAN IV, the goto was an important part of the language and many of the important modern structures were not yet universally mainstream. The ...


6

Flowcharts are a useful tool to understand programs that perform moderately complex sequences of interactions. They aren't always a good way to describe an algorithm, but they are a good way to describe the behavior of a system that reacts to external events in different ways depending on its state, with a non-linear control flow. Note that by flowchart, I'm ...


4

If you are teaching assembly code or maybe Fortran then probably you need to discuss goto and possibly flow charts. However, if you are teaching a modern high level language, even something as old as Pascal, you should probably avoid them other than as an historic curiosity. This was settled almost 50 years ago, actually. Along with some other illuminati ...


4

The real question here seems more like when should you teach goto rather than if you should teach it. The first example programs should certainly not be looking like those we wrote on the machines in WH Smith on the way home from school: 10 PRINT "HELLO WORLD!" 20 GOTO 10 A while true construct is more sensible here. However, if you introduce your ...


4

I teach a college level introductory computer science course, where the primary goal is to learn programming in Java with no assumed prior programming experience. I do teach flow charting when I cover decision making & looping. Flowcharts aren't a great tool for an entire non-trivial program. They are a reasonable tool for high level algorithm design ...


3

Binary digital computers (and the execution of most programming languages) are just big state machines at their very heart. State machines usually require non-sequential state changes. e.g. gotos A flow chart is a form of state machine. (superset or subset?) You need goto's to learn jump statements in assembly language, asm to learn machine code, and ...


2

The other answers are already spot-on, but I wanted to offer another way to think about it... My question is this: which is better for planning a set of algorithms: pseudocode or flow charts? By better I mean faster, more accurate, easier to understand and/or gives a better chance of scoring higher marks. Like many things in programming, ...


2

Both are a requirement of one of the courses that I teach. I like to start with a flowchart, as (for all the reasons mentioned by @GypsySpellweaver already) they provide a good visual representation of the problem to be solved, and can help then to generate the pseudo code. Value of flowcharts Although I have seen it argued that flowcharts are somewhat ...


2

I will concern myself mostly with goto, but first a little on flow charts. On Flow charts I see flow charts as just a ways to visually represent goto-ful low-level algorithms/code. What flow charts are not Some other answers have mixed up their use with state-machines, or decision trees. Doing this could result in coding each code path separately, this ...


1

goto is not bad per se, it depends the way you use it, that's the way Dijkstra and other papers should be read. It can be very useful to simply get out from inner loops without creating weird boolean conditions. Of course if you use it to produce spaghetti code, that is bad. For example, Java banned goto but gives a break to label statement which is exactly ...


1

While both notations have their use, I would only use flow charts when the algorithm lends itself to it, namely when the algorithm is made of loops and conditionals. If your algorithm is recursive for instance, or rely fundamentally on a particular data structure (for instance a stack or a queue) then flowcharts won't help you. In my experience I found ...


Only top voted, non community-wiki answers of a minimum length are eligible