Sure, there are some pretty funny (and clever) thoughts here. The quote about COBOL is priceless.
But this...
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.
FWIW, I have written over 1 million lines of BASIC for over 100 customers, most of it still it production, and all of it doing important work producing goods, services, and jobs in so many uncool industries we couldn't live without.
Maybe I'm an outlier, but I have gone on to learn algorithms, dynamic programming, database theory, client/server, and web development. I believe the elegant simplicity of BASIC and database theory, although limited in application, has provided an excellent base upon which to build.
I know that ewd is a giant to be respected, but I think it's a red flag when a teacher mutters "practically impossible to teach", even in jest. IMHO, that says more about the teacher than the student.
Posts like this are great for a laugh, but when you stop to think about it, all they really do is further amplify the perception of a huge gulf between theory and practice. Academics whine while those of us in the trenches are too busy to notice because our sleeves are rolled up while we build that which must be built.
Totally agree, I think we'd all be in major trouble if the mere exposure to Basic corrupted us. There is a whole generation that grew up on QBasic, GWBasic and of course Apple II's Basic.
As an aside, there's a definitely part of me that envies the days of building command line applications.
You really got to focus on the meat of the problem, instead of so much frilly interface issues which occupy us now. I think very few software engineers don't dream of the days when showing a text menu with a prompt for what action they wanted to take was about as far down the UI path you had to go.
I'm of course not arguing that the the web isn't far better in myriad ways, but the expectation to build beautiful interfaces, even if those expectations are purely our own, certainly has changed where we spend our time.
I'm still writing command-line applications (compilers), but they don't even do menus, everything comes from the command line or from files input.
But I don't think the server-side of the web is much different. Web servers are not a lot more than a function of the input stream to the output stream - compilers are much the same. A lot of fun can be had if you're in the deep end of the server side, writing framework functionality.
Ya, no for sure, I got to work on the backend of big web systems for a while and it was fun. (AMZN actually, the mother of all web backends)
But once you are in the teeny startup space then you become the jack of all trades and then you have to deal with the whole stack again. Unless you figure out how to make money off of jsonip.com that is. :)
I think he's referring to very old BASIC which used numbered lines, a whole lot of GOTO's, did not support subroutines (or did it? Correct me...), etc.
Correct. Many of the concrete arguments from "Goto Considered Harmful" fall apart when you even have named labels rather than line numbers. BASIC can be used to make a mess, but BASIC can also be used to write highly structured programs- you must be dilligent. I haven't written BASIC in years, but personally I think BASIC taught me why structured programming, careful naming and indentation are all vital to creating comprehensible code. Staring down a few thousand lines of your own spaghetti code from months before drives the point home in a very useful way.
BASIC has always supported subroutines, albeit in about the most primitive way possible: the GOSUB command jumps to a particular line number, then the RETURN command jumps back to the line after the GOSUB.
ANSI BASIC has supported SUBs and FUNCTIONs going quite a ways back. Microsoft just didn't bother to support that standard except in its commercial compilers, and later beginning with QBasic.
Some non-Microsoft microcomputer BASICs (for example Extended BASIC on TI-99/4A) support them to some extent.
That may be the case, but the oldest ANSI basic that Wikipedia mentions is "for minimal Basic" from 1978. This text is from 1975, and I doubt that ANSI standard had anything like what we nowadays call functions.
Typical Basics of 1975 had gosub/return, but no functions (= no arguments, no return values). Apart from loop variables, all variables were global.
Commodore Basic had a "def fn" command, but it only supported single-line (= single-statement) functions.
Add in the effect that one had to 'name' subroutines by line number, and compare this with the Lisp's and Fortrans of ten years earlier, and Dijkstra's position becomes quite defensible.
FWIW, I have written over 1 million lines of BASIC for over 100 customers, most of it still it production, and all of it doing important work producing goods, services, and jobs in so many uncool industries we couldn't live without.
No offense, but being in production for a long time is not an indicator of design quality. Some code is kept because it works well, other gets stuck in production precisely because it's a tangled, fragile and undocumented mess that people are afraid to touch.
As I see it, the real measure of code quality is how easy it is for others to modify your program.
Easily modified code does not need to be scrapped whole-hog and can be incrementally updated, so I agree with you that being in production for a long time is not an indicator of design quality with either valence.
I started programming on TI-BASIC (that's right, on TI's TI-80 http://en.wikipedia.org/wiki/TI-80). I don't know how mutilated that makes me, but if people such as me were put in an asylum, well... you'd need a pretty big asylum.
IMHO, people who start with Basic are doing it as a first exposure to something they will love to do, so not such a bad thing. Hell, learning TI-BASIC didn't stop me from acing all the Lisp classes I took afterwards.
I believed he earned his right to say whatever he wanted to say about Basic (or any other languages) with important contributions to the field.
And, as other pointed out, it's probably related to his work in formal methods and structured programming.
Sure, he earned his right to say it. But pretty much everyone has a right to speak their mind. That doesn't change the fact that this is an opinion, albeit one from a creator of the field.
Stroustrup says things all the time that I do not agree with. It's important to remember that appeal to authority is a logical fallacy -- just because he's well known doesn't mean he is necessarily correct.
Also, as you mention, he is coming at things from a totally different perspective. He probably couldn't care less if everyone is unable to be productive in his favorite language, as long as it met his standards (which do not seem to include many practical or productivity concerns).
The second time, I cried.
Sure, there are some pretty funny (and clever) thoughts here. The quote about COBOL is priceless.
But this...
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.
FWIW, I have written over 1 million lines of BASIC for over 100 customers, most of it still it production, and all of it doing important work producing goods, services, and jobs in so many uncool industries we couldn't live without.
Maybe I'm an outlier, but I have gone on to learn algorithms, dynamic programming, database theory, client/server, and web development. I believe the elegant simplicity of BASIC and database theory, although limited in application, has provided an excellent base upon which to build.
I know that ewd is a giant to be respected, but I think it's a red flag when a teacher mutters "practically impossible to teach", even in jest. IMHO, that says more about the teacher than the student.
Posts like this are great for a laugh, but when you stop to think about it, all they really do is further amplify the perception of a huge gulf between theory and practice. Academics whine while those of us in the trenches are too busy to notice because our sleeves are rolled up while we build that which must be built.