I learned how to program in VB4 too. My parents had no idea why I wanted it or what it was for. I used to take the textbook sized manuals with me to read/study while camping and fishing.
I first learned it by myself in VB5. I didn't even understand functions, but writing those MessageBoxes with buttons and then having them create even more message boxes was so great! I remember a high school friend bringing me 5 diskettes with VB4 installer because I didn't have it on my home computer.
Then next year I enrolled in AP Comp Sci - hardcore turbo c++. Just blew my mind!
> Then next year I enrolled in AP Comp Sci - hardcore turbo c++.
Funny enough, AP Comp Sci went the other direction in the early 2000s, switching from C++ to Java precisely because it was too hardcore for the average high school student.
My high school in ~2010 had the progression C -> C++ -> Java. I remember the C++ that we were taught being easy enough to learn after a semester of C, and graduated before I could take Java.
haha. I was so excited to learn about C-style strings in AP comp sci 2 I think. And bitshifting, and crazy recursions, queueing, etc. Good old days... I was so arrogant after that too. C is the best and everything else is garbage because it's "slow".
E.W.Dijkstra would disagree: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
When Dijkstra wrote that quote in 1975 he didn't had Visual Basic in mind, he was thinking the much older BASIC dialects that used line numbers and GOTOs for flow control.
Dijkstra was trying to promote structured programming languages like Algol and Visual Basic is based on the QBasic dialect which has full structured programming features like WHILE and FOR loops, IF that would work with compound statements (that is have the THEN part be more than a single command), local variables, functions, recursion, etc. It might be hard to image nowadays but there was a time when those weren't available to all languages. Though note that the next year after Dijkstra wrote that quote, the original Dartmouth BASIC actually got structured features. Though it wouldn't be until QBasic that you'd see a (popular) BASIC dialect having those in home computers.
Regardless, this quote was outdated long before Visual Basic 1 was made, let alone VB6.
GOTO for flow control is not that bad, it's just a tail call after all. The real damage is things like having everything be global variables. But part of that was a technical limitation, as things like "proper" call stacks and reentrant code as the default still had plenty of overhead, and even FORTRAN didn't support them.
I'm not sure what you have in mind but in the 1975 dialects of BASIC the code was something like
10 REM Grab input
20 GOSUB 1000
30 IF VALUE=BAR THEN GOTO 100
40 IF VALUE=BAZ THEN GOTO 200
50 IF VALUE=BLA THEN GOTO 300
60 GOTO 20
100 REM Bar stuff
110 blahblah
199 RESUME
200 REM Baz stuff
210 blahblah
299 RESUME
300 REM Bla stuff
310 blahblah
399 RESUME
1000 REM Code that grabs input
1010 blahblah
1100 RESUME
Note that this is a bit more readable than what people worked with since now you have syntax highlighting.
I'm not sure where tail calls enter in the picture... there wasn't even support for functions, at best you had GOSUB/RESUME which was essentially assembly-like CALL/RET.
I don't think that example you've posted is right (the grab input one, not the game on Github).
Firstly, RESUME was to continue execution after an error (eg ON ERROR RESUME NEXT). I think RETURN is what you might have meant?
Secondly, you cannot RESUME/RETURN from a GOTO. I think you meant GOSUB; which was a crude approximation of subroutines. BASIC did also have GOTO as well though.
Yes you are right, i meant GOSUB/RETURN. Though instead of "RESUME" (which should have been RETURN) most programs would use GOTO 20 (in an opposite expression of what Dijkstra wrote about, i accidentally used a 'function call' idiom instead of a spaghetti 'jump wherever' one :-P).
> I'm not sure where tail calls enter in the picture...
GOTO essentially involves setting the continuation of your program to something other than the following instruction(s). That's what a tail call does. No "functions" involved except as a high-level description.
Goto has its place. It's not evil, but should be used judiciously. After all, C family constructs such as break, continue are glorified/specialized, albeit scoped and unlabelled gotos.
One of the places I like gotos is when I need to break out of a nested loop. A goto to outside of the outer loop is far more obvious than a flag and a conditional to break from the parent nested loop. It also generates better machine code and uses fewer registers, at least in debug mode.
Sure, goto can be abused, just like every other language construct. They have their time and place, though.
The issue was not the presence of goto itself, but the fact that is was one of the main tools for flow control, while as you say it should be used sparingly.
It is like having an army of soldiers armed with a David Crockett[1] instead of a regular rifle. Things may get ugly fast.
Yes. And Dijkstra would be wrong. (Or, perhaps more accurately, prone to somewhat bombastic hyperbole.)
BASIC is structurally similar to ASM, moreso than is any other HLL, at least of any popularity. Like almost any language (or paradigm) it is possible to get stuck in its particular ruts, and when BASIC was at its peak popularity there were probably lots of people stuck in those ruts just as later happened with Java and the static, class-based OO paradigm more generally. A learning language isn't something you stock with exclusively, it's something you learn with and then diversify from, ideally, and for that, BASIC (old-school unstructured imperative BASIC) is great.
BASIC (old-school unstructured imperative) is structured as the "ASM" language for an old-school desk calculator from the 1960s, with a few tacked-on features around string manipulation, input handling etc. plus more, depending on the hardware. It was fine for what it was in the 1960s (a simplified "scripting"-focused version of FORTRAN), but the needs of even slightly more modern coding are very different, and BASIC would not serve them well.
to me, that was always a great example of the difference between IT and CS.
I totally understand how someone trained in VB was "mutilated" for CS. Because the priorities for CS coding are totally different than for commercial coding.
But from an IT perspective the point of programming is to be profitable, not perfect. VB allowed people to write profitable programs quickly. It was a fantastic environment if all you wanted to do was write desktop applications for businesses.
The quote is about BASIC. Visual Basic is a variant of BASIC.
The quote was also thrown around a lot in the late 90's as a "VB sucks, you should use a real programming language" comment in the usual language flame wars.
Certainly, the next few years of my learning to program was unlearning ideas I had developed from coding in Visual Basic. But it gave me the start in understanding how functions work, how sub-procedures work, and how objects work. More importantly though, Visual Basic gavve me the excitement and possibility that I could make this thing on my family's desk do pretty much whatever I wanted. And Visual Basic made that very accessible.
IMO it depends what you mean by “good programming”. An Excel spreadsheet with a bunch of VBA macros is by absolutely no means graceful programming or beautiful programming but it’s highly effective and has served as an entry to the world of programming for a huge number of people, myself included. It’s productive programming with little of the bikeshedding you’ll find in much less “mentally mutilated” setups.
Probably just hyperbolic. Bad habits are a common complaint in music and sports education too. Not insurmountable, but not helpful, and it must be frustrating as a teacher to have to unteach bad habits.
Christian theology was historically a great impediment to learning about physics; some Christian cults continue to impede people from learning about biology.
People who are really good at manipulating other people seem to have a hard time learning to do productive things, maybe because it's too easy to manipulate other people to do them instead, but maybe because people sometimes follow the Law of Attraction, where you make wishful thinking come true by believing in it hard enough, while software and Volkswagen engines do, if anything, the opposite.
More broadly, I think any field of learning carries with it a sort of implicit value system: we consider things x and y centrally important, while things a and b are inconsequential details. Much of learning a field involves internalizing these values to the point where you apply them automatically without even being aware that there's an alternative. But often they are suboptimal or even counterproductive in a different field. Volkswagen engines don't care about paint color or whether your grandfather just died, but they do care about thousandth-of-an-inch tolerances and not making mistakes. Interior decorating doesn't care about thousandth-of-an-inch tolerances or clean abstractions, but it does care about paint color and whether your grandfather just died. Debugging software doesn't care about not making mistakes or paint color, but it does care about clean abstractions.
This is even true in subfields within the same field: real-time engine control software cares about memory allocation in a way that seems completely insane to anyone who programs in Python, for example.
BASIC tends to reward novice programmers for banging on a piece of code cluelessly until they get it to work in some cases. Dijkstra, by contrast, believed that what was important was having sufficient logical understanding of the program's space of possible behaviors that you could be sure it would work even before testing it; he in fact designed and successfully taught an introduction-to-computer-programming course that used no actual computers. It's unsurprising that someone who had internalized BASIC's value system would be extremely resistant to Dijkstra's preferred approach, and that Dijkstra's disciples would be extremely resistant to the BASIC approach, even though in fact they are complementary, and each one works best for some classes of problems, so those who are best at one of these ways of working are those who would gain the most from learning the other.
