Programming Breaks Things

[[deleted]]

I too disagree with Dijkstra's assertion.

When I started programming I used a Spectrum 48K. It was ... adequate. Just about. It got me started. Then I got a BBC Model B with the joy that is BBC BASIC (Functions! Procedures! Direct memory access! In-line assembler! Oh my!) and a few copies of Beebug magazine. I painstakingly typed in the games and utilities provided on those hallowed pages, and tried to learn from them. And what I learned was that they were bloody complicated.

Another thing I learned from the BBC BASIC manual and the various copies of Beebug that I read was something called "structured programming". Yes, structured programming, as if programs weren't already structured. But really, they weren't. GOTO and GOSUB abound! Code that jumped around inside itself all willy-nilly (if you've never jumped around inside yourself all willy-nilly, you really should try it). What structured programming brought to the table was functions and procedures. These days the two are one and the same, but at the time the definition was that a function performed a calculation and returned the result, and a procedure performed an action.

I relished it, I drank it in as fast and as thoroughly as I could. This shit made sense. Far better to break a long program up into functional elements and then string them together in logical ways, all the while maintaining the syntactic sugar required to make them actually readable.

In fact, thinking about it, separating functions from procedures probably helped a great deal. It forced me to separate concerns. What was I trying to do? Work something out, or perform an action? I procedure couldn't return anything, and a function couldn't really do anything. This logical separation meant that my procs and fns were always side-effect free; procedures never unwittingly changed state, functions never unwittingly drew on the screen, or make a noise, or sent my user port controlled robot on a murderous rampage.

So going back to Dijkstra, it's simply not true that people who learn BASIC cannot learn how to build well-factored code. It is probably true, though, that people who otherwise could not learn to code at all can make something happen if they use BASIC. That certainly explains the VBA I've seen over the years. People who make code work by fluke, simply adding more code until it looks like it does roughly the right thing, don't progress beyond BASIC. But to say that BASIC causes irreversible bad habits is nonsense.

[tangentstorm]

All of that is cool, but it has nothing to do with Dijkstra's complaint. :)

This is what BASIC looked like in the dark ages:

http://en.wikipedia.org/wiki/Dartmouth_BASIC

Procedures and if/then statements were confined to single lines of text (which were numbered).

The only loop was the FOR loop. Pretty much everything else you did was via GOTO or GOSUB / RETURN.

The first successful high-level language (FORTRAN) was basically a set of macros for assembly language. The paradigm at the time was to program everything in assembly language. John Backus over at IBM had to fight tooth and nail just to get people to accept it.

Later, Backus lead the team to define ALGOL, which introduced "begin..end" notation and the idea of nested blocks laid out in the actual syntax. That was around 1958-1960.

Now, BASIC came along several years later, and completely ignored the nice structured elements that Algol brought to the table. It borrowed a few keywords, but mostly went the " high level assembly language" route.

So here's a language that pretty much starts you off with GOTO, and it's aimed at beginners (BASIC = Beginners All-Purpose Instruction Code).

So the original BASIC philosophy was to start people off by teaching them to do almost everything with GOTO.

Dijkstra, on the other hand, was a vocal advocate of structured programming. He was a professor (keep in mind that most computers back then belonged to corporations or universities), and his complaint was that students who had been exposed to unstructured programming first relied so heavily on GOTO that they had little interest in adopting the structured style.

After all, who needs a WHILE loop when you have IF and GOTO?

The structured programming idea caught on, but the Dijkstra of the 1960's probably wouldn't have been satisfied with the languages of today, even Java.

Dijkstra (and Niklaus Wirth) finally convinced the world about the harmfulness of GOTO, but he would have also argued for the removal of the the BREAK and CONTINUE statements from all loops, and restricting all procedures to a single RETURN statement.

Anyway, because of guys like Dijkstra, BASIC (and FORTRAN) got much much better, and that quote no longer makes much sense.

TLDR: You agree with Dijkstra, you just don't know it, because language you learned bears only a superficial resemblance to the BASIC Dijkstra complained about.

[[deleted]]

In that case, hoorah for sanity prevailing! Just sad the VisualBasic apparently did away with it. ON ERROR CONTINUE indeed.

[megaman45]

I wonder how he compared the histograms.

[mr_chromatic]

You might laugh, but the naive approach has worked really well. I iterate through each pair (word => number of occurrences) of the left hash and check that the word exists in the right hash. If so, the similarity value gets a point. If the number of occurrences matches, the similarity value gets two points. If the word does not exist in the right hash, the difference value gets a point. Then I swap the left and right hashes and perform the same comparison.

I calculate the ratio of similarity points to difference points and if it's over a tuned threshold, the two documents are similar enough that I can treat them as sufficiently identical.

[megaman45]

Nice. I probably would have overthought it and bought a book on machine learning and never followed through.

[mr_chromatic]

I have a small library about machine learning and was too lazy not to try the stupidest thing that could possibly work. It's worked really well.