AHC : Make the BASIC progamming language widespread among hobbyists

[Johannes Parisiensis]

In 1964, John G. Kemeny and Thomas E. Kurtz designed the original BASIC language at Dartmouth College in New Hampshire so that students from other fields than maths and related sciences may be able to use computers without having to learn FORTRAN or, worse, assembler.

This easy-to-learn language, divided in various dialectes, spread itself among the 1970s microcomputers and was critisized by the leading computer specialists for its non-structured nature.

The fortunes of this language dwindled in the 1980s, anthough the Visual Basic canbe seen as a offshot.

The objective is find a POD making the BASIC language widespread among a wide base of amateurs - maybe reducing the number of dialects so that programs are more interoperable, even if, however, one cause of this phenomenon is the differences between the architecture of the computers.

 

[Mark E.]

Not likely. I look at BASIC as more or less a watered-down derivative of FORTRAN and not in the path of the more complex end-user programs of the nineties and beyond.

 

[Johnrankins]

In 1964, John G. Kemeny and Thomas E. Kurtz designed the original BASIC language at Dartmouth College in New Hampshire so that students from other fields than maths and related sciences may be able to use computers without having to learn FORTRAN or, worse, assembler.

This easy-to-learn language, divided in various dialectes, spread itself among the 1970s microcomputers and was critisized by the leading computer specialists for its non-structured nature.

The fortunes of this language dwindled in the 1980s, anthough the Visual Basic canbe seen as a offshot.

The objective is find a POD making the BASIC language widespread among a wide base of amateurs - maybe reducing the number of dialects so that programs are more interoperable, even if, however, one cause of this phenomenon is the differences between the architecture of the computers.

VB is more than an offshoot, it is where BASIC went. To stop VB from replacing 1980s style BASIC you have to get rid of Windows.

 

[Johnrankins]

Not likely. I look at BASIC as more or less a watered-down derivative of FORTRAN and not in the path of the more complex end-user programs of the nineties and beyond.

VB, C#, C++, Java etc. are all turned into CLR (Common Language Runtime) so there is no real difference these days except programmer preference. Anything you can do in C# you can do in VB and vice/versa. The main advantage of C# these days is that it is less verbose while BASIC has the advantage of the syntax being closer to everyday English.

 

[Ameise]

VB, C#, C++, Java etc. are all turned into CLR (Common Language Runtime) so there is no real difference these days except programmer preference. Anything you can do in C# you can do in VB and vice/versa. The main advantage of C# these days is that it is less verbose while BASIC has the advantage of the syntax being closer to everyday English.

No, they aren't. C# is almost always converted into CIL bytecode (though there is no requirement in the specification that it be so), and then executed by either Microsoft's CLR or a third-party interpreter/JIT (like Mono). C++ can be compiled into CIL, but that is certainly not the default that any developer uses (I can't think of the last time we have ever compiled a C++ program targeting the CIL). Practically all C and C++ programs on this planet are compiled against their chosen native targets (x86, x86-64, ARM, etc); there's little reason to use the CIL target if you are writing in C++, since if you cared that much about universal portability you'd have written it in C# in the first place. Java is compiled into JVM bytecode, and then for Android applications that JVM bytecode is recompiled into Dalvik bytecode.

 

[Johnrankins]

No, they aren't. C# is almost always converted into CIL bytecode (though there is no requirement in the specification that it be so), and then executed by either Microsoft's CLR or a third-party interpreter/JIT (like Mono). C++ can be compiled into CIL, but that is certainly not the default that any developer uses (I can't think of the last time we have ever compiled a C++ program targeting the CIL). Practically all C and C++ programs on this planet are compiled against their chosen native targets (x86, x86-64, ARM, etc); there's little reason to use the CIL target if you are writing in C++, since if you cared that much about universal portability you'd have written it in C# in the first place. Java is compiled into JVM bytecode, and then for Android applications that JVM bytecode is recompiled into Dalvik bytecode.

All Microsoft programming languages get translated to the CLR unless you think Microsoft is lying. http://msdn.microsoft.com/en-us/library/ms131102.aspx The vast majority of computers out there are still windows based.

 

[Ameise]

All Microsoft programming languages get translated to the CLR unless you think Microsoft is lying. http://msdn.microsoft.com/en-us/library/ms131102.aspx The vast majority of computers out there are still windows based.

Why would you link to the SQL Server 2005 MSDN? Nothing there states that C++ is compiled to CIL, either (nor would I expect it to do so).

C++ is also not a Microsoft language, but rather is defined by the C++ spec which is ratified by ISO. C# is originally a Microsoft language, but the spec has been made open, while the .NET library still is Microsoft's.

Perhaps you're confused by how the compiler works? Visual C++ (and other compilers as well, like GCC or Clang) compile all modules (source files) into object files - that is, foo.cpp is compiled into foo.obj (or foo.o or whatever said compiler uses). The contents of that object file are not defined by the spec - under Visual C++, it is an intermediate bytecode which is not the same as CIL; this is done so the linker has more context available to it when linking, particularly if you enable LTCG (Link Time Code Generation) where optimizations are performed across module boundaries.

How do I know this? I work with C++ on Sony, Microsoft, ARM, and Apple platforms every day. It is my job. I also occasionally work with Java and C#. I could set the flag (which is not set by default) in Visual C++ to compile CIL instead of the end target, but I don't, because that would be silly.

If you're curious, the original language extension used by Microsoft for C++ under the CLR was called "Managed Extensions for C++". It was replaced by C++/CLI (ECMA-372), which has been mostly superseded by C++/CX (which I don't like at all). I never use either of these simply because there's no need - there is little that the .NET runtime offers me that WinAPI and libstd++ don't offer.

I'd point out, again, nothing in the C# spec mandates CIL, and nothing in the C++ spec mandates any target, either. If you had the appropriate backend for a compiler, there is no reason you couldn't compile C# directly to ARM64 machine code, or to JVM bytecode, or even to C++ (there are some weird backends to convert one language to another). The same goes for C++, or Java, or any other language. C# generally targets CIL because that is what the most popular compiler (Visual C#) does by default. Visual C++, by default, targets x86-32. Setting up C++/CX or C++/CLI is kind of a pain, actually.

However, just because any language can target basically anything doesn't mean they're equal. C# is capable of a lot of things that C++ is not, for instance, like reflection. The C++ languages defines practically nothing for this. BASIC is even simpler - it simply can't do as much, and because BASIC doesn't encode much type information, etc (it is far too high level) its performance suffers. It is also a nightmare to read for engineers like myself.

 

[ChaosNDiscord]

BASIC was the first language I learned! It helps that the command screen of C-64 was essentially a BASIC compiler. If you can make that system more widespread and adopted, well then perhaps more people would have learned at least the 'basics'.

Load"*",8,1

Woot!

 

[Ameise]

BASIC was the first language I learned! It helps that the command screen of C-64 was essentially a BASIC compiler. If you can make that system more widespread and adopted, well then perhaps more people would have learned at least the 'basics'.

Load"*",8,1

Woot!

BASIC is a poor language to do any high-performance development on, particularly on the systems available in the 1980's and early 1990's. There is very little contextual information available to the compiler, and the performance of emitted binaries is terrible compared to ones written in assembly, let alone even C or C++.

There's a reason most games until the early 90's were written in Assembly, and thereafter most games are still written in C or C++.

 

[Johnrankins]

Why would you link to the SQL Server 2005 MSDN? Nothing there states that C++ is compiled to CIL, either (nor would I expect it to do so).

C++ is also not a Microsoft language, but rather is defined by the C++ spec which is ratified by ISO. C# is originally a Microsoft language, but the spec has been made open, while the .NET library still is Microsoft's.

Perhaps you're confused by how the compiler works? Visual C++ (and other compilers as well, like GCC or Clang) compile all modules (source files) into object files - that is, foo.cpp is compiled into foo.obj (or foo.o or whatever said compiler uses). The contents of that object file are not defined by the spec - under Visual C++, it is an intermediate bytecode which is not the same as CIL; this is done so the linker has more context available to it when linking, particularly if you enable LTCG (Link Time Code Generation) where optimizations are performed across module boundaries.

How do I know this? I work with C++ on Sony, Microsoft, ARM, and Apple platforms every day. It is my job. I also occasionally work with Java and C#. I could set the flag (which is not set by default) in Visual C++ to compile CIL instead of the end target, but I don't, because that would be silly.

If you're curious, the original language extension used by Microsoft for C++ under the CLR was called "Managed Extensions for C++". It was replaced by C++/CLI (ECMA-372), which has been mostly superseded by C++/CX (which I don't like at all). I never use either of these simply because there's no need - there is little that the .NET runtime offers me that WinAPI and libstd++ don't offer.

I'd point out, again, nothing in the C# spec mandates CIL, and nothing in the C++ spec mandates any target, either. If you had the appropriate backend for a compiler, there is no reason you couldn't compile C# directly to ARM64 machine code, or to JVM bytecode, or even to C++ (there are some weird backends to convert one language to another). The same goes for C++, or Java, or any other language. C# generally targets CIL because that is what the most popular compiler (Visual C#) does by default. Visual C++, by default, targets x86-32. Setting up C++/CX or C++/CLI is kind of a pain, actually.

However, just because any language can target basically anything doesn't mean they're equal. C# is capable of a lot of things that C++ is not, for instance, like reflection. The C++ languages defines practically nothing for this. BASIC is even simpler - it simply can't do as much, and because BASIC doesn't encode much type information, etc (it is far too high level) its performance suffers. It is also a nightmare to read for engineers like myself.

Again unless Microsoft is lying than VB, C# and C++ all get turned into the CLR. http://msdn.microsoft.com/en-us/library/vstudio/k1s94fta(v=vs.100).aspx As you can see they are all part of the .net framework and the previous article showed said all .net framework languages get translated into the CLR. This only applies to windows based machines but the vast majority of PCs out there are windows machines. Another msdn article on the same subject if you don't like the other two. http://msdn.microsoft.com/en-us/library/ms131089.aspx You are years behind the times, at least when it comes to .net languages.

 

[Ameise]

Again unless Microsoft is lying than VB, C# and C++ all get turned into the CLR. http://msdn.microsoft.com/en-us/library/vstudio/k1s94fta(v=vs.100).aspx As you can see they are all part of the .net framework and the previous article showed said all .net framework languages get translated into the CLR. This only applies to windows based machines but the vast majority of PCs out there are windows machines. Another msdn article on the same subject if you don't like the other two. http://msdn.microsoft.com/en-us/library/ms131089.aspx You are years behind the times, at least when it comes to .net languages.

They're not lying, you're just not reading MSDN properly. Again, this is my field.

I will even quote the MSDN page you listed:

You can develop your .NET Framework applications in Visual Basic, Visual C#, Visual F#, or Visual C++; any of these programming languages can be used equally well.

Notice, can. The vast majority of C++ programs do not use .NET (there are large restrictions involved in using it, along with performance issues to take into account). I haven't seen an F# program in a very long time. Also, again, MSDN in this case only covers Visual Studio. There are other compilers, and indeed other explicit settings in Visual Studio. I can actually paste a screenshot of Visual C++ or Visual C# (2013) if you'd like, in particular the project settings windows.

Very, very few people that I've met or work in this industry use C++ with .NET. It is too restricting and causes problems (and isn't really very beneficial).

Also, you're misunderstanding what the .NET framework is. C++, C#, etc aren't "part of the .NET framework". They are languages which can target CIL (or any other target, really), which enables them to link to and use the .NET Framework. The .NET Framework itself is a set of libraries (aka a framework) which are built and target the CIL.

I am still confused why you keep linking to the SQL Server MSDN, as well. The second link you give doesn't cover at all what you're talking about, and the first you appear to have misread.

If you want further proof - I've written a bootloader in Visual C++ for x86-64 systems. That is, it's a small binary blob that the BIOS can execute. It's the staging part for a kernel (like NT, or Linux, or a hobby kernel). If it were CIL, the CPU would not have been able to execute it (there is no CLR runtime at that point). I also work at a game developer professionally writing games, and I also do systems development as a hobbyist. You're arguing with me about something that I not only do for a living, but study in depth.

Also, if you really want to see how .NET can integrate into Visual C++:

http://msdn.microsoft.com/en-us/library/68td296t.aspx

Notice, C++/CLI is what they call C++ with .NET. There is a specific section on MSDN for using C++ with the CLR. I've had to read it in the past because certain pesky Microsoft platforms require at least a token C++/CX or C++/CLI binding layer. Notice, again the can that is part of the topic.

 

[viewcode]

VB, C#, C++, Java etc. are all turned into CLR (Common Language Runtime) so there is no real difference these days except programmer preference. Anything you can do in C# you can do in VB and vice/versa. The main advantage of C# these days is that it is less verbose while BASIC has the advantage of the syntax being closer to everyday English.

This is exactly the same as saying "Bacon, carrots, lard, wine are all turned into flesh and poo so there is no real difference these days except eater preference."...

The point is not that code in each language can be compiled/interpreted into a form that can be run. The point is that each language has its own syntax, vocabulary and quirks. BASIC was popular because it was close enough to English to be easily comprehensible. But the tricks used to make it comprehensible also meant that when the source code was translated into object code and linked, it took longer to run than it would have if it was written in, say, Assembler.

Professional programmers took (broadly) two routes as follows:

• Application programmers (games developers, etc) focussed on languages that ran efficiently, so the popularity of Assembler, C, C++, Java, etc. These languages had elements other than English (eg "{", "++", or even ";") and quirks (e.g. garbage disposal) and were not intuitively obvious. They are usually used to write applications that are later run by somebody else
• Business programmers focussed on languages that could be understood and rewritten over several years, so the popularity of BASIC, COBOL, Visual Basic, etc. These languages look like English sentences and programs written in them can be maintained over decades. They are usually used to write applications that are run in-house.

Incidentally, there is a gender split here: the former are mostly male and young, the latter are more female and older.

BASIC is an useful tool for learning programming, but sooner or later programmers progress down one route or the other and become more specialised. Somebody writing Visual Basic code in an Excel macro, will have little in common with somebody who writes SAS code on a mainframe, who in turn will have little in common with somebody who writes C++ on a desktop. BASIC was popular with hobbyists, but for professionals different languages (if we define Visual Basic as a "different language" for the moment) were more useful.

 

[Ameise]

This is exactly the same as saying "Bacon, carrots, lard, wine are all turned into flesh and poo so there is no real difference these days except programmer preference."...

Should be important to note, again, that as I've stated a few times, he's not correct. C++ can be compiled to CIL, but very few do so.

 

[ChaosNDiscord]

BASIC is a poor language to do any high-performance development on, particularly on the systems available in the 1980's and early 1990's. There is very little contextual information available to the compiler, and the performance of emitted binaries is terrible compared to ones written in assembly, let alone even C or C++.

There's a reason most games until the early 90's were written in Assembly, and thereafter most games are still written in C or C++.

Well yeah, but, it was fairly easy to understand and for the most part, self teach with the aid of a very poorly written BASIC instruction book. Without that I probably never would have developed the interest in programming and computers I have now.

Would I be writing high end games in BASIC? Hell no, but it was easy enough to be able to program some fun little easy games to show off to friends and such.

Later I became a web developer and largely worked on corporate systems that were heavily microsoft flavored so I often wrote and developed programs in VB, which, was heavily flavored by the earlier BASIC syntax so it was a lot easier of a jump than shifting into a completely foreign programming language.

I don't think anyone is arguing BASIC would be used widespread professionally for high end products, but for hobbyists as the OP mentions, that wouldn't be much of a stretch as I clearly remember a lot of programs back in the early 80s written for the c-64 and being passed around on floppys.

 

[Johnrankins]

They're not lying, you're just not reading MSDN properly. Again, this is my field.

I will even quote the MSDN page you listed:

Notice, can. The vast majority of C++ programs do not use .NET (there are large restrictions involved in using it, along with performance issues to take into account). I haven't seen an F# program in a very long time. Also, again, MSDN in this case only covers Visual Studio. There are other compilers, and indeed other explicit settings in Visual Studio. I can actually paste a screenshot of Visual C++ or Visual C# (2013) if you'd like, in particular the project settings windows.

Very, very few people that I've met or work in this industry use C++ with .NET. It is too restricting and causes problems (and isn't really very beneficial).

Also, you're misunderstanding what the .NET framework is. C++, C#, etc aren't "part of the .NET framework". They are languages which can target CIL (or any other target, really), which enables them to link to and use the .NET Framework. The .NET Framework itself is a set of libraries (aka a framework) which are built and target the CIL.

I am still confused why you keep linking to the SQL Server MSDN, as well. The second link you give doesn't cover at all what you're talking about, and the first you appear to have misread.

If you want further proof - I've written a bootloader in Visual C++ for x86-64 systems. That is, it's a small binary blob that the BIOS can execute. It's the staging part for a kernel (like NT, or Linux, or a hobby kernel). If it were CIL, the CPU would not have been able to execute it (there is no CLR runtime at that point). I also work at a game developer professionally writing games, and I also do systems development as a hobbyist. You're arguing with me about something that I not only do for a living, but study in depth.

Also, if you really want to see how .NET can integrate into Visual C++:

http://msdn.microsoft.com/en-us/library/68td296t.aspx

Notice, C++/CLI is what they call C++ with .NET. There is a specific section on MSDN for using C++ with the CLR. I've had to read it in the past because certain pesky Microsoft platforms require at least a token C++/CX or C++/CLI binding layer. Notice, again the can that is part of the topic.

I agree C++ is on its way out, just that it is part of the framework along with VB, C# and F#. C# has definitely taken a lot of the percentage of C++ programmers. I didn't argue that C# isn't replacing C++ just that it is all part of the framework.

I was being quick with it. We don't need to get into the gritty details. The point is all .net languages (IOW those languages that use the .net library) are converted into the CLR. I used the SQL MSDN because it came up first in my search, nothing more.

I also assume you missed this The .NET Framework class library is an object-oriented collection of reusable types that tightly integrate with the common language runtime. You can use these types to develop traditional command-line or graphical user interface (GUI) applications, as well as applications based on ASP.NET, Web Forms, and XML Web services. You can develop your .NET Framework applications in Visual Basic, Visual C#, Visual F#, or Visual C++; any of these programming languages can be used equally well.

The point is that all the various visual studio languages eventually use the same CLR which is what your computer actually runs. Other compilers are indeed different but since the vast majority of PCs out there are windows based most professional programmers wind up using the various Visual Studios languages. They are relatively easy to use, very flexible and are certain to run well on Windows machines.

 

[Sideways]

Could BASIC be used within a program? So instead of being a true programming language, it's more a tool for getting a program to do things with a set of executable commands added in?

Maybe the POD is simply that a hobbyist community develops in the early days of the internet, so a community uses it largely for amusement. They may have an educational outreach programme - IOTL Esperantists stopped claiming to be speakers of a future universal language and started claiming Esperanto was a simple language to learn as a stepping stone to learning others. Maybe BASIC enthusiasts make the same argument.

It may not be true, but maybe they could convince some people.

 

[Johnrankins]

This is exactly the same as saying "Bacon, carrots, lard, wine are all turned into flesh and poo so there is no real difference these days except eater preference."...

The point is not that code in each language can be compiled/interpreted into a form that can be run. The point is that each language has its own syntax, vocabulary and quirks. BASIC was popular because it was close enough to English to be easily comprehensible. But the tricks used to make it comprehensible also meant that when the source code was translated into object code and linked, it took longer to run than it would have if it was written in, say, Assembler.

Professional programmers took (broadly) two routes as follows:

• Application programmers (games developers, etc) focussed on languages that ran efficiently, so the popularity of Assembler, C, C++, Java, etc. These languages had elements other than English (eg "{", "++", or even ";") and quirks (e.g. garbage disposal) and were not intuitively obvious. They are usually used to write applications that are later run by somebody else
• Business programmers focussed on languages that could be understood and rewritten over several years, so the popularity of BASIC, COBOL, Visual Basic, etc. These languages look like English sentences and programs written in them can be maintained over decades. They are usually used to write applications that are run in-house.

Incidentally, there is a gender split here: the former are mostly male and young, the latter are more female and older.

BASIC is an useful tool for learning programming, but sooner or later programmers progress down one route or the other and become more specialised. Somebody writing Visual Basic code in an Excel macro, will have little in common with somebody who writes SAS code on a mainframe, who in turn will have little in common with somebody who writes C++ on a desktop. BASIC was popular with hobbyists, but for professionals different languages (if we define Visual Basic as a "different language" for the moment) were more useful.

Of course there are differences and certain things can be done quicker in different languages. As I said before VB is more verbose than C#. You can do the same thing using VB but it will take you longer. There is nothing these days that you can do in C# that you can't do in VB. VB will usually take you longer to write as it is more verbose as I said earlier. The point is that you can do whatever you want to choose as a language and it will, in the end, boil down to the same thing. C# main advantage is that it is written quicker than VB, which is important in and of itself.

 

[Ameise]

I agree C++ is on its way out, just that it is part of the framework along with VB, C# and F#. C# has definitely taken a lot of the percentage of C++ programmers. I didn't argue that C# isn't replacing C++ just that it is all part of the framework.

I was being quick with it. We don't need to get into the gritty details. The point is all .net languages (IOW those languages that use the .net library) are converted into the CLR. I used the SQL MSDN because it came up first in my search, nothing more.

I also assume you missed this The .NET Framework class library is an object-oriented collection of reusable types that tightly integrate with the common language runtime. You can use these types to develop traditional command-line or graphical user interface (GUI) applications, as well as applications based on ASP.NET, Web Forms, and XML Web services. You can develop your .NET Framework applications in Visual Basic, Visual C#, Visual F#, or Visual C++; any of these programming languages can be used equally well.

The point is that all the various visual studio languages eventually use the same CLR which is what your computer actually runs. Other compilers are indeed different but since the vast majority of PCs out there are windows based most professional programmers wind up using the various Visual Studios languages. They are relatively easy to use, very flexible and are certain to run well on Windows machines.

I didn't say that C++ is on the way out; it's being displaced in certain fields (like general application development) but for high performance applications (like games) there really is no suitable alternative. I'm writing C++ right now.

And you're still wrong about "them being part of the framework". They aren't part of the framework. That makes no sense. The framework is a set of libraries that applications compiled targeting CIL can link to. That includes managed C#, C++/CIL, C++/CX, etc. That excludes native C#, C++, C, etc. I'd point out that even if you were correct (which you aren't) your argument is still invalid - all programs in the end execute as native CPU instructions, which is only a bit lower in abstraction than the CIL is in the first place.

Yes, all .NET languages use CIL (the CLR is a runtime). C++ isn't necessarily a .NET language, nor is C# or any other language. That was my point; C++ compiled to a native target is still going to be substantially faster than C# compiled to CIL.

The point is that all the various visual studio languages eventually use the same CLR which is what your computer actually runs. Other compilers are indeed different but since the vast majority of PCs out there are windows based most professional programmers wind up using the various Visual Studios languages. They are relatively easy to use, very flexible and are certain to run well on Windows machines.

You are again misunderstanding what MSDN is saying. They do not all use the CLR. They use the CLR if you tell them to, and that is not a given. Visual C++ can be instructed to compile a project as a C++/CX project, or C++/CLI. Those aren't even the defaults, though - the default template project that Visual C++ uses is the same old native target it's always been. Absolutely no software I've written using Visual C++ has any dependency on .NET or the CLR (other than a quick launcher I whipped up). MSDN is referring to the capability to use .NET, not the requirement.

This also glosses over the large differences in features between each of the languages.

 

[viewcode]

Of course there are differences and certain things can be done quicker in different languages. As I said before VB is more verbose than C#. You can do the same thing using VB but it will take you longer. There is nothing these days that you can do in C# that you can't do in VB. VB will usually take you longer to write as it is more verbose as I said earlier. The point is that you can do whatever you want to choose as a language and it will, in the end, boil down to the same thing. C# main advantage is that it is written quicker than VB, which is important in and of itself.

I wasn't contradicting you. I was dealing with a different point.

 

[Morty Vicar]

BASIC is ideal as a hobbyist language, it doesn't have to be super powerful, in fact the more powerful a language gets the more complicated it tends to be to write simple routines. I have no head for maths or problem solving of any sort, but a friend introduced me to QuickBasic in school and I was instantly hooked, more from a creative motivation than a bona fide interest in computing or programming. Maybe that's the key here, to get BASIC into schools, once the kids start using it maybe some of their parents do too. Maybe as others have said make the C64 more widespread, last longer (ie they keep producing more advanced machines), maybe make the games industry and the internet slower to really get started, so people have more motivation to create their own content.