@BASIC insults
There aren't any in this thread. With the exception of the quotation from a distinguished academic in the field who I assume knew what he was talking about.
I first started learning GW-BASIC on an old DOS computer. If I didn't have my first steps in something basic like that, it would have been very difficult for me to move to QuickBASIC and then to VB6. (Also VB .NET)
That's a rather silly conclusion. My first steps were batch and then QBASIC & QuickBASIC, I didn't use BASICA or GW-BASIC before that. It simply doesn't matter what you start with.
I recommend first learning about memory and file oddities
I recommend first learning the language being chosen. Also not sure what you could mean by "oddities" unless you mean "well documented standard operations". The only time those few quirks in modern operating systems with relation to memory and disk space usage even matter would be if one was using a programming language that even let you deal with those low-level details, which sort of excludes almost all present dialects of BASIC. (and a good portion of other languages as well).
then starting with some drag-drop "programming language" like Scratch <I hate it, but a lot of others like it> or Game Maker (for easy game programming). Then there are good tutorial sites for various languages. Easy - just search the Web.
programs like clipper, game maker, Scratch (whatever that is) and it's ilk have some serious problems from a programming perspective.
First: they want to learn about computers and programming. These hardly serve that purpose. I can't speak for scratch, but I know most tools of this nature aren't designed to teach about programming concepts, and instead they are specifically designed to hide them. The thing is, the expression "No need to reinvent the wheel" is often used to defend these products, and it's such a silly excuse, especially in this context. the Original Poster basically wants to
learn how the wheel works, not build a wagon. I'm not saying the tools themselves are bad, but rather that they aren't the most ideal entry point when learning programming; people used, say, clipper, for creating small applications that deal with a database; Game Maker is designed f or, unsurprisingly, creating games. Scratch, from what a short google makes me believe, seems more similar to Flash; in that you draw components and the language constructs are used to mess about with those components (much like actionscript) of course this also has a relatively limited use-base; mostly for, as the site explains, "interactive stories, animations, games, music, and art" Now this can be conceived of rather broadly but it still isn't a general programming language.
Again, I want to reiterate, not that these are bad programs/languages but rather that they are designed for non-programmers, and also for people who currently have no real interest in programming but rather in the creation of the end result. Another prime example of this type of application/language is something like LOGO; And I'm sure a lot of kids became interested in computers because of logo. Thing is, it really oversimplifies things; I mean, that is what it's supposed to do, but if LOGO was the only interaction experience I had telling a computer what to do I would have never even explored programming further. I got more out of writing batch files then I did creating a LOGO "program". The important thing here is that tools like scratch, clipper, Game Maker, and even Visual Basic 6 are more shallow tidal pools on the beach of the programming ocean. If all you want to find are some pretty shells -create a game, basic database UI, animation, simple game etc - then they work fine, but some people are more interested in how those shells form and they will need to swim into the ocean to find out. (Visual Basic 6 is sort of on the fence since in a way it doesn't make the more complicated stuff impossible but it makes it seem so a lot of the time... just try implementing IEnumVariant for tons of fun). Basically, the tools don't teach programming or programming concepts, they over-simplfy them; and while this is all well and good when the product being created (game, animation, etc) is the goal, it isn't when you want to learn about programming because the goal there is to basically acquire the mental tools to do that stuff yourself. That isn't to say there isn't a market for people that are experienced with game maker, anybody who thinks there isn't a market for people who basically rip off another game engine and inject their own scripts and images into it are kidding themselves, because those type of games simply fill the bargain bins everywhere).
A corresponding type of application are things like frontpage, Dreamweaver, and other HTML editing UI tools. The point of those tools isn't to teach their user about HTML, it's to make a website; you don't use a dreamweaver template to learn about HTML, javascript, and CSS, but for the exact opposite reason. In the same vein, a person shouldn't use game maker if they want to learn how to create games, but rather how to
design games.
Again, I don't want to give the impression that I think such tools are stupid, or useless entirely, they are simply useless in the context of learning programming
in general- that is, how the wheel is made, not how it works, because that is what the OP is asking for. It may very well be that they are in fact interested in simply making games or (heaven forbid) database applications, in which case the suggested tools of that nature would suite the purpose quite nicely.
I'd much rather see unjustified optimism than unjustified pessimism.
If that was aimed at me, I am no unjustly pessimistic; just being realistic. If they haven't done anything programming wise it's silly to think that just because they are interested in learning they will become the next "Bill Gates" (Which is more a question of being a good businessman rather then a good programmer the way it is often meant to mean). That would be like me expressing an interest in nature and being told I'll be the next Jane Goodall- it's preemptive optimism. Unless there has been a demonstrated aptitude for the subject matter, it's a rather silly thing to say seriously.
What's the most important is the thinking behind solving the problem rather than the language used.
Yes, but different languages often require different thinking. in C, you could create subroutines, in early versions of BASIC you cannot. in Visual Basic 4 and later, you can create class modules and object heirarchies that you can't create in earlier versions and that completely change the landscape of the language. When the topography of a location changes so too must the way you attack that location. You cannot really create a linkedlist without hacking around the limitations of the language in QuickBasic, for example.
