The Value of BASIC As a First Programming Language

Mirk writes "Computer-science legend Edsger W. Dijkstra famously wrote: '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.' The Reinvigorated Programmer argues that the world is full of excellent programmers who cut their teeth on BASIC, and suggests it could even be because they started out with BASIC."

Comments

Start with scripting

[Anonymous Coward]

Scripting with JavaScript in Firebug is an easy way to learn and there is no compiler involved.

Re:Start with scripting

[Anonymous Coward]

At least, it has a decent syntax.

Re:Start with scripting

[Alien1024]

Javascript is just a bad language to learn how to program. A bad language all around, in fact. OK not as bad as BASIC, but still...

Re:Start with scripting

[Z00L00K]

Compared to vbScript JavaScript is a blessing, but compared to a fully compiling language with strong typing like Java it sucks.

Re:Start with scripting

[arethuza]

I used to have the same attitude about JavaScript - then I learned jQuery and got more familiar with the language and I really like it now - it has some serious quirks but at the core it is one neat little language.

Re:Start with scripting

[beakerMeep]

That's just nonsense. JavaScript is great for learning simply because it's good at giving immediate results that users can see, in a format they can all relate to (web pages). It's also a very nice language that doesn't throw too much IO stuff or memory addressing at the beginner. It adds a bit of "fun" to the coding process. Something that was sorely lacking when I wrote my first hello world in fortran.

A lot of the older coders hate it though because it's easy and flexible and gives the programmer much rope to hang themselves, but that's just "get off my lawn" nonsense. The reality is, and I'm surprised no slashdotter has mentioned this yet, is we all feel like we cut our teeth on the best programming language. And those other guys who do stuff differently must be wrong.

I swear I hear Foghorn Leghorn's voice when reading some of these comments. "I say, I say, a those new-fangled curly braces languages are an abominations boy! An abominable snowman, I say!"

This attitude is pervasive in the developer world and if you dont believe me, re-read all these comments. Developers need a bit more self reflection about what it means to be a good developer. It's not just about what crazy hard language you started with, or what perfect cohesion, or design pattern mastery you have. Rather nowadays, it's also about teamwork, problem solving, readability, modularity, and user experience. I know a few guys who might be masters of the command line, wizards at writing regex, and zen-like in their ability to do bit shifting math. But, for most projects, I wouldn't want them anywhere near my team/code.

People forget that learning isn't all about what the "right way" is. Learning is about accumulating knowledge in steps, and then retaining it. Making the process fun means better retention. I'd hope that more of the developer world groks this soon, as the machismo bullshit that comes out of these conversations is what drives smart and nice people away from developing.

Re:Start with scripting

[OeLeWaPpErKe]

If you're on about immediate results which user can see, nothing beats QBASIC (still included with every WinXP).

Type - F5 - immediate execution
and -should that not be fast enough for you- there's an "immediate" window below that's even faster

I loved that tool. Very limiting in what it can do, but talk about immediate -and enjoyable- results. It's even faster than turbo pascal and turbo C, both of which are still very, very fast in starting programs. And all of these make one want to ask the ancient egyptians for some hints to survive a single java or gcc compile.

And while, yes, qbasic is slow, it's certainly fast and capable enough to get a full-blown software rendering 3d engine operational in on a 286. Arguing about execution speed of qbasic on anything resemblind a recent machine is ridiculous.

Re:Start with scripting

[beakerMeep]

If you think my post was about compile or execution time, you perfectly missed the point. And, I really mean no offense by this (hope you dont take it personally), but quite frankly you epitomize what I meant when I spoke of developers who don't understand how people learn, and instead guage arbitrary factors like compile time or execution time. Hence your defense of QBasic's 3D capabilities which are wholly irrelevant to someone writing their first for loop.

Re:Start with scripting

[Alien1024]

That's just nonsense. JavaScript is great for learning simply because it's good at giving immediate results that users can see, in a format they can all relate to (web pages). It's also a very nice language that doesn't throw too much IO stuff or memory addressing at the beginner. It adds a bit of "fun" to the coding process. Something that was sorely lacking when I wrote my first hello world in fortran.

C# can also give immediate, direct results, is very easy to debug and has all the other advantages. From VS 2005 on you can even change the code while debugging and changes take effect without having to recompile.

I dislike javascript mainly for being weakly-typed. And encouraging the beginner to use late binding (being the only option) is just a bad idea.

For what is worth, I am not one of those programmers who feel they cut their teeth on the best language. I started with Sinclair BASIC and I have no problem to admit it is horrible, and, as I stated in another post, I disagree with the author of TFA when he says BASIC gave you an insight on control structures and how they were implemented under the hood.

Re:Start with scripting

[Rei]

And while, yes, qbasic is slow, it's certainly fast and capable enough to get a full-blown software rendering 3d engine operational in on a 286.

Wireframe, sure. Or using QBasic to make PEEK and POKE calls (but if you're going to go that far, heck, you might as well right in assembly). But the per-pixel draw routes in QBasic on the 286 were abysmal, and even line draws were way too slow. I think it called a full screen refresh for each graphics call you made. I would know how slow it was; I wrote 3d engines on the 286, both true 3d and raycasting. The 286 could barely handle *compiled* 3d; A10 Tank Killer was about the best it got. True compiled 3d didn't get half decent until X-wing on the 386.

The slow performance of QBasic was the reason I begged my father to buy me Borland C for my birthday back in 7th grade. I was completely blown away by the performance increase. But I'm still glad I learned in basic, as going from "no programming" straight to C would be a pretty big jump. I remember that in my first C program I was hit by a persistent bug that required a #pragma statement to get rid of. I can't imagine if I hadn't known how to program at all before that point.

Re:Start with scripting

[OeLeWaPpErKe]

I am the same boat as you. My father, of course, wouldn't pay for it so I ended up with Turbo pascal.

I did use an external polygon fill routine on a 286 for qbasic. And external line drawer. Even with that my engines were mostly wireframe.

Sad thing was, my sprite based games on c64 were far more advanced than the best thing I ever got going on a 286.

Man, the amount of time I could spend working to get a little 3d engine going.

Good times.

Re:Start with scripting

[Rei]

Were you like me, trying to come up with algorithms on your own for doing the 3d calcs before you ever read about them? My first attempt for dealing with rotation used my middle school knowledge of geometry; I calculated the angle from the center of the screen to each point with an arc-tangent, then added the rotation to it, then converted it back to screen space with sines and cosines. Not as fast or elegant as a rotation matrix, but it worked! ;) Oh, I was thrilled when I learned how simply you could do rotation without needing any trig.

My first year in high school, they had a "programming" course available as an elective. It was in Basic and only covered really simple stuff, but by then I was well versed in C. The only thing I really learned in that course was espionage. I wrote a program that mimicked DOS and would capture login attempts ;) My teacher let me use C for my final project, and I made a "demo" that had a bunch of scenes, such as me walking into a scene and shooting lightning bolts, a hyperspace tunnel, etc. My favorite part was where I had a stereogram generator. The hidden image was the teacher's username and password. ;) She got a kick out of it. Oh, and I also wrote a raycasting engine and the world's most realistic Pong AI for fun while goofing off in that course (the AI mimicked the reasons why humans miss -- reaction time, impact location estimation error, reaction speed, etc). ;) I later incorporated that Pong AI into an entirely x86 assembly Mode-X Pong game called RuriPong, which had pseudo-3d animated special effects, sound effects, mouse support, etc.

Ah, good times indeed. :)

Re:Start with scripting

[OeLeWaPpErKe]

I tried and tried to come up with a rotation routine. It took me years. Eventually I got hold of some math books that mentioned polar coordinates and so I calculated back and forth with immensely long trigonometric routines, not even using arctangent. I basically started with x = a cos t (equiv for y) and simply had forward and backward lookup tables (and fixed point math allowing direct indexing into an array) (if you have 256 values for sin and cos each in those tables it's more than accurate enough for 320x200 graphics. Even on 640x480 it was hardly noticeable). Need a massive speedup ? Change that lookup table into 64 entries.

Lookup tables were a solution for several problems. Taught me the value of symbolically isolating variables in mathematical expressions.

Oddly enough, the main problem was not speed, the main problem was long-term loss of accuracy (be re-using calculation results). I eventually got that solved : simply restart entirely from the initial model for every frame. Hardly any computational cost, and accuracy demands go down significantly.

I wrote a lot of games and quite a few demos too. Not as advanced as those I found on BBS'es because well, try understanding mandelbrot without knowing about complex numbers. I actually tried several values for i, obviously none worked. But I didn't know anyone who could explain me what was wrong. Heh, it's funny when I think back to it.

Good programmers aren't easily ruined

[syousef]

A good programmer has experienced many languages and done things in many ways. A good programmer has compared all these various experiences and understands the advantages and disadvantages of each language and programming technique. A good programmer doesn't get bogged down in line numbers and GOTO statements and never move beyond that. If someone does get bogged down they never had the attitude to be a good programmer.

Re:Good programmers aren't easily ruined

[Unending]

I agree completely my first language was QBASIC and I didn't bring any of that with me, but I could still go back and do it just fine.
That said if I were to teach someone how to program now I would probably use javascript.

Re:Good programmers aren't easily ruined

[phantomfive]

http://slashdot.org/journal/239880/Slashdot-moderation-is-awful

Heh......this is what happens when you rush super-fast to comment without reading the article, post something unrelated, and end up getting modded down. You end up thinking slashdot moderation is awful. :)

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Can't agree more. It's the person that matters and not what language they started out with. A good programmer will notice the limitations of a language and quickly switch to better programming methods when they are made available in a new language.

I started out with BASIC (gwbasic) on PC-XT (the ones before 286) around 1991. Now, I'm a full time kernel programmer working on embedded systems.

Re:Good programmers aren't easily ruined

[Interoperable]

I learned in Fortran (I should qualify this by pointing out that I'm not a particularly good programmer) but it seems to me that writing logical code that uses GOTO statements would be a good introduction to computer logic. A complex program may become unreadable, but as a learning tool I could see that it might have merit. Good coding is about understanding logical procedure (and comments).

Re:Good programmers aren't easily ruined

[jpmorgan]

Indeed. Dijkstra was frequently wrong, especially when he made grand sweeping statements.

GOTO is a good example, 'GOTO considered harmful' is practically biblical law amongst many programmers, but it's worth remembering that he made that statement in the context of an argument with Donald Knuth. Knuth won: (http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf)

Re:Good programmers aren't easily ruined

[Dahamma]

Absolutely. It was drummed into me (and apparently most coworkers), and I can't believe how liberating it is once you realize, yes, in appropriate contexts "goto" can result in code (especially in error handling cases) that is both more readable and more efficient. Dogma is rarely the answer.

Re:Good programmers aren't easily ruined

[syousef]

Heh......this is what happens when you rush super-fast to comment without reading the article, post something unrelated, and end up getting modded down. You end up thinking slashdot moderation is awful. :)

Heh? Stop pontificating for 5 minutes would you? I haven't been modded down and my comment relates to the summary and is not meant to say anything negative about the article. Are you even aware of the irony of you rushing to criticize me without provocation? Pipe down.

Re:Good programmers aren't easily ruined

[syousef]

The irony is that under the covers, it's all done with jump instructions anyway.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Yes. I started with basic (a lot of basic), then went on to Pascal, then C, Cobol, modula2, apl, 4 different versions of assembly language, and I've been staring at a lot of PHP and python (and perl) lately. Oh, and some java and pl/sql. I've written more code than I care to admit. The first year I learned basic, I wrote more than 200 (most quite small, but still...). I don't exactly consider bash scripts to be programs, although it is Turing complete. I still prefer procedural languages to objected oriented ones, but I don't consider my basic time to be a waste of time. Basic concepts are learned and repeated (ignore the pun). Its more likely that there are a lot of programmers around because of Basic. Some of the Basic (ok, groan over the pun) principles followed me through CS in university. Its true that I didn't see as much of them in Lisp or prologue (Artificial Intelligence), or cryptography (more math than anything else), but at least some of it was there.

Re:Good programmers aren't easily ruined

[phantomfive]

No, I think it's funny.

Re:Good programmers aren't easily ruined

[smash]

I'd argue that goto IS harmful - however like all harmful things, there are use-cases where it is either necessary or useful to accomplish a particular objective.

Much like a chain saw not being an all purpose cutting tool....

So... avoid using it when not strictly necessary, but if it is the only sane/high performance way of getting things done in a special use case, by all means...

Re:Good programmers aren't easily ruined

[erroneus]

I too started out with a range of BASIC varieties. I coded on Commodore PET and 64, AppleII and Color Computer and all sorts of thing like those. I then moved on to Assembly language for Motorola processors. Those two language experiences have the lacking of something in common -- functions; creating them, linking to libraries and all that. This meant I learned to do it ALL myself, whatever it was, and my code wasn't all that portable except for copy, rename and modify to suit. Everything was GOTO, GOSUB, JMP and JSR.

I also worked/played with Basic09, which was BASIC for Microware's OS-9. It was a bit more modern where it presented me with data types, functions and no line numbers. From there I grew into C.

As far as beginning programming is concerned, I think there is value in learning to make the machine do things very explicitly at first. Old style BASIC and even Assembler provide that experience. People tend to have a black-box mentality with everything they do and care little about what is actually going on within the black box. Having worked with languages without libraries and needed to do everything myself gave me some appreciation and insight into the black boxes we use in other languages. I tend to think these are pretty important insights especially when the black boxes don't do exactly what we need them to do.

And one other thing -- memory management. That simply isn't a topic on anyone's mind in programming these days. It was when I started. Request memory, release memory. Many of the machines I started on were limited to 64K! It was a primary concern. These days, people waste memory as if it were unlimited. Memory leaks are signs of either bad/sloppy coding or bad/sloppy black boxes. Either way, the further people distance themselves from how the machine actually works, the worse programming becomes in some respects.

This leads me to object oriented coding. Jeez what a mess that is. I grew up procedural and it is hard for me to think any other way. But then again, that's how computers actually work in the first place. Object oriented programming merely distances people from the machines and prevents newbies from appreciating how the machines really work. And the idea of mixing "data" and "executable code"??? Really? Damn. Sounds like injectable code execution exploits to me. When I started, we knew to keep those two things separate from the very beginning. Object orientation mixes them up and probably does more to lead to exploitable code than anything else.

I guess as I grew up coding, being aware of boundaries and limits, input validation and all manner of things like that (which were a lot more necessary in old BASIC and Assembler due to their lacking of advanced data typing) became first nature in programming. These days, people pay little if any attention to these details. And so every time I rant about sloppy or bad programming habits leading to very exploitable code, I am coming from a history of growing up under the notion of being aware of where and how memory is being used, testing and limiting the input and output, ensuring that infinite loops don't happen and all manner of things like this. Then people respond with "...you just don't understand! no one has time or energy to waste on that stuff!"

For me, it's unimaginable to write code without checking itself at every turn... this was probably the most important thing I took away from my earliest programming experiences.

Re:Good programmers aren't easily ruined

[simoncpu was here]

You can read a more informative article on Slashdot moderation here.

Re:Good programmers aren't easily ruined

[hopejr]

A good programmer has experienced many languages and done things in many ways. A good programmer has compared all these various experiences and understands the advantages and disadvantages of each language and programming technique. A good programmer doesn't get bogged down in line numbers and GOTO statements and never move beyond that. If someone does get bogged down they never had the attitude to be a good programmer.

I agree. I was one of those who started with BASIC, but am a good programmer (not meaning to boast - it's what I've been told by colleagues and bosses). BASIC is a good starting point to learn how procedural programming works, and can build from that to other paradigms and languages. It's people who only feel comfortable with that stuff that don't move on from their GOTO statements. I think this guy, Dijkstra, is like Freud by studying 60 german house-wives who have no life, and thinking the whole world is the same.

Re:Good programmers aren't easily ruined

[pedestrian crossing]

I also started in Fortran and by the time I got through my second semester, I had an epiphany - highly structured code is very important if you are going to maintainably do anything of significant complexity. I don't think the language matters so much, once you get to a certain point you realize that you have to modularize your code if you are going to create anything beyond a simple classroom assignment. Languages like BASIC and PERL are great introductions for beginners because they are interpreted and present a low barrier to entry. The focus can be on basic programming concepts and they provide instant gratification. That said, if one is to go further and "become a programmer", you have to understand the need for structure, typing, scope etc. and take things to the next level. If you have the aptitude to be a good programmer, this will become clear to you as you take on more complex tasks. If you don't have the aptitude, well, you are going to be a shitty programmer no matter what language you started with. GOTO in a high-level language is bad in that it is a crutch that is tempting for the beginner to reach for, and overuse makes code difficult to maintain. Making a rule of avoiding it forces you to think through your flow/structure/logic.

Re:Good programmers aren't easily ruined

[zappepcs]

I agree. My first program was on a TI-99 in basic. I had to learn how the syntax was required to be, and what functions were available. As I moved on, I learned the same things for the next language, and rinse/repeat as necessary. None of these experiences have formed my thought into "this is the only way it can be done" thinking. We might as well say that people who have learned to use MS Windows are ruined forever. Stupid is as stupid does.... meh

Re:Good programmers aren't easily ruined

[AVee]

If, and only if, you're programming in a language which doesn't provide any constructs to do error handling. Dijkstra was right, goto's are a bad idea and should not exist in a language. Knuth was right, in the absence of something replacing goto you're better of using it then not using (if done properly).

All of that discussion is passed us now, most of us have been writing software without using goto for the last two decades, goto has been replaced with try/catch constructs, labeled breaks, switch statements etc. None of the examples Knuth provides in that paper are still relevant in any modern language. By that measure, Dijkstra won.

It's not surprising either, Dijkstra was always in utopia, talking about how things would be if he build the world himself (which doesn't mean he's wrong). Knuth has always been about how to deal with the current reality (including the state of programming languages), and not so much about changing that reality.

Re:Good programmers aren't easily ruined

[rsidd]

Thanks for the link. However, I'm not sure you read beyond the title. On page 2, Knuth foresees two types of reactions based on reading the title alone, and yours sounds the first type. In fact Knuth does not disagree with Dijkstra, and he quotes Dijkstra to show that Dijkstra was not dogmatic about GOTO either. Knuth's purpose is to explore where GOTO has a place and where it is better to eliminate it.

Re:Good programmers aren't easily ruined

[geminidomino]

I agree. My first program was on a TI-99 in basic.

Wow, another one? I was lucky. My old man splurged for the "Extended Basic" cartridge and all the toys (A "P-box" with one 5.25" floppy drive larger than most desktop machines today, speech synth, magnetic tape reader).

Even 25 years later I can still recognize the two-tone boot up sound of powering that thing on... /nostalgia

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Well it IS done with jump instructions, but as few as possible because the branch penalty is usually high (especially on an x86). If you don't use the goto statement then your program is more abstract, and structures like loops can be more easily optimised by the compiler to use as few branches as possible. Not to mention things architecture-specific like ARM's condition codes which can turn a loop with multiple if-else statements into a block of code with only one branch instruction.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

I disagree. GOTOs are great at the assembly level and in things like state machine switch cases.

But using exception for flow control instead of state testing method and thinking that "goto are great in error handling case" just shows that you're using a language that is forcing you to catch checked exception.

Bad, bad, bad practice.

Terribly bad.

And, yup, I probably was using the equivalent of a JMP in a 2GL before you knew what a 2GL was (you've probably only ever written programs in a 3GL). Blessed be your co-workers and shame on those who are using "exceptions for flow control" and no re-thinking the very brokenness of most exception in the very first place.

Re:Good programmers aren't easily ruined

[lw7av]

I miss GOTO. I used it (abused it) quite a lot when I was 11.

Re:Good programmers aren't easily ruined

[Darinbob]

The problem is that people translated "considered harmful" into "thou shalt not use!"

As for BASIC, I know good programmers who overcame it. A lot started with BASIC because it was the standard language you got on micros by default, so the particular generation who became interested in computers because you could get one at home (if you had money or your parents could be whined into one) most likely used BASIC first.

But as a teaching assistant for intro to programming for a couple of years, some students just did not overcome bad habits. Some were argumentative, claiming that Pascal was stupid because you had to do all the useless stuff like declaring variables that gets in the way of getting stuff done. In fact, the more a person had used BASIC in the past the more they tended to be a "I already know how to program type" who were resistant to doing things differently...

Re:Good programmers aren't easily ruined

[AresTheImpaler]

That said if I were to teach someone how to program now I would probably use javascript.

oh wow, I have so many questions for you. These are my first 3, if you could please answer them:
1. Why the hell.. err sorry.. why would anyone in Hell want to learn programming?
2. Is it really that bad over there?
3. Can I call you Lucy?

Re:Good programmers aren't easily ruined

[bluescreenbert]

And the idea of mixing "data" and "executable code"??? Really? Damn. Sounds like injectable code execution exploits to me. When I started, we knew to keep those two things separate from the very beginning. Object orientation mixes them up and probably does more to lead to exploitable code than anything else.

Your post pretty much proves Dijkstra's point. You did not manage to lay off your old thinking habits. You do not bother to think how an object oriented compiler works and to me it sounds that you are stuck in 80's style programming. For your information, object orientation does not mix up data and code. It merely gives the programmer a paradigm to access data. Code is related to classes, data is related to objects.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Totally agreed. I started out with BASIC and now I'm in SALES for Gods' sake...

Re:Good programmers aren't easily ruined

[xaxa]

I used a GOTO last week. It was a one-off script, but anyway:

You are receiving a stream of records:
AKE 3908
KCO 2058
KCO 299
COR 9023 ...
The first field is an identifier, the second a value. The values need to be summed, to produce output like:
AKE 3908
KCO 2357
COR 9023 ...

I did this:

    receive(id, val)
    previousId = id
    previousVal = val
    while( receive(id, val) )
        if (id == previousId)
            previousVal += val
        else
X:
            output previousId, previousVal
            if (not last)
                previousId = id
                previousVal = val
            end if
        end if
    end while

Re:Good programmers aren't easily ruined

[RDW]

"Your post pretty much proves Dijkstra's point. You did not manage to lay off your old thinking habits. You do not bother to think how an object oriented compiler works and to me it sounds that you are stuck in 80's style programming."

'Object-oriented programming is an exceptionally bad idea which could only have originated in California.' - Dijkstra

Re:Good programmers aren't easily ruined

[xaxa]

Damn, I hit submit by mistake.

        if (not last)
            last = true
            goto X
        end if

(And I don't need the test for last above.)

I can see one way to write it without the goto -- you could just do output previousId, previousVal at the end (but I didn't do that, as I didn't want to duplicate the output code, or make an output function).

Any other suggestions?

Re:Good programmers aren't easily ruined

[Anonymous Coward]

When goto is not an option give me a break;

Re:Good programmers aren't easily ruined

[clemdoc]

1.) For my amusement
2.) Yep.
3.) No. And when you'll be my guest in a couple of months after your horrible acc^W oops, sorry, not supposed to tell, anyway, NO.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Knuth's proof that you *can* do structured programming with goto statements is not a proof that you *should* do structured programming with goto statements.

Knuth won

Citation required.

By and large, the use of goto is harmful. Error handling in plain C is the counterexample (see the Linux kernel for some excellent examples), but programming in plain C is considered harmful under almost all circumstances anyway. Kernel hackers know when and when not to use goto. For everyone else, the advice to avoid goto is still sound advice.

Remember, advice does not follow boolean logic. Advice can be not absolutely true while remaining useful. Realizing the advice was not 100% true is a part of "growing up" as a practitioner, but don't throw the baby out with the bath water. Dijkstra was right more often than anyone you are ever likely to talk to.

Re:Good programmers aren't easily ruined

[drewhk]

My jurney was
QBasic -> Pascal -> Delphi -> C -> C++ -> Java -> Scala (present)

with many small encounters:
Prolog, SML, Python, Ruby, Perl, Verilog, various assemblers, etc.

It does not matter where you start. What matters is to be able to learn, and to have an open mind.

Re:Good programmers aren't easily ruined

[wileypob]

First you complain about people not understanding how machines actually work, then you make it perfectly clear you've no idea how object oriented languages are implemented. In C++, code still goes in .text sections, and data is still on the heap (or possibly .data or .rodata), so the mixing of code and data is an abstraction.

"Object orientation mixes them up and probably does more to lead to exploitable code than anything else."
Wow, what BS.

BTW, I also grew up in the 80's on microcomputer ROM BASICs, and while I had unlearn bad habits when I went to real languages, I did learn a lot about how to solve problems.

Re:Good programmers aren't easily ruined

[g253]

Exactly. That's the one big fact that always made me skeptical of the idea that goto was bad.
Of course, the point is that there are better structures that are often more elegant or appropriate, but I think a goto can be useful, even in high-level programming. I've found Bram Cohen's blog entry on the matter to be quite interesting: http://bramcohen.livejournal.com/66555.html

Re:Good programmers aren't easily ruined

[r00t]

Much like a chain saw not being an all purpose cutting tool...

That depends. Short ones can't reach when you need it, but the lumberjack ones are good for everything. You can make ice sculptures, disarm thugs (or disleg them if you prefer), cut your wedding cake, trim your nose hair, or cut down a great big tree.

Re:Good programmers aren't easily ruined

[pe1rxq]

Actually object orientation does mix them up.... atleast most implementations and compilers do.
Things like methds and overloading are done by passing function pointers around as data.
I like object orienting, if all you know is classes and objects you are never going to grasp how your code enabled a certain bug or exploit.
It is the exposure to things like Basic, Assembly, Pascal and C that teach you how your object oriented piece of code actually ends up inside this magic thing called the CPU....

Re:Good programmers aren't easily ruined

[smallfries]

I learned in Fortran (I should qualify this by pointing out that I'm not a particularly good programmer)

Perhaps, but at least you don't eat quiche.

Re:Good programmers aren't easily ruined

[smallfries]

So far you've proven either that you suck at programming, or that you suck at cut and paste. But that is not a program that uses a goto. You could stick with your current proof, or if you try again you may remove all doubt.

Re:Good programmers aren't easily ruined

[AVee]

receive(id, val)
previousId = id
previousVal = val
beforeEOF = true
while (beforeEOF)
    beforeEOF = receive(id, val)
    if(not beforeEOF || id <> previousID)
        output previousId, previousVal
    else
        previousId = id
        previousVal = val
    end if
end while

Re:Good programmers aren't easily ruined

[Canazza]

The worth of what you learn first is down to how you connect to it, not whether or not it's a good language or not.
We were forced to learn 'TrueBASIC' in Standard Grade, it didn't have line numbers or GOTO statements but even at 15 I knew it was nominally useless for anything practical.
However, you did have control over the computers internal beep and much fun was had making our computer play songs. All of a sudden I could make a computer DO something. Something more than just print "Hello World" or run a Dice simulation. The Computing department tried to stop us, but it highlighted their own incompetence as they couldn't figure out how to turn off the internal beeper.

I also agree with the poster above about starting out with Javascript. It's easy to write, quick to change, has very visual results (which is better for teaching with) and has a reasonable OOP model. So long as you teach manipulating the DOM and stay away from inline document.write()s then it teaches OOP concepts incredibly well. I started with it, before moving server-side with PHP, which - being syntactically similar to it - prepared me for C++ (my first brush with strongly typed languages).

I still code alot of Javascript today, alongside moving to C#.net on the server side (I've not written a line of PHP in about 2 years, whether that's good or bad is a matter of opinion)

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Which points to the inherent value of BASIC as a starting language: It's conceptually closer to the way computers work than other high level languages. Line numbers and GOTO are the equivalents of memory addresses and JMP instructions. A good programmer eventually sees why unstructured code causes problems. If you've started with BASIC, you either appreciate and embrace the clarity of better languages or you were hopeless to begin with. Someone who only believes that GOTO is a troublemaker is more likely to think in an unstructured manner than someone who knows why (and therefore that) GOTO is problematic.

Re:Good programmers aren't easily ruined

[SharpFang]

*shrug*
I never found myself in need of use GOTO.

Sometimes I wished `break` could take argument of how many levels it should break out of, but usually abstracting the entry to a function and replacing break with return fixed that.

Sometimes I found myself writing:

do { ....
if(something) continue; ...
if(something_else) break; ...
} while(0);

but it was a rare crutch and it still kept scopes clear. No ability to jump into middle of a loop without initialization.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

This leads me to object oriented coding. Jeez what a mess that is. I grew up procedural and it is hard for me to think any other way.

Dijkstra was right after all. Or he was wrong and you were never going to be a good programmer anyway.

I too started with low level languages like BASIC and assembly. I too found that a valuable lesson. But I didn't just learn how everything is implemented at the machine level, I also learned how fragile and unmaintainable code in those languages is.

OO programming and memory management solved problems that I (and certainly many others) had previously identified and solved the hard way. Have you never written code like windowClose(window), windowResize(window,width,height), etc. (with window being a data structure describing the window) and put all the window* procedures into one file? That's a class right there. When you used heap memory, did you not at one point decide to wrap malloc and keep a list of all memory allocations so that you could reliably free them and avoid memory leaks on operating systems which did not clean up after programs like modern ones do? That's a rudimentary form of memory management.

High level programming doesn't free people from understanding the problems, but it does provide a more expressive way of writing down the solutions.

Re:Good programmers aren't easily ruined

[CptPicard]

Wow. I know that I have always had the impression that low-level guys really can't see the forest for the trees and seem to stress the nitty-gritty at the expense of having an idea of the big picture of what kind of "things" go into a programmed solution... but wow. :)

Re:Good programmers aren't easily ruined

[AlecC]

I went Fortran -> (Assembler)->Algol->Coral->(Assembler)->Pascal->(Assembler)->(Assembler)->C++->(Assembler)->Java->Python

Each Assembler is a different machine.

Coming from that trail, I really miss typing in Python, which I otherwise like. I would love an optional typing scheme: define an interface, and check that the variables passed locally conform to that interface.

Re:Good programmers aren't easily ruined

[swilver]

I don't think this even works properly in the case of 0 or 1 records.

In a language that does not have (labelled) break/continue statements you are doomed to use ugly booleans to control program flow, but there should never be a need to use a goto even in those languages. I sometimes wonder however what's worse... ugly booleans to control program flow... or a goto... I hate both.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

You're an idiot. OO does not mix code and data. It's an abstraction. It's not physical. Perhaps you should learn a little before you run off at the mouth.

Re:Good programmers aren't easily ruined

[mcgrew]

it seems to me that writing logical code that uses GOTO statements would be a good introduction to computer logic.

I'll agree with Dijkstra to a point -- BASIC makes it harder to learn modern high level languages like C or Java. BASIC is more like assembly than it is like C; there's little difference between JMP FF37 and GOTO 100.

Now, if they're talking about Visual Basic, I'll agree with Dijkstra, that language is an abomination and should never be foisted on anyone.

I do databases at work, and used to use dBase and Clipper for small datasets, NOMAD for big datasets that required the mainframe. I loved those languages; I could make the computer do almost anything, and write the code with minimal effort. Now I'm mostly using MS Access, and I absofuckinglutely HATE it. I don't even consider it "programming".

Re:Good programmers aren't easily ruined

[xaxa]

(With the last bit) it works with one record, but it won't work with zero records.

AVee posted the "ugly booleans" way. Personally, I think the labelled goto way is clearer -- the code for outputting the last record is (except for the label) outside the loop.

I don't really see that a labelled break/continue is much different from a labelled goto.

Re:Good programmers aren't easily ruined

[OeLeWaPpErKe]

I still love delphi. Talk about simply starting a program and getting it running, Delphi was heaven on earth. Yes, it can't do everything (though it has winapi support that's good enough to write even things like filesystem drivers or firewalls in Delphi), but it was such a pleasure to get a small application running quickly.

I still don't understand why academics have such hate for that language. And the language they mostly replace it with - java - is not better, it's a lot worse.

The object pascal compiler was a pleasure to use compared to today's clunky and slow-as-hell compilers. People underestimate the advantages of a hugely fast compiler.

Re:Good programmers aren't easily ruined

[tepples]

If, and only if, you're programming in a language which doesn't provide any constructs to do error handling.

In G++, if you throw once in your program, the linker brings in 64 KB of exception handling code from libsupc++ into your executable. That's not much on a PC, but it's a lot on a handheld or otherwise embedded device where everything has to be statically linked.

labeled breaks

Which version of C or even C++ has these, and what concrete advantage does it have over goto?

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Well done good sir.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

Though you wrote some great satire, the part about defensive programming is very valid.

Re:Good programmers aren't easily ruined

[Mashdar]

Well it IS done with jump instructions, but as few as possible because the branch penalty is usually high (especially on an x86). If you don't use the goto statement then your program is more abstract, and structures like loops can be more easily optimised by the compiler to use as few branches as possible. Not to mention things architecture-specific like ARM's condition codes which can turn a loop with multiple if-else statements into a block of code with only one branch instruction.

You are killing me. Anyone with any ISA experience knows that branch PREDICTION has a high cost associated with it in cases where the predictor does not match the situation. While, granted, IF X GOTO Y logic can damage optimization for a known prediction scheme, a simple GOTO has almost know cost associated with it (unless you have a cache miss or something, which you would have in any case, not just with GOTO). And loop unrolling is swell, but most good compilers are capable of unrolling loops regardless of how they are written. And most good compilers will actually convert your evaluations to match whatever branch prediction scheme is in place.

Re:Good programmers aren't easily ruined

[LWATCDR]

OOP is an extension of Structured programing which is what I hope you mean by procedural.
Or as Wirth wrote Data Structures + Algorithms = programs. What OOP does is combine data structures and algorithms into a single package and aid is proper abstraction.

And no most exploits come from People using OOP Languages in same manner they used CBM basic 2.0.

Of course the real reason that we have so many exploits is that most programs and languages date from a safer kinder time. You didn't expect people to try to send you misinformed data files. And frankly most OS,s where never designed to be on a planet wide network with hundreds of millions or billions of users and millions of a criminals trying to hack them.

Re:Good programmers aren't easily ruined

[azmodean 1]

This is so true, I think programmers need experience with a language that doesn't do hand-holding so they can learn for themselves why structured programming is so important. This is something I found very lacking with my CS degree (ymmv of course), we were told why rigorous design is necessary, but we were never exposed to systems sufficiently complex to show us the pain that could be created by undisciplined coding.

I never saw just how bad it could be until I got into the workforce and had to maintain terrible code. That experience quickly changed my opinion from, "Software Engineering* seems to be a really good idea... in theory", to being certain of it's necessity to the point of looking my boss in the eye and telling him that no, I can't deliver on his deadline because we have code reviews and regression tests to do, and they are not optional.

Re:Good programmers aren't easily ruined

[charleste]

I went:
BASIC -> Pascal -> C -> C++ -> FORTRAN77 -> Assembler -> {OMGPonies! ALL SORTS}

Now, I work routinely using both scripting languages (bash, Perl, JavaScript, PHP, Python, Jython, did some ColdFusion even, and others), and programming languages (C, C++, Java, et. Al.).

A Programmer can flip-flop between ANY language and may only need a reference manual (or Google) to get the correct syntax. If you can't, you are simply a Coder.

Re:Good programmers aren't easily ruined

[Frequency Domain]

The irony is that under the covers, it's all done with jump instructions anyway.

That's irrelevant. Programming languages exist for humans, not for the computer. The entire development of programming languages has been a drive to abstract away from how the hardware works and towards modes that facilitate expressiveness and power for humans. For example, there are no objects at the machine level, but humans often view the world as classes of similar objects that interact, which makes that a very expressive paradigm for modeling. (The first object-oriented language was Simula, and was created to facilitate simulation modeling way back in the 1960's.)

Re:Good programmers aren't easily ruined

[azmodean 1]

I don't really see that a labelled break/continue is much different from a labelled goto.

Particularly when you have programmers who, when they are told "no gotos", they just synthesize them out of other programming constructs so that they aren't "technically" gotos. Example:
void some_function( ) {
    do {
        some processing;
        if( test for fatal error )
            break;
        some more processing;
    } while( 0 );
return;
}

Isn't that lovely? No gotos, there, except that that it generates exactly the same code that a goto would have, and is either marginally more readable or very less readable, depending on whether the while(0) construct confuses you or not.

Re:Good programmers aren't easily ruined

[TrackBike2]

My programming class, the only one I ever took, was BASIC. I was a senior in HS in 1970. Programs were stored on paper tape. The school had a total of 16KB disk space. Since then, every single job has been computer-based. My first out-of-college job, I was lead programmer for the data acquisition system testing large centrifugal compressors. Six months into the job, my boss complimented me on my programming skill. When I told my boss about THE class, she said, "Shut Up. Tell no one, and continue doing a great job." Next job I did CAD, FEA -- wrote my own pre-processors, and QA (statistics). Later I used an early flavor of XML and an emacs editor to create over 12,000 page of compiler docs in one year. Other jobs were with CAD and FEA firms, where coding (or a deep understanding) were necessary to effectively use the product. To this day I hand code web pages. And all this started with a single class in BASIC.

Re:Good programmers aren't easily ruined

[hazah]

Things like methds and overloading are done by passing function pointers around as data.

In assembler, if I understand correctly, the only difference between code and data is the policy set by the OS on that page of memory...

Hell, even if what I just said is blatantly wrong, have you ever seen an apache module? C is not an OO language what so ever (doesn't prevent the techniques, it simply doesn't help at all), and yet function pointers are passed around like there's no tomorrow. I suspect that this quite common in the C world.

My specific point is this: Every single paradigm and language can be viewed as 'mixing them up' based on how you are presenting the concept (your reference to the implementation details of a compiler). That doesn't make your point invalid, it's just an illustration that it's not really necessary to emphasize that it happens under the hood. It muddied the water a bit even, since you're implying that there are languages/paradigms that do not do this at all.

Re:Good programmers aren't easily ruined

[hrimhari]

Ah, the memory lane. I went:

(MSX) BASIC -> Assembly -> Pascal -> SH(s) -> C -> C++ -> Java -> Javascript -> C# ...

Yes, good programmers can do any language, but we all have preferences, no? I grew fond of Assembly, shell scripting, C, Java and Javascript.

I could get things done in BASIC out of necessity, since I didn't know better. I would never choose BASIC for anything today.

I was not convinced by C# for two reasons:

1. I couldn't stand Visual Studio
2. I found it utterly annoying to frequently have to call Windows C APIs and translate ins and outs to the C# model to really get things done.

Re:Good programmers aren't easily ruined

[mypalmike]

The irony is that under the covers, it's all done with jump instructions anyway.

How do you think "if", "else", "switch", "for", and "while" are implemented? Jump instructions are used in each of these constructs. Exception handling is an additional construct that allows code to be written so that the flow of control within a function is inherent in the structure of the code rather than through explicit jumping.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

I would create a STL map, read in all the data adding val to the existing val associated with your ID, then output everything. Or read in everything sort it, then run your code. Your code, as it is now, will produce output with repeating IDs and vals if you receive the same ID again later on. In effect your output will look like this.

INPUT:
AKE 3908
KCO 2058
KCO 299
COR 9023
KCO 2000
KCO 100
COR 200

OUTPUT:
AKE 3908
KCO 2357
COR 9023
KCO 2100
COR 200

You're really going to make me add those myself?

Re:Good programmers aren't easily ruined

[martyros]

I read the original "Goto considered harmful" paper, and most of the reasons cited don't apply in many modern languages.

For example, one reason against using "goto" was that in BASIC, you jumped to a line number. This meant that any statement in the program was potentially a target for goto; writing code with the idea that someone somewhere might jump right into the middle was considered too much cognitive overhead.

In C, however, there are no line numbers; you jump to a label. That means (1) if there's no label, you can be sure no one is going to jump there and (2) if you see a label in the code, you can be pretty sure that there *is* a goto somewhere, and you should do a search to find out where.

I think the problem is that many people coming from languages like BASIC have goto as their main model of branching, which really needs to be un-learned. Use goto for that special exception where the normal branching mechanisms (if, while/for, switch, &c) don't fit the program logic cleanly.

Re:Good programmers aren't easily ruined

[jellomizer]

The GOTO command is an old language command and it is not Basic Only almost all older languages have a form of GOTO. While it is a more true representation on what the computer is doing under the covers. As well early computers displays were quite limited (80x25/40x25) makes it quite difficult to properly indent wasting 5-7 more spots of white space. As well most of the editors were line editors with line numbers... With the technology at the time GOTO offered much better code then Procedural programming could at the time. Now it doesn't make good computer and should be avoided, as with modern displays that can clearly display hundreds of characters per screen. Tabbing and using up white space isn't an issue with programs that allow you to scroll left and right, and page editors where you can move up and down and even add new lines in the middle much easier. I remember in GWBasic having to renumber some of my programs because I put in more code which I had numbered.
Ok
list 10 - 20
10 PRINT "HELLO"
20 PRINT "DONE"

Then having to go up and renumber and execute each line again.

A real pain

No you just go to the line and type what you need without numbering... It is a big advantage.

Re:Good programmers aren't easily ruined

[xaxa]

I would create a STL map, read in all the data adding val to the existing val associated with your ID, then output everything.

In this case there were a couple of gigabytes of records, so this wasn't an option (not enough RAM).

Your code, as it is now, will produce output with repeating IDs and vals if you receive the same ID again later on.

Usefully, I know there won't be any repeated IDs.

If this wasn't the case then I'd either need to store the stream (size M), or perhaps store the IDs and how many times each occurs, then fetch the stream again (size 0.5 M + the frequency data).

Re:Good programmers aren't easily ruined

[KlaymenDK]

Exactly. Good stuff CAN be done with GOTO statements.

The original Zork game basically has the player wandering from room to room. In the source code, believe it or not, each room has its own 6-digit label, and the game uses nothing but GOTO statements to move the player around.

And yet, it's a pretty decent game.

Re:Good programmers aren't easily ruined

[vtcodger]

***GOTO is a good example, 'GOTO considered harmful' is practically biblical law amongst many programmers,***

It's well to remember that at the time Dijkstra wrote "GOTO Considered Harmful", he was working very hard on automated proof of correctness. We've pretty much abandoned that for everyday code because we can't figure out how to do it. If you can rigorously describe function, you don't need to test function, you need a compiler for the rigorous description.

Anyway, I have long thought that Dijkstra's point was mostly that if you allow programmers to transfer control any place they feel like going any time they feel like going there, you've made proof of correctness orders of magnitude harder. And I think he was right about that. Indeed, modern GUIs tend to go anyplace they feel like going any time the user twitches and testing GUIs is next to impossible -- which IMO is a large part of why they often work badly.

Thanks for the link -- hadn't read that paper before. Clearly, it needs a lot of reading for any degree of understanding if you are as dumb as I am.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

These days, people waste memory as if it were unlimited. Memory leaks are signs of either bad/sloppy coding or bad/sloppy black boxes.

Memory leaks and wasteful memory use are two different issues.

I grew up procedural and it is hard for me to think any other way. But then again, that's how computers actually work in the first place

No, they don't. As you obviously know, computers work by executing machine instructions that specify registers, memory locations, etc. Procedural programming is an abstraction. For instance, you don't control register allocation when coding in C.

Object oriented programming merely distances people from the machines and prevents newbies from appreciating how the machines really work.

What's the difference between this:

typedef struct Sound {
    int samplingRate;
    int channels;
    void* buffer;
};

void Sound_Play( Sound* pSound );

and this:

class Sound {
private:
    int samplingRate;
    int channels;
    void* buffer;

public:
    void Play();
};

Answer: basically nothing - the generated code will be more or less identical. Adding inheritance with virtual methods creates function pointers that can vary by class. That's all.

And the idea of mixing "data" and "executable code"??? Really? Damn. Sounds like injectable code execution exploits to me.

OK, this is simply uninformed.

I certainly prefer coders who know what's happening at the CPU level. But these are things that can be understood in C++, Java, and other OO languages. Being at a higher level of abstraction does not mean you automatically don't consider using best practices in things like memory allocation. It does sometimes mean that you lose some control over certain things the CPU is doing. But that's true in C as well, as you lose control over register allocation, certain instruction optimizations, etc.

Re:Good programmers aren't easily ruined

[sjames]

In languages like C, goto is useful as a sort of 'exceptions lite' and can greatly improve readability and even the efficiency of the compiled code.

The problem with goto is that it can also be used by a less proficient programmer to create a tangled unmaintainable mess.

Re:Good programmers aren't easily ruined

[Opportunist]

No programmer starts out as a good one. They start out as people who know little if anything about programming. Considering how kids these days learn programming much earlier than probably we did, they will start learning programming before they even have the math background to play the "it's not the language, it's the algo" game.

The ability to abstract, as is necessary to be a "good" programmer, is also anything but innate. You may be better at it than someone else, but it's still a learned trait. Kids learn easier using concrete examples and usually have a hard time grasping abstract concepts. That's the reason why math through the ages made use of apples and prunes to teach basic algebra. It's just way easier to grasp. No pun intended.

And kids learn using rotes rather than using basic concepts and developing their own from basic knowledge. Hence that core difference between basic and languages like C hits twice as hard: Basic uses commands. C uses functions. Not only do they look similar but behave vastly differently (which hurts because of the rote nature of kids' learning, they figure "looks the same, works the same", which it just doesn't), the concept that EVERYTHING in C and most other imperative languages is a function, including the stuff you write and your subroutines, hell, the whole program code, is something that is not easily grasped by someone who learned that program execution starts at the first line.

Re:Good programmers aren't easily ruined

[sjames]

The chainsaw is certainly not an all purpose cutting tool. If you're trying to cut your steak it certainly is harmful. However, none of that suggests a global ban on chainsaws considering that when felling a tree, a steak knife is not useful.

Perhaps "indiscriminate use of goto considered harmful" would be more accurate.

Re:Good programmers aren't easily ruined

[Blakey Rat]

Goto is useful when you have an outer loop, an inner loop, and the inner loop needs to break out of *both* loops. Even Javascript contains a goto-like concept for that purpose (continue to a label).

Re:Good programmers aren't easily ruined

[zildgulf]

Exactly, I owed my skills in IBM and Intel assembler programming to learning BASIC first and then Pascal. BASIC taught me how to use programming languages with limited control structures and Pascal taught me good programming habits.

When I then learned Assembler, Fortran, C, and Java I could build from that foundation. I could program using GOTOs in the proper context and still have easily readable code. GOTOs are handy when you are in a conditions loop and you need to exit immediately in the middle of the code.

Re:Good programmers aren't easily ruined

[Dahamma]

Exactly. I work mostly on embedded devices these days, where it's either straight C or C++ with exceptions and RTTI disabled.

And the compiler is effectively turning all those fancy high level control flow constructs into gotos (jump, whatever) anyway. If programmers spent more time understanding what happened to their code when they compiled it and less worrying about nitpicky style issues, it would probably be bother more readable AND more efficient.

Not that I'm saying everyone should go make their code look like assembly language - just don't think that "the prettier the C++, the more efficient the program will be!" I guess I'm just amazed by how many new CS grads don't even understand basic memory management any more, let alone compilers...

Re:Good programmers aren't easily ruined

[hitmark]

so in the end it comes down to the skill of the craftsman, not the tools.

Re:Good programmers aren't easily ruined

[Capsaicin]

We were forced to learn 'TrueBASIC' in Standard Grade, it didn't have line numbers or GOTO statements

In which case it hardly qualifies as 'BASIC' for the purposes of Dijkstra's admonition, does it?

Re:Good programmers aren't easily ruined

[hitmark]

i wonder if the same could be done with a case.

Re:Good programmers aren't easily ruined

[w0mprat]

OO has proven to be just as secure as the programmers ability to make it secure, just like any other language.

If I went back in time to the 80s and told my young BASIC-coding self what was possible with a few lines of PHP it would have seemed like science fiction.

I call this progress.

Re:Good programmers aren't easily ruined

[Anonymous Coward]

The irony is that under the covers, it's all done with jump instructions anyway.

How do you think "if", "else", "switch", "for", and "while" are implemented? Jump instructions are used in each of these constructs.

I believe that's what the man was saying.

Re:Good programmers aren't easily ruined

[Dahamma]

goto's are a bad idea and should not exist in a language

The most basic "language" for almost all CPUs (assembly, or the machine code it generates) uses a basic branching construct that in the end is pretty much a goto of one form or another. So good luck with that...

Re:Good programmers aren't easily ruined

[twosat]

Don't you know that the problem with GOTO was solved years ago with COMEFROM http://en.wikipedia.org/wiki/COMEFROM ;-)

Re:Good programmers aren't easily ruined

[Anonymous Coward]

If you want to know if BASIC is a good language to start with, dig up a copy of the game DONKEY, lovingly written by William Gates, III. Personally, I've never had any love for BASIC, of the console or visual variety, but I've got no problem with a programmer who used BASIC as a first language so long as they don't try to write every language as BASIC. Poor programmers have a tendency to write every language as their first language, even when the language proscribes otherwise. The issue with GOTO, in my opinion, at least in object-oriented languages, is that it violates encapsulation and creates a very...wrong program flow if used improperly, but, as previously mentioned, limited GOTO use can be valid (I've even seen goto used in the code for Firefox...I removed it before I compiled though; it didn't seem necessary and altering the closing braces only slightly, I was able to bring about the same program flow without goto, so I'd consider that particular goto use extraneous.) and an experienced programmer need not fear raptor attack with properly thought out and effective goto use, so I would in part disagree with Dijkstra, although considering that the majority of programmers are average, rather than good or even great, a greedy algorithm would suggest that choosing the programmer who avoided BASIC would more likely result in good code in a language other than BASIC, all else being equal.

Re:Good programmers aren't easily ruined

[KlaymenDK]

You'd need to put it in a loop, but sure ... if you really want to. :p

Re:Good programmers aren't easily ruined

[gjuro]

now I suspect my wife's first language was basic. she frequently uses goto...

Re:Good programmers aren't easily ruined

[Steve Max]

In this case, goto is conceptually simpler and closer to the actual program workflow: the program goes to the same "places" as the player. You could make it with other constructs, but why?

Re:Good programmers aren't easily ruined

[metamatic]

Code is related to classes, data is related to objects.

That's one model of OO. There are others. JavaScript is OO, and it doesn't even have classes, to pick one prominent example.

Fuck him.

[OrangeCatholic]

I was on Basic from 1986 to 1993, and it was the most meaningful years of my life.

Re:Fuck him.

[Anonymous Coward]

And those years are the origins of my most profitable refactoring work, turning 20+ year old BASIC sludge into proper solutions.

Re:Fuck him.

[dillee1]

No. Thank you.

Re:Fuck him.

[Hurricane78]

Well I was on BASIC too. GWBASIC to be exact! On a Commodore PC 10 (i8088!)
But Pascal was my antidote.
Then I learned Java. And...oh horrors... PHP. The BASIC of these days.
And Haskell is my definite final antidote right now.

Re:Fuck him.

[Anonymous Coward]

I was on Basic from 1986 to 1993, and it was the most meaningful years of my life.

Yeah, me too. BBC Basic (or should that be BASIC as in Beginners All Symbol(ic) Instruction Code) from 1985 to 1990. Most creative I've ever been as a coder.

Re:Fuck him.

[Anonymous Coward]

Exactly. Bull shit. Those of us who learned to program Apple/Commodore basic are writing the good code now, while this generation that learned on Java/PHP/Perl/whatever are frankly rubbish. I do C and ASM for a living - and spent years of my life on Apple BASIC. Fuck off webdeveloper .net slashdot scum.

Time heals

[Quiet_Desperation]

Depends on the BASIC. I use RealBasic at work as an alternative to LabView. It's object oriented, multithreaded and completely "Visual".

as potential programmers they are mentally mutilated beyond hope of regeneration

Am I the only person on the Earth who just writes off hysterical, panty-wetting stuff like this? When did he say this? in the 1960s or something? It's 2010 now, right?

Re:Time heals

[techno-vampire]

Remember, this is Wirth we're talking about. He's the guy who made a fetish out of top-down programming while designing a language that's intended to be written and compiled bottom up! The guy's never been anything but a quiche-eating hypocrite in my book.

Re:Time heals

[julesh]

Depends on the BASIC. I use RealBasic at work as an alternative to LabView.

RTFA. The author is quite clearly talking about non-block structured BASICs of the MS-BASIC kind.

Am I the only person on the Earth who just writes off hysterical, panty-wetting stuff like this?

Again, read for context. Dijkstra was being intentionally hyperbolic in a joke article when he wrote this. He did intend the point behind it, though.

Re:Time heals

[multi io]

It's Dijkstra we're talking about. And Dijkstra does have quite a few genuinely useful and lasting achievements speaking for him (semaphores and such), while Wirth was indeed, more or less, a quiche-eater.

Re:Time heals

[AVee]

Depends on the BASIC. I use RealBasic at work as an alternative to LabView. It's object oriented, multithreaded and completely "Visual".

as potential programmers they are mentally mutilated beyond hope of regeneration

Am I the only person on the Earth who just writes off hysterical, panty-wetting stuff like this? When did he say this? in the 1960s or something? It's 2010 now, right?

Well, not the 60s, but 1975. Still about 20 years before RealBasic was developed. So don't be offended, he wasn't talking about your beloved RealBasic.

Re:Time heals

[jandersen]

Depends on the BASIC. I use RealBasic at work as an alternative to LabView. It's object oriented, multithreaded and completely "Visual".

Not really; BASIC, as Dijkstra talks about, is not the modern development tool that is barely BASIC any longer. As a programming language regarded, modern 'BASIC' is not really much different from C++ or what can loosely be called "Object Pascal" - it only resembles BASIC because it has kept many of the same keywords.

No, BASIC was and still is, as far as I am concerned, the line-by-line interpreted language that was meant to be a simplified FORTRAN, and as most of the languages from that time, it has a number of features that codify some of the things you can do in assembler (but really shouldn't) - I still shudder at the thought of PERFORM SECT1 THROUGH SECT5 VARYING ... - a sort of combination of a FOR loop and a GOSUB the allows overlapping subroutines with no explicit returns.

BASIC allows practices that bad because they can make programs unmaintainable; and the limitations in the language mean that you are more or less forced to code that way. This is of course not because those that designed the language were idiots - it was never meant to be used for serious programming: Beginner's All-purpose Symbolic Instruction Code - the name says it all; this was only an introduction to things like FORTRAN (for numerical computing) or COBOL (for i/o manipulation).

Am I the only person on the Earth who just writes off hysterical, panty-wetting stuff like this?

Probably not, but it seems to me that you are the one hysterically wetting your pants. A person with a sense of humour would see that this kind of radical statement was meant as a provocative input into a sometimes heated discussion. If one were to interpret your words in a positive spirit, one could say the same; that you are probably just emphasizing a viewpoint by exaggerating.

Re:Time heals

[walterbyrd]

BASIC allows practices that bad because they can make programs unmaintainable; and the limitations in the language mean that you are more or less forced to code that way.

I'm sorry, but that has not been true for decades now. In fact, for many versions of BASIC, the opposite is true. By the 1980s (or earlier) versions of BASIC such as TurboBASIC, and MS-Professional BASIC, all but did away with the line number model. Even the free QBASIC does not use line numbers by default. I suppose it is still possible to use line numbers, but you would have to go out of your way to do so.

Also, practically all computer languages allow bad practises. The worst spaghetti code I have ever seen was written in Pascal.

Re:Time heals

[Quiet_Desperation]

Probably not, but it seems to me that you are the one hysterically wetting your pants.

If you say so. I posted a quip. *You* posted a rant. We'll let the historians decide.

Re:Time heals

[Quiet_Desperation]

So don't be offended, he wasn't talking about your beloved RealBasic.

Oh, cheer up. It's almost Christmas!

Re:Time heals

[Dun Malg]

Dijkstra does have quite a few genuinely useful and lasting achievements speaking for him

The important thing to remember about Dijkstra is to look at what he did more than what he said. He made a lot of really asinine sweeping generalizations that, for some reason, people have taken as some sort of universal truth. I transitioned from BASIC to 6502 assembly to C to C++ to (everything else) without any serious injury. The notion that BASIC "ruins you" is the griping of a cranky old professor complaining about students who keep asking him where "GOTO" is in whatever language he's trying to teach.

Re:Time heals

[Dun Malg]

For purposes of this submission and the comment from Dijkstra, we are talking only about the line-numbered "classic" BASIC. The non-numbered variations were developed as a direct response to the very criticisms leveled by Dijkstra et al.

Re:Time heals

[jandersen]

Being European, I clearly don't know what "quip" and "rant" are; my impression was that a rant was when you keep going on and on about something, just to let off steam, which I didn't.

However, on a side note: I see your reply was rated "Troll" which I think is nonsense; to me it looks like a very valid response.

Re:Time heals

[chthon]

I read this document from him several times, and I always had the impression that it was really tongue in cheek.

A well deserved 'Whoooooshh' for all of you who took it that serious.

Re:Time heals

[Quiet_Desperation]

Meh... the mods are generally high on crack or meth or drain cleaner or something. I get Troll mods on innocent things quite often. I also get humor posts rated "Insightful", so their delusions swing both ways. ;-)

Simplicity

[azgard]

There's something to it. I recently downloaded a ZX Spectrum+ manual from worldofspectrum.org (the colorful one), and was amazed by how simple the language is. The complete reference takes like 10 pages? And it can draw lines and circles..

Now compare it with any modern language, such as Java or Python. The language description itself takes 10x more than that, and the libraries available are vast. I am not arguing it's a bad thing; I am just arguing that simplicity may be a key here.

Re:Simplicity

[MichaelSmith]

I started out on a little basic-in-rom interpreter and it was okay for a while. If I needed performance I had to write 6502 machine code. Eventually my dad built up a CP/M system and I got my hands on pascal.

But I knew people of my fathers generation who grew up on fortran and still wrote fortran in newer languages (pascal, c, etc). IMHO fortran was more harmful because it went further than basic and the coding style it imprinted on people went deeper.

Re:Simplicity

[JumpDrive]

Ahh, that quote was a spaceship flying about 300 km over your head.

Re:Simplicity

[wye43]

I agree, simplicity has prevalence over principles of programming like avoiding gotos or design patterns.

The first step is the hardest - don't strangle newbies with good, but complicated concepts.

I had BASIC as my first programming language 20 years ago and I don't see myself as "mentally mutilated beyond hope of regeneration".

Re:Simplicity

[JumpDrive]

Sorry to be so abrupt, but I think what he was saying is that a lot of people learn Visual Basic and never learn what they are doing. They get hung up on results and creating them as fast as they can and it becomes a habit they can't break.

One case in point the number of programs with security flaws.

Another being the overhead of simple programs or the lack of concern of programmers for needless overhead.

Yes, there have been a number of people who have become good programmers after using Visual Basic, but there are also a lot of really crappy programmers who started with Visual Basic.

Re:Simplicity

[AVee]

If you had Basic as your first language 'only' 20 years ago, you probably didn't use the kind of Basic Dijkstra was talking about. His remark about Basic is 35 years old, stuff changed in the 15 years between that.
The basic you used probably wasn't line number based, had constructs like case statements and proper functions with locally scoped variables. Those thing were added, amongst others, because people like Dijkstra insisted they where required.

Re:Simplicity

[wye43]

If you had Basic as your first language 'only' 20 years ago, you probably didn't use the kind of Basic Dijkstra was talking about. His remark about Basic is 35 years old, stuff changed in the 15 years between that. The basic you used probably wasn't line number based, had constructs like case statements and proper functions with locally scoped variables. Those thing were added, amongst others, because people like Dijkstra insisted they where required.

You assumed wrong. It was on Spectrum, it was line number based, there was no case statements, no local variables.

But besides the obvious dick s... age contest(which sounds wrong anyway :P), what exactly is your point?

Re:Simplicity

[wye43]

Your wrong assumption apparently deserved a mod up - my faith in humanity has collapsed. Oh wait, it was never there in the first place.

Now go on and mod me down, it makes perfect sense that anonymous people on the internet people know better about my past than myself.

Re:Simplicity

[AVee]

Did you spot the word 'probably' in there? Read it again, it's really in there. And nobody modded me up, thats just karma. If I was posting just to offend you I wouldn't waste so many words.

Re:Simplicity

[Anonymous Coward]

If you want simple in Python:

import turtle
turtle.speed("fastest")

turtle.up()
turtle.goto(-150,80)
turtle.down()
turtle.width(5)
turtle.forward(55)

Re:Simplicity

[Anonymous Coward]

Weasel words at their best. And you are proud of it!

That explains it!

[voodoo cheesecake]

Damn, all this time I was blaming it on Bacardi 151 mixed with Jolt!

Meh

[s1lverl0rd]

I started out with QBasic. It was absolutely horrific - the language itself and the code I wrote as well. QB convinced me to never, ever try VB.

So yes, starting out with BASIC helped me tremendously :)

Re:Meh

[serviscope_minor]

I don't remember tha language being bad.

It was free from line numbers and allowed proper structured programming.

Re:Meh

[TheDarkMaster]

A bad programmer can make bad programs independent of language.

Second story from this blog this week...

[julesh]

...and I'm wondering: what's with the random sushi pictures?

Re:Second story from this blog this week...

[gibbled]

Clearly there's something fishy going on there...

Re:Second story from this blog this week...

[ipquickly]

no offense to sushi connoisseurs
but preceding the activation of image block
a feeling of illness ensued

Re:Second story from this blog this week...

[geminidomino]

Haiku overflow.

System halted.

Re:Second story from this blog this week...

[geminidomino]

Or, more on-topic:

Haiku Overflow
It was programmed in BASIC
System halting now

That might be right...

[Robert Zenz]

...but does totally depend on the programmer himself. BASIC (including VB6, VB.NET) gives you many bad habits and wrong estimations about how programming is (Case-Sensitivity, Implicit Type-Casting...). It's an easy to learn language, but you _have_ to look beyond your own nose if you wanna start with a C-like language afterwards.

Funny argument

[phantomfive]

His argument is kind of funny. He says people who've learned in BASIC have learned what NOT to do when programming. I have to admit he has a point....I learned exactly why spaghetti code was a bad idea after doing it for a couple years. Some people think they know what spaghetti code is, but unless they've written code with line numbers, they probably don't.

Re:Funny argument

[0123456]

Some people think they know what spaghetti code is, but unless they've written code with line numbers, they probably don't.

And the good old days of 'LET A = NOT PI' to save three bytes of RAM :).

(ex-Sinclair BASIC programmers will understand why such arcane constructs were beneficial when you were low on RAM)

Re:Funny argument

[jpmorgan]

I agree. I started on QBASIC, so I didn't have to cope with line numbers... but the code was still spaghetti. I remember the joy I felt upon discovering subroutines.

It's like a child burning themselves for the first time. Sometimes it's the best way to learn.

Re:Funny argument

[azgard]

It should be also said, though, that for people who programmed on 8-bit computers (I had ZX Spectrum), there was hardly any other way than to have spaghetti code at the time. OOP was non-existent and Lisp too complex. At the time, global variables, fixed-length arrays and GOTOs were the way how to actually program effectively (both in BASIC and assembler).

Re:Funny argument

[phantomfive]

That is totally true, I remember the first time I saw structured programming, it was something simple, just an easy way to print a list of items on the screen, and it was literally a feeling of the joy of discovery. I got addicted and started thinking up my own ways to structure code.

Compare that to the guy I met when I was tutoring CS, who said, "functions, why do I have to use functions to write this program? I know how to use functions, it's such a waste of time." The idiot could have finished the program in the time he spent complaining about it, but he certainly did not feel the joy of discovery.

Re:Funny argument

[phantomfive]

Yeah, there were no 'else' constructs. If you wanted an else, you had to do it yourself with a couple GOTOs. Also, the worst part about line numbers was when you decided to add something later, and there weren't enough lines. A program that had been refactored this way a few times could literally move randomly through the source code.

Re:Funny argument

[geminidomino]

I have to wonder if my starting on TI-BASIC is what led me to be a subroutine fetishist.

If I see the same two lines of code repeated, I wrap it in a subroutines. I have way too many 2-3 line subs...

I is bad programmer. :(

Re:Funny argument

[pinkstuff]

I completely agree. As with most things, learning how NOT to do things is often as important as learning how to do things.

Re:Funny argument

[JayAEU]

Yeah, and hardly any of the BASIC interpreters at the time had a RENUM command to assist in the refactoring... Even my trusty Sharp 1403H had RENUM and I'd have been lost without it after the 2nd refactoring iteration. ;)

Re:Funny argument

[Alioth]

But even code with line numbers could be nice - consider BBC BASIC. It has all the constructs you need to write nice code (named procedures etc), but still has line numbers. The main problem with the older BASICs were that all variables were global, there was no scoping at all.

Re:Funny argument

[chelberg]

I started programming in HP Basic around 1974. Line numbers, gosub, the whole bit. I taught myself how to program from the tutorial programs included with the language. TUT01, ....

As I learned how to program I learned what not to do if you want to maintain your code. I learned how to program in blocks, subroutines, etc. virtually while still using BASIC as the tool. If you didn't learn how to be systematic in your coding, you would never be able to build large programs in BASIC. By large programs I mean 1000's to 10's of thousands of lines of code. (I wrote two large programs during this time in BASIC, a chess program and a FORTRAN emulator to do arbitrary precision arithmetic, which I wrote to be able to solve diff eq's to do solar system modeling among other things).

If I had written spaghetti code I never would've been able to debug these monsters. If you are a good programmer you build your own style and mechanisms to manage the complexity. When I went to college, I learned PASCAL, and then I ported my chess program to it in just a few weeks. I loved the structure, but also felt it straightjacketed me with some of its limitations.

Now, my favorite language is LISP, but I program more in C++ as it is the language most of the students I work with know. Over the years I've programmed in more languages than I can recall.

In looking at all the languages, each has its uses. Knowing many languages lets you think in more metaphors, and styles, so you can choose the best one for the problem you encounter. You can program horribly in any language, and you can code elegantly in any language. Learning how to think about how to solve problems logically, efficiently, and elegantly is the key to being a good programmer, not the particular language you are currently using.

Re:Funny argument

[c 0xFF]

The irony is that QBasic is structured, but nobody seemed to know how to use it. I had that problem -- I was so used to GOTO that the concept of functions seemed strange.

I got over that problem as soon as I learned C.

Re:Funny argument

[c 0xFF]

Alternative theory: Programmers who've learned in BASIC must learn how to work around its limitations.

The ability to surpass the language itself makes for great programmers. Case in point: assembly language, especially simple ones like PIC. Learning how to create if/then/else, while, for, switch, and other constructs from the very limiting "test and skip next if zero" instruction is very educational.

Spaghetti code is not inevitable when limited to GOTO. An organized mind will find ways to create meaningful code.

Re:Funny argument

[mcgrew]

The tiny amounts of RAM were only part of it. The biggest hurdle was that the 1.4 mz chip ran everything on the board, making it possibly the world's slowest computer.

You could make a decent game if you were willing to hand-assemble machine code.

Re:Funny argument

[Fred Foobar]

Some people think they know what spaghetti code is, but unless they've written code with line numbers, they probably don't.

And the good old days of 'LET A = NOT PI' to save three bytes of RAM :).

(ex-Sinclair BASIC programmers will understand why such arcane constructs were beneficial when you were low on RAM)

For those who never used Sinclair BASIC, I'll tell you why this is so: the BASIC interpreter converted the BASIC code that you typed into the machine into a smaller bytecode. Most tokens would boil down to a single byte, and all (most?) numbers are converted to floating-point values. In this case, "NOT PI" takes (I'm guessing) 2 bytes, whereas the floating-point number "0" takes (I'm guessing again) 5 bytes. Both expressions are equal to 0, though the "NOT PI" form would take a bit longer to execute than a literal 0.

Note: I've never actually programmed for the Sinclair, but the BASIC interpreters for a lot of machines of the era worked like this. I used Commodore BASIC for years, so I know it's true of that interpreter. Then again, a lot of those old machines used Microsoft BASIC interpreters, so this should be expected.

Re:Funny argument

[Anonymous Coward]

Spaghetti code gets worse when you factor in overlays. My first professional job was using BASIC. Writing some new but mostly maintaining years old, many times patched code. Took forever to figure out where to make changes. Thank god it had a debugger.

as noted above

[Anonymous Coward]

I was #1, the top banana, programmer for assembly, C, pascal, fortran and many more even ada, extremely well paid on route 9. Learned programming with a sinclair zx-81. then went to college to be a computer engineer. Go Figure!
If you cant program in basic, you cannot be a programmer, or an engineer for that matter.

BASIC is great for kids

[VirtualUK]

I disagree with the premise that BASIC teaches bad habits. I stick with the old adage a bad workman blames his tools. BASIC teaches kids (like I was over 30 years ago) from the ages of 5-6 how to put together simple logic, and gives them the very basics of languages constructs like variables, loops, sub routines, etc. without them having to grasp structures, classes, polymorphism, OO, etc. that a lot of grown ups that have been involved with writing code for quite some time can have issues with.

Re:BASIC is great for kids

[phantomfive]

If you had read the article, you would know that you had just written a fairly decent summary of the author's main point.

Re:BASIC is great for kids

[Anonymous Coward]

I maintain that Python can do this much more easily due to the fact that there are simply fewer ridiculous syntax requirements in a simpler to read format. The things you learn in BASIC can be taught at a much more significant level in Python (inline AND block comments, order of instructions, basic control structures, variables and their use) without jumping through the hoops that you will in BASIC. Python's use of whitespace and extensibility allow beginners with an aptitude to expand on their knowledge easily by making simple inferences about how some control structures work (Python has an excellent for loop implementation) .

Python does not require classes, can be used as an imperative language, and can provide subroutines in the form of other functions easily simply be defining it in the environment (which is not a difficult concept to grasp, "the computer needs to be told that it can use it" will suffice for beginners which is true enough).

Basically, Python can provide all the same benefits as BASIC without the stupid unnecessary crap (Explicit Line numbers? Really? Are we still using punch cards?) that always annoyed me.

I will give BASIC one thing - it's basic geometric drawing library was really easy to use. Problem is, we NEVER USED IT except as a "hey, so this is how you use it, now we're never going to talk about it again." Might as well have learned LOGO (which I had taken as well, turtles were awesome and provided a good intro to iteration even if it was never described as such in class.)

Re:BASIC is great for kids

[Anonymous Coward]

Actually, those things could be better taught by primary school mathematics teachers. Primary school maths is supposed to be all about patterns. Examples: efficient methods of computing the sum of an arithmetic series; symmetry (etc.) of shapes; identity elements for + and multiplication; basic logic arguments like p -> q (not like that of course, but in real world terms). All of this quite literally is child's play.

After that programming computers is nothing more than an application of those simple facts. Did I mention QBASIC anywhere?

Granted, I had a similar experience to yours, playing with DOS with the said QBASIC and batch files and all the rest. That said, I think it is harmful to be introduced to programming too early before mathematics. You know how to build a great program at a young age, but with no appreciation for the ideas for what they are. You can go in one direction but not the other. If you think you can, you went the other way already.

The problem is having bad teachers. Luckily for me I didn't have many (but not 0) of them.

Re:BASIC is great for kids

[Anonymous Coward]

For some kids. I remember fighting against it when I was maybe 10. I was by far the best in my class in math and physics, and I remember being really pissed off that others picked it up so easily.

When I tought myself C (yes, using ``The C Programming Language'' by K&R), I was in heaven. Somehow, it made sense. Grasping things like structures, classes, polymorphism, dynamic vs. static memory allocation and so on is what made it logical and interesting.

All in all, it really depends on the character. This is why some people end up studying biology and some computer science, for example, or why people have such different opinions on BASIC.

Re:BASIC is great for kids

[smash]

A bad workman may blame his tools, but BASIC (traditional line numbered basic) is a tool that encourages formation of bad habits.

If you can't get your head around basic data structures, then perhaps programming isn't an ideal career path. To do anything useful at all, you ARE going to have to deal with data structures.

Pascal or even C is a much better first language, imho.

I started off with TRS-80 Color Basic on a Coco 2.

Re:BASIC is great for kids

[Anonymous Coward]

5-6 year olds are just learning how to READ and you expect them to be able to learn to program?! o_O`

Re:BASIC is great for kids

[Anonymous Coward]

I stick with the old adage a bad workman blames his tools.

Argh. Pardon the fork, but it's a poor adage. What it's meant to teach about attitude is lost upon the intended target, the beginner, because the simple mindset misinterprets it to mean that skill always triumphs over bad tools; that there are no bad tools. It causes more confusion than clarity.

Sorry, but after half a lifetime of using and selling tools, I just twitch when I hear that one trotted out. I agree with you on BASIC.

Re:BASIC is great for kids

[smash]

Not sure when you learned to read, but at age 6 I was learning to program, yes. Or at least modify existing basic programs. Pretty sure by the time i was 9 I'd modified a program that drew with the joystick (in text-mode chunk-o-vision) on the coco2 to work in graphics mode instead.

Re:BASIC is great for kids

[badran]

LOGO.... Now that was fun. I remember drawing all sorts of things with that turtle.. The Fill command was really fun.

Takes me back to the days of DOS games and floppies.

Re:BASIC is great for kids

[badran]

Yes. It is the perfect age. A programming Language is very similar to a Spoken Language, and kids can grasp these concepts faster than adults.

If you learn how to speak to a PC at that age, then your golden....

Re:BASIC is great for kids

[Anonymous Coward]

Remember that the adage was about craftsmen who were expected to *build* their own tools. Hence if they complained about the quality of their tools, the implication was that it was their own fault.

Re:BASIC is great for kids

[Viol8]

"A bad workman may blame his tools, but BASIC (traditional line numbered basic) is a tool that encourages formation of bad habits. "

That's saying hammers are to blame for people not using a screwdriver when they see a screw. Sure , if you're a lousy workman then all bets are off but if you have an aptitude for programming then you'll soon catch on to structured programming etc. BASIC is good for teaching basic logic which is what kids need.

You don't learn to drive in a Ferrari.

Re:BASIC is great for kids

[Mongoose Disciple]

Eh. I was writing simple games in BASIC at age 6. I'm pretty sure C memory management would have kicked my ass sideways at the time. I submit to you that this doesn't necessarily make me a bad programmer in a larger sense.

I mean, in a sense teaching yourself to program as a kid requires comprehending very basic algebra, so who's to say what one could or couldn't pick up, but it seems like it'd be harder to get C pointer math right without even knowing what multiplication was.

Sometimes something very simple and limited really is the right tool for the job or the audience.

Re:BASIC is great for kids

[Anonymous Coward]

Read TFA? You must be new here.

Re:BASIC is great for kids

[Locke2005]

Visusal Basic HAS "structures, classes, polymorphism, OO, etc.". My worst complaint about it is that I'm never sure when it is passing by reference or passing by value.

Re:BASIC is great for kids

[griffeymac]

Fewer ridiculous syntax requirements? Stupid unnecessary crap like explicit line numbers?

Isn't Python that language where the whitespace/indentation affects the workings of the program code?

For a kid starting out to program, I don't at all think that BASIC is a bad idea. If nothing else it might light the fire inside a future hacker and encourage him or her to absorb as much as they can from 'puters. Why start with something that is any more complicated than it needs to be?

10 REM ** COOL PROGRAM **
20 PRINT "I AM BORIS! I AM INVINCIBLE!"
30 GOTO 20

Re:BASIC is great for kids

[Dun Malg]

Eh. I was writing simple games in BASIC at age 6. I'm pretty sure C memory management would have kicked my ass sideways at the time.

Likewise, only I was doing it at 9 over an Adds-Regent print terminal with a 300baud acoustic coupler to the mainframe where my father worked. The line number paradigm is easy to grasp for a beginner, and allows practically effortless transition to the address paradigm in assembly. I was working for (game company) writing assembly for the C64 several years before I even learned C. The one thing that most helped me in learning C was a full understanding of how the assembly underneath worked. Pointers? Walk in the park. Structures? Unions? Memory management? Buffering? Null terminated "strings" that are really only character arrays? No problem for someone with assembly experience. You ever see someone try to learn assembly when all they know is Pascal? It's ridiculous.

Re:BASIC is great for kids

[Doctor Faustus]

Basically, Python can provide all the same benefits as BASIC without the stupid unnecessary crap (Explicit Line numbers? Really? Are we still using punch cards?) that always annoyed me.

I'd consider Python an educational successor to Pascal, since BASIC never deserved consideration apart from being free with DOS. Still, the last version of MS Basic to require line numbers came out in 1988, when punch cards really were still routinely used in some places.

Re:BASIC is great for kids

[Blakey Rat]

Basically, Python can provide all the same benefits as BASIC without the stupid unnecessary crap (Explicit Line numbers? Really? Are we still using punch cards?) that always annoyed me.

When's the last time you used BASIC? It hasn't had line numbers in decades.

Man, you were doing such a good job, too, until I got to the part where you made it apparent that you have absolutely no clue what modern BASIC even looks like. Shame.

Re:BASIC is great for kids

[Anonymous Coward]

Sadly, Python also has some very nasty warts, like the implicit creation of variables upon first use (so typos mean subtle bugs!) and the frankly bizarre scoping rules that go with it.

Even Visual Basic has "Option Explicit". Even Perl has "use strict". Python would do well to copy them, if it wants to be the best option for a didactic language.

There is value in BASIC

[JazzXP]

It's what I started on, and learning the fundementals such as if/else, do/while, variables, arrays, etc will give you a massive head start on any programming course in the future. It's so simple that when you look at code it's not so complex that it will scare you off, and easy enough to just start hacking around (even the good old:-
10 PRINT "HELLO WORLD"
20 GOTO 10
is quite valuable).

That said, it's not really worth while learning all the ins and outs of the language as anything real world (even *shudder* Visual Basic) will be quite different.

Re:There is value in BASIC

[daveime]

while (1) {
        print "HELLO WORLD"
}

For the "purists" out there who think GOTO is the Devil.

I'm amazed they haven't had a go at Intel yet to try and get JMP banned.

Never got basic.

[OpenQL]

And the name doesn't sit easy for me.

Simple rewards

[Anonymous Coward]

I learned BASIC on a Commodore Vic-20 when I was about 6. The big problem with that flavor of BASIC was its shallowness: it didn't reward elegant solutions to programming problems and it was very easy to hit the performance limit. I never really managed to build anything more complex than text adventures and very simple arcade games. Still, the BASIC prompt was the very first thing you saw when switching on the micro so you were naturally attracted to experimenting with it, assisted by handbook that was included in the box. The prompt rewarded curiosity, especially when you started to enter those seemingly random values for PEEKS and POKES. Nowadays, on Windows machines, the prompt is hidden away from sight and there's hardly any mention of a programming or scripting language anywhere in the GUI.br /br /I can't say that learning BASIC made me a better or worse programmer, but that's what got me interested in computing in the first place: those simple but oh-so-thrilling rewards of getting the machine to do what you want it to do.

Re:BASIC is irrelevant

[black3d]

Not recognising the relevance of BASIC as described in the article, it's possible you're around a decade or two younger than the individuals the article is referring to.

Simple, but genuine rewards

[zr-rifle]

I learned BASIC on a Commodore Vic-20 when I was about 6. The big problem with that flavor of BASIC was its shallowness: it didn't reward elegant solutions to programming problems and it was very easy to hit the performance limit. I never really managed to build anything more complex than text adventures and very simple arcade games. Still, the BASIC prompt was the very first thing you saw when switching on the micro so you were naturally attracted to experimenting with it, assisted by handbook that was included in the box. The prompt rewarded curiosity, especially when you started to enter those seemingly random values for PEEKS and POKES. Nowadays, on Windows machines, the prompt is hidden away from sight and there's hardly any mention of a programming or scripting language anywhere in the GUI. I can't say that learning BASIC made me a better or worse programmer, but that's what got me interested in computing in the first place: those simple but oh-so-thrilling rewards of getting the machine to do what you want it to do.

Re:Simple, but genuine rewards

[Linker3000]

I would have thought the problem on the VIC-20 wasn't shallowness, but (column) width!

I started on a 3016 PET at school and then bought my own C64. Great days coding in BASIC, with machine code calls for serial I/O. Among other things I wrote a nifty VT100/220 emulator that ran in graphics mode with its own character set (designed by me) and also a map editor for Boulder Dash.

Both were probably of 'commercial quality' for the time, but being a fresh-faced youth, rather than hard-nose businessman, I just uploaded them to various BBSs for anyone to download.

Bah!

[Greyfox]

You haven't really programmed until you've implemented a linked list using arrays in Basic!

Worthless? Hardly!

Re:Bah!

[Anonymous Coward]

BTrees in Brainfuck. Discuss.

Re:Bah!

[smash]

Pointless.

Re:Bah!

[badran]

Good reads from 13 years ago....
http://www.petesqbsite.com/sections/tutorials/tutorials/tutor2.htm

Re:Bah!

[shutdown -p now]

Out of curiosity, how would you implement a linked list using anything in BASIC, given that the language doesn't have pointers, nor any other kind of a first-class pointer-like construct (BYREF arguments are not first-class, as they cannot be used in data structures); nor any way to allocate memory on the heap and manually manage its lifetime?

I can see how the first part can be worked around using PEEK/POKE, but you still have that problem of allocating memory...

Re:Bah!

[HTH NE1]

Out of curiosity, how would you implement a linked list using anything in BASIC

Arrays.

Seriously, if you have to ask the question, you need to restudy Turing machines.

Re:Bah!

[shutdown -p now]

Do you mean using a single global array as a kind of heap, and indices into it as pointers?

Sounds pretty nasty, as you'd have to, effectively, implement your own heap manager, and deal with all the associated quality-of-implementation issues (such as fragmentation).

Re:Bah!

[chthon]

Probably, but a good learning experience. I urge you to pick up a copy of Structure and Interpretation of Computer Programs.. They use exactly the same method to explain how Lisp (Scheme) implements list structures.

Re:Bah!

[Greyfox]

You set up two arrays. The first array contains your data element, the second array contains the index to the next element in the list at the same index as the data element in the first array.

The next logical question would be "Why would you ever need to know that?!" It's the sort of thing that might come in handy if you ever have to bust out the assembly language, though I think your options for structuring data in that language are more flexible than they were in BASIC. Also, sometimes a job will constrain you to a certain limited language. Probably not BASIC, though I could see being stuck with COBOL or something equally obnoxious. It is occasionally handy to know how to work within the limits of a brain-dead language.

Appreciate the difference

[Katatsumuri]

As a programmer who started with old-school BASIC (numbered lines, etc), I was overjoyed with better elements of structured programming in Turbo Basic, and totally excited with C when I learned it. It felt like having my hands untied. So I would state the contrary: you cannot fully appreciate the structured programming unless you went through the GOTO hell.

I hear a lot of similar FUD from some people, like "you can't grok OOP if you started with C", or "anyone who touched .NET or Java is lost for C++..." It boils down to "people are idiots, they can't possibly learn anything new, they are either indoctrinated at birth in My True Way, or lost and hopeless." Who in their right mind would take that seriously?

Re:Appreciate the difference

[dkf]

It boils down to "people are idiots, they can't possibly learn anything new, they are either indoctrinated at birth in My True Way, or lost and hopeless." Who in their right mind would take that seriously?

That quote reminds me of a number of religions who have exactly that attitude. Makes me suspect that it must be a recurrent (though no less foolish) theme to human thought...

Re:Appreciate the difference

[fredrik70]

hear hear, all very true. I still remember the pain when I ran out of numbers (when I needed to insert some code inbetween 2 lines) and needed to sit down and renumber the whole piece of code, now trying to add big enough increments between the numbers.
c was heaven after such thing

Re:Appreciate the difference

[Corporate Troll]

Similar thing for me. Started on BASIC (with the numbered lines, indeed) and then when I discovered Turbo Pascal, I was liberated. BASIC just always felt limited. All because of my dad who showed me BASIC first, because I wanted to calculate stuff, and something like "calc.exe" didn't exist. He showed me "PRINT 10+10" and I was sold. Later when he saw I was programming, he bought me a Turbo Pascal book. Ah, those were the times. :-)

Re:Appreciate the difference

[Frigo]

anyone who touched .NET or Java is lost for C++...

That's strange. I heard from several sources that programming in Java for a while makes one's C++ code cleaner.

Re:Appreciate the difference

[Katatsumuri]

The argument from those people was that garbage collection spoils you. Maybe some other convenient features / syntactic sugar might also pose a threat. I never believed that. I think that learning additional languages / paradigms can make you a better programmer.

Re:Appreciate the difference

[Lemming Mark]

That sounds familiar to me too. Quite a lot of companies seem to be asking for specific experience in a particular language or a particular kind of development. This does strike me as pretty bizarre sometimes, since often that doesn't sound like the truly hard part of the problem they're recruiting someone to solve! Obviously everyone who prides themselves on their abilities probably regards their personal expertise as being the hardest / most advanced thing out there but it's a bit worrying if that's taken to an extreme of excluding skilled programmers ...

Re:Appreciate the difference

[terrahertz]

Religions don't have attitudes. People have attitudes. Sorry for being OT, but elucidating this distinction has become a bit of a hobby of mine.

But I do agree with you and the GP in the points you make.

Re:Appreciate the difference

[danlip]

I felt exactly the same way when I learned structured programming after starting with BASIC. On the other hand, I've met some programmers whose thinking was damaged by BASIC, but I suspect they would never have been good programmers regardless of their starting language.

Re:Appreciate the difference

[Dun Malg]

Adherents to the various religions tend to conform to a prevailing attitude associated with their specific faith.

That's what statements like "[religion] has [attitude X]" mean. Seriously, get with the program. Language has many shortcuts, and if you insist upon taking them literally in order to say they're technically wrong, you're just another jackass blasting an airhorn in the audience during a debate.

Re:Appreciate the difference

[terrahertz]

Why are you so angry about the point I made? I have interrupted nothing, and in the spirit of my own beliefs, I'll forgive you the ad hominem.

I happen to consider myself a believer, though I have major philosophical, moral, and ethical disagreements with the majority of human beings who identify with the same beliefs/Religion that I do.

That is why I take exception to the notion that a Religion can have an "attitude" -- because that perpetuates stereotypes that if person X identifies with Religion Y, then they believe Z. You say that we all ought to interpret this "shortcut" in one way, but I have observed many different interpretations in my own experience.

It is interesting to me that your comment history shows a pronounced frequency of Troll moderations, and yet you don't appear to be just "having a laugh" -- you sound genuinely unhappy. Do you want to take our discussion off the site? I feel compelled to offer my assistance in raising your spirits.

Re:Appreciate the difference

[Haeleth]

That quote reminds me of a number of religions who have exactly that attitude. Makes me suspect that it must be a recurrent (though no less foolish) theme to human thought...

Really? Which ones? I can't offhand think of any religions that believe you have to be indoctrinated at birth and can never hope to find the truth later in life. (I can think of plenty that believe that they are the One True Way and that everyone who doesn't follow them is lost and hopeless, but they pretty much all agree that it's never too late to repent and convert.)

Instant Basic

[tsackett]

Anyone else remember learning to program with the book "Instant Basic"? It was formatted like a Trader Joe's advertisement, with lots of Victorian clip art, and it let a lot of us learn the basics of programming -- conditional branching, loops, variables -- without actually having access to a computer.

Re:Instant Basic

[Iskender]

Wait, are you serious? If you are, please describe this in more detail. That's either a good joke or really interesting.

Re:Instant Basic

[tsackett]

There's a picture of the second (1982) edition at amazon: http://www.amazon.com/Instant-BASIC-Freeze-dried-Computer-Programming/dp/0918398576/ref=sr_1_9?ie=UTF8&s=books&qid=1268240739&sr=1-9

The original goes back to 1977. I've actually got a copy of it around somewhere. I should put up a tribute page.

Basic and Basic...

[chrysalis]

Whoever hasn't coded with GfA-Basic or Omikron Basic never experienced how a fun and versatile language it was.

Variety

[RenHoek]

I've gone from MSX Basic to Turbo Basic to Turbo C. Now I can code in all kinds of languages, assembly, PHP, Ruby, Javascript, etc..

I do think that BASIC has value as a first language because it gives back results immediately. Sure, nowadays there are other script languages, so you don't have to go through compiling and all the other complexity. BASIC is valuable because it's just that: basic. You don't have to worry as a first-timer about libraries, include files, functions and everything else. You get down to the very basics like variables and program flow.

And after a lot of years of BASIC programming I knew the limitations of the language (which largely depends on the interpreter). That's when I switched over to Turbo C. And to be honest it didn't took me long at all to learn C because I was a pretty reasonable BASIC programmer.

What I _do_ object against is stuff like Visual Basic. That's taking a limited language which is simple and jamming it into a place where it shouldn't belong. To let Visual Basic work, they stuffed all kinds of non-original basic stuff in there which make it more complex then something like Visual C. Their idea was "lets make making real application easy with Basic, because Basic is easy right?". It doesn't work like that.

I also think that Java is not a language that people should start programming in to be honest. Object oriented programming is NOT something people should learn before they had a taste of procedural programming. Fun fact. I went back to my old school to see about taking some night classes to get my CS degree. (I dropped out at the time and I've learned a LOT more on the job then what they were teaching.) At their open house classes I asked about procedural programming and if they still taught it. They scoffed and said nobody uses that anymore. This when I've been a Linux kernel developer for 10+ years now which is 100% procedural ANSI C. It's all Java they teach nowadays.

In closing. I think a good programmer is somebody who explores. If I have a Windows application that does something cool, I take it through a disassembler to see what makes it tick. I look up DOT NET C# code snippets to see what it's all about. I look through COBOL and ALGOL source code to see what constructs people used in the past. I patch ARM assembly code to fix bugs. I do all those things and not rigidly stick to a single programming environment. A good programmer is a state of mind, not the language he works in.

Re:Variety

[RenHoek]

PS..

GOTO's have their place, even in modern programming languages. Fuck C for not having a 'break [n]'. :)

Re:Variety

[vikingpower]

Amen at your last phrase. If it takes Rebol to perform a certain task, then heck - let's use Rebol ! If the next assignment is best done in ADA - well, why not ?

I once had a boss, a very good manager, one of those who had crept up the scales from electronics engineer to vice-president. He had only one test to submit candidates for software engineering positions to. It was about designing an algorithm, and therefore language-independent. You could answer with pseudo-code, Java, C, or with an outline of your algorithm in French. Invariably, it would expose your ways of thinking. Still the best test for prospective programmers I've ever seen.

Re:Variety

[Anonymous Coward]

This when I've been a Linux kernel developer for 10+ years now which is 100% procedural ANSI C. It's all Java they teach nowadays.

To be fair, even so-called "procedural ANSI C" is often coded in an object-oriented style now. While the language doesn't give you a lot of support for it, if you're using a single data structure (let's call it a "class") and a bunch of functions (let's call them "methods") that only operate on that data structure... well, you just did OO programming. C++ was originally just syntactic sugar that made this kind of thing easy to express, and then sorta exploded from there.

If you're doing kernel development, the real issue I'd have with learning Java is that it doesn't teach you very much about the fundamentals of how a computer works at an architectural level ("ooh, magic garbage collector! abstraction galore!"), but most people don't end up doing kernel programming.

Re:Variety

[Anonymous Coward]

I can't possibly agree with this more than I do. Day to day, I code in Ruby now and -- despite some 'flaws' in the language -- I love it. It's fast to code in, flows well and I can get the ideas in my head expressed decently. That being said, I have coded in quite a few languages for fun and to see how they work and how well I work with them. I love esotoric languages and in their oddness, they have taught me new ways of thinking sometimes, often as a surprise to me. (My favorite by the way: Rail -- just a fun language to play with.) I've done C, C++, Java, but they never give me the thrill of using something like Lua, tcl, Pike, and various other lesser-known languages. If I didn't go out and explore and look for new (to me) languages, I doubt I'd be any good at what I do or have nearly as much fun doing it. All of the nitty-gritty details of CS and languages aside, it's fun to see how other people have come up with giving the same instructions to a computer; it's all machine-code in the background afterall.

Re:Variety

[shutdown -p now]

What I _do_ object against is stuff like Visual Basic. That's taking a limited language which is simple and jamming it into a place where it shouldn't belong.

To be honest, modern Visual Basic (VB.NET and beyond) is only "BASIC" in a sense that it uses a bunch of old keywords and basic constructs (such as DO..LOOP or FOR..NEXT). Semantically, though, it's almost exactly the same as C# (which is itself not that far from Java), and definitely not more complex.

I know a lot of people coming from BASIC background hate VB, but in truth, it's actually a fairly reasonable language to start learning .NET (or even OO in general) with. You get all the same constructs feature-wise, but with a syntax that is more verbose and descriptive, and a few extra checks turned on by default.

To give a specific example: in Java, you use keyword "final" to indicate that a class cannot be inherited, and also that a method cannot be overridden. In C#, you use "sealed" for the same purpose. But VB has two separate keywords, namely, "NotInheritable" and "NotOverridable" - which are lengthy, but their name tells exactly what they are.

Another keyword example: what is "abstract" in Java and C#, is "MustInherit" and "MustOverride" in VB - again, depending on whether it's applied to a class or to a method.

For syntax in general, compare Java/C# "List<int>" to VB "List(Of Integer)".

Extra checks can be handy, too. For example, in Java, "2000000000+2000000000" is going to silently overflow and become a large negative number. In C# the default is the same, though you can write "checked(...)" if you want to get an exception instead. In VB, arithmetic overflow checking is on by default, and you'll get OverflowException.

Re:Variety

[Lunzo]

The part I hate most about VB.NET syntax is how backwards it feels.

Dim foo as Integer

My mind works in the following order: "I need an int variable. What do I call it? foo would be a good name." In C#.NET or any other language with C style syntax I can type in the same order that I think:

int foo;

The same pattern is repeated in method declarations with parameters and the return value. Also why do I have to specify ByVal on every single argument? Why not just make it the default like C#?

I think the verbosity is also an issue. Due to the verbosity of VB.NET a function with more than about 2 parameters will either flow off the screen, or require you to split the definition over several lines. In C#.NET it all fits on one line and is just as obvious what is going on.

Re:Variety

[shutdown -p now]

My mind works in the following order: "I need an int variable. What do I call it? foo would be a good name." In C#.NET or any other language with C style syntax I can type in the same order that I think

You're just too used to C-family languages, that is all. It's not at all more natural, as evidenced by the fact that countless languages in other families use the reverse syntax. For example, Pascal (and Modula-2, Delphi etc):

var foo: integer

Type-first declarations are also harder to read when nested type declarators (pointers, arrays) are applied. For example, consider this:

int[] x

Now you need to read the type left-to-right to parse this as "array of int", while declaration as a whole is still read right-to-left. And it's even more messy when arrays get into it. For example, in C#, which has multidimensional arrays:

int[,][] x

If you read the type right-to-left, then this is "1D array of 2D arrays of int". But if it really parsed that way, then accessing the array would actually look like this:

x[1][2,3]

Note how the comma has moved. This is quite surprising, which is why C# reverses the order yet again for array specifiers - so consequent []s in the middle of a type declarations (which are parsed right-to-left) are parsed left-to-right. D doesn't do this to avoid confusion, but that leads to the aforementioned inconsistency between declaration and use. And I won't even touch the mess that is C declaration syntax...

You can do:

[,][]int x

but this is goddamn ugly. And compare to Pascal:

x: array[,] of array of integer

Much clearer, isn't it?

The same pattern is repeated in method declarations with parameters and the return value. Also why do I have to specify ByVal on every single argument? Why not just make it the default like C#?

It's the default, actually, and not required by the language. It's the stupid IDE which keeps inserting it. I've heard they want to kill that in next release.

Re:Variety

[rbanffy]

> Now I can code in all kinds of languages, assembly, PHP, Ruby, Javascript, etc..

Just make sure you are not writing FORTRAN code in assembly, PHP, Ruby, Javascript, etc.. ;-)

Re:BASIC is irrelevant

[ipquickly]

just great, more sushi, I should block images from that site

I started with Apple BASIC, and I was playing around with peek and poke before the other students even knew how to properly misuse goto.

But that was when I was 13. The first year of college should not teach BASIC.

But why are we not introducing BASIC or the very beginner friendly 'Ruby' to students when they're 13 anymore?

I started with BASIC

[OpenSourced]

Years before I took any formal course, I was looking at the manual of a BASIC computer and making circles on the screen by programming a dot that kept to the same distance to another and rotated. I still remember the emotion of seeing a real circle emerge on screen. I don't know if BASIC helped me much to program, but the immediacy of the thing certainly did much to keep my interest alive.

Re:I started with BASIC

[KillzoneNET]

I too started with BASIC. In my case this was freshmen year in High School back in 1999 on QBASIC. I had dabbled a little with HTML but that was nothing like an actual language that had logic. It was there that I learned the basic blocks that made me the programmer I am today. I went from simple logic to loops to graphics and sound.

By the end of the year I had a full animation of a house with Christmas lights and music. I even had a very primitive text based RPG working with the ending taken straight out of Monty Python's Holy Grail.

It was from there that I learned C++, JavaScript, and many other languages. The logic from BASIC carried me over very easily to other topics.

The problem with students is not the language they learn, but the fun they can find out of it. You have to find what interests them and drive them in that direction.

Re:I started with BASIC

[vikingpower]

Kewl sig !

Re:I started with BASIC

[OpenSourced]

http://slashdot.org/journal/92046/My-sig :-)

Re:I started with BASIC

[Anonymous Coward]

Similar anecdote: I "cheated" in Advanced Pure Mathematics at high school, by programming the TRS-80 down the hall to proportion and draw out the radially-defined functions on X-Y graphs. Watching those graphs appear on screen after editing the formula was a delight I have not experienced since in 30 years of coding. I freaked when my Pure Math prof walked in one day and "caught me" in the act of "finishing my homework" using the TRS-80. Instead of reprimanding me, he assigned me to teach anyone else in the class how to program in BASIC for the Applied Math course - he said that if I understood both the pure math and computer language well enough to "cheat" like that, then he had nothing to reprimand me for. He was pleased to find a free resource for other interested students. He was a great guy - I wish all teachers were as sensible and open-minded.

BASIC was a source of great invention and discovery, and the lack of a WHILE loop didn't harm or impede us in any way whatsoever. Like other posters have pointed out, earning your brownie points with BASIC sure made "advanced" programming languages very easy to understand, both in terms of constructs and WHY those constructs were a good thing - nothing like 10 levels of nested GOTOs to make you appreciate strict function and procedure definitions.

Re:I started with BASIC

[skiman1979]

If nothing else, THAT is the key to what makes BASIC so good as an intro language. With only a few simple lines of code, you can have a full program up and running getting input from the user and displaying things on the screen. I first got interested in programming as a kid because I thought it was awesome that I could write some text on the screen to make the computer do what I wanted it to do.

You get to learn about core programming concepts like loops, if/else statements, and the like without worrying about classes, structs, event handling, threads, and other similar things that although are helpful, are not necessary to create a program. Some languages (besides BASIC) don't even have some of those more advanced components.

Back in my day...

[Anonymous Coward]

Back in my day... we didn't have basic...
we didn't have Assembler
We didn't have machine code
we didn't even have ones...
we coded in zeros

Re:Back in my day...

[vikingpower]

Man - back in MY day, we wished we'd had zeroes ! We used empty animal skulls for zeroes.

It's not the language, it's the teacher

[willoughby]

Most folks who have learned C++ learned it in a classroom with a real teacher. Most folks who learned BASIC learned by banging away on a computer keyboard at home.

Most people aren't very good at teaching themselves. I've seen this a lot with people trying to learn Morse code and giving up in frustration.

You can pick up a lot of bad habits without someone to guide you.

Re:It's not the language, it's the teacher

[vikingpower]

I concur on the Morse code. I learned it in the Navy, from a good and patient teacher, who basically insisted upon enormous amounts of exercise. Now, twenty-odd years later, it still sits so deeply in my brain that nothing can wash it out.

Re:It's not the language, it's the teacher

[urusan]

A good teacher is extremely valuable and it certainly makes the process a lot easier.

However, the teacher is less important than the student in determining the quality of their education. Compared to books, a teacher adds expert interactivity to the learning experience which is nice but not essential. A good teacher can also improve the quality of their students by sparking interest in them, but it's ultimately up to the students to learn.

Additionally, being able to teach yourself effectively is a crucial skill for a programmer. You can't rely on teachers to always be there, and sometimes you just have to sit down and learn something from a book (or even worse without one).

I've learned many of my most valuable lessons from books and from my successes and failures. Books in particular are the key to effective self-teaching of an established skill. They contain much of the wisdom that a teacher would impart upon you, and are often written by the top experts on the subject instead of whoever is available to teach the equivalent class. Of course, book learning by itself is a very poor way to attain a skill. A self-taught student must combine what was learned from the book with experience doing it themselves. The trials of experience are the exams of the self-taught. One more ingredient to add in when possible is to find a guru that one can go to for help. They fill the same role as the teacher, but without the formalities or the regular class times.

Re:It's not the language, it's the teacher

[TapeCutter]

Most folks who have learned C++ learned it in a classroom with a real teacher. Most folks who learned BASIC learned by banging away on a computer keyboard at home. Most people aren't very good at teaching themselves. I've seen this a lot with people trying to learn Morse code and giving up in frustration.

I stand as an exception to your rule. I learnt Basic and Pascal myself then was taught C, COBOL, LISP, etc at uni, then learnt C++ by myself mainly because C++ was still new in the late 80's. If you learnt C via the K&R route then C++ is fairly obvious, classes are just data structs with function pointers. In fact the the Watcom C++ I leant with was just a set of #define statements on top of Watcom C.

As for learning morse code that's just a boring memory excercise that cannot be ported to anything else. For example most C programmers have more or less memorised ascii codes but that doesn't help them one bit if they want to memorise morse or ebcdic codes.

Re:It's not the language, it's the teacher

[Anonymous Coward]

I don't know any half-decent C++ programmer who learned it in a classroom with a teacher. Every good C++ programmer I know started with BASIC, moved to C, then to C++, and was self-taught the whole way through. The guys who can't learn without being spoon-fed by a teacher are not the guys you want to work with.

Auto-tuition may indeed induce bad habits, but losing bad habits is a lot easier than gaining talent or intelligence from nowhere.

In any case, teachers of languages do not know good habits. Many C++ teachers teach things which are well known to be bad practice, in that dogmatic way that only teachers can. Undoing that is a lot harder than undoing something someone *personally* thought was a good idea once. People with their own bad habits don't argue as hard as people who think an authority is speaking through them. This is another reason I don't want to work with people who were taught C++ in a clasroom. They are closed-minded and usually about 5 years out of date on best practices (same as their teachers).

It's all a little academic anyway. The bad habit that C++ programmers could benefit most from losing is the habit of programming in C++ in the first place.

Re:It's not the language, it's the teacher

[Anonymous Coward]

It's the person, not the language or teacher.

I taught myself TI 99/4A Basic and Extended Basic, also Apple II Basic. I could program circles around my instructor in high-school, and actually subbed for him when he was out (yes they had a real teacher handle discipline, but I taught the class).

By the time I took the high school programming class, I'd been a programmer for 3 years and knew all kinds of tricks to shorten code, speed things up, better algorithms to handle searches and sorts. The instructor would write 10 to 15 lines of code to do something, then usually after everyone would get done with the lab work, I'd go up and write 3 lines of code that did the same thing, faster, smaller, and in my mind, easier to use.

Attitude and aptitude will get you further than any instructor or course.

Re:It's not the language, it's the teacher

[Anonymous Coward]

Many "real teachers" aren't that good teaching others, and more often than not, have superficial knowledge of the tool they're teaching. I've seen 16 year old kids with more grasp of good programming habits and what should and shuldn't be done than many teachers. Also, it should be noted that many teachers have zero real-life experience in actual programming, so they really aren't a good metric.
As of bad habits go, I see people picking bad habits in social context with other people, not staying at home. You are right when you say many people aren't very good at teaching themselves, but they still far away from not being able to grasp somewhat simple concepts (syntax, structure and good practices are actually pretty simple concepts - most spoken languages have a higher degree of complexity).

Re:It's not the language, it's the teacher

[molo]

Hi, I'm trying to learn Morse code (been listening to ARRL CDs and downloadable courses from hams), but its been slow going. How would you suggest that I proceed?

Thanks.
-molo

Re:It's not the language, it's the teacher

[willoughby]

Under what conditions have you been listening to the ARRL cd's? While driving to/from work, perhaps? People have been learning Morse since before there was radio so the methods which work best are pretty well known by now.

1) Learn code as you will be copying code.

The test is given with you sitting at a desk or table, listening through headphones & copying with pencil & paper. So, learn code by sitting at a desk or table while listening through headphones & copying with pencil & paper.

2) No matter what method you choose to learn the code, if a blind person couldn't do it, it's wrong.

Morse is an aural language & must be learned as such. Computer programs which beep the speaker, then put a big "R" on the screen are a terrible way to initially learn the characters. Visual stuff works in a different part of the brain. It's *very* difficult to learn Morse by any method which requires you to *look* at anything.

3) Don't get hung up on getting it perfect.

Push yourself on to the next lesson when your copy is about 87.57322% right. You'll never be perfect at the speed you're learning & perfection is not necessary. If you're learning at 5wpm you'll miss some characters. Push yourself on through, you'll pick up speed later to 8 wpm or so, and *then* your 5wpm copy will be perfect.

4) Limit learning new characters to 30 minutes a day.

You can practice the characters you have already learned as much as you want - by sending or copying, but your brain can only absorb so much new material at a time. Anything more than about 30 minutes just won't stick & will just frustrate you when it doesn't.

I'll shield myself from the "offtopic" mods & hit "submit now...

Re:It's not the language, it's the teacher

[RobertinXinyang]

Keep in mind, Morse code is no longer a component in any amateur radio exam. Further, if you get an extra class license you will not have to take the code portion of the exam to your radio-telegraph operators license as the extra class license exempts you fro that portion of the exam.

Re:It's not the language, it's the teacher

[molo]

Thanks for the suggestions. I think #1 is probably a big part of it, getting time to sit down and listen to Morse is hard. I'll stick with it. I appreciate the input.

-molo

Re:BASIC is irrelevant

[Anonymous Coward]

I'm doing a Programming Fundamentals course (mandatory and boring for me) and they're using Java... most of the students have never programmed in their life, and are completely overwhelmed by OOP.

Bah

[tsotha]

Computer-science legend Edsger W. Dijkstra famously wrote: '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'

Like all eminently quotable people, Dijkstra tended to hyperbole and oversimplification.

Re:Bah

[HNS-I]

Excellent comment you made there.

Also it's what professors do. They batter the students, somewhat like in the army. The first thing my professor asked was if we had any experience in programming, especially in c (the course was in c). So I told him I did. And he said: "Right you are going to have the most trouble learning this." [Why I read a whole damn book about it you insensitive clod!] But that attitude you will find throughout. Only when you have progressed can you have a normal discussion with them.

Now I know odds are great that someone will make reply about how elitism is bad and all. But I prefer getting a good education from an elitist jerk to getting misinformed by "someone from the field" that only started teaching because he wasn't wanted in the industry anyway.

I think I need to drink my first coffe of the day.

Re:Bah

[Anonymous Coward]

Can I quote you on that? ;)

Re:Bah

[clickety6]

"Like all eminently quotable people, Dijkstra tended to hyperbole and oversimplification."

Surely you meant:

  "Like all outstanding, amazingly prominent, extremely eminently quotable people, the immortal and infallible Dijkstra tended to massively over-exaggerated hyperbole and leaving out too many difficult bits."-

Re:Bah

[dkleinsc]

Like all eminently quotable people, Dijkstra tended to hyperbole and oversimplification.

Then the obvious conclusion is that all eminently quotable people should be ignored completely.

Re:Bah

[Hythlodaeus]

It's well known that Dijkstra was a curmudgeon with hearty disdain for anyone who wrote software on anything but a chalkboard.

Re:Bah

[Dun Malg]

I wouldn't say that. Pretty much any quote from Richard Feynman is solid gold. Most quotes from Dijkstra are ridiculous generalizations sparked by minor pet peeves ("these damn first year students keep asking where GOTO is!!!")

Re:BASIC is irrelevant

[Anonymous Coward]

programming is about being rigorous. that should be taught at college. not some sloppy language where anything goes and with the magical on error resume next that "fixes" all of your bugs. you know what is propaedeutic for real programming to freshmen? fighting segmentation faults. learning to trace stack overflows. checking that what they are doing do what they thing it should do, even if that means checking the return value of each printf.

we don't really need another generation of people who'd like to be programmers but doesn't wan't to learn the intricacies behind it. we've enough problems as it is, with sql injections and stuff.

First language doesn't matter

[urusan]

The first language I learned was Javascript. Well, actually I tried to learn QBASIC but it was just so horrible that I lost interest and nearly didn't become a programmer. I don't think any of that made a difference in the long run.

What's really important is learning more than just the language you started with. Learning many different ways to express yourself will really get you thinking about problems in a way that is not tethered to the specific syntax of your favorite language (not to mention introduce you to many different features that you might otherwise be ignorant of). Additionally, truly learning those extra languages will generate a lot of mental exercise. How you've spent the bulk of your time is far more important than where you started out.

Essentially, the author is trying to rationalize his start with BASIC by turning into some sort of advantage...either that or he's joking.

and...

[tjstork]

And Dijkstra does have quite a few genuinely useful and lasting achievements speaking for him (semaphores and such),

Didn't Dijkstra also pretty much lay down subroutines and coroutines.

There's never anything wrong with any language

[zlel]

A language may lend itself more naturally to a certain way of thinking, but isn't bending the language for the job the role of the programmer? I personally agree with the author - I think it's always a good mental workout to work in languages that do not give you the wealth of constructs and libraries of the many language popular today, but more than that, starting out in Basic exposed me to the many dialects of Basic very early in my career such that I'm now used to programming in unfamiliar languages.

Re:There's never anything wrong with any language

[CptPicard]

Really? How good are you at Prolog, Lisp and Haskell?

It wasn't all that great...

[Kjella]

...but it was BASIC. And the expectations were so low. "10 PRINT "Hello, World!", "20 GOTO 10" and it started doing something. The programming manual was well worn by the time I was 10, would that have happened with any other language? I doubt it. Things like lack of scoping makes the easy things easier and the hard things harder. The point isn't to learn everything from your first language, the point is to get started and interested at all. Moving to DOS was sorta ok, but moving to Windows killed my interest. C/C++ was just horribly complicated, I remember trying to get up a window in the Win32 API and it was like wtf, how hard can this be? MFC was even worse, Java (really early java, on hardware of the time) was slow and unresponsive as fuck, Javascript was a toy language for websites and never really like Pascal or VB much either. I didn't regain my interest in programming until I went with C++/Qt, or maybe more Qt than C++ really. QMainWindow *mw = new QMainWindow(), mw->show(). The hard stuff is still hard, but I very very rarely find I write "overhead" code that I shouldn't have to.

Re:It wasn't all that great...

[smash]

My history is similar, however i discovered Turbo Pascal and inline assembly. Couple that with the ease of getting into and programming mode 0x13 (display = array of bytes :)) and actually getting interesting things to happen was fairly straightforward and fun.

I lost interest in Window systems as well due to the amount of bullshit to get anything on the screen just killed interest. I've gotten into Cocoa with xcode and interface builder recently, and its fun again :)

I definitely agree, its the "overhead" code you need to screw around to just get anything interesting to happen these days that kills the fun.

Re:It wasn't all that great...

[SharpFang]

You should give Javascript a second chance. It seems like a toy on the surface, but once you uncover a second depth, it becomes very interesting. For starters, you can put on the left side of assignment operator things you would never expect any language could allow you to put there.

Advanced Javascript programs are composed in 90% of very tricky Javascript rewriting Javascript into some completely different language (and looking progressively less like Javascript), and then 10% of extremely straightforward business logic in the new language that matches the problem perfectly and looks almost but not quite entirely unlike Javascript.

Re:It wasn't all that great...

[ender-]

...but it was BASIC. And the expectations were so low. "10 PRINT "Hello, World!", "20 GOTO 10" and it started doing something. The programming manual was well worn by the time I was 10, would that have happened with any other language? I doubt it. Things like lack of scoping makes the easy things easier and the hard things harder. The point isn't to learn everything from your first language, the point is to get started and interested at all. Moving to DOS was sorta ok, but moving to Windows killed my interest. C/C++ was just horribly complicated, ...

I wonder about this these days. While I have no desire to push my daughter to be a programmer, I do want her to have some basic understanding of how the computer works underneath. She's almost 5 now and loves to play games on the computer, mostly educational things like Jumpstart. By the time she was 3.5, she could turn on the [Windows] computer, log in [no password], start Firefox, and navigate through the various websites we had set up on her bookmark bar. She could go to and start the games she wanted, and watch the videos she wanted.

That's all well and good, but what is her motivation to take the next step? Back in the day, kids got excited by computers. They were new, and interesting and CLI-based. Turn on the computer and it dropped you to a command prompt, or in some cases, straight to a BASIC programming prompt. To do ANYTHING on the computer largely required that you learn at least a little bit about typing out and writing what you wanted the computer to do.
On top of that, many of the computers came with some kind of guide or handbook explaining BASIC and what it could do. It was painfully easy after looking at the manual to type:
10 print "My sister has cooties"
20 goto 10

Tada! After 2 minutes of reading and 30 seconds of typing you had a working program. From there it was fairly small steps as you found out how to do this thing or that thing that the computer was capable of.

But now? First of all, computers are ubiquitous. To my daughter a computer is just a tool for playing games and watching videos, and no real knowledge is required to do almost anything you want on the computer. A few mouse clicks and the game starts or the web-page loads. There's no introduction to the underlying basis of how all those things work and are created.

Then there's the fact that today a kid grows up with the computer booting up straight to a GUI. Windows comes with no real programming capabilities. Linux comes with bash, or perl or maybe python installed, but those are largely text-based languages. Is a child who is used to the computer throwing fancy graphics at them going to get excited about making the computer type out a few lines of text? They don't want to write a text-adventure game [which they've likely never played]. They are going to want to write a 3D Fantasy RPG. That's not something that a kid is likely to look at and find that it's quickly possible. To a large extent, the jump to making a GUI window and then making it do much of anything is significantly more complicated.

How are kids today going to have their imagination sparked and given the opportunity to even think that they can, with just a little bit of work, make the computer do useful things? Or to even think of writing such things themselves rather than thinking, "Oh I need my computer to do this, I'll just Google for one of the hundreds of programs that already do what I want, or load up Synaptic and download one of them."?

I'm sure there ARE kids who see that potential and search it out, but I think it is much less common than it was 35 or even 20 years ago. Are we going to have a shortage of people who are really deeply interested in programming and how computers work, leaving us with only those who didn't start programming until they got to college and decided maybe programming could be a reasonable career path?

As she grows and starts improving in her reading, how do I introduce my daughter to the idea that she can not only consume what's handed to her on the computer, but can actually make the computer do cool things herself?

Re:It wasn't all that great...

[martin-boundary]

You should give Lisp a (first?) second chance. For starters, you can put code anywhere where data might go, and vice versa :)

Re:It wasn't all that great...

[SharpFang]

...elegant weapons for more civilized times... ;)

In praise of...BBC BASIC

[mccalli]

Yeah, there were no 'else' constructs. If you wanted an else, you had to do it yourself with a couple GOTOs. Also, the worst part about line numbers was when you decided to add something later, and there weren't enough lines. A program that had been refactored this way a few times could literally move randomly through the source code.

I never owned a Beeb, though I had several friends that did. I used them at school a lot too, and their BASIC was extraordinarily advanced. The ELSE statement was there, as was the standar(ish) GOSUB, but you could also define true procedures which returned values etc. (DIM PROC), and there was a clean way of dropping down to the 'OS' proper (OSCLI statements).

In addition, it also solved the line number problem you mentioned. It had a renumber command so that everything would become properly spaced out again. I remember the style of coding you're describing from my C64 efforts - the C64 was actually MS BASIC and it was dreadful, anyone wanting to do decent high-levle coding used to get the Simon's BASIC cartridge.

As a whole though, the BBC simply had the best BASIC of any 8-bit I encountered. That's not too surprising given its background and use as a teaching tool, but they did it very well indeed.

Cheers,
Ian

Re:In praise of...BBC BASIC

[mccalli]

DIM PROC

Argh. DEF PROC, not DIM PROC.

Cheers,
Ian

Re:In praise of...BBC BASIC

[PhunkySchtuff]

I'll second the BBC's BASIC, going forwards from the Model B to the Archimedes and there was an amazingly powerful basic lurking under the hood there. It was in ROM, like the bulk of the OS, so it was always there and it was quite fast. Basic programs were saved to disk (transparently) in a tokenised format, and executed as such and, yes, there was the great renum command that would put everything back on a nice and neat increments of 10 line spacing...

Re:In praise of...BBC BASIC

[Andy_R]

The renumber command was great until you came across a computed GOTO. Nothing quite prepares you for the horror of menu code like this:

10 Input A
20 Goto A * 50

Especially when one of the options doesn't fit into 50 unrenumberable lines and you find code like this

10 Input A
20 If A=7 THEN GOTO 1537 ELSE GOTO A*50

Re:In praise of...BBC BASIC

[Anonymous Coward]

Yeah, there were no 'else' constructs. If you wanted an else, you had to do it yourself with a couple GOTOs. Also, the worst part about line numbers was when you decided to add something later, and there weren't enough lines. A program that had been refactored this way a few times could literally move randomly through the source code.

I never owned a Beeb, though I had several friends that did. I used them at school a lot too, and their BASIC was extraordinarily advanced. The ELSE statement was there, as was the standar(ish) GOSUB, but you could also define true procedures which returned values etc. (DIM PROC), and there was a clean way of dropping down to the 'OS' proper (OSCLI statements).

In addition, it also solved the line number problem you mentioned. It had a renumber command so that everything would become properly spaced out again. I remember the style of coding you're describing from my C64 efforts - the C64 was actually MS BASIC and it was dreadful, anyone wanting to do decent high-levle coding used to get the Simon's BASIC cartridge.

As a whole though, the BBC simply had the best BASIC of any 8-bit I encountered. That's not too surprising given its background and use as a teaching tool, but they did it very well indeed.

Cheers,

Ian

Agree 100%. I taught myself BBC Basic as a young kid. I also remember the VDU commands for manipulating graphics. Learning BBC basic was remarkably well organised and functional.

Easily gotten over

[wrmrxxx]

easy language first your get-over is

FORTH started I at-all me affected not and

Re:Easily gotten over

[Mathness]

I knew it, Yoda was a Forth programmer!

Re:Easily gotten over

[K. S. Kyosuke]

It's even encouraged in the Bible: "Go Forth and *!"

Re:Easily gotten over

[LWATCDR]

RYN Reverse Yoda Notation.

Re:Easily gotten over

[Anonymous Coward]

Strong in Forth, he is!

Basic is, well, basic.

[Plekto]

My son is currently at the age where he wants to start learning to program. The thing is, other than Basic or similar entry-level languages, he just can't wrap his 11 year old mind around C++ or other more complex languages to start. And I can't exactly drop him straight into SQL or Linux either. He has to start somewhere, and simple languages fill this gap very well for the young. It's also the same reason why I hope that they never stop making those ###-in-one electronic kits. The basics may be old and useless to most of us here, but to our kids and grand-kids someday, it'll make the difference between being a good engineer or technical person versus just another brainless repairer who swaps parts without knowing why.

Learning out of a book in high school or college isn't obviously the same as hands-on building and programming.

Re:Basic is, well, basic.

[Anonymous Coward]

You could start him on Python. It's got easy syntax and human-readable code (for the most part) and provides an avenue of further learning once he gets the basics down.

Re:Basic is, well, basic.

[TapeCutter]

"Learning out of a book in high school or college isn't obviously the same as hands-on building and programming."

It was 1964 and I had just started school when a teacher showed me how to light a torch bulb with a battery and a piece of wire, I felt like a caveman who had just been shown how to make fire! To imply that school is just book learning and no hands-on is just plain nonesense. OTOH, I totally agree with the rest of your post.

Re:Basic is, well, basic.

[Teancum]

I would recommend that your son try to pick up Scratch as an introductory programming language. It offers a GUI development environment and adding multi-media features such as animation and sound tracks is like breathing air in that language. He is probably interested in making his own "shot 'em up" type of game anyway, and that is a perfect language to get started with those kind of concepts.... and it teaches object oriented design right from the start as well.

There are also thousands of example programs to download from the main website, most of which are written by middle school/junior high kids as well. There is also a surprisingly large group of professional software developers like myself who are closet Scratch developers and have "pushed" the language to some interesting extremes. The language is also sandboxed in a way that keeps most of the major problem issues with software development away.

The only thing that I find lacking with the language is that it was purposely built to avoid any kind of access to external data storage devices like a hard drive (other than to load and save the programs themselves). I personally think this was a mistake, but it is a part of the philosophy of the language and something that allows it to be used in most public schools where it is being used.

Re:Basic is, well, basic.

[Plekto]

I would recommend that your son try to pick up Scratch as an introductory programming language.

I have looked at it(and so has he) and it's really not "nuts-and-bolts" type programming. That's the problem, really. There's very little any more between the big complex languages that adults use and stuff like this that really isn't teaching you serious programming. The obvious question(there were similar programs and "languages" in the past in the 80s and 90s) is where do the kids go from this? Right. Usually thrown into the major languages in high school and college where their heads explode because it's a course for a grade rather than something that they can easily learn in their free time. I suppose HTML and PERL and the like is somewhat usable as an entry level(not sure I want to call it a "language", though, since it's really running scripts and formatting and the like), but it's really not serious low-level programming, either.

BASIC, as much of a bad rep as it gets, actually does fill a lot of that gap for beginners(though they might actually have to learn that evil stuff called math - oh no!). Yes, it's old, yes, it's not cool. But last I checked, the world didn't explode when we all learned it growing up. Plus, there are tons of emulators out there.

Re:BASIC is irrelevant

[julesh]

What a bunch of horseshit. Most modern intro-to-programming classes are taught in C and/or C++.

Really? I've looked at a *lot* of courses, and I've hardly ever seen either C or C++ taught as first language. When I started doing this, Pascal was the most common with a smattering of Modula-2, ML and LISP. These days, it's almost always Java. If it isn't, it's OCAML, Modula-3 or LISP.

What intro-level courses use C or C++?

Dijkstra ? Legend ?

[vikingpower]

Dijkstra, who taught at Eindhoven Technical University - which is how I superficially came to know him - was mostly a self-declared legend. He cultivated his own myth, even going as far as publishing a little book with his own quotes.

Re:Dijkstra ? Legend ?

[plasticsquirrel]

Ha, right. The guy who invented semaphores and solved some of the most difficult theoretical problems in Computer Science was a "self-declared legend." Are you serious? Sure, Dijkstra was opinionated and arrogant, but he was also a genius. He came through with rigorous solutions to the problems that really plagued the field of CS. That doesn't mean that he had perfect perspective, by any measure of the imagination. For example, he argued that first year Computer Science students should not even be allowed access to a computer. Rather, that they should just formally prove the correctness of the programs they write. I think fellow Computer Scientist Alan Kay said it best:

I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras.

Now since I mentioned Alan Kay, I should mention that Squeak / Smalltalk and Scheme are perfectly good alternatives to BASIC. They are refined and elegant in a way that BASIC, Python, and their ilk could not hope to be. They also give people powerful tools without a myriad of special cases, alternative syntax, and back-room slop. For example, Scheme is a very simple language, but by default supports arbitrary precision and limitless recursion. The last time I put Python's recursion to the test, it crashed pretty quickly.

Re:Dijkstra ? Legend ?

[Anonymous Coward]

For example, he argued that first year Computer Science students should not even be allowed access to a computer. Rather, that they should just formally prove the correctness of the programs they write.

What exactly is wrong with this? If someone truly appreciates computers for being what they are (rather than something related to a job or labour) then they should be able to think about computers whether or not one is there.

Not having something in front of you forces you to consider concepts in their full generality. It is like thinking about gravity without being on a planet: your intuition about gravity is not tainted by thinking that g = 9.8 m.s^{-2}.

And it is possible to do that. Teaching assuming that you have tactile or visual learners is not a requirement in any subject.

Re:Dijkstra ? Legend ?

[vikingpower]

Ha, right. The guy who invented semaphores and solved some of the most difficult theoretical problems in Computer Science was a "self-declared legend." Are you serious? Sure, Dijkstra was opinionated and arrogant

Genius is not necessarily in contradiction with being arrogant. What is your point ?

Re:Dijkstra ? Legend ?

[Edmund Blackadder]

He may have been self declared legend, but he was declared a legend by many other people as well.

Re:Dijkstra ? Legend ?

[McDutchie]

Genius is not necessarily in contradiction with being arrogant. What is your point ?

I think his point is that being arrogant is not necessarily in contradiction with legitimately being considered a legend.

Re:Dijkstra ? Legend ?

[K. S. Kyosuke]

"Sure, Dijkstra was opinionated and arrogant, but he was also a genius."

arrogant: Making or implying unwarrantable claims to dignity, authority, or knowledge; aggressively conceited or haughty, presumptuous, overbearing.

As far as I understand it, you are not "arrogant, but a genius" when you have the knowledge that the others don't - you're just a genius and the others are just miffy.

Re:Dijkstra ? Legend ?

[RAMMS EIN]

I think you sort of have to cultivate your own myth if you want to become famous. There are a lot of brilliant people out there who most people have never heard of. Dijkstra made great contributions to computer science and programming, but to say that that is what made him famous belittles the work of all those others who did so, too. He was famous because he made great contributions _and_ worked on his visibility.

Being famous is not one of my goals, so I don't engage in a lot of activities that would raise my visibility. In fact, I sometimes feel I work on my visibility too little - other people get asked for things that I would have been a better fit for, simply because people know them and not me. On the other hand, I don't claim to be anywhere near as good as Dijkstra. He changed the world in a way that I likely never will.

Re:Dijkstra ? Legend ?

[danlip]

I think fellow Computer Scientist Alan Kay said it best:I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras.

Which makes the Dijkstra quote on humility in TFA beautifully ironic.

Re:Dijkstra ? Legend ?

[danlip]

I think the second part of that definition is more relevant. Dijkstra was definitely arrogant, no matter how brilliant he was and no matter how much he contributed to CS. Or maybe you can say he was just an ass. But it certainly wasn't that "others are just miffy".

Re:Dijkstra ? Legend ?

[Dun Malg]

I think you sort of have to cultivate your own myth if you want to become famous.

ehhhhh..... I think you have to cultivate your own myth if you don't have a great number of concrete accomplishments to cement your reputation. Richard Feynman was a pretty unassuming guy, and he ended up famous anyway. Dijkstra probably didn't need to sell himself, so he really doesn't fit the category. He was just a kind of a loudmouth by nature.

Re:Dijkstra ? Legend ?

[azgard]

Richard Feynman was a showman. He certainly cultivated his own myth, maybe unknowingly, but certainly. He would probably be famous even if he didn't get the Nobel prize.

Dyslexic programmer

[GuyFawkes]

Back in the day I used basic a LOT, arguably like a sophisticated calculator programming language to do engineering calculations.

Show me a page of PHP even and everything goes blurry and out of focus.

That's dyslexia for you.

and...

[Vahokif]

And Dijkstra's algorithm for graphs, used on the Internet to this day.

Seconded!

[thijsh]

Commodore Basic taught me to love programming, have fun making little games and all important binary operations and encoding for sprites and font
QBasic allowed me to take my learned lessons to the 8086 and add much much more visually appealing graphical interfaces (still mostly games, but also editors etc.)
QuickBasic introduced me to libraries and compilation, i've built some great hardware monitoring interfaces with sensors and relay switches
Visual Basic allowed me to explore the win32 API and libraries, i''ve built some of my greatest applications with it ranging from editors and filtering proxies to a graphical music collection interface I could control with a remote

I loved basic, it taught me so much but most of all it taught me to love programming... The days of fun little programs in basic are over and I have no intention of ever going back... but there is definitely meaning there, and I would recommend anyone to try programming with basic... as a self-taught programmer I can say you will learn a lot from basic.

Re:Seconded!

[Just Some Guy]

Commodore Basic taught me to love programming, have fun making little games and all important binary operations and encoding for sprites and font

Preach it. My first exposure to binary was working through the examples in the Commodore 64 Programmers Reference Guide (still the best manual I've ever read). Sprites were 8x8 images stored as a 8 bytes, each byte representing a row, and each bit representing a pixel. I probably went through that section 15 times before I truly understood and believed that binary math works, but the lesson paid off in spades. Back then, it was figuring out how to peek and poke a memory location to make a single pixel blink. Now it's loading and storing a memory location to toggle a serial control line on an embedded controller. That little machine gave me a good start.

Re:Seconded!

[onepoint]

do you recall doing collision detection in the sprites, that was fun. I loved my c-64. wish I still had it.

Re:Seconded!

[c 0xFF]

My experience exactly.

I started out on BASIC, moving to BASICA when my dad bought a new computer.

My first introduction was a fiction book (I wish I still had it) that told a time traveling story. At key points in the adventure, the main character had to solve some problem by writing a program ... and the source was included in the text. I would type the program in and run it. Some were games that could be played, others were simulations. All could be modified to play with and understand programming concepts.

And yes, the bad guy is caught in the end: he journeyed to colonial America, but was caught because he had pristine-white teeth (no cavities or fillings) even though he had an intense sweet tooth.

I also progressed to QBasic, which got rid of line numbers (finally!!!) and added functions (although I never really learned how to use them). At the time I was introduced to C by my uncle. I never understood it at the time, mostly because the things that I needed to do were so much harder to do right: input from the user and graphics on the screen. But over time I realized the power that other languages had over BASIC because of how, well, basic it really is.

So that's the lesson: BASIC is fine as a toy, but real programmers will have to move on from it at some point.

Re:Seconded!

[kainino]

My first-ever exposure to programming was in BASIC, using Learn To Program BASIC by Interplay. This was probably 2000 or earlier--I was about 8 or less. Needless to say, I wasn't very good at it. But it definitely taught me to love programming.

I never really learned anything involving more than simple command line style logic (LTPB BASIC had mouse/sprites/sounds as well), but maybe that's a good thing. I had a magic 8 ball, a program for figuring out the week day of a given date (based on a method my dad gave me), and some other "meh" stuff.

Somewhat interestingly, the next thing I did, IIRC, was learn HTML and JavaScript from WebMonkey. During that time period I forgot most of BASIC, and pretty much all I can remember how to use off the top of my head are REM and PRINT.

Nowadays, though I don't (never did) program all that much, I do "real" programs in C++, and I regularly use Python for quick little scripty things (often helpful for homework, and Python 3 works great as a calculator).

Re:Seconded!

[BikeHelmet]

Have you looked into LUA? It might be a better option that Basic - and it's pretty respectable on your CV, if you're into game programming.

Re:Seconded!

[BikeHelmet]

Any language will teach you the basics of whatever you're interested in, within its own capabilities.

I learned that binary stuff with Javascript. I wanted to encrypt some data, so I figured out Base64 encoding. (which is technically 6 bit, but whatever)

Re:Seconded!

[Anonymous Coward]

Visual Basic also introduced me to object oriented programming and to databases in an easy and accessible manner.
I would also like to emphasise that the inspect, edit and continue debug interface in QBasic was really cutting edge at the time and there are still programming environments in common use that don't support that.

Who learns BASIC anymore, anyway?

[gig]

Are people still teaching or learning BASIC?

I know JavaScript, PHP, and AppleScript, and I learned them so I could script the Web browser, the Web server, and the Mac desktop, respectively. With just a few simple lines of each you can make really practical and productive things happen that seem to me like they would reward the beginner. My background is publishing, though. Maybe I'm biased towards programming that makes documents.

What does BASIC actually do?

Re:Who learns BASIC anymore, anyway?

[smash]

Basic (in its heavily mutated modern incarnation) allows you to debug Access Databases and Excel spreadsheets put together by accountants when they fuck up.

Re:BASIC is irrelevant

[someone1234]

Depends on your age when you start learning. I was 12 when i first met "programming", it was a TI programmable calculator. It was fun to squeeze as much functionality as possible from less than 1K Basic. Then came C64, with its ~38K Basic. Its Basic was very weak, but i learned how to read disassembly when i read the code of various Basic extensions and read books that contained snippets on extending C64 basics. Eventually i made my own Basic extension, cracked games to create trainers, made an own turbo loader that had half of its code on the floppy drive. So, by the time i went to mid school, i programmed device drivers in machine code!
I learned PL/I and other archaic languages in mid school, even punch cards! I learned C on my own and was taught in it only by the time i went to high school.

Back when i was 11..

[Anonymous Coward]

my mother draged home a 286 from work. I knew nothing, but i poked and i prodded and finally learned that exe files were programs. I stumbled upon qbasic.exe and did'nt understand what it was. I pressed F1 and the help appeared. I read it all many times and my programming carrer took of fromt here. It took several years before i left basic for C and ASM.

Today i have no problems getting my work commited to the Asterisk project. The guy is full of it.

Re:Back when i was 11..

[Narishma]

The guy isn't talking about QBasic or VB or any of the other structured or object oriented Basics. He was talking about the Basics of the era, where you had mandatory line numbers, no functions or procedures, no typedefs, only global variables and so on...

I'd guess there's a critical period & an attit

[weston]

I think the author is mostly on. He's aware Dijkstra was exaggerating for effect, but also completely correct... if you started programming in the early home computing era, you probably started with a BASIC. I was lucky enough to get some varied exposure earlier to some other languages (LOGO and some shallow assembly), but until I was 15, it was pretty much Basic.

And none of my programming habits now resemble anything close to the BASIC I wrote in when I was that age. Except, occasionally, for the rare cases where global state seems to make sense, and even then, I try to namespace things in one way or another. But by and large, I picked up structured programming, I picked up object-oriented programming, I picked up logic programming, and I'm learning to enjoy functional programming.

I will say... there was a time when I was probably close to being "ruined." It was when I was learning C++, and I only really had Pascal, basic C, and Basic under my belt. And I had a pretty solidly structured-imperative mindset, and really hadn't seen any other way of doing things. C++ married data structures and methods in an interesting way, but it didn't seem like more than a stylistic practice to me. I was pretty sure most languages were alike, you just had syntax and typing differences.

But there was one thing: I'd had to learn Prolog for a very specific job. We were teaching it to high school students in a CS summercamp I worked at for a few years. The first year, I just thought "Man, this is weird," more or less got through all the exercises, and left it behind, and did what most people do: dismiss it as an odd research toy. The second year, I thought "this is weird, but interesting." The third year, I thought "Wow. There are all kinds of intriguing ideas here."

And there are, and I still think it could stand to see more usage in mainstream software, but more importantly, I think I'm pretty lucky I got repeated exposure to a language that forced me to think differently before I got very far into actually working in the software industry.

Because I now think there's either a critical period (or possibly, at a minimum, a critical attitude of some kind) after which a lot of programmers tend to lose either the humility or the curiosity that drives people to think about different programming constructs and habits. I think if a programmer has been minimally exposed before they reach it, they'll keep just enough of one or both of those attributes that they'll be interested in what they don't already know, rather than arriving at the point where "they've already learned the last programming language they'll ever need."

And if they don't get so exposed, they become Blub programmers, where generally $Blub is some industry-leading language that does enough you don't easily bump up against tasks that are near impossible in it.

To tie this back in with a point I think the author missed, I suspect that some of the difficulties with Basic are actually part of the reason why it didn't end up ruining more programmers. Almost everybody who really came to grips with it as a tool probably realized that it couldn't possibly be the last programming language you'd ever need (if it weren't enough that any effort to look into working as a programmer revealed that Basic was clearly not the strongest payroll ticket).

Better than nothing

[kainosnous]

When I was first learning to "program" I had nothing more than an old computer with DOS. The internet was something I had heard about, but had never experienced myself, and I didn't know what Linux or even Unix was. The only way I had to learn was from some books I found at the library. At first, it was just .bat files. When I discovered BASIC (I thing it was GW BASIC), I was excited to have it. Later, I discovered QB.

There are some advantages. First, I didn't have to set anything up or worry about what includes I needed. A simple PRINT "Hello word" was enough. What was better with QB was that with the press of F1 I could browse the list of commands. Also, it came with a Gorillas.bas and Nibbles.bas. I spent hours injecting lines of code into those games.

Sure, if you have a full Linux environment with gcc, man pages, and web access then BASIC is just some lame toy, but if it's all you have It's a start.

Re:Better than nothing

[vikingpower]

Yup. I'll always remember my first line of code. Some geeks on my high school were excited about writing games on a Commodore, that loaded its BASIC code from a tape recorder. I thought "mwah, so what". Until I discovered the PEEK and POKE commands. I was sold forever to computer programming.

Re:Better than nothing

[RAMMS EIN]

``Sure, if you have a full Linux environment with gcc, man pages, and web access then BASIC is just some lame toy, but if it's all you have It's a start.''

Yes.

And, frankly, I would rather not teach someone their first programming steps using C on Linux. For a first language, I want them to have to learn as few concepts as possible before they can do something. Include files, the whole boilerplate for main, pointers, and the edit-compile-test cycle are just too much. I want them to be able to type in a single line and have it work.

At the next step up, I think I would prefer a language without too much magic happening behind the scenes. Automatic memory management is wonderful, but I want my hypothetical programming students to realize that everything has a cost, and objects don't just come out of nowhere and go away when you don't need them anymore. The same applies to a lot of other things, even function calls and the humble "i = i + 1".

Considering the above two things, it looks like my students would learn at least one reasonably high-level, but, more importantly, interactive language, and at least some sort of assembly language. The first, to get into programming at all, and the second to really understand what is happening inside the computer.

After that, it would be the bread and butter of programming: abstractions, abstractions, abstractions. Unless you are unfortunate enough to code for an assembler with no macro support, or a language like the original COBOL, you will write your program by taking what the language gives you and using it to create abstractions that fit the problem you are solving. This is where you create your functions, your macros, your data structures, your objects, your rules, and any other abstraction you may need so that the tools you have fit the problem space. In the process, you will come across the various programming paradigms: structured programming, object-oriented programming, functional programming, declarative programming, etc. I think this should ideally be done using a language in which all the concepts can be expressed. Unfortunately, few languages can do this well.

Once you reach this stage, you know a lot of things that will come in useful in programming in general, but there is still a lot left to learn. You will need to learn the specifics and the libraries of the languages you will be using. For example, if you are going to program in C, you will need to understand pointers and dereferencing. You will need to learn common pitfalls and how to avoid them. Concurrency should be a big item here. You will have to learn how to write maintainable code. You will have to learn about efficiency - how to write efficient code, but, more importantly, how to spend your time efficiently.

And that's just for programming. To be a good programmer, you will also have to learn related disciplines, such as design, documentation, communication, and version control.

But the first step is that first program. Nobody will ever succeed in climbing the mountain without taking the first step. And if we want people to climb the mountain, that first step had better be easy.

In my opinion, the old BASICs, with line numbers and gotos, aren't half bad for the first step. They are easy to get started with and yet pretty close to the fundamentals of your computer. I would be interested in hearing better suggestions, though. Especially since they may help avoid the risk of people who never made it past the first step writing serious projects in BASIC...

As for me, I started with IBM BASIC (first step), then did x86 assembly (fundamentals), then C (because people told me that's what real programmers use) and PHP because I had to use it at work, then Java (because the propaganda convinced me that it was the Messiah among programming languages), and then I realized I shouldn't just listen to other people, but also do my own research and draw my own conclusions. Since then, I have learned many programming languages just to learn about the concepts i

BBC BASIC

[tomalpha]

I cut my teeth on BBC BASIC back in the 80's. It was simple, powerful, let you do pretty much anything and best of all came with a built in assembler. Now that was really neat.And it just worked. It was easy to optimise individual subroutines in assembler. This was age 10. At my simple state school with a couple of BBC Model Bs in the corner, I wasn't the only one doing that either.

I make a living writing C++ now and seem to do fairly well at it. The kids coming out of university that I interview these days haven't touched BASIC, or C++ for that matter. We want them to write good C++ when they come and work for us. The intelligent ones adapt easily to working with pointers etc. The less able ones that have somehow made it through the interview process struggle.

Re:BBC BASIC

[Richard Russell]

I was disappointed to see you refer to BBC BASIC in the past tense, when it's still used today and still has the neat features such as a built-in assembler. In fact the latest version of BBC BASIC for Windows was released at the beginning of this year. There's a list of some of the more interesting and surprising applications of BBC BASIC over the last 28 years or so at http://www.bbcbasic.co.uk/bbcbasic/birthday/

Not Basic, but restrictions

[s-whs]

The Reinvigorated Programmer argues that the world is full of excellent programmers who cut their teeth on BASIC, and suggests it could even be because they started out with BASIC."

Bullshit. You know what may be a reason? The extreme restrictions. In the 80s I used a fairly good Basic, BBC Basic, but I mostly used 6502 assembler. This on a machine with very limited memory. What that does is cause you to do things as efficiently as possible, it makes you think how to best represent the data in memory etc. In german there's a saying: In der Beschraenkung zeigt sich der Meister" (which translates loosely to "given restrictions, the expert will show himself to be an expert") but I think even better would be "In der Beschraenkung bildet sich der Meister", i.e. given limitations you will become an expert at various problems.

In literature there are similar situations. Limits of form/rhyme may instead of restrict a writer, actually make him write better material...

But back to Basic: The limitations in there (the early 1980s and some later versions) are mostly not helping one to become an expert. They just annoy. What I clearly feel and which is what Dijkstra probably refers to (as it may be a strong effect in some programmers) is that I know how to do something directly, and thus the minimalist urge is there to write something different to using the features of the language you're using because for example you may think that would be less efficient.

Re:Not Basic, but restrictions

[s-whs]

Bullshit. You know what may be a reason? The extreme restrictions.

Just to clarify: I obviously mean the restrictions in general, not in Basic. All languages on the 1980s computers had severe limitations. And the 8 bit machines had severe limitations in speed and memory. To make a good program that was fast and that fit into memory was always hard work...

What Dijkstra meant was:

[Anonymous Coward]

What I (like to) think Dijkstra meant, when he issued his famous quote, was probably a lot more like:

"Programmers who learned BASIC first can't really be coaxed away from thinking that all languages should be as easy as this."

Trying to convince a BASIC programmer that they should understand CPU Instructions, Registers, or hell, even pointers, or why you should end a statement with a semicolon, is hard to teach a programmer for whom UP UNTIL NOW, THE COMPILER (or runtime) DID IT FOR THEM.

Anything else seems like a step backwards. And hence, they do not respect the more elementary languages. "Really," they think, "is it so hard for the compiler to manage my memory allocation for me, when my $400 1978 micro can do it when I program it in BASIC?"

A well-educated programmer has since learned that programming is, in essence, understanding how to get the machine to perform a task; and, that, while there are different ways of asking, only a certain exact way will ultimately be understood by the machine. And you might as well know the exact way, since any problems will be related to that exact instruction (or lack thereof), and it is also obviously optimal in terms of effort (both for you, and the machine).

Dijkstra was commenting more on how children who learned to program on simple BASIC micros didn't usually grasp the new expectations of the compilers when they were writing for things such as mainframes. But, on the other hand, why DO you have to manage your own memory, still? The imperious little bastards who refused to learn anything that requires them to know more about the machine than BASIC required, well, they did have a point. In fact, in many more modern languages - like the recent Google Go - you mostly don't have to concern yourself with things like memory allocation.

Dijkstra was right, but he was also wrong.

Hey, I know..

[Anonymous Coward]

I know spaghetti code, but then again I am mentally mutilated by Brainfuck2D.

I'd have to agree

[JumpDrive]

I've seen to many programmers who get way over there head with Visual Basic and think they are ready to jump into more powerful programs.

I think I see a representation of what he was talking about a lot. Even here I see it in the responses. "I wanted to draw a circle on the screen. So I figured out how to do it in BASIC and I did." and they kept on with this attitude, never considering what the memory issues are and communication issues. So they right code on 16GB RAM with the RAID 0 15000 RPM SCSI with the latest 3.x CPU's and look like dear in headlights when they have their resulting code bomb on a 1.7 GHz processor with 2GB of ram.

I simplify, but from where I sit that's what it looks like to me.
Don't get me started on stuff I've seen come out of LabView. (You mean there's a limitation on a Southbridge?).

The Language is Irrelevant

[Degro]

I found programming by learning Basic in a high-school programming class. Anyone that was so affected by the first language they were introduced to had some preexisting conditions I'd say... If a person only has the capacity to think in terms of the tool currently in their hands then forget about it. I quickly moved on to C and Linux in my teens when Basic didn't support what I wanted to do and my empty wallet didn't support Borland or Visual Studio. So yeah, thank you BASIC, public libraries and Linux.

BASIC was great at the time.

[Sarusa]

I did Apple and C64 BASIC (and 6502 assembly language) to death back in the day. You really can't get more 'oh no, gotos everywhere!' than those, but I seem to have survived it. Of course I realized the fragility that GOTOs and JMPs engendered. The key thing is that it nurtured my love for programming because it was so easy to slap things together. Now of course, I can see where it had flaws, but what was I going to use Back in the Day? Pascal? Please, I learned it. But Wirth and Dijkstra's beloved Pascal, while great in theory, was in practice crap for making neat stuff with the minimum amount of effort compared to BASIC + 6502 ASM. If you wanted to do the REAL stuff in Pascal instead of just masturbating for your professor you had to learn the pcode interpreted byte code stuff, which was just fancy assembly language (though it was neat as a precursor of modern VMs). I could (and did!) churn out an entire game in AppleSoft BASIC while the UCSD pascal system was chonking away on the floppy drive editing or compiling or whatever, and god help you if you didn't have two floppy drives. Meanwhile BASIC would happily run with just a tape drive or /nothing at all/. She was an easy whore but things got done. These days I use Python with the added advantage that I think it's the most maintainable language even if it doesn't have the purity of something like Scheme, but none of those were an option at the time.

So yeah, spaghetti code is bad, but I think any decent programmer learns that sooner or later anyhow. If BASIC got you going, more power to you.

More to the point, is coddling uninterested putzes with Java's strait jacketed purity so they can churn out more utter crap really a better alternative than BASIC's trial of fire? Because that's our current go-to plan. I apologize in advance to those excellent Java programmers I know who can really make Java sing, but you, even more than me, already hate that most of the people using Java are FactoryFactoryFactoryAbstractFactoryTools. Far better to flush them out earlier.

Re:BASIC is irrelevant

[Ambiguous Puzuma]

Maybe C and C++ aren't common for introductory programming courses anymore, but they used to be for a time. About 10 years ago:

I took an introductory C programming "class" as part of the Columbia University Science Honors Program for high school students. It was the only programming course offered.
The Computer Science Advanced Placement exam switched from Pascal to C++.
At Rensselaer Polytechnic Institute, Computer Science I and II were taught in C++.

structures? pah!

[Anonymous Coward]

While there are no doubt some great programmers using structured languages, let us all not forget those great programmers who work with their own structures and only have global variables and labels are a luxury of the compiler , and where gosub is but a pipedream -- BASIC the training ground for assembly language maybe?

Actually, CS dept is kind of mentally mutilated

[j1976]

Yeah... I wrote my first commodore 64 basic program when I was 10, and now I'm about to finish a phd in computer science.

Either C64 basic wasn't all that dangerous to one's mental health, or maybe it isn't a problem to be "mentally mutilated beyond hope" when working within academia.

Hrm. Actually, when thinking that last part of the statement through, it does seem like a rather fitting description of both me and my colleagues. I just never knew it was because we had programmed basic.

Re:Actually, CS dept is kind of mentally mutilated

[Anonymous Coward]

The good thing about C64 basic was that it was so limited and slow. Most of the advanced functions such as sprites or sound were performed by directly manipulating the memory addresses using the POKE command, so when it came to learn assembler you were half way there already, and to do anything fast you really needed to use assembler anyway.

I taught myself programming at home on the Sinclair ZX81 using the horrid BASIC keyword entry, and practised at school on BBC microcomputers in BBC BASIC. When I got my C64 I programmed some stuff in Commodore BASIC, but then taught myself 6502 assembler. If it weren't for BASIC I wouldn't have the job I have today.

TCL/TK

[Colin Smith]

it really doesn't doesn't get much simpler. Even shell and batch scripting is more complex.

The base language can be described in a couple pf pages, it works great for functional, oo and imperative programming. It's also trivially simple to learn.

The main problem is a lack of an easy to use code repository & plugin modules.

Re:TCL/TK

[dkf]

The main problem is a lack of an easy to use code repository & plugin modules.

I use ActiveState's repository, which has loads of packages ready to use and easy to install. It's only really on Linux where this is an issue, because each distro has its own repository of everything (and it's usually not that well maintained either).

Re:BASIC is irrelevant

[Eraesr]

At college we started off in Pascal but quickly moved on to C and a bit of Java. I'd say that if anyone is considering BASIC as a first language, they should choose Pascal instead. But to be completely honest, these days OO programming has become so important that it's probably better to start off in Java or C# from the start.

Ever see BBC Basic?

[serviscope_minor]

The BBC Model B was released in 1981. It had a nice dialect of basic with named procedures, named functions, dynamic memory allocation, typed variables, proper pointer indirection and a cleverly integrated assembler.

It had pretty much the full suite of structured programming tools.

Maybe the comment had some value before 1981, though I don't think it did. For the last 29 years, however it has been somewhat out of date.

Re:Ever see BBC Basic?

[itsdapead]

Maybe the comment had some value before 1981, though I don't think it did.

Except the BBC Micro never really made it out of the Commonwealth, so the rest of the world pretty much had to wait another 10 years for Visual BASIC to appear.

VisualBasic would like to disagree

[the_raptor]

Anyone who remembers when VisualBasic was heavily used knows BASIC doesn't teach people to be better programs. Even C or any other "good" functional language doesn't teach you what not to do. As the saying goes C++ will not only let you shoot yourself in the foot it will load the gun and cock it. I don't think you even realise most of the major programming pitfalls until you have done a major project or gone back years later to maintain your own code (and spent more time trying to figure out your logic than it took you to write it in the first place). I started off with BASIC* (on Win 3.1 machines) but that was only because it was the only programming language that nearly every computer had. These days there are so many easier, more powerful, and just plain better "teaching" languages and toolkits.

If you just want to teach a kids the real raw mechanics of what a computer does let them lose with an ASM-like language and a simple CPU simulator (there are various robot simulators out there, or you could even invest in a real robotics platform). If you want them to learn to program there are much better tools out there to achieve that than BASIC.

* And only learned how to really program when I got my hands on Pascal.

Re:BASIC is irrelevant

[slashsloth]

Here in Ireland (NUI, Galway) C has been used as the first / introduction to programming language for a long time now. There was a brief & failed effort to use Java; I had the "pleasure" of trying to tutor some of the people who had started on Java -- they were a confused bunch. Of course there are plenty of people who fail to "get it" with C too.

Started with BASIC, sure...

[Alien1024]

The world is full of excellent programmers who cut their teeth on BASIC

Because it was the language that came preloaded in the ROM of so many home computers back in the early 80's.
I cherish memories of the time I started programming in Speccy BASIC, at a single-digit age. I got to love programming on that machine. But I do not think it's any good for a beginner.
The point that the author makes, that "the horribleness of BASIC was its virtue. It forced us to think around corners. It made us think through what the control structures really were, and how they were implemented." is moot - assuming he's not joking, if you really want to train that way of thinking, you're much better off learning Assembler.

Re:Started with BASIC, sure...

[Rockoon]

It forced us to think around corners. It made us think through what the control structures really were, and how they were implemented." is moot - assuming he's not joking, if you really want to train that way of thinking, you're much better off learning Assembler.

Most of the experienced assembly programmers I know started with an old-school basic (gw-basic, basica, one of the rom basics) and today also program in a BASIC derivative (VB, PowerBasic, TrueBasic, etc..)

None of them enjoy C++.

I often hear C++ programmers declare that learning assembly is stupid, that processor are too complicated now to write efficient assembly, and so on.

I do not think that these things are a coincidence. Basic programmers from the 70's and 80's turned into tinkerers, while C programmers from the 70's and 80's turn into architects. Its counter-intuitive when you first think about it, but it seems to be the truth. That Basic programmer had a lot of architecture done for him but had to struggle to tinker, while that C programmer had tinkering handed to him by the language but had to struggle with his own architecture. Each eventually masters what is difficult on the field they play in, while taking for granted that which is easy.

Regardless of the target language, if I need a project lead for a large application I would want a good solid architect, but if I want a library written (perhaps even for that large project) then I would want that heavily experienced tinkerer on the job.

Re:Started with BASIC, sure...

[Chatterton]

I started with the Sinclair ZX-81 Basic. Quickly followed with the Z80 Assembler on the same machine due to memory constrains (1KB and 16KB later). Years later I got my first 8086 PC (Tandy 1000 SX) with QBasic. I moved quickly to Turbo Pascal and then again Assembler due to the easy in-lining in Turbo Pascal. Got to program in Assembler for the 286, 386, 486 and it was easy, fun to extract the last drop of power of these chips. I have learn some other assembly languages 6502, 68000, IBM360. Assembly language make me learn how computers work, Make me go deeper in the rabbit hole and learned how a processor worked and communicated with the memory / other chips letting me add a 2nd KB of memory to my ZX-81 with a cutter, some wires and an bunch of chips. All of this make me more conscious of how a program really worked and how high level construct were really executed on the processor level making greatly more easier to learn new languages.

Now I barely touch assembly for processors like the Core I7, Athlon X2 64 & al. Not due to the complexity of the assembly language who keep being 'easy', but due to the extreme complexity of these processors. When you put together the number of instructions executed in the same cycle, the deep of the instruction pipeline, the heuristic branch prediction, some out of order execution,.. all the tricks a modern processor use make it very very hard to beat for example the intel C compiler with your own hand crafted assembly.

As for your C++ programmers: Learning assembly is NOT stupid but it is true that recent / last generation processors are too complicated to write efficient assembly.

Re:Started with BASIC, sure...

[hazah]

I will admit to being a self proclaimed C++ enthusiast. But I've never gotten that sense from professional C++ enthusiasts. (I'm speaking about people who enjoy the feel of C++ not the people who have to use it because of some external influence and would jump ship if they could). The sense I did get though is that the farther you are on the learning curve of the language, the more you start thinking in terms of "code generation" (realized by template meta programming techniques). The best parallel I found for this in the C community is the lex/yacc code generators. I think this happens because often there are better ways to express the problem domain than the traditioal "step by step, this is how the computer will do it" way of general programming languages such as C. C++ just takes this mode of thinking a step further by providing the tools necessary to augment generating C type code.

Re:Started with BASIC, sure...

[Rockoon]

Now I barely touch assembly for processors like the Core I7, Athlon X2 64 & al. Not due to the complexity of the assembly language who keep being 'easy', but due to the extreme complexity of these processors. When you put together the number of instructions executed in the same cycle, the deep of the instruction pipeline, the heuristic branch prediction, some out of order execution,.. all the tricks a modern processor use make it very very hard to beat for example the intel C compiler with your own hand crafted assembly.

The Core line of processors are much simpler than the end of the Pentium line. Its really not that difficult to understand what the processor is doing (its not magic, its reasonable steps), and in fact men like Agner Fog have made it easy for you to become informed. The AMD64 line is also pretty simply.

I agree that ICC is very good. Its clearly the best C compiler on the planet, but its still not outstanding. Thats why people who specialize in optimization can still carry large salaries. Its true that there isnt a large market for optimization experts, but the market that is there desperately needs them.

GIGO not GOTO

[SteveAstro]

Admittedly, it may take some application, but you can write crap in any programming language, and you can write structured BASIC programs. You need to have been introduced to the technique that's all.

There seem to be VERY few assembly language programmers here pointing out that underpinning ALL our oh-so-elegant programming languages is one of JMP $ LCALL and RET.

Steve

It doesn't matter what you start with ...

[petes_PoV]

... just so long as you start.

OK, BASIC might not be the prettiest language in the world and it has some features which make it hard to maintain IN A PROFESSIONAL ENVIRONMENT. However, for kids playing at home wDijkstrahere the half-life of a piece of code is measured in days, it provides an easy entry with a smallish learning curve. Just like you start off playing with Meccano, you aren't expected to become a professional engineer and build bridges from it (though it has been done) but it does let people develop a love of engineering.

I have read a lot of Dijkstra's work. He's basically an academic who's writing is intended to impress other academics with it's insight, theoretical accuracy and idealism. As a practical basis for doing real-world projects, it falls a long way short.

Re:BASIC is irrelevant

[slashsloth]

Surely Python is the language to start with these days? It's straightforward, doesn't force any particular model, i.e., can use for procedural, OOP, functional style. Most importantly it's not a toy language.

Yes and No

[gaelfx]

We can argue 'til we're blue in the face about what the best first language to learn is, but the simple fact of the matter is that it doesn't matter as much as we want it to. Even the second language we learn doesn't really matter that much. What matters is the transition from the first to the second language, assuming they're different enough to really consider the second language a different language (I would argue that going from C to C++ is not significant enough a change to be considered as a "second language"). If it goes smoothly, you've got a capable coder on your hands. If it takes more than a few tries to write "Hello World!" in the new language, chances are you have someone destined to be befuddled by any kind of more advanced programming methods. Granted, there are several factors that go into the significance of the transition, not the leas of which is time and depth spent coding in the first language, but those are issues are part of a much bigger pedagogical discussion than this. And no, I didn't RTFA.

Re:BASIC is irrelevant

[mrsurb]

Again, around ten years ago (1998) we learnt C++ in first-year computer science at the University of Wollongong. Second year branched out into java and assembler, but I was a physics major so didn't go that far.

Re:BASIC is irrelevant

[geminidomino]

What intro-level courses use C or C++?

Florida State University -- COP3330, "Intro to Computer Programming". 100% C++

Re:BASIC is irrelevant

[Z00L00K]

It's not necessarily a bad thing to have done things in BASIC, but bad habits can be formed by that language. However the other side of it is that if you first see the bad sides of BASIC then you can recognize the good sides of other languages.

And BASIC of today is Python.

Re:BASIC is irrelevant

[atisss]

Oh really? And university students should have no prior knowledge to programming? We have full universities of such students, they get degree and go working for some brainless company doing minor tasks.. Or they could continue study until they are 40, then they will probably be able to code.

I started at 12, and BASIC gave me some idea of how computer is actually working. Probably it's time for new languages, but You just can't learn programming at college in few years. You have to grow up with that.

Remember the age in which he wrote this

[epo001]

When Dijkstra wrote that, kids did not have access to computers. Any child has the flexibility to learn the, ahem, basics from BASIC and move on after discarding it.

Adults, on the other hand, tend to stick with what they first picked up on. Look at how badly most (non-techy) people use modern GUI-based systems, sticking rigidly to the few things they have picked up over the years.

This thread has lots of people who learned to program BASIC as a kid and then moved on, they think their experience invalidates Dijkstra, it does not, it reinforces it. Dijkstra was spot on, except as a training language for children BASIC is harmful.

Azijnpisser...

[2fuf]

...is the Dutch word for what I think of Dijkstra. He's overly negative is his opinions only to impress others and to let off steam built up by his personal frustrations. Besides his wonderful contributions to CS, he was mainly just a grumpy old man who's opinions have been grossly overrated. The gems of his work are in his scientific contributions, not in his tantrums.

It's not where you start, it's where you're headed

[Trerro]

-Can you warp your head around coding logic?
-Can you avoid chaining yourself to a specific language, and instead choose one that works well for what you're trying to do, rather than force one to work outside of its intended scope?
-Can you handle both procedural code and OOP, and are you aware of the pros and cons of each?
-Can you write code others (not to mention you a month later!) can actually read?
-Are you willing to take the time to truly learn programming, rather than just copy-pasting a few functions and hoping it works?
-When you learn a language, are you willing to actually learn the language, and not just make it behave like one you already know?
-Are you aware that debugging often takes longer than actually coding, and are you willing to put that effort in for the sake of quality code?

If you answered yes to all of the above, you're probably going to be a pretty good programmer, whether you started on C/C++, Assembly, BASIC, or hell, ZZT-OOP. Every language has places it really shines, and every language has glaring flaws - if there was a prefect language that was good at everything, we wouldn't need a few dozen of them. :)

I learned with basic as a young man.

[Anonymous Coward]

http://en.wikipedia.org/wiki/Simons%27_BASIC Simons basic had actual procedures and loops It also had very powerful access to graphics, sound, and input devices.

One of my earlier programs was one that mapped out the frequency response of a bass speaker and enclosure, complete with graph.

Re:BASIC is irrelevant

[fredrik70]

I started in school with Ada (the horror!) thought this programming thing was not for me. then we went on to c, and I saw the light....

Having said that, I do mostly c# and python nowadays and I DID start with Basic (on the Apple II) by myself before getting to the programming classes in school

Laziness motivates learning better programming

[dugeen]

With the old 80s BASICs you had a lot of work on your hands to organise a program. You had to note down line numbers of subroutines and be disciplined in choice of variable names so as not to create unwanted side-effects. As more structured languages came along, this effort was no longer necessary - I was happy to learn Pascal, then C and C# because of the possibility of less typing, less notemaking and less headscratching.

Re:BASIC is irrelevant

[barrkel]

On error resume next didn't exist in MS Basic for microcomputers, of which the author of the article speaks. It wasn't anything goes in terms of variants either - variables had types, indicated by suffix (!, % or $).

It was more like programming in type-safe assembly language, but without an argument stack.

Re:BASIC is irrelevant

[dakameleon]

When was anyone introducing languages to students at 13? There's bound to be a significant chunk of us out there who poked around our computers and went to find these things out ourselves. BASIC just kinda sold itself with the name - you knew it was a good starting point. Self-discovery and a curious mind is probably outdated in the corporatised world, in spite of the roots of many of us who learnt by screwing up an autoexec.bat file or two on Dad's computer. Nothing teaches you to pre-check your logic than having to explain to Dad why his computer doesn't work any more :)

Without a doubt BBC BASIC helped me

[jabjoe]

BBC BASIC was my first language. On the Acorn, many things where BBC BASIC, with ARM assembler sprinkled in at bottle necks. Me and a few friends taught ourselves (we shared things we found, and played each other's games). I remember not knowing about procedures/functions. For a few years I wrote everything with GOTOs. Finding out about procs was a revelation I still remember. I look back at the code from my childhood with a certain pride, despite the horror of it. All the variables had shortened names because it made things run faster. Everything was fixed point and logical shifts instead of devides. It is tangled and nasty, but it runs, and being the games is done in BBC BASIC, fast. (SWI for sprite rendering helped!) I do wish someone had got me started on C earlier, didn't set up RiscOS to compile C until I was 19, but there was no one until I was able to do it myself. Setting up gcc on RiscOS had a bit of reputation for being hard, older friends had failed. But once I was up and running, I wrote a C software 3D engine demo thingy, dropped out of uni (stupid multimedia course), moved myself to Windows, C++ and OpenGL, got a job speeding up a startup's 3D engine (which was like a lesson on how not to do 3D), and never looked back. I owe my working life to having BBC BASIC as a child. As a kid in the 80s/90s, you couldn't ask for a better start than BBC BASIC on the Acorn, you could knock together fast enough games to be worth doing. The modern day equivalent I guess would be python and pyGame.

Re:Without a doubt BBC BASIC helped me

[Richard Russell]

As a kid in the 80s/90s, you couldn't ask for a better start than BBC BASIC on the Acorn, you could knock together fast enough games to be worth doing. The modern day equivalent I guess would be python and pyGame.

Or, dare I suggest, BBC BASIC! You can find some nice examples of games written in 'BBC BASIC for Windows' at http://www.bb4w-games.com/

Evolution

[ledow]

Like all things, you can't give a blanket statement here. Yes, there will be some people who "learned" BASIC when they were young and now, when they are let loose on an Excel macro in work, will pine for line numbers and GOTO's. But they would have done that no matter what they learned. However, there's also a damn lot of people who moved on from BASIC very quickly but still have a fond association with it because of their history and because of the simplicity of some tasks in BASIC (of course, a lot of things are more complex but depending on your project you can still "win" on speed using BASIC). If I was to "invent" my own programming language, there are features from just about every language I've ever used that I'd want to be incorporated. Even BASIC has some things that I'd want to include, or that have been copied into lots of other languages.

I think BASIC was an introduction - a way to hide the complexities, to say "don't worry about memory management and data structures just yet, let's learn half-way to being able to program so you can get interested and have some fun quickly". And then when you did that, it was *so* much easier to move to other languages. Of course you still had to learn and change habits - but that's the point of learning. People who drove a moped when they were 17 don't go on to drive a car and keep twisting the indicator stalks to change gear or accelerate.

But BASIC only corrupted those who were corruptible - those who didn't *care* how the computer allocated memory or whether the program was efficient or readable were bound to carry on not caring in other languages. And those people, by definition, would have been like that in any language and probably *never* go on to learn any other.

My dad bought me a ZX Spectrum in 1987 or thereabouts. I was 8. Within the first week I was trying to figure out how to program in BASIC (by the help of that orange-spiral-bound BASIC manual that came with it - damn that should be a compulsory item with all new computers). Without that book being included, I'd probably now only know how to 'LOAD ""' and my life would be very different. If that had been any of the C books that I've ever read, I would have thrown it in the bin immediately. Within a year (in between playing games, school, and pulling girls' hair), I was a pretty proficient BASIC programmer. It helped that I was also doing things like typing in listings from magazines (an early form of Open Source that will forever be sadly missed) and trying to understand Z80 assembly. By the time I got to secondary school (age 11), I was writing games for fun for my friends. I wrote a No-CD crack for Desert Strike when it first come out on PC, I was 13, and was incredibly proud of my first use of x86 assembly / Ralf Brown's Interrupt List - I never distributed it to anyone else but it's still sitting around on my machine somewhere. I did it using DOS "debug" and a hell of a lot of manual path-following and single-stepping through the code. Around the same time, I wrote a program for Windows 3.11 that prevented execution of programs with certain signatures / hashes / paths that integrated into the school's Novell network and was so damn good that even the network administrator (an old-school IT guy) couldn't bypass it on the test accounts. He seriously considered deploying it to help curb a spate of students running programs via Word macros, DOS command prompts and other clever tricks (I never had the heart to tell him how they were doing it, who had taught them that, or why I felt so guilty that I had to counter-act all those methods for him...)

By the time I got to Year 11 (age 15), I was programming on my TI-85 in the back of the class (and sharing those games / programs with the rest of my class) and writing "toy" operating systems for my PC. I was receiving email from Canada (a massive thing at that time) telling me how good my games were, and I was dabbling in everything I could find: C, Pascal, FORTRAN, assembly and even things like DOS Batch scripting and

FORTRAN

[kiddailey]

Personally, I think I was far more mentally mutilated from my semester of FORTRAN77 than from any form of BASIC. /shudders

Re:BASIC is irrelevant

[awshidahak]

Fundamentals of Programming CPTR-124 -- Southern Adventist University That one uses C++.

Value of BASIC right now = 0

[Anonymous Coward]

There are plenty of scripting languages right now - use one of them. What is it with all this archaic non-c love?

Re:BASIC is irrelevant

[Anonymous Coward]

Python is actually a really nice language, its only pitfall is that it considers whitespace significant.

BBC BASIC != old-school BASIC

[itsdapead]

I cut my teeth on BBC BASIC back in the 80's.

The comments of Dijkstra et. al. really relate to the original Dartmouth BASIC, Apple BASIC or the early Microsoft BASIC that you'd see on CP/M, PETs and TRS-80s.

BBC BASIC was partly designed to address those very criticisms (since the BBC Micro project was primarily educational) with a wider variety of loops, named procedures and functions etc. and could be used to write reasonably structured code. (It was also very, very fast!).

There was nothing really like BBC BASIC for years, until Visual BASIC started to take off.

Re:BASIC is irrelevant

[slpalmer]

> When was anyone introducing languages to students at 13?

Actually, that's about the age I started learning 6502 assembly on my KIM-1.

Re:BASIC is irrelevant

[Nerdfest]

When programming in Java, I still resist breaking out of loops, or multiple returns, even in small methods. These things seem to be normal acceptable practice with most developers, and really are fine when used in the right places. Because of early exposure to BASIC (and badly written C) I avoid them more than most.

I think the BASIC of today is Javascript. You see more badly written javascript than any other language..

Point taken, but...

[Moraelin]

Well it IS done with jump instructions, but as few as possible because the branch penalty is usually high (especially on an x86). If you don't use the goto statement then your program is more abstract, and structures like loops can be more easily optimised by the compiler to use as few branches as possible. Not to mention things architecture-specific like ARM's condition codes which can turn a loop with multiple if-else statements into a block of code with only one branch instruction.

Point taken, but in my experience people who have even marginal idea of what happens under the covers, tend to write better code than those for whom the underlying machine is a complete mystery. I'm not talking premature optimization, but merely knowing in the back of your head what a pointer is, or _why_ this operation is O(log n) and better thus than O(n), can save one from a lot of awfully wrong guesses and writing awful code.

My canonical example is a team whose architect (!) finally read somewhere that when passing an object to a Java method, only the pointer is passed on the string. So he actually decreed -- and none of the lemmings knew better -- that they should use parameters like the wrapper object Integer instead of the primitive int. (We're also talking Java 1.3 times, so no automatic boxing/unboxing either.) Because, I quote, "If you use Integer Java copies only a pointer to it, not the whole int."

Maybe knowing how much space an int takes under the covers would have helped.

Another time I hear my now ex-coleague Wally (not the real name, but pretty accurate;)) repeatedly going, "That can't be true!" and the like. Curiosity gets the better of me and I ask what's the problem.

"Java has a bug!" he goes, "I put a new key/value with the same hash code in a HashMap and it just replaced my old value!"

"Oh, yeah, we've had the same bug at the old company, " Wally 2 chimes in. "We had to manually set the capacity so it goes in another bucket."

(I clench my teeth to avoid screaming at the notion that there's any way to the right capacity to avoid collisions for keys that are random strings.)

I go and look at what he's doing, and sure enough he's got the debugger open and is looking at the bucket array of a HashMap. "Look! There! I had a different value and it replaced it!"

"Aha, " I try to be diplomatic, "can you please expand that 'next' variable there?"

"No, you don't understand! My value was there and now it replaced it!"

"Yes, I get it. But I want to see what's in that 'next' variable."

He clicks and goes, "Oh... there it is."

The whole concept of a linked list was new to him, obviously.

And if you think that's an isolated case, in the meantime I've run into two different teams whose "architect" actually made it mandatory to plaster his broken replacement for the hash-code method everywhere, because of that supposed "bug in Java." Supposedly they can hash a long-ish random String into a 32 bit int without ever having collisions. (Ok, 31 since Java doesn't use the sign.) Consulting can be depressing business, you know?

I could go on with more such WTF examples, but basically let's just say I wish more people would know exactly what happens behind those high level constructs and libraries. Because otherwise I see them take their own guesses anyway, and guessing wrong. I wish they'd know what a pointer really means, and why a LinkedList does _not_ use less memory than an ArrayList, and, yes, what kind of things will cause jumps. Or what kind of things will be optimized into a tail recursion instead of a plain recursion, as a trivial example of where it pays to know the difference between a JUMP and a bunch of PUSHes and CALL generated by the compiler.

Re:Point taken, but...

[erroneus]

Now THAT is a point I wished I was able to muster out of my brain at 2 to 3am this morning. I tried to say it, but it didn't come out as well.

I also made comments about mixing code and data together, but my point was that object oriented code tends to remove people from understanding the machine. Apparently, I have never learned a "real" programming language. (Hint: it all goes down to assembly and then machine language anyway!) Having an appreciation and even direct knowledge for how the machine does things will certainly affect how you approach coding. If you don't, you will start seeing some very confused people as described above.

But I guess my rant was mostly about memory usage, input data validation and ensuring that bad data doesn't go out. Many of these things are considered to be "automatic" by some coders. Recently I was involved with a contractor group who wanted to use wildcard characters other than * and ? because the SQL server they were writing to uses something else. Seriously?! I sensed SQL injection in 5, 4, 3, .... I insisted that they code for the user and the business process, not for the underlying architecture or back-end processing.

Re:Point taken, but...

[CptPicard]

A lot of those things don't really require an assembly-level knowledge of things. Understanding the complexity classes of your algorithms is perfectly doable without any kind of low-level understanding, so is managing the concept of linked lists, hashes, other data structures... pointers are essentially just an indirect reference type. Why tail calls are optimizable is clear from languages like Scheme already.

I'm not saying low-level understanding is useless, but it certainly overrated.

Re:Point taken, but...

[Hurricane78]

I wish more people would know exactly what happens behind those high level constructs and libraries.

Well, as my physics teacher once said: You can use the calculator, as soon as you know how to do it by hand, and understand why you are doing what you are doing.
I instantly realized that you can generalize this to pretty much everything. Especially using computers in general.

And since I love to understand things anyway, that’s what I do. :)

Re:Point taken, but...

[Hurricane78]

That’s a part of the beauty of Haskell. Your low level is called “math”. :)

Re:Point taken, but...

[CptPicard]

Yeah, I know. I'm more of a lisper though, but same thing.

Re:Point taken, but...

[Anonymous Coward]

and I just wish people would understand Java has references, not pointers... //Programming Nazi

Re:Point taken, but...

[Sax Maniac]

I love this 2-Wally story, but it sounds familiar. If that was you posting it before here on /, bravo, submit it to the daily WTF!

Re:Point taken, but...

[Requiem18th]

I understand your point but ---in the spirit of these kinds of stories--
The REAL WTF is that they are using random strings as keys for hashes. That hardly ever makes a good design as there are always better strings to use for keys like a date or an auto-incremental number or anything.

If you really have no idea what to call the key now what makes you think you are going to know later?
even if you operate between different instances of the program and thus you can't use a date, you could just concat the hostname and date or such.

IMHO not knowing the underlying implementation of library functions and objects is less problematic than not knowing how to use them to build a sane architecture..

Re:Point taken, but...

[Moraelin]

Yeah, I've posted it before.

Re:Point taken, but...

[hrimhari]

I'm pretty sure I've read this story before. Where was it..? Ah, here it is!

Re:Point taken, but...

[Anonymous Coward]

I once worked on a project that had brought in a bunch of Accenture contractors. One day, one of them that sat near me blurted out "Stack overflow?!?". I told him he had a recursive function that wasn't ending. He had no idea what I was talking about. A little bit of understanding about stacks, function calls, and recursion would have prevented me having to launch into a CS 101 lecture.

Re:Point taken, but...

[Anonymous Coward]

On the other hand, if you give the "Wally"s of the world all that info, they'll spend the rest of eternity trying to optimize the number of loads and stores done by an one-time initialization routine in a long-running application.

In other words, they will continue to FAIL, but in a different way. "Wally" needs to GTFO of the profession entirely.

Re:Point taken, but...

[Moraelin]

Well, the number of stories I have of _this_ calibre is rather finite and small. Most of the stuff I run into is more mundane stuff like telling them that the performance problem is because they make 100 remote RMI/IIOP calls, and they can stop inlining the loops by hand because it'll make no difference. In a way, thank goodness. If every team and project I ran into involved this kind of stuff, I'd probably be in a nice padded room by now, wearing a nice jacket with long sleeves ;)

So, yeah, they get reused :P

Re:Point taken, but...

[XDirtypunkX]

Actually, it's called System F.

Re:BASIC is irrelevant

[Eudeyrn]

What intro-level courses use C or C++?

University of Kentucky, CS115, CS215, CS216. A 3 semester 100% C++ block, required for all CS and CE majors.

Re:BASIC is irrelevant

[gaspyy]

Very similar to my childhood.

I wrote my first Basic program in 1983, when I was 7, on a ZX Spectrum. By 13 I was writing in assembler using Zeus, cracking games in order to copy them from cassette to floppy, writing utilities like a record/play sound, font editor and more.

At 15 I started learning Pascal. At 17 I wrote my first asm virus for x86 and started with C.

Later I used C#, PHP and javascript.

My favourite programming language right now? Actionscript. Epic fail, I know - I'll turn in my card in a minute. But I wrote a chess game in it and had tons of fun tweaking the performance.

no, Python is not the language to start with

[r00t]

First of all, you're clearly not an article reader. The point of initially learning with a painfully unstructured language is that you end up appreciating structure more, while being able to tolerate code that has awful structure. IMHO a better choice is assembly, but BASIC does have the advantage of providing faster rewards.

Second of all, many of us dispute the bit about Python not being a toy language. If you build your skills around Python, you'll hit serious trouble if you ever end up needing decent performance or unwrappered OS functionality. If you build your skills around C, whole new possibilities open up to you. You could even write a non-toy OS if you were so inclined.

Re:no, Python is not the language to start with

[Anonymous Coward]

If you build your skills around C, whole new possibilities open up to you. You could even write a non-toy OS if you were so inclined.

That's just crazy talk!

Re:no, Python is not the language to start with

[BrokenHalo]

IMHO a better choice is assembly, but BASIC does have the advantage of providing faster rewards.

Assembly's great, but you sort of have to keep re-learning it for different processors. My first programming was in assembly on a Burroughs B3700 back in the late '70s, and in a way it taught me everything I know about programming.

But if you're prepared to go old-school, my recommendation would be Fortran. As the quote goes: "Real Programmers code in Fortran. If the job can't be done in Fortran, do it in Assembly. If it can't be done in Assembly, it isn't worth doing."

Re:no, Python is not the language to start with

[K. S. Kyosuke]

The point of initially learning with a painfully unstructured language is that you end up appreciating structure more, while being able to tolerate code that has awful structure. IMHO a better choice is assembly, but BASIC does have the advantage of providing faster rewards.

Following this line of reasoning, we could easily come to the conclusion that the ideal beginner's language is Forth. After all, in its most rudimentary form, Forth is "painfully unstructured", but you after you learn to value structured constructs, you learn to add your own ones to the core language, and you get better performance and productivity than with BASIC. Hmmph?

Re:no, Python is not the language to start with

[Lemming Mark]

One of the reasons I like Python is that it is actually quite good at accessing unwrappered OS functionality - the standard libraries provide the ability to pack structs, etc, so if you want you can access ioctls without having to write native code (the inability to do that was one of the pain points I found in Java when I last programmed it - but that was 7 years ago, so I daresay things will have moved on!). When you do have to write "native" code, some combination of C (the native module API is fairly nice) or Pyrex / Cython makes it quite easy to do.

Python is certainly slow but I often find that doesn't matter too much. A combination of well-chosen native modules and / or existing libraries and / or careful algorithmic design can take Python's speed off the critical path. The Mercurial (hg) revision control system is written mostly in Python with some (now optional) native modules and it is one of the fastest version control systems out there.

All that being said, I think C is a pretty good language to teach people. It's not necessarily the language you want them to program (or even think) in, which is why my own lecturers didn't want to teach it to us. But without understanding a decent number of the concepts C makes explicit it's not that easy to appreciate what's really going on in the system and it's not that easy to appreciate the advanced features in other languages. We were lectured ML (a very nice functional programming language) and Java in my first year degree course. Occasionally we'd get told stuff like "ML is garbage collected" - it's pretty hard to understand what that means if you've only ever used garbage collected languages and don't know about explicit storage allocation! Ditto for pointers vs Java's references, etc.

In my work I've generally found C and Python to be complimentary - Python excels at interaction stuff, string processing, control plane logic. C excels at low-level things and stuff that needs to be high performance. They're easy to join up when necessary, so it works pretty well.

Re:no, Python is not the language to start with

[Teancum]

The one "danger" to learning assembly is that you quickly discover how lousy many of the current operating systems are in terms of not only resource efficiency (CPU, memory, and even data storage), but that a programmer in assembly can *gasp* actually do better than a typical compiler. Yes, I've heard the arguments that a compiler can do better than an average programmer.... which I think is pure bunk.

Some of the better "modern" assemblers also have features that make them work nearly as well as a high level language with memory allocation and "function" calling methods that strongly resemble what you might even find when writing in a language like C.

I do agree with you that re-learning a new assembly language is a bit of a pain. The largest problem with assembly is that you are so close to the hardware that you must understand the hardware itself and the processor architecture models. Of course if you are a competent software developer you should know this stuff anyway even if you use a high level language.

Of course knowing assembly also gives programmers an advantage when trying to reverse-engineer other people's software, but I digress at that point. Reverse engineering is not something typically taught at a typical university except as a "special topic" or some exceptionally enlightened professor willing to teach the topic.

Re:no, Python is not the language to start with

[Just Some Guy]

If you build your skills around Python, you'll hit serious trouble if you ever end up needing decent performance or unwrappered OS functionality. If you build your skills around C, whole new possibilities open up to you.

That's the dumbest thing I will have read today. I built my skills around 6502 assembler, written inside a monitor because I didn't know that real assemblers existed. I did my senior thesis on interfacing hardware to an embedded controller. I'm content writing memory-managing, bit-twiddling software in C. At the end of the day, though, I'd much rather write complicated stuff in Python than in anything else. Furthermore, I don't have any problem getting great performance out of it. The fact that you do says a lot more about the way you tried to write software in Python than it does about the language itself.

Re:no, Python is not the language to start with

[ld a,b]

I don't agree that assembly is a better choice. One thing basic had that few other languages have was an easy API for quick results(graphics and text) at a level where complexity is to be frowned at.

However, I do agree that BASIC set me up to learn assembly(and by extension C, Java and all other languages I learnt) far better than C would if I had been exposed to it first. From what I see in sites like Stackoverflow, most people starting in Java or even C, nevermind functional languages, have problems understanding the most basic fundamentals of computer architecture.

Sometimes they won't understand why their O(n) algorithm doesn't run in linear time because they know nothing about garbage collection and the data types they are using. You would think C programmers would have a good understanding of the problems involved, but in the end many new timers don't quite get pointers(They are able to use a subset, but more as if it was magic) because they were never exposed to unstructured programming.

I wouldn't touch BASIC again, but it was useful to me to set a mindset.

Re:no, Python is not the language to start with

[SQLGuru]

I think the average programmer can't do better than the compiler because they don't understand computers at that low of a level. I was surprised when I was going through college (90 to 94) how many CS majors had no clue how a computer worked. That has only increased today where writing code is even further away from the hardware. That being said, a compiler can generally be beaten by an average ASSEMBLY programmer.

For the most part, those average programmers who don't know the hardware can still be good programmers. You only need the uber-programmer-assembly-god to come in a tweak a few key routines to maintain performance of the whole system.....

Re:no, Python is not the language to start with

[ehrichweiss]

I actually came here to say the exact same thing about assembly. I'm teaching my kids programming on an old Z80 training board right now. It gives one better insight to the inner workings of a CPU and it is the one true "meta" language since every other language eventually becomes assembly, one way or another, when used. I know my programming skills went through the roof when I first learned Z80/6502 assembly. I wrote what I suspect was the first visual-based programming environment in 1985, a visual assembler for the Apple; if I'd only patented that idea that I thought was obvious at the time, I could be stinkin' rich. Today I can debug drivers for Windows despite the fact that I know little-to-nothing about programming for Windows. Of course one might say the developers of said drivers knew little-to-nothing as well.

Re:no, Python is not the language to start with

[danlip]

IMHO a better choice is assembly, but BASIC does have the advantage of providing faster rewards.

Assembly's great, but you sort of have to keep re-learning it for different processors.

No, you only have to learn it once, so that you "get it." Then you really understand what is going on under the hood and know how to do unstructured programming. After that you can program in high-level languages the rest of your life but be a good programmer. I agree that it is much better than BASIC for the type of "weight training" the TFA refers to.

Re:no, Python is not the language to start with

[colinrichardday]

First of all, you're clearly not an article reader.

Articles? We don't read no stinking articles! -- Slashdotter of the Sierra Madre.

Re:no, Python is not the language to start with

[Anonymous Coward]

If you build your skills around Python, you'll hit serious trouble if you ever end up needing decent performance or unwrappered OS functionality. If you build your skills around C, whole new possibilities open up to you.

That's the dumbest thing I will have read today. I built my skills around 6502 assembler

That was his point -- you didn't build your skills around Python, by your own admittence.

You are one of the experienced python programmers, and not one of the newbies.

Everyone has to start somewhere, blah blah blah. Not hating on the newbies.

Re:no, Python is not the language to start with

[jbolden]

I know you meant this to be kidding but the fact is RPL which is essentially a Forth was for many people their first programming language. And it wasn't a bad choice.

Re:no, Python is not the language to start with

[Shivantrill]

Assembly is not taught as a requirement at our local college. Regular BASIC isn't either. Real Programmers know more than one language and can fairly easily move from one to the other. They also are able to pick up new languages since they understand the basics of programming. Today, someone will throw a PHP web page together and call themselves a programmer. To truly be good at programming you not only need to know the language and it's syntax, but also what that syntax is actually doing in the machine. A mechanic woudl not be a mechanic if all he did was pump your gas and changed your oil, right? He/She needs to understand why you change the oil and what happens to it within the engine.

Re:BASIC is irrelevant

[Anonymous Coward]

We were taught BASIC in my maths class when I was 12. This was on PET computers (CBM4016) with cassette tapes for storage. I thought that was the usual age for teaching kids computers.

OO *is* procedural

[Viol8]

I know a lot of OO evangelists would have us believe otherwise but it is a procedural method of programming except the procedures are conceptually wrapped up inside a container that also has data. If you need more proof just remember that its entirely possible to do OO programming in C (a procedural language if ever there was one) using function pointers inside structures - and in fact this is exactly the sort of code the early C++ to C precompilers produced (along with a load of unintelligable macros).

Re:OO *is* procedural

[chthon]

Dammit, no mod points.

Exactly the same conclusion I came to.

Ouch!

[r00t]

most of us have been writing software without using goto for the last two decades

Us goto-loving programmers don't take two decades or more to write software. We just go to it.

Re:Ouch!

[Anonymous Coward]

We just go to it.

To the C-levels, I presume? ;)

Re:Ouch!

[Anonymous Coward]

Us goto-loving programmers don't take two decades or more to write software. We just go to it.

I gave using GOTO a try, but found that there's always some exception that will catch me out.

Re:BASIC is irrelevant

[vtcodger]

I agree on all counts. Python has its moments -- especially when the student moves on to lists and classes and especially when they fall afoul of the unexpected consequences of = being a binding operation rather than an assignment. But in general, the simple stuff is simple. And it works. I think that's really what you want in a tutorial language. And it's probably not all that bad in many real applications either.

If Python has a problem as a language for tutorial programming, it is probably in its rather limited error checking.

Re:BASIC is irrelevant

[King InuYasha]

My university here teaches intro with C++, which they feel isn't a good choice. However, they teach it because Electrical Engineers need to know a "C" or "C-like" language. Apparently they want to shift to Python in the near future, which means they need to work out how to bridge between Python and C in Intermediate (which is another required course for Electrical Engineers)...

Wrong language.

[machine321]

as potential programmers they are mentally mutilated beyond hope of regeneration

He's thinking of APL, not BASIC.

Re:BASIC is irrelevant

[pe1rxq]

I made my first Basic program when I was about 9. There is a special kind of magic in seeing your first few basic instructions work.
The concept of a computer executing just a long string of instructions becomes very clear.
If somebody had shown me pascal at that time and started to tell me I had to first make functions (I had never heard of such a concept, and probably couldn't have imagined how a computer was supposed to handle that) and only then could do some work inside them you would have lost me...

I saw Pascal and later C only after I had done a lot of exploring in basic and literaly poked the entire machine...
If you have been lost in spaghetti a few times the concept of a function (and later objects) becomes much clearer.

I have seen some being thought programming in Delphi. They don't grasp functions and objects as easily simply because they don't know which problems are solved by them.

Amstrad CPC Basic was superb

[Viol8]

It didn't have procedures like BBC Basic unfortunately , but what it did have was a simple type of multithreading. It had the AFTER and EVERY keywords which meant you could get the interpreter to call a subroutine once or all the time after a certain number of clock ticks. When I moved on to real multithreading in C then C++ my experience learnt on this helped me immensely since the race conditions you could get in posix threads are nothing compared to those that you can get in a multithreaded Basic language where all variables are global and there is no locking!

Re:Amstrad CPC Basic was superb

[twosat]

Years after I got rid of my Amstrad CPC I heard that it was actually a cut-down version of BBC Basic

Re:Amstrad CPC Basic was superb

[Viol8]

POssibly , I don't know. It was certainly slower and it ran on a different CPU.

we need BASIC, or something similar

[nerdyalien]

My first computer language is BASIC too.

Obviously, it can't do anything fantastic. But it can invigorate the enthusiasm of the casual coder to do more coding. That's the best trait in my opinion.

I mean, I don't think a first time coder wants to write an OS kernel. Maybe he/she wants to print his/her name on the screen, see computer knows the answer from 2+2, draw a geometrical shape on the screen... simple things that makes them happy.

Once they are done with simple stuff, they might level up to experiment with algorithm type tasks, e.g. routines to generate Fibonacci numbers, prime numbers etc.

Certainly, nothing I picked up in BASIC helped me in anyway on any language I tried later. But at least, when I walked into CS101, I wasn't someone totally new to the concept of 'programming' and wasn't scared at all. What I see is, people who never had programming experience before college years, tend to develop a real hatred towards it in their freshmen year.

Somebody above mentioned JAVA (or any OOP language) is a bad idea for new programmers. I totally agree with that. Even my CS101 taught JAVA, it wasn't a pretty experience. May be I am strange person, I never liked Visual Basic either.

But in my 2nd year, I learnt C.. it is to-date, the best damn thing I learned in my life. It pave the way for me to learn C++, MATLAB, C#.

In my opinion, programming is not something one can teach to a great depth. Its something one needs to explore with his/her inner curiosity. BASIC can spark that inner interest. BASIC gives some hope for a newbie casual programmer, rather totally putting off like most advanced languages does (even C/C++). That's what matters at the end of the day.

I saw M$ is rolling out 'Small Basic' as an replacement for original BASIC (in many plaforms including linux). I never had the chance to try it out, but I see some important additions that helps coder to play with GUI, internet so on. I am glad to see someone is putting effort to bring the programming back down to absolute ground level.

BASIC was rather bad

[lucian1900]

While BASIC was (is?) a rather bad language overall, programmers of today are blessed with at least two excellent high-level languages with large communities that they can use for almost anything: Python and Ruby.

Re:BASIC is irrelevant

[smallfries]

It used to be fashionable to introduce children to Logo long before that age.

Re:BASIC is irrelevant

[Anonymous Coward]

And BASIC of today is Python.

easy != bad
Complicated conventions and workarounds don't make a good programming language.
Teaching people to program in C is so much more complicated than Java/Python because you have to explain all the conventions (read: main, NULL) and workarounds (read: arglists, macros) people came up with.

Re:BASIC is irrelevant

[Hal_Porter]

I quite agree. I fire bullets over the heads of my students as they program too. Makes the bastards learn to duck.

Another BBC BASIC comment

[jregel]

It never ceases to make me smile that any discussion about BASIC invariably brings BBC BASIC fans out of the woodwork, and I'll add myself to that list.

To be honest, BBC BASIC spoilt me. I was familiar with the concepts of using procedures and functions, but never progressed to the built in assembler. The thing is that BBC BASIC and the sheer power (for the time) of the MOS (operating system) was so far advanced of the other 8bit machines available at the time. I then moved to the 32bit Acorn Archimedes range which also features BBC BASIC. So, when I got my first PC it was a complete shock - there was QBASIC, but it didn't work the same way and seemed far more limited. It didn't integrate so elegantly with the operating system.

For me, BBC BASIC and the MOS is a truly amazing piece of work and went with a truly revolutionary piece of the hardware. As an example, the BBC B hardware (the most common computer to run BBC BASIC in the early 80s) has a built in floppy disk drive port, parallel and serial, a programmable ADC port, a digital "User" port for controlling mice etc, a 1Mhz(!) bus for controlling other devices such as sound synthesisers, the ability to add an Econet module to create a local network and the "Tube", an interface/protocol for interfacing with a second processor (the first ARM processor was designed using the Tube interface). How many other 8bit machines in the early 80s could do any of that? The operating system also supported paged RAM/ROM and a very sophisticated display driver (called "VDU") where screen co-ordinates mapped to a virtual screen resolution, effectively allowing your routines to be resolution independent.

If you have an interest in old computers, or elegant design, but have never played with a BBC or even a BBC Emulator, you owe it to yourself to track one down.

Re:Another BBC BASIC comment

[Alioth]

We had econet at school. A friend and I wrote a client/server MUD (multi user dungeon) in a mixture of BBC BASIC and 6502 asm. Good times.

I have two BBC Micros at home now :-)

Re:BASIC is irrelevant

[vrmlguy]

Surely Python is the language to start with these days? It's straightforward, doesn't force any particular model, i.e., can use for procedural, OOP, functional style.
Most importantly it's not a toy language.

I've been struggling to teach programming to my kids using Python (and other languages), and have never been completely satisfied. I'm thinking that I need to start by teaching a restricted subset that looks a lot like BASIC. Two character variables are missing, but OTOH python doesn't use '$' to indicate string variables. The big thing is to include a GOTO statement, such as http://entrian.com/goto/, to be used until other flow control mechanisms are taught. I wonder if I can extend Entrian's code to include a GOSUB?

Of course, there's always Perl.

It's 2010

[Anonymous Coward]

And that kind of proves his point, doesn't it?

Re:Bah (Dijkstra was Pompous)

[Required Snark]

I personally heard Dijkstra say say something ridiculous. I was working for Burroughs in Mission Viejo on their Algol machines when he was a Burroughs Fellow, and they trotted him out to lecture the troops. I guess that they hoped that we would somehow become smarter if we were exposed to his brilliance. As we were walking to the meeting I was in just behind him, and he turned to his companions and said "I need to take a negative drink", meaning that he was going to take a leak before he started speaking. Some how that always seemed wrong to me, because I thought it would be better to "put a negative drink."

As for the badness of Basic, all I can do is think of what Knuth said: it is good to know multiple different styles of programming languages. Only knowing languages descended from Algol: C, C++, Java, PHP, JavaScript, is too limiting. It's good to be proficient with LISP/Scheme, assembly on more then one CPU, a string processing language (Perl/Awk), and an industrial language like Fortran or Ada. Logic/declaritive programming is also a useful skill. One size does not fil all, and if you are comfortable with multiple paradidms you will be a bettere programmer. Personally, my next language experience is going to be with Haskell, because I really like Scheme, and I want to understand the functional paradigm.

Line numbering is irrelevant :-)

[digitalchinky]

I learned BASIC as a young kid in the very early 1980's. All thanks go to Mattel (Aquarius) and some little known company called Microsoft! When I got to secondary school they exposed us to Turbo Pascal - I completely failed to wrap my head around this crazy language that had no need for line numbering. Even assembly (micromon on the C64) had what I thought were line numbers at the time. I was 10 years old! I spent close on 4 months looking over shoulders and copying work before it all started to sink in.

I'm not really sure if BASIC was a good thing for me or not. C and C++ were though - that's where I really learned how little I actually knew :-)

Re:Line numbering is irrelevant :-)

[walterbyrd]

Maybe you were using the wrong version of BASIC? If you had used MS-Profressional BASIC, or many other versions of BASIC, you would not have had to use line numbers.

Re:Line numbering is irrelevant :-)

[ender-]

This is similar to my experience. I wouldn't say I *learned* BASIC, as I never did anything more complicated than drawing circles and making random sounds. But what little experience I had was with BASIC which I had messed around with at home for years.

So then comes my Sr year in high school, and I have a choice of taking "Computer Math" which used BASIC, or "Computer Science" which used Pascal. I saw a bit of someone's Pascal code and thought, "Hey, there's no line numbers! How are you supposed to know where you are or where to 'go to'? ". It looked confusing so I took Computer Math, which taught me nothing and thus I failed to be introduced to real and useful programming.

As a result, I've ended up as a Sysadmin instead of a programmer. Not that I don't like what I do but I think I'd have been a little happier as a programmer.

Thanks to some moderately heavy bash-scripting I've had to do in the last few years, I'm finally starting to feel comfortable with how a program might work without line-numbers, and I'm finally back in school taking some programming classes [Visual C++, because the local community college is TOTALLY in bed with Microsoft], but I feel that because of BASIC, and my initial confusion at seeing non-BASIC code, I lost a good 15 years of programming and experience.

Exacty.

[TheDarkMaster]

Exactly. It not the language that makes a bad programmer, is the lack of knowledge.
Speaking a language that has dominated the market is "garbage" because it would be "too easy" to "superdevelopers of today" (so they think) is a huge childish that I can only see people who think using 50MB of ram to make a "hello world" is acceptable.

Re:BASIC is irrelevant

[ZeroExistenZ]

I wrote my first Basic program in 1983, when I was 7, on a ZX Spectrum. By 13 I was writing in assembler

I really wonder what your demography was, and the profession of your father/mother...

For me personally, I cannot envision myself programming at 7. Around that time there was just the commondore 64 around in very specific households; I used to go play space invaders on the commondore of my friend, but we never got further as typing in the commandline to start something up (and go play outside while we waited it to boot up) and his parents and brother being very protective about the PC and the PC-time allowed. So there was no programming for me at all around that age, other then gaining a great interest playing alot of nintendo, tiger games, or even 70s "television" games.

Up until my 14th I just screwed open my electronic toys trying to understand it, to the hating of my parents because I'd just drive it for a while until bored and get out the screwdrivers. I kept on doing that until I hit puberty and tried to screw other things, unsuccessfully mostly. Around that age the internet started to integrate in my life, but I was with the first few percentage of people even aware of the internet. This is where my programming-story started: before I already wrote retarted batch-files but with the internet I moved up to mIRC programming bots (printing out the full manual and reading over it day and night, those were the days) to help with fileserving, got into FTP-concepts to circumvent the ISP "port blocking" and eventually went to JavaScript because the animated gifs were sortof retarted but I had problems getting the gist of Turbo C. After understanding the concept of JavaScript, becoming pretty decent at it (and webconcepts with it) I was forced to look into PHP and databases. Once I got bored with that, I wanted to do "real things", and picked up C++ in which I've ended up doing socket and LPT programming. After that, picking up new languages and getting things done has become simpler and simpler.

But it's hard for me to imagine programming at the age of 7 (other then a VCR or something), I really didn't have the information or environment until I had a internet hookup. And that concept only came into my home with my brother starting IT at uni (which he gave up pretty soon for consultancy and certifications.)

Re:BASIC is irrelevant

[ZeroExistenZ]

I was always told my "generation of programmers" would be the last who will be articulate in both procedural and OOP programming and will most of the time or migrate the one to the other, be the last to maintain procedural languages while the next generations will only be schooled to understand OOP-concepts.

That was the period .NET 1.1 was being a horrible pain, and .NET 2.0 was the new promised land after Java (they've took the main concepts, and sortof sweeped the horrible things under the carpet in a VB-like fashion).

I must say, I've often been the "new guy who refactors the messy monster code nobody is wanting to come near" and haven't seen much full OOP-implemented architectures, mostly an improvisation of a mix of technologies...

I'm guessing the next generation will be schooled directly in C# as you say... As it teaches OOP-concepts, doesn't have the "transitional and historical workaround", and helps you protect yourself against making too big fuckups.

Re:BASIC is irrelevant

[FlyingBishop]

While I don't much care for Python, you have never programmed in either BASIC, Python, or both. Comparing BASIC to Python is like comparing the Model T to a Ford Cube. Yes, we get it, you don't like these newfangled languages. But Python is in no way analogous to BASIC.

Python has scoping, functions, good control structures, and a usable set of data structures.

Re:BASIC is irrelevant

[FlyingBishop]

The conventions in C are for the most part design choices used to encourage you to program in an efficient manner.

I assure you, BASIC is not easy. But that's also why comparing it to Python is beyond stupid.

VB.NET

[zepo1a]

I use VB.NET (2005 and up) mostly at work. Back in the olden days when I was in college, we learned, in order. BASIC 1 & 2, FORTRAN, COBOL 1 & 2 and then ASSEMBLER for your degree.

I was a VIC-20 hacker and then moved to C-64 and then ATARI 800XL (mixing basic and ML) before I started my college days. When Turbo C came along I bought that and learned a bit on my own, by that time they were also teaching that at the college I had went to so I went back and took a semester of C.

I like all those languages, but BASIC is still my favorite. I'll take an app I've coded here for work, and for fun, recode it in C# (or even C...C++ I consider a nightmare), but really, there is no difference anymore speed wise for your basic apps. Yeah, I'm not writing device drivers or sending bits through serial ports or IN and OUT ing to the sound card, but then not everything needs to be coded to the bare metal ALL THE TIME. When it's required I can do it, but most of the time, it's not

Yeah, back in the day I ditched basic for a while and used C because the basic interpreters were slow. But today, I'm happy with VB.NET (and C#).

I'll never understand the hate for BASIC. It's a tool, you can use it right or you can use it wrong.

Re:BASIC is irrelevant

[SharpFang]

Perl as introduction to programming for kids?
You will be lucky if they put you in prison for life, for child abuse.
If they don't, you'll have the misfortune to spend the rest of your miserable and short life in the grim world you will have created, filled by monstrosities from worst nightmares.

If BASIC was mutilating the young minds, Perl is in the line of Cthulhu summoning with minors.

Basic is just fine...

[Genda]

It had PEEK and POKE... what else do you need :-)

Re:BASIC is irrelevant

[CptPicard]

If Python has a problem as a language for tutorial programming, it is probably in its rather limited error checking.

Well, one can have an entire discussion over the merits of, say, static vs. duck typing. IMO most type errors are so grave that they are caught by even simple testing (remember, Python is still strongly typed), and messing with the type system especially if you're a beginner is more trouble than what it is worth... in particular in languages like Java where the OOP stuff can make the learning curve far more steep than it needs to be.

learn assembly and you'll know the why of basic

[mondotom]

For those that ventured into assembler will understand the goto and line nums of early Basic

Re:BASIC is irrelevant

[CptPicard]

That just makes learning and developing your mindset about programming much slower. Programming is, at least to me, a formulation of a computable solution in some Turing-complete language. The machine-specific stuff is actually not the part that the human is most required in, as it can be pushed to be done by the machine itself.

A wrongly constructed algorithm fails just as much in a higher-level language as it does in a lower-level language, but allows for clearer, faster understanding of why it actually fails. The machine-implementation failure related stack traces are code-monkey style stuff in comparison.

Re:BASIC is irrelevant

[Jurily]

Most importantly it's not a toy language.

That's why it should be kept far away from beginners. What if they accidentally type "import skynet", huh?

GOTO = JMP in assembler

[EmperorOfCanada]

I always found the original Basic, with its gotos and line numbers, to resemble assembler. When I was around 10 I found it very easy to make the jump from Basic to assembler. I would really hate to make the jump from Java to assembler if I were now starting out. Not that I would advise programming in assembler but it is a very good thing for all programmers to know . As basic and assembler both grew up they both even added labels. So in a way learning to get anything done in Basic was actually quite hard core.

Mootest point ever

[Vexorian]

Aren't there excellent programmers that started in any language? Heck, I started with mIRC scripts and even THAT was enough for me to develop logic... Whether there are excellent programmers that started with Basic or not, there would be no easy way they are 'excellent' because of BASIC and not despite that...

Re:BASIC is irrelevant

[biryokumaru]

God, Logo is the worst pile of crap to force on a child ever. BASIC is a far better choice. Trust me, I was forced onto BASIC and then Logo in elementary, and that Logo class was idiotic. I felt like I was getting dumber by the minute.

Disclaimer: I am now an EE, not a CS.

BASIC then...

[yoshi_mon]

My 1st Hello World! was done on a Pet. I then got my own 1st computer a TI99 4/a that had of course BASIC which I played around with but only in a very limited fashion. (Again mostly Hello World! type stuff. Hey I was not even 10.)

It was when I got my //e that I really started, and had the capacity to, looking beyond a simple goto loop and did so with that Apple. It was neat because at the time there were all sorts of cool tricks that people would use. Such as poking a small assembly program into $300 to speed up their Applesoft program.

Furthermore the monitor was right there. You could drop into direct assembly mode at any point. I had a friend who could program directly into the monitor and it was very cool to watch. My talents were much more modest and I needed a real assembler to do anything more than the very basics but it did let me cut my teeth on something other than BASIC.

So my point would be that BASIC is ok to start with but it should never be the only thing that people who want to know what programming is all about should see. From those roots I remember looking at Pascal and Forth just to get an idea of what out there. Mind you I am not, and have never really been, a coder other than scripts and whatnot but I have the background to at least sit at a table with programmers and have an intelligent conversation. Gives me nice nitch in being a liaison between the suits and the hardcore geeks.

Re:BASIC is irrelevant

[biryokumaru]

We had to do Ada for CS 101, which wasn't awful, but didn't seem like a very solid language to have to use after spending High School teaching myself rudimentary usage of ASM/C/C++/Java/C#.

Re:BASIC is irrelevant

[AlecC]

My problem with this is that Python does not require you to specify what type is expected.So, when maintaining code, you have no idea what this strange thing being passed in, other than it seems to support methods foo() and bar(). I keep having to read code, written admittedly by hardware engineers, where some strange object is passed through many layers of call. It may be documented somewhere, but the source code leaves me no way of finding it. It makes for unmaintainable code unless you are meticulous in your embedded documentation. Even the best of us fail occasionally in this department, and IME Python encourages this tendency.

Re:BASIC is irrelevant

[biryokumaru]

Yes, yes, yes, and when I recieved my Doctorate in Baraminology from Thunderwood College we...

Wait, Wollongong is a real place? You Aussies and your crazy words...

Re:BASIC is irrelevant

[Anonymous Coward]

My first real programs were written in perl. While perl can be sloppy, at the time, there were few other languages that had that kind of power. No compilation, instant feedback, and can do pretty much any task you can think of. I think perl, in some ways does remind me of BASIC.

Basic good for non-programmers

[QuincyDurant]

Anyone who has done technical support will have had occasion to wish that some users had studied a bit of BASIC. It teaches the fundamental difference between computers and everything that preceded them--the ability to store and execute instructions:

10 n=n+1
20 Print "Hello"
30 if n=10 goto 50
40 goto 10
50 whatever
I am an English major, and I don't know if the above code would actually produce 10 "hellos," as I expect, but I know conceptually that this is how computers work. And therefore I know enough to understand why my spelling checker, for example, doesn't always do what I expect.

I can't believe that learning BASIC causes blindness. but if it does, most young programmers would like to be allowed to keep doing it at least until until they have to wear glasses.

Re:Basic good for non-programmers

[walterbyrd]

Another reason that BASIC is good for non-programmers is that BASIC syntax is used in applications like spreadsheets.

Re:Basic good for non-programmers

[Anonymous Coward]

If you're going to horrify us all at least do it in fewer lines next time :p

10 n=n+1
20 Print "Hello"
30 if n10 goto 10

Re:BASIC is irrelevant

[gbjbaanb]

No, I still think its best not to start off with anything other than something really simple. The point is not that you get to learn OO or web services or whatever, but that you get it to work immediately, with interactive debugging. I'd even go so far to say you should learn a scripting language (like php or python), but they tend to be too web-centric and not-so-easily debugged.

Hmm, that said, there is a PHP debugger/IDE. Perhaps that would be best to start with.

Then, once you have the basics of programming in you, you can branch out to new stuff. But its important to realise that what you or I know, the 10 year old newbie to programming doesn't have a clue about. He has to learn the stuff we've forgotten to take for granted.

You could start with Pascal as the 2nd language, and extend yourself to Modula-2 as the third, but you'd probably be better off learning C as the 2nd, and C++ as the 3rd.

BTW. today OO isn't so important - its all Web Services. Oh sorry, Cloud services. Oh sorry, the *next* big thing ;)

BASIC needs to be viewed in context

[Anonymous Coward]

BASIC was a perfect language for a world that did not grow up with digital technology. It didn't require a lot of book time, it didn't require much project planning, and it didn't require an appreciation of abstract computing disciplines. Never underestimate the value of a language that produces results after one line of code.

The value of hitting the metal

[yelvington]

Eons ago, I took a computer science course for nontechnical majors at the University of Illinois taught by Daniel Slotnick, creator of the Illiac-IV and a pioneer of parallel computation. He made us write code in binary for a theoretical machine. On paper.

That is the worst possible way to create a computer program of significant complexity, with all the spaghetti-code flaws of the original Beginner's All-Purpose Simplified Instruction Code (BASIC) plus many of its own, especially mind-breaking tedium. I utterly hated it, and actually took an F on that exercise, but I got the point, completely. I had a sudden deep respect for assemblers and especially macro assemblers.

Too many modern programmers have no real idea how computers work, or even how languages work, or why they're built the way they are to solve what kind of problems. Getting under the hood changes all of that. When I moved on to C, I understood how it functioned ("really a preprocessor for PDP-11 assembly language").

I don't know whether the cited blogger is right when he says this sort of thing makes your brain stronger. I do know that it prepared me to understand viscerally the significance of higher-level languages and advances in the art.

I did dabble a bit in BASIC along the way -- on a CDC Cyber-9000 and a Commodore VIC-20. The latter made me understand that all of this can be fun.

Re:BASIC is irrelevant

[nschubach]

In my case, it was trying to explain to my father why I felt my game was more important than that silly quicken folder. That wasn't a game. We only had 40MB to deal with and that was getting in the way of what makes a computer good. Eventually I found QBASIC and GWBASIC on there and it was all I needed to make this machine do what I wanted! I had previously learned on a TRS-80 by copying code out of a magazine and editing it here and there. The new computer didn't seem to have the same interface, so I figured I was at a loss and this machine could only deal with machine code. It wasn't cool enough to have a prompt that you could just start programming in.

Duh

[Anonymous Coward]

I'll make a simple observation here.

At the end of TFA, there's a bit about how BASIC allegedly helped the author "the ability to think about a hundred things at once" which in turn helped quote strings appropriately for a DB -> Perl -> JavaScript -> HTML situation. It apparently only took three times to get it right.

And then comes the assertion that no "amount of structured programming helps with that kind of frankly messy problem". WHAT? No, entirely wrong. A simple but good solution would be to use literal string quotation (instead of having strings interpreted at every step), or a String transformation at the end. You know, so that you DON'T rely on having all of DB -> Perl -> JavaScript -> HTML and your string in exactly the state they are right now, and actually can make changes to any of these without making changes to everything else as well.
 
Really, if the author of TFA deems his skills with BASIC as valuable it is mainly because he's good at entirely going against common modern programming guidelines and likes to create situations (as BASIC near automatically did) where one constantly struggles to make the least amount of changes to code to not be forced to do more changes in code, and needed to think of hundreds of things to not hit a wall, but still fails at least a few times due to the complexity of it all.

The rest of the article is more than equally silly, mostly the repeated assertion that various abilities were bestowed onto people who learned BASIC due to the adversity of programming in it. Basically, it boils down to "your brain probably grew from the challenges and you got skills now". I can't agree, I only learned BASIC specific, entirely useless skills from BASIC.

Re:BASIC is irrelevant

[OeLeWaPpErKe]

Rigorous programming is as much of a trap as sloppy programming. In my experience programming projects often fail entirely due to too stringent, too rigorous programming methodology. Totally neglecting the "let's get it working" angle gets you only failure.

And yes sloppy code causes disasters. But at least they cause disasters only after actually running the code. Rigorous programming causes disasters before the first cpu has seen the first bit of your program.

Besides is there any argument against sloppy programming except the sort of academic frustration people have with badly spelled letters, not even reading the contents ?

Besides, extremely sloppy programming is how all big successes started, linux, windows, hell even unix started out more than just a little sloppy. And the very popular ruby language ... talk about sloppy. Yes it's very nice for certain kinds of programming, but everyone can see it's the next perl.

Yes, even smart guys can be Trolls

[ClosedSource]

The only significance of Dijkstra's comment is that it proves that Trolls predate Slashdot.

Linux file systems are object-oriented

[jonaskoelker]

This when I've been a Linux kernel developer for 10+ years now which is 100% procedural ANSI C.

If you'd said 99% I might have agreed.

But no, Linux isn't 100% procedural. The file systems are object oriented---each file systems presents a vtable to the vfs layer, which is then used to translate the `read' system call into, say, the reiserfs `read' call, or the ext3 `read' call, or the [...].

In other words, the vfs layer invokes the read method of the class corresponding to the file system in question.

(And no reductionistic arguments, unless you want to argue that programs aren't procedural either, because there are no procedures but only a bunch of GOTOs with a stack...)

I started out with Atari Basic

[heffel]

When I went to college, I was originally a Civil Engineering major. All engineering majors were required to take an "Intro to Programming" course taught in FORTRAN.

My previous BASIC exposure helped me code in circles around my classmates. It was pretty obvious then that having previous BASIC experience was a great asset.

I enjoyed my FORTRAN class so much that I decided to switch majors to computer science, where I had to take another "Intro to Programming" class, this time in Pascal. Again, previous BASIC exposure had me way ahead of my classmates.

I have always been puzzled by Dijkstra's dislike of BASIC, you could certainly notice a big difference between students who, like me, had been previously exposed to programming and those who hadn't. And back in those days, most personal computers came with a BASIC interpreter, therefore "previous exposure to programming" pretty much meant "exposure to BASIC".

Didn't I see that posted on ./?

[Sugemax]

BASIC is terrible (Score:0, Troll) by Ed Dijk (3102) 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.

Re:BASIC is irrelevant

[smallfries]

I did both at that age as they were the fashionable languages to introduce kids to programming. I actually quite liked Logo, although you have to pick up recursion before you can do anything really cute with it.

Disclaimer: I am now a CS, not an EE. :)

BASIC was so horrible I learned assembler....

[gweihir]

And then Pascal and C. Quite frankly BASIC is very well suited as an example on how not to design a programming language, as its flaws are glaringly obvious. (Java, which is just about as bad, requires much more effort and experience to find and understand its problems.) That makes BASIC an ideal first language to move on from after about a few weeks or so. Those that are comfortable with BASIC and do not want to move on even after a few months should probably be considered unfit to become programmers.

Re:BASIC is irrelevant

[Old Grey Beard]

FORTRAN man, eh? No wonder you posted as AC.

Its not the language...

[Drethon]

Its how you use it. A good programmer understands that no matter what programming language they use, the same structures apply (ex: branches, loops and function call/gosubs).

I write my first few little programs in various basic languages. I learned quickly that programming in blocks (one entry point, one exit) simplified things greatly. My first real training was in college in Java. This just further emphasized proper coding structure and built on what I had already learned on my own.

Since then I can develop programs in C/C++, Java, Ada, assembly, DXL, Perl and other languages but no matter what the language is I simply picture what structure I want to use and then figure out how that language can implement that structure.

Ultimately its not the language, its the developer...

Re:BASIC is irrelevant

[Teancum]

I'm curious about what kind of "bad habits" can be learned using modern dialects of BASIC today?

Then again, the current incarnation of Visual BASIC and other similar implementations of the language are such an abomination that you can hardly call them BASIC either. Well, I should note it isn't the earlier implementations of Visual BASIC, but rather when some C programmers got ahold of the language and threw out some of the exceptional power that BASIC holds over other languages.

I'll admit that the traditional "Dartmouth BASIC" can result in some unnecessarily complex spaghetti code, but then again it also shows who the sloppy programmers are when they try to do tricks to save a couple bytes of code that ultimately makes code maintenance almost impossible. I've always hated "clever" programmers anyway, and this can be a pitfall in any language. Then again, this version of BASIC was designed to be used on a line printer terminal.

I don't want to admit to how many or how large of a program I've written using that software editing system, but it is more than a few and some fairly large programs.

BTW, I don't consider Python to be today's version of BASIC. Instead, I would consider Scratch to be the true philosophical descendant of BASIC. If you've never tried this programming language out, you are missing out on a very unique experience, and something that is certainly going to influence software design over the next century or more. For my own children, this is the software development environment I've been using to introduce basic software development concepts, and it teaches object-oriented design and event interrupts right from the beginning. Who knew that an introductory language could introduce multi-threaded design so easily? My only major complaint is that it encourages the use of infinite loops not as something to avoid but even implements a specific construct to push its use.

Yes, Python is pretty good, but it isn't an introductory environment.

There's a better way to do it...

[Fished]

Like most, I disagree. The bottom line is that my early days programming BASIC (first on a Commodore VIC 20, then on an Altair, then on a Commodore 64 which is about when I graduated to assembler, then to C. But I still did some BASIC right through the 90's from time to time until I learned perl for "quick and dirty" stuff.

I think that the most important thing that BASIC taught me was that, there had to be a better way. So, I started to learn different programming languages, different environments. And I eventually learned the habit of using the best language for the job. If I needed to make "Patrick Rox!" scroll up the screen, ad infinitum, I used BASIC. Along the way I was forced to learn many languages, and learned most of the standard ones as well as some oddities (like Forth, Prolog, etc.) If I needed to write something fast, I used Assembler. If I needed to write a lot of code, I used C or Pascal or (later) perl. Nowadays, I do most of my code in Ruby, but at work I just got stuck with a project that's a combination of perl and shell and it was no biggy, and I decided yesterday to do a personal project in Python/Django because of it's better unicode support (the project will be mostly "about" handling Greek texts.) From an early age, I developed a solid understanding that languages are fungible, and that there's often a better language and environment for the job and than the one I might know best.

This contrasts with the kids I see nowadays (grump grump) who, if they bother to program at all, only seem to ever learn one programming language and one programming environment and tend to think that that's the end-all-be-all solution to everything. If they know VB, it's all VB. If C++, then it's all got to be C++. Java, python, ruby... you get the idea. Why? Because none of those languages (except maybe VB) really suck, and certainly none of them suck nearly as much as good old Microsoft BASIC on an early 80's Micro did. So it's easy to just stay stuck in a single language and never learn a vital lesson that separates "prorammers" from "people who write some code."

BASIC code is awful if left untended

[SlappyBastard]

Most languages sort of enforce a framework whether you like it or not. Not BASIC.

When I was a kid and I learned BASIC, I thought it was hot shit. And I didn't have a great amount of trouble learning Pascal.

But, when I got older and I started programming in C++ and eventually in PHP, I noticed that almost nothing from BASIC carried over. If it weren't for iterative loops, I think there would be nothing of value to come out of BASIC in learning other languages. Even in Visual BASIC, it's astonishing the number of times you end up using a C-like structure just because that's what works best.

The only thing BASIC really does is offer an easy gateway into programming. Is that good enough? I don't know.

Transcendental functions by hand?

[tepples]

You can use the calculator, as soon as you know how to do it by hand

What trigonometry teacher asks students to compute a cosine on pencil and paper using Taylor series or CORDIC? My math teacher gave students seven cosines to memorize (0 to 90 degrees in 15 degree steps); for anything else, students were expected to use a calculator.

Re:BASIC is irrelevant

[Teancum]

I really wonder what your demography was, and the profession of your father/mother...

For me personally, I cannot envision myself programming at 7.

I've been teaching my 7 year old how to program, and they think it is a really cool thing to do. Yes, it isn't something that easily comes to them, but it is something they are certainly capable of doing.

I don't know if you've seen it or not, but Scratch is a programming language that fairly easy to pick up and extremely powerful. 7 years old is still a little bit young even for this language, but not impossible, and certainly you don't have to be a pure genus to be using this language at that age. I'll admit, however, that even this language is more geared toward middle-school aged kids (10-14 years old) where kids that age seem to have the patience necessary to grok the concepts and be able to make something useful that goes beyond the simple examples.

It doesn't, however, take a college degree to learn at least the basics of computer programming. I started to write my first programs when I was 10, and that was several decades ago.

A little historical context

[Anonymous Coward]

BASIC evolved over the years. If memory serves, Basic at the time Dijkstra made these comments had no functions with local variables, no structured control statements, and so on. It was more like assembly language with good string support.

Nonsense!

[sagematt]

I started with BASIC and now I'm a professional Visual Basic developer!

break 2; // electric boogaloo

[tepples]

Sometimes I wished `break` could take argument of how many levels it should break out of

It can in PHP. Java and Perl have a different solution: label the start of a loop and then use that label as the argument of break. In C, it's just a matter of discipline to use goto only to replace a throw or labeled break.

Re:break 2; // electric boogaloo

[SendBot]

I've been using php for 14 years and I never knew you could do that with "break" until now. THANK YOU!!!

also , I'd mod you up for the subject line alone if I wasn't posting this comment.

Re:BASIC is irrelevant

[The_Wilschon]

10 I started with GW-BASIC, and now IF my colleagues need some programming help, THEN I am the GOTO guy.

Small systems

[tepples]

programming in plain C is considered harmful under almost all circumstances anyway

On a lot of systems smaller than a PC or a smartphone, environments like Java and .NET introduce too much system overhead. If you have 4 MB of RAM, you usually don't want to devote 3 MB of it to the runtime. Are you trying to imply that "almost all circumstances" involve comparatively big computers? If not, then what am I missing?

Re:Small systems

[ChatHuant]

On a lot of systems smaller than a PC or a smartphone, environments like Java and .NET introduce too much system overhead. If you have 4 MB of RAM, you usually don't want to devote 3 MB of it to the runtime.

While I generally agree with you, I'd like to note that runtimes for .NET can fit in space an order of magnitude smaller than your 3 MB limit: the .NET microframework (which is open sourced under the Apache license), only needs about 300k.

Re:Small systems

[tepples]

ChatHuant wrote:

the .NET microframework (which is open sourced under the Apache license), only needs about 300k.

From the Wikipedia article:

The CLR is an interpreter

Interpreters generally have a tenfold speed overhead if an app isn't library-bound. If I have a 67 MHz CPU, and it must translate input to output 60 times a second, I usually don't want to waste a large percentage of CPU time on an interpreter.

and uses a simpler mark-and-sweep garbage collector rather than a generational approach.

But is this mark-and-sweep collector incremental? If not, that's a deal-breaker because I don't want to miss inputs while the GC is hogging the CPU.

Re:Small systems

[XDirtypunkX]

I believe what the OP meant is that plain C can be pretty dangerous, even in experienced hands. But so are explosives and there are times when they're the best tool for the job.

As a side note, Java and .NET run well on a lot smaller systems these days. The .NET micro framework actually runs on devices with as low as 64K of RAM relatively well. Like anything, you trade safety for performance, but if you have performance to spare then safety isn't a bad way to spend it.

BASIC is fine...Really!

[Anonymous Coward]

I cut my teeth on BASIC, fell asleep in Pascal class and ended up with a degree in Journalism. Which I then used sparingly while earning 100K+ writing VB apps and managing software development projects. The moral of the story is that what you learn is not nearly as important as what you do and the quality with which you do it.

Prototype-oriented object systems

[tepples]

Code is related to classes, data is related to objects.

How does this dichotomy handle prototype-oriented object systems in languages like Self, JavaScript, or Lua, which don't have a solid concept of a "class"?

I agree

[joshsnow]

I agree. A good library or Framework allied with the basics of the language and some knowledge of best practice probably go a lot further than people give credit for. I too learned BASIC (BBC-Basic) and had a lot of fun with it. Was taught PASCAL and Modula2, but I struggled with C. Pointers and memory management and the lack of instant feedback that you get with BASIC really put me off. I spent years with some 4GLs and database specific languages before a very well structured, framework heavy proprietary OO language eventaully took me to Java, which is where I am now. However, I will be revisting C and ObjectiveC in order to do something with the iPhone. It's not nearly as daunting now as it once was.

Re:BASIC is irrelevant

[Anonymous Coward]

Should have said What intro-level courses use C or C++ "at relevant, non-reject universities"

basic aint what it used to be

[johnrpenner]

when you think of basic - you talk of GOTO statements & line numbers.
but modern Basics just havent used Goto statements or Line numbers in almost 2.5 decades!

except for some syntactical curiosities - the code you write with basic
supports the same structures as C, pascal, or java for decades already.

when's the last time you've seen Basic code? did it have line numbers or goto statements?
how about variable records (structs), function passing, and C-like dimensioning:

| local FN generateRawMoves(board as ^boardRecord, moves(0) as moveRecord)
|
| dim as long pieceMoves, numMoves, querySquare
|
| numMoves = 0
|
| for querySquare = 1 to 64
| pieceMoves = 0
| long if board.square[querySquare] 0
| pieceMoves = FN pieceTree(board, moves(0), querySquare)
| end if
|
| numMoves = numMoves++
| next querySquare
|
| end FN = numMoves

basic as it was 20-30 years ago is not what basic has become.

on the mac, there's currently a very useful (free!) futurebasic5 to C
cross-compiler available here, with an active 20yr+ user community:

FBtoC: http://www.4toc.com/fb/
|
| FBtoC 5.4.4 creates Mac OS X universal applications
| (Mach-O executables) from FutureBasic source.

real basic allows object oriented (cocoa) code, and is cross-platform:

RealBasic:
http://www.realsoftware.com/realbasic/

basic has also been adopted to some new paradigms.
it used to be that basic wasn't compiled, and interpreted languages
were considered too slow -- now basic is compiled, and java abounds.

or -- instead of using csh for scripting -- how about basic??

Apple I BASIC as a Mac OS X Scripting Language
http://www.pagetable.com/?p=35
|
| $ cat reverse.bas
| #!/usr/bin/apple1basic
| 10 DIM A$(100)
| 20 INPUT A$
| 30 FOR I = LEN(A$) TO 1 STEP -1
| 40 PRINT A$(I,I);
| 50 NEXT I
| 60 PRINT
| 70 END
| $ chmod a+x reverse.bas
| $ echo MICHAEL STEIL | ./reverse.bas
| LIETS LEAHCIM

basic aint what it was - so stop this thirty-year old gripe against goto & line numbers... aaargh.

Function pointers

[tepples]

In C++, code still goes in .text sections, and data is still on the heap (or possibly .data or .rodata), so the mixing of code and data is an abstraction.

In C++ implementations, every object with a virtual method carries a hidden field (whose name is unspecified) pointing to an object representing the object's class. This class object acts as a virtual method lookup table full of function pointers. So if you're opposed to function pointers, you're opposed to the way most C++ implementations handle method calls, but then you're also opposed to languages like Lisp and Python that treat functions as first-class objects.

Is BASIC less structured than other languages?

[walterbyrd]

I get the feeling that a lot of posters think of BASIC as 1964 Dartmouth BASIC, or GW-BASIC. But is that entirely fair? Various versions of BASIC have, pretty much, abandoned the "GOTO LINE NUMBER" model decades ago. BASIC may still support the GOTO statement, but I think most languages have some form of "goto." There have also been compiled versions of BASIC for several decades.

BASIC was not originally designed to be an object-oriented language. But, neither was C, and C led to C++, Objective-C, and Java. Other languages not originally designed to be object oriented include: Perl, PHP, Pascal, and - I'm sure - several others.

Re:BASIC is irrelevant

[walterbyrd]

Python has scoping, functions, good control structures, and a usable set of data structures.

BASIC has had all that for decades. Clue: there are many versions of BASIC which have progressed since 1964.

the problem with predictions

[the agent man]

they may not only be dead wrong but also inspire other people in pretty stupid ways. On the first day of my ugrad CS education the professor, most likely influenced by Dijkstra's absurd statement, had students raise their hand if they had previous BASIC programming experience. Then, he went on a rant claiming that we, the BASIC programming kind, would have virtually no chance on graduating from this institution. Couple of years later he had to eat his own words and hand me over the price for best student. Later I was one of the few of that class that got PhD in CS. So there Dijkstra!

Re:BASIC is irrelevant

[Anonymous Coward]

Hey idiot. When you were just smear of cum in your mom's vagina, we were writing code. So shut the fuck up.

God how I miss GOTO

[elrous0]

Every time I use Java I'm reminded just how much I miss the old GOTO statement. Java can take a program that would take ten lines to write in basic and turn it into a huge pain in the ass with multiple methods and nestled loops.

Re:God how I miss GOTO

[chthon]

Java : not primitive enough to have GOTO, but not advanced enough to support functional programming.

Re:BASIC is irrelevant

[CptPicard]

The deal is that if you're writing generic enough code, you shouldn't really care what it actually is that you've got, as long as it works as required. Explicitly spelling out things like interfaces help the compiler, but is generally redundant information.

Documentation should always be written of course, especially when behaviour needs to be documented. This is something that a static type system won't help with.

Re:BASIC is irrelevant

[FlyingBishop]

Not the one I use at work.

And VB .Net doesn't count as a BASIC.

But perhaps the biggest problem is that BASIC doesn't really mean anything because there are so many wildly incompatible, and poor quality implementations. For that alone it doesn't resemble Python at all. You get Python, you basically get Python. BASIC you have to re-learn it every time (and never like what you hear.)

Re:BASIC is irrelevant

[AlecC]

Which implies that you have to write bug-free code. If you write generic enough code with bugs in it, how is the maintainer to know which incomprehensible operation on which inscrutable object is wrong?

People tend to document the original class better than random uses of the class. With static type checking, you can get back to the declaration and at least find what the class had in it when it was created, which will give you some idea of its use.

This was not helped by the fact that the implementors overused dictionaries. These inscrutable objects contain dictionaries of values indexed by abbreviations opaque to those not in the secret order.

BASIC a gateway to assembly.

[Anonymous Coward]

In the 80s, BASIC had no compound objects, conditional blocks had to be coded as conditional jumps to numeric line positions: machine code didn't seem too different, and was a necessary step to get anything to run at a decent speed.

Re:BASIC is irrelevant

[SQLGuru]

Yeah, my programming went more or less along the lines of this (skipping database languages and languages only covered as topics in a class with no significant amount of code written):

BASIC --> Pascal --> C --> Ada --> C++ --> PowerScript --> Java --> C#

After learning Pascal, I still only have a single exit point for any loop or function. Set a boolean and check it, last few loops are effectively NOOPs (not the most efficient, but I can tune those out if perfomance becomes an issue). Only one return per function. etc. etc. My BASIC code, though, probably overused GOTO.

Re:BASIC is irrelevant

[CptPicard]

IMO Python-style genericity makes code much briefer and manageable in the sense that it is easier to see that some piece of code, in isolation, does things correctly as long as the assumptions regarding the objects given hold. And as the type information is there at runtime, type errors actually crash the program in testing very quickly, after which it's just a case of verifying where you're making that call and what it is you're giving the function.

I do understand what you're saying, but simply am a bit unimpressed by the supposed benefits of explicitly telling the compiler what you already know.

By the way, Lisp wins here in general; it's duck-typed to begin with, but lets you annotate type information, which both helps the compiler and and can warn you when the compiler can tell the type annotations do not add up.

The real problem with BASIC.

[Steauengeglase]

It has nothing to do with the language crippling your mind (though some days I do wonder about VB), but because the language has been taught in High School/Middle School Computer/Typing classes where teachers are more than happy to pass anyone who can print text to a screen and type 30 words a minute. It was (, no idea if it is still taught in public school) just a random elective that pretty much anyone could take and pass. Some people pass it, don't enjoy it, exclaim that they can program and for the rest of their lives feel that programmers are overpaid, entitled nerds who would serve the world better if they were ditch diggers.

Dijkstra didn't program

[e2d2]

I don't take advice from "programmers" that don't own a computer. If it's mathematics were talking about, big ideas, yes. For actual real world use, that's just plain crazy. If we all followed academia's approach we'd use a functional language and every application would be mathematically provable. Sure it may take a century to complete, but it will be "perfect".

Re:BASIC is irrelevant

[SharpFang]

Yes, yes, the the dark side is so easy to reach, so powerful and tempting!

Re:BASIC is irrelevant

[AlecC]

It is not so much telling the compiler what I know, it is telling the source code, in a checked manner, what I know today that the maintainer (who may be myself) does not know tomorrow. It is a big fallacy that source is needed only for man to communicate with machine; just as important is man communicating with man. And if I can get that communication machine checked, should I not do so? Just like assert(), @override, private: and other annotations which add nothing to functionality but reduce finger trouble.

Commodore BASIC

[Anonymous Coward]

Yep. Everyone should start programming with Commodore Basic V2. It should be the law!

BASIC rocks!

[Spit]

The best I used was on the SinclairQL; beautiful and almost Pascal like, you could create advanced programs without much effort. But the real beauty of BASIC was on the 8-bit systems, really sucky dialects like Commodore basic 2 made you hit the hardware to do anything meaningful so it was a short step to assembly.

A good environment for tinkering with basic is the ZX Spectrum emulator BASin. It has advanced tools for coding and debugging, as well as creating assets for games etc. Sinclair basic really is one of the nicest around with plenty of good doco.

Classic BASICs aren't dead yet...

[VanessaE]

I'm surprised no one's mentioned Blassic yet. It works quite well for the odd project, or just to play around with. You can use it with or without line numbers and it supports a handful of different syntax models. I believe there are graphics/windowing commands, and it supports file I/O operations as well. You can even call programs from the command line and pass arguments to them, similar to regular scripting languages.

Since I'm not that great with other languages, it has proven itself rather useful a time or two.

Proof

[gyrogeerloose]

I learned to program on an Atari 800 using BASIC. Now I can't code my way out of a paper bag.

BASIC *can* be learned in a structured way, but...

[Qaelith_2112]

In the 80s my high school BASIC programming teacher (TRS-80 Model IIIs) made us go through the trouble of structuring our programs very much as if we were coding in Pascal or some other more structured language. At the time I didn't fully appreciate the added burden and limitations that were being imposed on us. Understand, though, that I was a self-taught Commodore 64 BASIC spaghetti coder complete with a generous spattering of GOTOs and not nearly enough GOSUBs. Certainly these programs would have been a nightmare to diagram. That (at the time) unwelcome discipline imposed in that high school class was of immeasurable value later on as this was an excellent prep for other languages later on and for building far better code than if I were to have continued through life trying to code as if I were still on that C-64. Still, I can't help thinking that maybe Pascal would have been a more natural way of introducing that discipline and it leaves me wondering how many in other similar high school BASIC courses at the time weren't so lucky as to have structured approaches taught in connection with a totally not-structured language. But there's the flip side: Without that amazingly accessible C-64 BASIC that can literally be learned in no time with a quick read-through of the user manual and a handful of other peoples' code to pick through, I doubt I'd have ever bothered to learn in the first place.

ZBasic

[Anonymous Coward]

I kind of miss ZBasic. Small, fast and with an expert friendly editor. (This was before I knew about the VI/VIM editors.)
The entire compiler/interpretor was a ~60k MS-DOS .com executable, including a full screen editor.
I still have version 4.6 somewhere.

Apparently also available on CP/M, Apple ][, Macintosh and TRS-80.

Re:BASIC is irrelevant

[Sheik Yerbouti]

If you want to teach kids programming I recommend Scratch, Alice, or Greenfoot kids want to make games that's why me and all my friends learned basic on our 8 bits was to write games. These environments enable quick game making successes which increases interest.

Says the man who does not know HTML links

[Anonymous Coward]

Dijsktra was right. The debate about GOTO statements was done in the framework of the emerging structure-programing style. Even Knuth says in that article:

"From these remarks it is clear that sequential composition, iteration, and conditional statements present syntactic structures that the eye can readily assimilate; but a go to statement does not. The visual structure of go to statements is like that of flowcharts, except reduced to one dimension in our source languages."

With the introduction of exceptions and structured error handling, there is no compelling case for continuing using GOTOs. Java, Python, Ruby and many others modern languages does not have goto, and no one seems to miss it.

Amanda Seyfried/Julianne Moore love scene? Check!

[Impy the Impiuos Imp]

Modern, Visual Basic-style basic, with full procedures/function calls, full-length symbol naming, and no line numbers, sure.

Old-school, with line numbers (REN anyone?), 2-letter max variable names, and gotos up the wazoo, no thanks. And the latter's what I "cut my teeth" on, and I'm the best programmer on the planet.

Oh, wait. n/m.

A couple of quotes for the younger reader...

[BrokenHalo]

"modern" assemblers also have features that make them work nearly as well as a high level language with memory allocation and "function" calling methods that strongly resemble what you might even find when writing in a language like C.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.

Of course if you are a competent software developer you should know this stuff anyway even if you use a high level language.

Of course, the determined programmer can write a Assembly program in any language.

;-)

Re:BASIC is irrelevant

[ZeroExistenZ]

I've been teaching my 7 year old how to program, and they think it is a really cool thing to do

I can imagine that, then they're still very eager to learn and i'd imagine it's more sortof a puzzle, while they integrate the concepts (also mathematical, I find programs to be downwards compatible with mathematics, but not a requirement to grasp the programming concepts) and learn how to deal with correctness (the compiler doesn't forgive)

It sounds like a large added value for these children, but only when they have the inclination themselves and enjoy the entire interaction (very likely with you as guidance, in a "playtime" setting while they get creative with it.)

Stimulation is really good, sometimes I wished my parents were more stimulating as I was left to find it myself (a screwdriver and librarycard saved my childhood and teen days :)

Can't put state of mind on a resume.

[gillbates]

While I agree that good programming is a state of mind, the problem is that HR can't recognize good programmers. In fact, a large number of organizations can't recognize the difference between a good programmer and someone who merely has experience in a given language.

There seems to be this notion in Corporate America that if you haven't been formally trained in a language (i.e. college courses), or have some documentation of doing it professionally (i.e., on your resume), then you don't know it and you can't learn it. When I was in college, I really believed that getting a degree would afford me a job working among intellectuals. Instead, I'm working among people just as stupid and ignorant as the blue collar counterparts they hold in contempt. Unable to learn something of their own volition, without having been taught, the notion that someone can, or will, learn something new is completely foreign to them. They can't understand how a C programmer could also be proficient in Java.

Re:I'd guess there's a critical period & an at

[DogFacedJo]

    I feared there was a critical period - there is so much reason to suspect so. So many folks I've met seem frozen, whether in life, in mindset, or in the development methods that they learned during their larval phase.

    I still fear that there is a critical period for scepticism, but I'm at least reassured that folks can learn significantly new perspectives and, in particular, to even go larval again later in life and pick up major new skills, whether new programming approaches or the entire suite of new models and mindsets needed to deal with a new field entirely. I've seen folks jump successfully between different engineering fields, coding styles, industries, etc. ...

    I haven't seen, personally, folks successfully make the jump between the engineering/technical mindset and the serious liberal arts' points of view. Perhaps there is a more qualitatively different wall there than merely a larger conceptual distance - I don't have a decent theory. The people I see who seem to be centred in-between major disciplines like art, science or engineering tend to appear strongest at that very point, in the interdisciplinary space, rather than having two masteries with an intersection where they choose to play. While some can be extremely proficient and have a broad expertise, they have always appeared to get weaker as they traveled from their personal centre. This is a small set for me, though, thus even more anecdotal than the rest of my ramble.

    Sadly, as far as a minimal exposure notion goes this might be extremely hard to dispute by experience. I read an article in Byte 25 years ago on LISP or Prolog, or even did a few weeks of them in a survey course during uni; do these give one enough of a 'seed' such that if one is able to properly discover them later in life it was only because that opening was created so many years earlier? Who can say reliably that they have had no exposure to an idea within a field once entering it. Clearly folks who only got into tech in some year can reliably state they didn't encounter certain concepts before that point - but a single person rambling drunk at a party, something one had forgotten, if that is enough to be a your seed for a future successful exploration of that concept then I can't really claim any significant idea I ever came to understand well later in life hadn't been exposed to me years earlier.

Even reading /. might ...

Bah.

Re:BASIC is <3

[geekmansworld]

Though I know a handful of different programming and scripting languages, I'm IT by trade, not a developer. So I've never learned C++.

But, I did cut my teeth on the most basic BASICs: for Commodore 64 and Apple II. It was working in BASIC as a wee kid tinkering around for fun that taught me the fundamental principles of logic, variables, and program flow.

So, thank you BASIC! You'll always hold a special place in my heart.

Re:BASIC is irrelevant

[bwcbwc]

Well if you need a decade or two of historical perspective to understand the issues raised by an article, doesn't that pretty much confirm that the article's premise is irrelevant? More specifically: The BASIC of Djikstra's era isn't the same as the modern BASIC language exemplified by VisualBasic, Cypress Basic or even VBA. So Djikstra's concerns about properly structured programming are no longer relevant -- Basic in Windows is fundamentally different, and open source platforms have abandoned BASIC in favor of other languages. However, if you abandon the specific references to BASIC and acknowledge the fact that some languages are better at enforcing structured programming habits than others, then Djikstra's concerns are relevant. It's far better to teach beginning programmers in Pascal or Java than it is to use Perl, for example.

If you want to breed programmers, use LOGO

[anyGould]

Seriously.

If I had to decide what made me like programming, it was being six years old and getting to drive that dumb turtle around a screen (wasn't lucky enough to have the physical turtle). Later I picked up Basic and Hypercard in high school, Modula-2, Batch, C and C++ in university, Perl, Javascript, Java and VBA in my career and personal projects. But I probably wouldn't be doing what I do now if I didn't discover how to draw shapes on screen.

Now, Logo isn't a "useful" language. But it shows kids that you can control the Magic Game Box. And your future programmers will see that, go "cool!", and run with it.

It's the Lego theory - people who end up building things as adults liked to build with blocks and legos as kids. The complexity comes later.

Nirvana Quest

[strangeattraction]

Dijkstra...isn't he that guy that built the crazy computer in Star Trek. Just kidding or am I. All programmers should start out in assembly. This will weed out those that are not serious. Knuth realized this long ago. They should then be made to program in a language I invented called GOTO where everything is a goto statement. This will show them exactly what they are giving up when they go to languages without gotos. Then I would have them write programs that are all in one file and only in caps. See how they like that. And finally I would have them write programs in some kind of XML based language like XSLT (ick). And just so they don't whine about their fancy IDEs they have to write a COBOL compiler in COBOL with punch cards. If they still want to be programmers, we can let them cut their teeth on Scheme for a couple of years using only ed (text editor). Then and Only then should they be allowed to even view Java or any other OO programming language. Amen.

Re:BASIC is irrelevant

[thebagel]

Southern Illinois University Edwardsville. CS140, CS150 sequence uses C++.

hmmm

[neuromountain]

I started with APL. After the mushrooms wore off, I switched to BASIC and then FORTRAN and then.....

The world is full of excellent programmers ...

[Anonymous Coward]

who cut their teeth on Basic, and Microsoft continues to hire them

Exceptions

[bussdriver]

Exactly what I was thinking. Nobody seems to touch assembly anymore.

What about exceptions? I've always thought of them as a logical progression of the goto. Possibly as a result of goto being so useful in situations where you need to break out of multiple code blocks such as error conditions. Exceptions fulfill this use case while adding something goto always lacked-- indirection: I remember goto situations where I would redirect the goto or with some logic decide to goto another "higher" place to properly handle an error. Had goto been acceptable, I think that a "smarter" goto would have been associated with exceptions... "Advanced" goto involved labels instead of line numbers or memory locations- it was just the next logical step to make labels exist at run time so one could decide to catch or redirect them by their label.... I never encountered this because I learned goto was "bad" while learning C and pascal and the dogma at the time but when I ran into exceptions, I immediately thought "goto is back".

Think of java-- its all objects. So, we have these silly things called Singletons which only exist because we can't admit it was a mistake to kill global variables so we create a "new" concept that re-invents the wheel we couldn't live without. Even then, a Singleton is not built-in its a hack work around in for the rigid object only dogma (and where classes have runtime properties that is just paying lip service - those are still globals; one could do the same thing with a global struct but that would be taboo...)

it teaches you what NOT to do

[josepha48]

you can do so many things in basic and so often they are all bad things to do. the use of goto for looking is a bad practice. I will say that MS took it to a level that made it visually easy for people to make large ugly coded programs that did lots of things that people would now write in java/c# today

Re:I'd guess there's a critical period & an at

[Anonymous Coward]

I agree that there is a critical stage in the development of a programmer that will shape the end product.

I was fortunate enough to have Scheme (think LISP) taught to me in my intro CS class (after learning BASIC as a kid and being exposed to other things like Logo and FORTRAN). This opened up a whole new way of thinking about logic structures and recursion that just isn't possible with BASIC.

My university curriculum also included "Comparative Programming Languages" in the second year of CS, which taught four or five vastly different languages. I would find it hard to believe if other schools didn't do the same, as it's just massively useful for a young programmer to get this exposure early in the process.

Holier-than-thou

[Bobb Sledd]

Ugh. I get so tired of this Elitist "holier-than-thou" crap. Define bad program. Program with lots of bugs? If a program works as intended and it requires no updates, users are happy with it, it's secure, and it is useful, then what difference does it make if it was made entirely using GOTOs ?

There's this "Well if it isn't made with C++ it's shit" mentality again.

Look, you can make really great programs without typing and scoping. And very quickly, too, without bugs. You just have to be good at making and keeping your own conventions, keeping things modular, and doing things in the most efficient manner.

Beyond that, a judge of poor programming? Bite me.

Re:Holier-than-thou

[chthon]

If a program works as intended and it requires no updates, users are happy with it, it's secure, and it is useful, then what difference does it make if it was made entirely using GOTOs

The mistake that you make here is that programs require no updates. Every program requires updates, because requirements change and new use cases are introduced. A program with GOTO's is much less readable from the beginning, and thus it becomes more difficult to maintain it.

Re:BASIC is irrelevant

[shutdown -p now]

What if they accidentally type "import skynet", huh?

They'll get an error. Because it is, in fact, "from __future__ import skynet"!

BASIC is good for teaching would-be gurus

[presidenteloco]

Because, with its gotos and numbered code satements, it made pretty explicit that the computer
was implementing a "program counter" or "program current-instruction pointer" which was advancing
step-by-step through the program and being redirected to another block of code using a jump of some
kind.

Someone who is going to become an excellent programmer will take that, and discover for themselves
that always structuring ifs with gotos as a standard pattern in an if then else organization makes their
programs easier to write and to maintain and understand.

They will also learn to create standard patterns for looping while checking a condition, and
for creating distinct subroutines with structured ways of going to them and returning, including
creating extra variables which are used to pass arguments into a subroutine.

Thus you don't just learn structured programming. You learn what aspects are important about it
(the patterning of control flow, localization of similar purpose code etc.) and you learn the mechanics
of how a compiler is going to make it work i.e. what it will do under the hood.

Great stuff.

I'd put it this way.
-Bad programmers will be outed sooner by starting with Basic.
-Excellent programmers will become even better and wiser faster by starting with Basic and
climbing up out of it.
They will also have a quick straightforward path from Basic down to understanding assembly code and
ways and advantages of structuring it.

Re:BASIC is irrelevant

[Just Some Guy]

God, Logo is the worst pile of crap to force on a child ever.

Really? Most programmers respect Lisp, even if they don't use it themselves.

Disclaimer: I am now an EE, not a CS.

Ah, OK. Here's your cookie and a warm blanket.

Re:BASIC is irrelevant

[Anonymous Coward]

I'd say that if anyone is considering BASIC as a first language, they should choose Pascal instead.

Compared to which BASIC, for what reasons, and which Pascal ?

But to be completely honest, these days OO programming has become so important that it's probably better to start off in Java or C# from the start.

Do you not think Visual Basic .NET is an equally good platform for learning OOP/OOD ?

Do ! BASH GOTO

[nuckfuts]

In writing .BAT files to run under Windows, the available commands for conditional logic flow are extremely limited. There is an "if" statement, for example, but no "while"" statement. I recall when goto statements and labels became available (MS-DOS version 3?) it suddenly became possible to implement complex logic in .BAT files. Sure, it's not pretty, but it's mighty useful. That primitive syntax still works on Windows today, all the way up to Server 2008. Even though PowerShell is now available, I still like the simplicity and ubiquity of .BAT programming.

If you disagree with my sentiments, please exceute the following code:

@echo off
SET DESTINATION=HELL
GOTO %DESTINATION%

Get off my lawn.

[GargamelSpaceman]

The article seems to be saying everyone ought to use a crappy ancient tool so as to excersize their mental muscles to be able to use the crappy modern tools that are prevalent for now. Because the size of the programmer's skull is limited and will not be getting an upgrade anytime soon, eventually progress will stagnate long enough because of programmers running up against this law of nature for someone with a really good idea about how to do things to catch up and overtake the herd of programmers who have become proficient at producing crappy code.

irrelevant

[PJ6]

Nearly all the people I'm hiring now have never touched the original BASIC, and those who have are usually valuable (and expensive) because of their long experience. So from the point of view of career evaluation the question is totally moot. And should people should be introduced to programming with BASIC? Is this even a question? Nobody's doing this. Nobody uses it any more. Why was this even posted?

Mentally mutilated beyond hope of regeneration

[Chess Piece Face]

Terry Schaivo called. She said "................"

Well, not really random

[Moraelin]

1. Well, I didn't mean random as in actually generated by SecureRandom, but more like in, "they had nowhere near the control over their contents to guarantee they can hash to a 31 bit value without collisions." For the purpose of that custom brewed hash method that was supposed (in their imagination) to never create collisions in a HashMap, the strings were as good as random, and there was mathematically no way to guarantee the lack of collisions.

There are plenty of Strings which are as good as random in that aspect. User names for example. Car registration numbers. Whatever, really. Above some 5-6 alphanumeric characters that are out of your control, even if you ignore case, hashing it to 31 bits will necessarily always result in different hash codes.

Because that was the "problem" they were trying to solve. They thought in all honesty that a hash collision causes the wrong value to be changed, so they tried to write a hash method which would never cause collisions. But on the actual Strings they used, that was impossible.

2. There are cases where generating cryptographically-secure random keys is actually the right design. The trivial example is: browser session ids. Having a predictable sequence of session IDs is actually considered exploitable. If a user can predict the next or previous key, conceivably they could hijack someone else's session.

Re:BASIC is irrelevant

[walterbyrd]

> Not the one I use at work.

But that is just *you* not really "BASIC"

> And VB .Net doesn't count as a BASIC.

Why not?

> But perhaps the biggest problem is that BASIC doesn't really mean anything because there are so many wildly incompatible, and poor quality implementations.

Ignore those implemenations. Stick with a major version. BTW: that is the same argument that linux bashers use. Also, if you are creating a GUI app with python you have all kinds of incompatible libraries to fight with.

> For that alone it doesn't resemble Python at all. You get Python, you basically get Python. BASIC you have to re-learn it every time (and never like what you hear.)

You may have some points, but you are all over the map. First you compare python to 45 year old BASIC. Then you dismiss widely used VB.NET with no explaination. In many ways, Visual BASIC compares very well to Python. For creating a quick GUI app on Windows, VB is much easier and faster.

Interesting

[Windwraith]

I only know my personal experience, unfortunately no one around me knows how to put code together.
Anyway, I started with "GWBASIC" I think, then moved to Quickbasic after some months.

My target is just making games, not even commercially, just because I love designing them, doing graphics, music... My hobby, not my professional choice.
With BASIC, it was easy, and I had the ability to focus on making a tiny, pretty game instead of focusing on the coding part. And it taught me many things about game logic, how things worked behind the scenes.
When I got a big, good enough idea, I jumped from QB to C+Lua+SDL+GL, and, in all honesty, it's not hard, just time consuming (fortunately for me)

The best thing is that, within the constraints of BASIC and a 8086 computer (CGA graphics! 4 putrid colors of WIN!), I learned to optimize code, which is a very valuable thing that, it seems, many game programmers of today weren't exposed to.

Then again, even with such a skill, I can't consider myself (or many wouldn't consider me) a real programmer, I don't feel capable to writing a desktop application, and I ignore the terminology of things. I can build a house and succeed but I am no architect.

Still, what this meant to say is that BASIC can surely teach some things, at least as entryway to "logic" which is the most important weapon of a programmer.

Re:BASIC is irrelevant

[FlyingBishop]

Point is, the OP was claiming that BASIC and Python are in the same language family, which is just false. And as for BASICs with good data structures, scoping, and real functions, yeah, they're probably fine to use.

But such BASICs have as much in common with the BASIC people talk about when they say BASIC is terrible as Java does with C. Probably less, since C is a well-designed language.

Re:BASIC is irrelevant

[Anonymous Coward]

My highschool had a mandatory, though only 1-term long class on introduction to computers and what we mainly did was learn about the various parts and were introduced to BASIC. This was in early 80's and we used Commodore PETs. I was 12.

Re:BASIC is irrelevant

[jasonq]

BASIC is still a great learning platform. As a whippersnapper back in '78 I learned the pain of GOTO and moved to GOSUB. Through my own ineptitude I was jarred into functional/procedural programming. Moving to objects after that was a natural progression. Sink or swim.

correlation or causality?

[dbrower]

I was on Basic from 1986 to 1993, and it was the most meaningful years of my life.

Were, by chance, those also the years you discovered sex?

Knuth's Programs were Horribly Unreadable

[billstewart]

(I learned programming first with several flavors of BASIC in the early 70s (plus books about F0RTRAN and COBOL but no chance to use them, then learned Academically Much Better programming with PL/C (the Cornell PL/I compiler, similar to IBM Checkout), then algorithms with Knuth Spaghetti Code and Knuth MIX, then IBM and PDP assemblers, then a summer job with RPGII, then Simscript, then C, shell, lex/yacc, and many other languages.)

Knuth's books on programming were fundamental then, and still are - understanding what machines are doing, and how to think about that, and understanding how mathematics relates to algorithms and programs, and how to think about them, are fundamental to good Computer Science and good programming, and probably always will be. But Knuth's actual programs that he used to teach them were inexcusably unreadable spaghetti code, and MIX was just appalling, even given the goal of being machine-vendor-neutral. It's especially frustrating, because when I first used Knuth's books it was at least in the context of a class with a professor walking us through the critical parts, while now when I want to use them as reference books I've got to wade through that sludge myself. The syntax and structure made it difficult to learn the semantics which are what was really valuable about Knuth's work, and they make them difficult to use as a reference book.

Algol 60 came out around 1960, and widely used for programmers who wanted to share ideas with each other (e.g. CACM, the Communications of the ACM journal, was mostly in Algol 60, though sometimes it used Fortran) and Knuth was writing almost a decade later. He could have done 95-99% of his non-assembler programs using Algol and Algol-like pseudocode, and it would have been much easier to read because you could tell when he was doing a FOR loop as opposed to looking for the incrementation and backward-pointing GOTOs, and when he did want to do things that were tricky it would have been easy to figure out which were the tricky parts. (Lisp was also available around 1961, and for some things Knuth taught it would have been better, but for many things a procedural language is really enough closer to the metal than a functional language that it wasn't always appropriate.)

And MIX? Ugly not-very-machine-like assembler, with decimal numbers and odd-sized words? It's a hopeless thing to use to teach algorithms, except for algorithms that are really about bashing the bits when you need to do that. And yes, the world wasn't as clean or pretty back in the 1960s, and there really were Burroughs machines that were almost that ugly, but still, it wasn't the best choice then and looks even worse now. If I were writing something back then I hope I'd have used something cleaner, though the PDP-8 and IBM 360 didn't come out til the mid-60s, and byte sizes didn't really standardize for a while, even though people pretty much knew that binary sizes made things much cleaner.

BASIC BASIC vs modern not-really-BASICs

[billstewart]

If you have modern control structures, and subroutines with actual local variables, and don't have line numbers, you're not really running BASIC.

If your control structures are limited to "IF something THEN line# ELSE line#", GOTOs, and GOSUB, then you're using the real thing, or something pretty much like it. You can write non-spaghetti code in even the earliest BASICs, but you had to be disciplined enough to always do it, and without local variables, GOSUBs didn't let you write large programs with multiple authors unless you were very very well behaved about agreeing who got to use what range of name space, especially since most names looked like "LETTER DIGIT DIGIT".

Compare it with LISP's Simplicity (or LOGO, FORTH

[billstewart]

No, not that baroque Common LISP stuff, one of the original LISP dialects, that pretty much just has parentheses and a few simple statement types, or maybe Scheme if you want one that's slightly newer. It's straightforward, simple, clean, beautiful, and powerful enough that you could write the software for, say, an entire universe using it.

Alternatively, if you want a simple language with a short manual designed for kids to use, which is good at drawing lines and circles, there's LOGO; you might not want to write an entire universe in it, but if you want to draw a picture of a planet, it'll do the job (though it'll do a better job of drawing the turtle part and the disk than it will with the elephants in between.) Or if you want one that's not for kids, but lets you pack heavy-duty programs into toasters and is a predecessor of Postscript, there's FORTH.

As far as vast libraries go, you'll see the same thing with FORTRAN; most programming problems are either trying to build utilities for general-programming problems, or trying to solve real-world problems that are more about the problem space than the program space, so it's not surprising that any language that has a clean subroutine interface and a large user community will have lots of libraries written for it. You couldn't do that at all in BASIC, because GOSUBs didn't have local variables, and line numbers weren't locally scoped either, but almost anything other than BASIC or maybe RPG has libraries.

Of course, in practice, I never started using LISP for real applications; I usually use C/C++ or shell/sed/awk. But I've had at least one friend who used XLISP to build prototypes of graphical programs, and found that they were usually not only faster to write than the languages used for the production versions, but also faster to execute :-) And there are a lot of old Smalltalk users around and a few young ones who view their environment the same way.

Re:BASIC is irrelevant

[irishxpride]

It's far better to teach beginning programmers in Pascal or Java than it is to use Perl, for example.

Could you elaborate on this point? I am not primarily a programmer; I am a networking nerd for an ISP. I have however, in the course of my duties, had to utilize a variety of programmer-like skills. I learned programming originally in perl, because it was the closest thing to shell scripting (which I generally understood enough to accomplish my goals) that met my immediate needs. I'm curious what kind of bad habits I may have inherited from my initial exposure to perl as opposed to, say pascal. Specificity would be appreciated as my goal is not to argue, but to hopefully learn and save myself some headaches...

ahh, time sharing BASIC!

[vaporland]

Remember time sharing? We were running BASIC on a Hewlett-Packard Series 2000 Access minicomputer using a Teletype dialup terminal session at 10 characters per second, while the same time 31 other people were doing the same thing. It had a rudimentary operating system and was fairly bulletproof. The hard drive (about 100MB) was the size of a small washing machine.

Of course, it was the secret objective of my classmates to create programs that would bring the entire system to a crawl.

The HP2000 did not directly support any kind of instant messaging (other than master console warnings).

We did some pretty cool stuff in BASIC. My classmates and I created a real-time chat program in BASIC in 1975 that let us talk to students at different schools. Another guy had written a series of FOR / NEXT loops that would play "Blue Danube" through an AM radio plugged into the HP2000's backplane power supply...

language and thought

[mangodhamma]

You might as well say that Johnny can't be a poet because his first language was German not English. There's a relationship between language and thought but they are not the same. A good programmer is a good thinker - of a particular kind. The language he/she uses to express those thoughts is almost (but not entirely) irrelevant. For example, I can express myself more fluently Thai than I can in Khmer, even even though I am equally skilled in both. And while I am not a programmer, I cherish my first experience learning BASIC because it gave me an insight into the world of programming that has been invaluable to me in my work as a writer working with scientists and IT specialists. So three cheers for BASIC.

Long Live the TI-99/4A !

[EricTheO]

I had no cartridges or cassette tape storage for my TI-99/4A, so I had to type in all the BASIC code from books and manuals. I would then play around with the code to alter games. I once looped a prtion of a game where little stick men would randomly collide with mugs of beer and then fall down with a chat bubble then popping up saying "Whoops too Drunk!", the "highlight" of my programing career! ;-) I ran it on my color TV in a window facing the apartments courtyard. That apartment building was like Animal House circa 1980ish. It was a hit of the party though after the first 2 kegs where emptied.

Re:BASIC is irrelevant

[Eraesr]

Perhaps, but Visual Basic .NET is still a bit the retarded brother of C#. Sorry to say so, but some of the nonsense that VB.NET accepts as valid code is just unhealthy.

Re:BASIC is irrelevant

[laffer1]

Bad habits can be formed in any language. I've seen bad Perl, Python, C, C++, Visual Basic, BASIC, sparc assembly, ...

You can teach someone to program, but it's hard to teach them to do it well just like anything else in life. They have to see value in doing things correctly. They have to want to comment their code, to format it, to name variables in a logical way, etc.

I worked with several computers growing up including a Commodore PET, Apple IIe, Commodore 64, and was exposed to BASIC. I had a class on BASIC in 8th grade and another in community college (2001). They used BASIC to teach control structures, basic sorting, etc. It worked well for new students (to programming) because the language constructs were simple and didn't get in the way. Conversely, when I started working on my bachelors degree, the university started with C++. Almost every class used C++. Many students were confused at first.

My wife started with JavaScript at her college and then moved to C++. I think it went much better there because they started with a language students could actually see benefit to. If you can code something simple and add it to your website, it makes it a whole lot easier to learn. (yes, it's scary we're both programmers)

I taught myself VBScript and Visual Basic before college because I wanted to do classic ASP development. I wrote VB ActiveX dlls to wrap functionality for speed, etc. I didn't get the hang of writing gui apps right away, but the usefulness allowed me to learn a lot about the language. Student interest is more important than any language you choose to teach with. You need to come up with interesting projects.

First, you teach them how to program and then you teach them why you do things the way you do. You also teach them the skills to learn new languages or it's a waste of time.

Re:BASIC is irrelevant

[JimFive]

But it's hard for me to imagine programming at the age of 7 (other then a VCR or something), I really didn't have the information or environment until I had a internet hookup.

Kids these days! I learned to program on a Sinclair ZX-81 when I was 10. Back in the day we had these things called magazines, but they weren't like the magazines of today. Back then, the magazines had useful information in them like full program listings with commentary by the author about the design decisions. Some magazines had an ongoing contest to see who could write the neatest program in a single line of BASIC code. In addition, we had these things called Libraries that have Books in them that also had fully commented programs for various computers (Mostly, Commodore and Apple). Most of the software I used that I didn't write came from magazines and books, not computer stores.

Not being able to imagine learning to program without an internet connection kind of boggles my mind. The internet has only really been around in the general public for, what, 15 years? What do you think people did with computers from 1950 - 1990?

Oh, yeah...Get off of my lawn!
--
JimFive

Python, Haskel and yes Pascal

[niftymitch]

BASIC is clearly a left turn.

Better to teach a structured OO language like Python, Haskel and yes Pascal. Java is too hard to get started for the beginner.

One of the historic features of Pascal was that if it would compile it would almost be guaranteed to run (almost). There is a lesson in this as it removes a lot of tedium from the teacher.

Clever languages that are too plastic are too hard for teachers to learn, teach and grade.

The key is the teacher and secondary is the cost but in an Open source world languages like Python, Ruby, Haskel, cost is nill. Teaching the teachers is much harder and more challenging.

Bad coding does not discriminate

[Halotron1]

Or as Atwood put it: You can write fortran in any language

Excellent and horrible coders exist no matter what language you choose.

The logic that a single language can spoil your mind would only lead to you experiencing fewer languages in order to avoid damaging your precious brain!

I'd wager that most of the top programmers in the world have written significant amounts of code in at least 10 different languages.

MySQL and PHP

[Danzigism]

Like a lot of people, I started off with BASIC and thought that is how programming was. I never was exposed to anything object oriented. The day I was exposed to C I decided to give up programming haha. But alas, 15 years later, I found a really good book written by the Head First Labs (O'Reilly) all about how to use MySQL and PHP. I think those who were DEAD SET on BASIC back in the day, should have no problem whatsoever using MySQL. It is plain english. Yes it's a database, but it is exciting when you learn to use it. Add some PHP and you start learning the essential format of more modern code. Simply understanding what semicolons, curly brackets, concatenation, and the basic operators do, will get you very far.