For smaller projects, VB6 was great. I wrote a number of tools with it. For anything large-scale, things could get out of hand quickly. I remember having to work on localising a VB4-based ERP system that was very slow, unwieldy and full of spaghetti code.
And in the 90's, what people would do is to do the prototype with VB and expect to write the app in something else. But then the executives would see it, think it's 80% done because the UI was done, and push forward with it in VB. Or it would start out as a small, niche app in VB and then grow in scope.
Either way, what would start off rationally would end up in chaos. Part of that was the language, and Microsoft is to blame there; the fix, C#, came too late. But the other, larger part was the failure of component development. And that's what people miss and that's what still remains to be solved.
Yes, it was an answer to Java but remember, VB apps didn't scale. They exploded at scale. And no matter how much you, as an organization, promised yourself you wouldn't scale up that VB app, it kept happening. So it was also an attempt to try to fix that.
When I was young and stupid I was trying to learn game development in VB6. I had a type library that provided bindings for DirectX. This was in the late 90s, so I would have been on Windows 98.
I learned quickly how SLOW VB was, but was in denial about it. I wanted to make it work, but anything that required more than a few lines of logic made it impossible to maintain even 30 fps. At the time, though, I was afraid of C/C++. I thought "Those languages are too complicated! Why would anyone use them when VB is so simple?"
Back to these times. I try to remake a N body problem simulator. I was trying to imitate an old DOS program called "GRAVITY.EXE" on VB6
I throw it, when I saw that my VB6 was slower that the old 16 bit DOS program, and that setting the timer control to throw events too fast, could make Windows unresponsive.
I used to have an irrational fear for curly braces and semicolons, given BASIC looks clean and simple. I see that now in some young programmers who try to stick to Python. Interestingly, seeing Rust code for the first time also reminded me of that.
When I was young, I saw the same until I worked with a team of professional devs and the code was clean and performant and easy to get around in.
> VB4-based ERP system that was very slow
Yep. VB4 was made for the transition from Windows 3.1 to 95. The first effort was good enough but not great. IIRC, it compiled to byte code and then a runtime would interpret it. Once VB5 came out with native compilation, the resulting code became very snappy.
In my opinion basic was not about the language. It wasn't that easy to understand, it wasn't that powerful, it was slow.
It was about simplicity, it was easy to make sound. To draw to the screen.
It was about accessibility. Computers with it would boot right to a basic prompt. To use a computer was to program, and you were certain to naturally be exposed to programming and learn by doing rather than in a classroom.
It was also about the fact you could easily open up other programs and read and modify them, much like older fashioned web and HTML.
That's why these new basic projects fail so often. Python is simply better, and the ease of use of modern computers and phones means that the push basic used to have is just gone.
Basic is being able to hear your data when you play it on a tape. It's about being able to cheat in your game by changing the code. It's typing code in from magazines and making games in math class. It's warm and fuzzy and you just can't bring it back.
actually, basic being so slow might be some kind of good feature. one of the first programs i ever wrote was an implementation of conway's game of life in basic on a z80 cp/m machine. i was unhappy with the results. this made me learn z80 assembler so i could get it to run much, much faster.
but probably, looking back from old age, what i should have done was improve the algorithms i was using.
i think basic is a good thing. perhaps a bit sad that people today do not have instant access to it.
Maybe programming is dead due to app stores on one hand and AI on the other, but I still wish that web browsers included an easy and visible onramp to the rather capable and powerful JavaScript language that is built into every one of them.
Actually, I was amazed the first time I used visual basic. This was probably the first version of visual basic and it was loooong ago. It let you do gui programming immediately, which was pretty new. You sort of intuitively learned event-driven programming in a few minutes.
Drag a button on the screen, and with a click you could enter the code to run when it was pressed.
In comparison, lots of systems since then have been pretty powerful, but you exchanged that for layers (and layers) of complexity that many people never got through.
For example, I was pretty surprised the first time I used xcode. I thought it was apple - and they would make things easy. But in comparison to my first try at visual basic it was not intuitive, even after using it a while. (Did Steve Jobs ever try it?)
There’s nothing inherently slow about Basic. There were several implementations of Basic compilers that were plenty fast enough. Sure, they weren’t as fast as C, C++, Pascal, and Fortran, but they were good enough to make commercial software with.
The first BASIC implementations were compiled. In fact, compilation to machine code was one of the 4 original requirements for the language when it was first developed as a language for the Dartmouth College time-sharing system (efficiency and performance being directly related to the number of users that the system could support.)
Many early BASIC implementations for microcomputers (such as tiny BASIC) prioritized memory usage over speed, so they tended to favor interpreters. But as others have noted, numerous compiled BASIC implementations existed as well.
Later dialects of BASIC had code blocks and functions, making GOTO unnecessary. If you were using GOTO in your BASIC code in the 90s, you were doing it wrong.
try / catch is almost he opposite of On Error Resume Next
OERN would make it so uncaught errors were silently ignored and execution would just continue on the next line as if nothing wrong happened. This would likely result in more errors, which would then also be ignored.
Frustratingly, the "on error goto" mechanism in Visual Basic is basically try/catch, except that the error object doesn't give you any kind of stack trace (not even the procedure or line number where the error occurred) so you have to constantly catch and rethrow errors just to add context information.
But we are talking about programming languages today. The article in question is "Nostalgic for VB? BASIC is anything but dead." The article details alternatives you can run today, such as FreeBASIC.
The commenter you're replying to argues that BASIC no longer has the advantages it had in 1963, which are unrelated to the language syntax, and that Python offers a closer alternative in that it makes programming accessible.
If they're invisible, your text editor is doing something very wrong. They cause a fixed amount of blank space that otherwise would not be present. That is very visible.
BASIC is very verbose and diluted syntax. This makes it great when you're coming from say English as your language, but it makes absorbing a larger system slower and and harder IME. It also jumps through some hoops to accomplish lower-level or peripheral tasks, which makes understanding what is actually happening at a conceptual level more difficult. So I think the correct level of "UNDERSTAND" needs to be considered.
If Visual Basic is supposed to be for beginners, it's surprisingly complicated.
It has both value types and reference types and both can be passed either by reference or value, giving four ways of passing parameters compared to Python's one way.
It has both early and late binding, compared to Python which again has only one kind.
It has "default properties" on objects, which lets you sometimes use some objects directly in place of some of their properties but sometimes not.
It has different syntax for function calls in expressions and statements, combined with a completely redundant third way (the "call" statement) that confuses matters further.
And in addition to being both statically and dynamically typed (with "Object" declarations) it's also both strictly and loosely typed (with Variant values).
It was also created 16 years before the first version of Python, 36 years before Python2.
It was written in time with completely different paradigms and the two languages weren't even built with the same design considerations in mind.
Obviously, newer languages are going to tend to be easier to work with for beginners, that should be a given. We've made massive improvements in the field in the last few decades.
Scheme was created 16 years before Visual Basic and has none of these problems, so I don't see what the age of the language has to do with how difficult it is to understand. (Also, Python and Visual Basic were actually both created in 1991, so they're contemporary.)
Basic was created 11 years before Scheme, and VB was itself derived from Basic, so would have had much of the same design decisions and considerations as a result.
The question I was addressing was whether it was "easy to understand". I'm sure there are explanations for why it's such a complicated language, such as e.g. the "call" statement probably being there for compatibility with QBASIC which required it in some corner cases.
How does BASIC being easy to use or not have anything to do with newer languages being easier to use?
Newer languages have the benefit of hindsight and rapidly improved technology. Better graphics, more power, fewer of the heavy limitations that came with early technology. Between the time that BASIC and Python first came out, we went from System/360 mainframes to Windows 3.0 on our home desktops. Obviously newer languages are going to be able to take advantage of this increased power and wider abilities of computers.
It should be plainly obvious to anyone who takes more than a second to think about it.
Let me be clearer. The category changes and the changes can often be applied retroactively.
"In hindsight, that wasn't actually easy. It was a massive opportunity for highly motivated learners, but the amount of motivation needed was more than what can fairly be called easy."
I'll compare to an early bicycle with no pedals. They were a breakthrough at the time, but in hindsight they hadn't reached "easy".
And just like making a better bike, plenty of the issues with BASIC could have been fixed on the equipment of its heyday.
And it's not just that things improved over time and you need to be new. There are very old bikes that are plenty easy. But it took a while to figure out.
A strictly-enforced style guide can remove that confusion. My struggle with VBA is mostly around idiosyncracies in the Microsoft Excel object model (e.g. a "window" object has members for both the entire workbook and for a single worksheet).
It is. The way the two are defined/called us different, making refactoring a nightmare if you ever have a subroutine that later needs to be converted to a function to return a value. There's a reason other languages don't make this distinction. In every other language I'm aware of, it's all functions, and some return values and some don't, and refactoring between the two is easy.
No, I get what they're saying, especially with older dialects such as C64 BASIC. It may be approachable to beginners, but the thought of trying to maintain software written in it isn't incredibly pleasant.
On the C64, I find even 6510 / 6502 assembly to be easier to follow than C64 BASIC.
I noticed basic is simple and easy to read if you don't try to add structure to your program. As soon as you start messing with functions, arrays, variable types, it all becomes a mess.
This is 1964’s BASIC, and it is quite basic (if you pardon the pun). It had no form of functions or procedures, not even the most elementary “GOTO and remember where you came from so you can return here later”. If you look at a more modern Basic implementation, they are more complex, and tend to have pointless complexities like differentiating Sub and Function procedures or two call syntaxes.
That's kind of the point. BASIC was conceived as a simplified FORTRAN that beginners could learn in an afternoon but which was capable enough to enable them to write useful programs.
1964 BASIC did support single-line function definitions (see page 13.)
Dartmouth BASIC kept evolving into the 1980s and seems to have turned into a pretty capable language that retained much of the accessibility of the original. I wonder what would have happened if True BASIC had been a free/open source project instead of proprietary software.
It was capable enough for writing very simple programs on one of the earliest time-sharing systems (DTSS). Not really what we'd consider "useful" today, though. To be fair, you hit the limits of usability pretty quickly on any 1960s language. Even text editing was comparatively kludgy back then, which is why BASIC used line numbers to ease line editing on teletype terminals. There was no point to a "free-form" language since everything was entered line-by-line to begin with.
> Not really what we'd consider "useful" today, though
Simple numerical/mathematical programs are certainly useful today, especially for students and researchers - BASIC emerged from Dartmouth's math department after all. Of course now we can run them on pocket calculators - some of which still run BASIC!
As I understand it, subsequent editions of BASIC running on Dartmouth's time-sharing system were used for a wide variety of applications, including:
- numerical programs (including scientific and engineering computation)
- simulations
- text formatting and document preparation
- statistics and data analysis
- communication programs such as online chat
- data storage and retrieval
- course management and grading
- games
- printing things from form letters to large signs
etc.
Regarding the limits of 1960s computing, it's worth noting that primitive computing systems, along with numerical and control software, were useful in helping to send humans to the moon and back (among other impressive accomplishments.)
> 1964 BASIC did support single-line function definitions (see page 13.)
Those are extremely basic functions that can only do a simple math operation on a single number. This is a function in the math sense, but not useful for programming.
I don't think we're in disagreement except on the point as to whether DEF FN was a useful feature or not. It's certainly useful for numerical code.
Personally I'm kind of impressed that it existed back then at all, as well as the simplicity of original BASIC that enabled regular people to write useful programs, nearly 60 years ago.
No. I actually liked VB when I was a teenager. It was very easy and (using ms parlance at the time) quick to develop small applications. For me it was not much more from a mere toy. I know some people used it for serious purposes, but I'm sure many of these uses were makeshift prototypes that eventually nobody had the time or money to rewrite. I don't think many serious and popular apps were written in VB and were maintained for a long time. I don't think it was adequate for that purpose and I don't know anyone who thought it was.
I used to joke that anyone claiming to be a "Very senior VB developer" was basically saying, "I don't know how computers work".
While it was a funny way of blowing off steam (and indeed senior VB devs didn't seem to know things like calling conventions or static linking), therein lies the miracle of VB. People could make business applications without having to know that stuff.
Often enough, they had VB devs for the frontend, and the heavy lifting done in *.dll's written by more hardcore C++ devs. I guess it worked out well enough that way.
I also got a copy of VB (I think VB4) as a teenager and it was a perfect stepping stone into GUI programming. I had been writing DOS games in QBASIC for years, and some basic (heh) C/C++. But the leap to writing Windows apps in C++ was terrifying. There was so much more to learn. What the heck is an SDK and why does the Windows SDK contain like 5 trillion different functions, many of which have ALMOST the same name and method signature? What is an event? What on earth is a CORBA or an OLE? As a teen with no mentor and no resources besides books and the early web it was overwhelming.
But VB did so much of the work for you. And it was BASIC, which I already knew well. So it was exactly what I needed to understand the fundamentals without having to boil the whole ocean at once just to get a window with a button on my screen.
Agree it wasn't really suitable for large scale projects (although it got used for them anyway heh). Somehow VB apps always looked and felt "wrong", like they were a cheap knockoff. But for learning, and writing quick non-commercial apps, it was just right.
All that said, I feel no nostalgia or desire to go back.
If you'd like run classic BASIC programs on your old programmable calculator (HP 15-C) you can use this compiler written in Idris: https://gitlab.com/michaelzinn/voyc
It was mentioned briefly at the end of the article, but I think Free Pascal and Lazarus are the closest in spirit to what Visual Basic classic was.
It’s the best drag and drop interface builder I’ve seen in an open source project and it’s cross platform and compiled to static binaries for easy distribution.
Personally I'm pretty fascinated by the way these projects typically center around a traditional forum, with various software structures in place that shape the user experience.
For example, prolific library authors may be invited to publish directly to their own subforum and kind of use it as their own website, etc.
When new projects start, spin off, fork, etc, the forum is often the first part of the user experience to see created, frameworked and decorated in depth.
Decent is really subjective, so maybe a good starting point is to give an actual example or specification of what you're looking for.
One advantage of this particular coding ecosystem is that you can use Delphi docs, techniques and tutorials as well, which can be helpful to know.
But if your specification is "cover all aspects of Lazarus itself at confirmed 1:1 functionality with the current major version" then it might be a difficult ask.
There are some really great resources out there, but they are not going to meet every definition of decent docs.
For me it was enough to watch some YouTube tutorials[1] to get the gist, identify some idiomatic workflows, start building, do a bit of searching in different documentation resources, and ask follow-up questions at the forum.
It's nice that we can also ask ChatGPT for help these days too.
The traditional forum model is mostly a strength but has some drawbacks, strength is that you have a treasure trove of searchable knowledge and if you ask a question to the dedicated community you have high change to get a helpful reply, because almost everyone using that language is on that forum.
The drawback is that there is usually relatively little information outside of the forum and uncommon that code is shared on things like github, instead code sharing is typically done by copy&paste on the forum, which makes it a bit harder to track and standardize conventions.
I wrote the linked article because I wanted to explore dead easy programming environments for people who liked BASIC and VB, partly because 40 years ago, I liked BASIC myself.
C++ is the anti-BASIC. So are virtually all modern programming tools. Vast complex hard languages designed by professionals for professionals. Anything with braces in it wasn't designed for beginners.
Python is also very much a C-ish Unix-ish tool, too. It's just that Unix folks are so used to this that they don't notice.
What does % mean? Oh, well, it depends. Where?
How do you print a number? Oh, well, it depends. You can use %d but also %f but only if you want so many decimal places...
This is ugly crufty stuff, but if you're used to that and grew up with it, it's normal.
Python only looks easy and simple if you're used to C.
I think VB was such a smash hit not because of the language but because the ease of writing a quick GUI for Windows, there wasn't really anything quite like it at the time. Other GUI builders existed but were harder to use and not as well integrated.
The appeal of VB lives on in WinForms with C# as the backing language. Initially MS tried hard to keep VB.Net around as a fully emancipated partner but it turns out everyone just moved over to C#.
> I think VB was such a smash hit not because of the language but because the ease of writing a quick GUI for Windows, there wasn't really anything quite like it at the time.
I agree completely. The language itself was pretty crap, but there was nothing like it for rapid layout and wiring of a GUI. IMO, even modern tools like the storyboards and visual components in Xcode don't quite make it (they're more powerful, certainly, but also much more complicated to use).
Basically how Pascal still exists in Delphi/Lazarus. I'm not a fan of the language, but Rapid cross-platform GUIs that compile to native code instead of bytecode that anyone can just drop to ILSpy are really compelling.
> "Initially MS tried hard to keep VB.Net around as a fully emancipated partner"
Not very hard[1]; "making Visual Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.
And the sky didn’t seem to fall, not inside Microsoft. VB6 developers were up in arms, but they were disappearing anyway, because most of them were corporate developers who were migrating to web development anyway. The real long term damage was hidden.
With this major victory under their belts, the MSDN Magazine Camp took over. Suddenly it was OK to change things. IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon."
As a classic VB and C# developer, that was their mistake. VB.NET has no reason to exist. If it was much more backwards compatible with VB Classic it would have had a reason to exist -- it would have allowed VB projects (of which there were millions) to migrate over to .NET smoothly.
and would give a lot for something contemporary and cross-platform along those lines which was likely to stay around. Thought that was going to be Runtime Revolution/Livecode, but that went back to closed source --- I suppose I should look at Lazarus/FreePascal (but I didn't do well with Delphi back in the day).
Applescript Studio seemed promising --- really wish that that had been opened up to make iOS apps.
IMHO the key distinction is between BASIC, the group of languages, and VB, the SDK. The article notes this but I think it is really the crux. In other words, did BASIC draw us in because it is a straightforward language? Or because of the power that VB provided?
As others point out, many hobbyists still use variants of BASIC...I don't think we can claim it's the most practical language for most uses, but it has its niche for sure, and is fun to use.
Visual Basic, however, while at the time representing a _fantastic_ entry point to development (at least it was for me), has been legitimately replaced by other, newer models, some of which the article notes.
"Visual Basic, however, while at the time representing a _fantastic_ entry point to development (at least it was for me), has been legitimately replaced by other, newer models, some of which the article notes."
Before VB setting up a GUI application was hard and required a lot of specialist knowledge, then VB made it easy, and its replacements on the web are making it hard again :-). I still don't know an easy way to set up a web with a database that also allows you to go into depth if needed.
Yeah, I loved VB's drag-and-drop method of building a GUI. Are there any programs out there these days that will let you drag-and-drop components to build a web page?
There are some drag and drop webpage builders for WordPress and things like Squarespace which are mentioned ad nauseam on podcasts and YouTube channels which promise something like it too.
My first "language" was straight machine codes. I have then "progressed" to assembly, C and many other languages. For some reasons I've never liked Basic and whenever I had a choice I would avoid it.
I started with a computer that booted to the BASIC prompt, the ZX Spectrum, and later moved to Z80 assembly language.
After the low-level stuff it was MS-DOS 3.3, with DEBUG.com for assembling intel assembler, and later MS-BASIC, Turbo Pascal, C, and all the later languages.
BASIC still has a soft-spot in my life, I wrote a trivial implementation of BASIC in golang which is complete enough to be fun, but missing specific features for running things like the widely-reshared Star Trek game. Maybe I should setup a stretch-goal of completing a bunch of common games/programs and work on it some more.
BASIC was never my cup of tea, but I used it because it was all that was available at the time. And books of programs really helped.
The company I worked for in 1996 made all kinds of money from Visual Basic development for clients. We built what one would call a CRM system, we built a legal document management system, we build a CMS for early web site publishing (kinda sorta echoing wordpress), we build a timecard entry system. The rapid prototype and good debugging support meant quick time to market. And you'd still be able to run them all with the VB6 runtime preinstalled on every windows machine in the world.
I recently discovered various projects of that era on my archive and was kind of scratching my head on what those .cls files meant, and chuckling over my comments from 30 years ago...
This is a great point. I haven't run into an easier visual prototyping system that's accessible and fairly close to what the end user would see from an interaction perspective. Did this way back in undergrad. Used VB to quickly visually prototype and then Visual C++ for the final project.
I think nowadays Python is the new BASIC. It has an interactive mode; It has access to a hell amount of libraries and APIs one can imagine; It is easy to program. I'm sure it can open the door for so many kids.
But you didn't even have to open the references dialog to create an application.
VB was great because it made easy stuff easy but it also made more difficult stuff possible. You could reference other libraries, of course. You could also directly call Win32 APIs. But you didn't need to that. You didn't need any boilerplate or ceremony -- you could drop a button on a form, double-click on it to add code, and make it do something without knowing anything about the infrastructure to make that possible.
As far as I know, there are no tools that do something equivalent now that aren't so sandboxed that it's a dead end.
I started programming with BASIC back in the late 80s and into the early 90s. Started with gw-basic and then with QBasic, both of which were included in versions of DOS.
QBasic was really cool at the time. I wrote a lot of (very crappy and slow) games in it. The documentation was all readily available and it had a lot of power. QBasic (and VB) were very "batteries included" and that was amazing.
But, and this may sound harsh, I've always felt that BASIC was a language of desperation. You use it because it's the only thing available to you, not because you actually want to use it. There was a time where some form of basic was available on literally every computer. This continued well past the 80s with VBA and gave a lot of people the power of extensibility over their applications.
Back when I was writing a lot of BASIC code, I quickly found myself running into walls and realizing that it just wasn't a great environment to build anything serious in. The lack of a real compiler in DOS was the primary reason I found Linux and C in the mid 90s. Once I had my hands on a C compiler I never wanted to look back ever again.
(I know that QuickBasic and Visual Basic existed and could create binaries. But, I was young and couldn't exactly afford them. Before finding C, I was using a BASIC environment called ASIC, which wasn't quite as nice as QBasic, but could produce binaries.)
It makes me wonder how things might have been different for me if DOS came with a C compiler and something like raylib. The lack of a real (free) compiler drove me to Linux. Would I have still gotten into Linux? I don't really know!
You never got to the stage of pirating QuickBasic off of a BBS somewhere. I went from 8bit BASIC to QBasic to QuickBasic and then to VB. I even started writing some assembler and linking it with QB code.
QuickBasic and all the variants filled a niche that exists in multitudes now but did not exist in the early 90s. There weren't many high-level languages with garbage collection in common use.
At that time I was developing on a 286 -- Linux was still far in my future.
But all my friends had pirated copies of every development tool. I don't know how we even got it all. We were lucky to be adjacent to a larger city and therefore have closer access to files and information.
> I know that QuickBasic and Visual Basic existed and could create binaries.
Very small binaries. Unfortunately you had to include the rather large run-time libraries with them (BCOM*.LIB or vbrun*.dll respectively). IIRC vbrun300.dll was >300MByte which was rather large at the time, as well as the library functions it contained an interpreter and your executable wasn't fully native code (your code was transpiled to something the interpreter could process more efficiently, and the executable had a small chunk of native code to load the RTL and get it to execute the rest). IIRC VB6 was the first version to properly compile to native code.
Sorry, yes my scale was off, I meant ~400KByte nor MByte. More than a quarter of a common formatted floppy (half even, given 720KByte-less-overhead disks were far from rare at that point).
One other thing that VB did well was integrate with Windows COM components. I was working on a scientific application at the time. Just for fun, I spent a half an hour to add a button on the data grids that would start Excel and push the data over. The scientists were more excited about the Excel integration than the actual statistical analysis features I was working on.
Hard to be nostalgic for VB when your day job includes a VB6 development rube goldberg machine of multiple VMs to continue to maintain/debug a "not broke" application in 2023. It certainly feels quite broken given the complexity of the rube goldberg machine, but the business priorities to lift/shift/rewrite are always behind the priorities to keep the current users happy.
The article delves into VB's alternatives only, but VBA (Visual Basic for Applications) is also very much alive. My brother uses Excel VBA to teach Decision Support Systems and Genetic Programming at the university. Excel provides a very capable and easy to use environment for data modeling, and Visual Basic provides ample functionality for implementing algorithms on top of it with zero setup cost.
There's a web-based Applesoft BASIC editor that runs in emulated ProDos and has a large library of BASIC software that can be directly loaded (via the dropdown selectors in the top-right) at https://paleotronic.com/applesoft/
There's even the original BASIC version of Oregon Trail!
For a native BASIC interpreter, there's an enhanced version of Applesoft BASIC built-in to the microM8 Apple II emulator -- it has various enhancements including 3D voxel graphics and the ability to draw in SHR (Super Hi-Res) https://paleotronic.com/microM8
BASIC is ripe for a classic if-by-whiskey argument:
If by BASIC you mean the line-numbered language with single-character global variable names, with no flow control beyond GOTO and maybe GOSUB, which encouraged, nay, demanded humans crunch their own programs by removing as much whitespace as possible to fit them in RAM, then it wasn't a good language.
If by BASIC you mean the block-structured language with most modern flow control features, normal ideas about variable names and scope, which allows people to write GUI applications in a short period of time using GUI builders and easy access to libraries written in other languages, then it is a good language, but still not my favorite.
Just curious, theres something like vb6 gui rad tool today for multi platform projects (like it runs in windows, linux and mac) but for a more modern language?
Visual Basic was an incredible leap forward in programming in that it made programming accessible to much wider range of people. People that just wanted to make a computer perform a task without necessarily writing a commercial product or changing the world. Being a child of the 70's/80's, I was fortunate enough to learn by just diving in and writing Basic on a BBC Model B. I think the problem people have with BASIC is the 'B' for Beginner. It created a lot of snobbery. I remember being amazed when Windows came out because it brought a level of consistency to everyday software which meant that by and large you could get the basics of a piece of software without a manual. Before VB, there was a huge barrier to programming in Windows because for a long time it was C which, for all it's power, is not a language many people should be using. I suspect a lot of people here won't have experienced starting with an empty Window, dropping a Button on it, double clicking the Button and being dropped straight into the event handler code. It was a revelation. Especially when you realised that you got access to all of the other Windows goodies like printing, database access etc just by dropping a control onto a Form. Software development now is a long way away from the ease of access that VB gave us and is probably poorer for it.
133 comments
[ 2.9 ms ] story [ 214 ms ] threadEither way, what would start off rationally would end up in chaos. Part of that was the language, and Microsoft is to blame there; the fix, C#, came too late. But the other, larger part was the failure of component development. And that's what people miss and that's what still remains to be solved.
Because it wasn't a fix for VB - it was just the answer to Java.
Somewhat unfortunately, that "answer" swallowed the whole MS development ecosystem, and the VB world never really recovered.
Yes, it was an answer to Java but remember, VB apps didn't scale. They exploded at scale. And no matter how much you, as an organization, promised yourself you wouldn't scale up that VB app, it kept happening. So it was also an attempt to try to fix that.
I learned quickly how SLOW VB was, but was in denial about it. I wanted to make it work, but anything that required more than a few lines of logic made it impossible to maintain even 30 fps. At the time, though, I was afraid of C/C++. I thought "Those languages are too complicated! Why would anyone use them when VB is so simple?"
Yeah...I learned.
When I was young, I saw the same until I worked with a team of professional devs and the code was clean and performant and easy to get around in.
> VB4-based ERP system that was very slow
Yep. VB4 was made for the transition from Windows 3.1 to 95. The first effort was good enough but not great. IIRC, it compiled to byte code and then a runtime would interpret it. Once VB5 came out with native compilation, the resulting code became very snappy.
It was about simplicity, it was easy to make sound. To draw to the screen.
It was about accessibility. Computers with it would boot right to a basic prompt. To use a computer was to program, and you were certain to naturally be exposed to programming and learn by doing rather than in a classroom.
It was also about the fact you could easily open up other programs and read and modify them, much like older fashioned web and HTML.
That's why these new basic projects fail so often. Python is simply better, and the ease of use of modern computers and phones means that the push basic used to have is just gone.
Basic is being able to hear your data when you play it on a tape. It's about being able to cheat in your game by changing the code. It's typing code in from magazines and making games in math class. It's warm and fuzzy and you just can't bring it back.
but probably, looking back from old age, what i should have done was improve the algorithms i was using.
i think basic is a good thing. perhaps a bit sad that people today do not have instant access to it.
Drag a button on the screen, and with a click you could enter the code to run when it was pressed.
In comparison, lots of systems since then have been pretty powerful, but you exchanged that for layers (and layers) of complexity that many people never got through.
For example, I was pretty surprised the first time I used xcode. I thought it was apple - and they would make things easy. But in comparison to my first try at visual basic it was not intuitive, even after using it a while. (Did Steve Jobs ever try it?)
Many early BASIC implementations for microcomputers (such as tiny BASIC) prioritized memory usage over speed, so they tended to favor interpreters. But as others have noted, numerous compiled BASIC implementations existed as well.
Out of all the complaints I've seen about BASIC/Visual Basic, this has never been one of them.
OERN would make it so uncaught errors were silently ignored and execution would just continue on the next line as if nothing wrong happened. This would likely result in more errors, which would then also be ignored.
Something broke but we still moving to the next line.
However, if someone is going to learn, I'll bet they'll pick up python in a similar amount of time, and get a lot better tools when they do it.
BASIC was invented in 1963 and exploded in popularity in the late 70s. Python 1.0 didn't come out until 1991.
The commenter you're replying to argues that BASIC no longer has the advantages it had in 1963, which are unrelated to the language syntax, and that Python offers a closer alternative in that it makes programming accessible.
It has both value types and reference types and both can be passed either by reference or value, giving four ways of passing parameters compared to Python's one way.
It has both early and late binding, compared to Python which again has only one kind.
It has "default properties" on objects, which lets you sometimes use some objects directly in place of some of their properties but sometimes not.
It has different syntax for function calls in expressions and statements, combined with a completely redundant third way (the "call" statement) that confuses matters further.
And in addition to being both statically and dynamically typed (with "Object" declarations) it's also both strictly and loosely typed (with Variant values).
It was written in time with completely different paradigms and the two languages weren't even built with the same design considerations in mind.
Obviously, newer languages are going to tend to be easier to work with for beginners, that should be a given. We've made massive improvements in the field in the last few decades.
The whole point of this comment chain is to discuss whether BASIC was easy to use so it's clearly not a given.
Newer languages have the benefit of hindsight and rapidly improved technology. Better graphics, more power, fewer of the heavy limitations that came with early technology. Between the time that BASIC and Python first came out, we went from System/360 mainframes to Windows 3.0 on our home desktops. Obviously newer languages are going to be able to take advantage of this increased power and wider abilities of computers.
It should be plainly obvious to anyone who takes more than a second to think about it.
Because "easy" is a somewhat relative term. The category will shift over time.
The category shifts over time, sure. But what does that have to do with BASIC being easy or not? They're two separate topics.
"In hindsight, that wasn't actually easy. It was a massive opportunity for highly motivated learners, but the amount of motivation needed was more than what can fairly be called easy."
I'll compare to an early bicycle with no pedals. They were a breakthrough at the time, but in hindsight they hadn't reached "easy".
And just like making a better bike, plenty of the issues with BASIC could have been fixed on the equipment of its heyday.
And it's not just that things improved over time and you need to be new. There are very old bikes that are plenty easy. But it took a while to figure out.
Subroutines don't.
Is that a pointless distinction? Why?
Who ever needs to refactor BASIC!?
On the C64, I find even 6510 / 6502 assembly to be easier to follow than C64 BASIC.
Yes it was.
https://www.dartmouth.edu/basicfifty/basicmanual_1964.pdf
http://www.vintage-basic.net/bcg/superstartrek.bas
https://www.atariarchives.org/basicgames/showpage.php?page=1...
1964 BASIC did support single-line function definitions (see page 13.)
Dartmouth BASIC kept evolving into the 1980s and seems to have turned into a pretty capable language that retained much of the accessibility of the original. I wonder what would have happened if True BASIC had been a free/open source project instead of proprietary software.
Simple numerical/mathematical programs are certainly useful today, especially for students and researchers - BASIC emerged from Dartmouth's math department after all. Of course now we can run them on pocket calculators - some of which still run BASIC!
As I understand it, subsequent editions of BASIC running on Dartmouth's time-sharing system were used for a wide variety of applications, including:
- numerical programs (including scientific and engineering computation)
- simulations
- text formatting and document preparation
- statistics and data analysis
- communication programs such as online chat
- data storage and retrieval
- course management and grading
- games
- printing things from form letters to large signs
etc.
Regarding the limits of 1960s computing, it's worth noting that primitive computing systems, along with numerical and control software, were useful in helping to send humans to the moon and back (among other impressive accomplishments.)
Those are extremely basic functions that can only do a simple math operation on a single number. This is a function in the math sense, but not useful for programming.
Personally I'm kind of impressed that it existed back then at all, as well as the simplicity of original BASIC that enabled regular people to write useful programs, nearly 60 years ago.
Lucky gosub came soon after which left a return pointer on the stack, making things a lot better and basically being like an early function call.
Only problem was you could still goto around making life really confusing for yourself :) A lot of bad habits were learned this way :P
No. I actually liked VB when I was a teenager. It was very easy and (using ms parlance at the time) quick to develop small applications. For me it was not much more from a mere toy. I know some people used it for serious purposes, but I'm sure many of these uses were makeshift prototypes that eventually nobody had the time or money to rewrite. I don't think many serious and popular apps were written in VB and were maintained for a long time. I don't think it was adequate for that purpose and I don't know anyone who thought it was.
I used to joke that anyone claiming to be a "Very senior VB developer" was basically saying, "I don't know how computers work".
While it was a funny way of blowing off steam (and indeed senior VB devs didn't seem to know things like calling conventions or static linking), therein lies the miracle of VB. People could make business applications without having to know that stuff.
Often enough, they had VB devs for the frontend, and the heavy lifting done in *.dll's written by more hardcore C++ devs. I guess it worked out well enough that way.
But VB did so much of the work for you. And it was BASIC, which I already knew well. So it was exactly what I needed to understand the fundamentals without having to boil the whole ocean at once just to get a window with a button on my screen.
Agree it wasn't really suitable for large scale projects (although it got used for them anyway heh). Somehow VB apps always looked and felt "wrong", like they were a cheap knockoff. But for learning, and writing quick non-commercial apps, it was just right.
All that said, I feel no nostalgia or desire to go back.
It’s the best drag and drop interface builder I’ve seen in an open source project and it’s cross platform and compiled to static binaries for easy distribution.
In BASIC land, the QB64pe project has a maintainer for Inform-pe, a pretty straightforward drag & drop interface builder:
https://qb64phoenix.com/forum/showthread.php?tid=1311
Here's an example running under QB64 (though not Phoenix Edition/pe):
https://www.youtube.com/watch?v=a9pNGBaIr94
Background on the Phoenix Edition:
https://qb64phoenix.com/forum/showthread.php?tid=259
There's also Purebasic and Gambas, though Gambas isn't cross-platform...
https://www.purebasic.com/
https://gambas.sourceforge.net/en/main.html
Zooming further out you have e.g. Defold and Cerberus X, which I'm not sure about the drag & drop but GUIs are certainly doable.
https://defold.com/
https://www.cerberus-x.com/community/index.php?pages/about/
Then there are Wonkey and wxBasic...
https://wonkey-coders.github.io/
https://www.wxbasic.net/
Et cetera... :-)
Personally I'm pretty fascinated by the way these projects typically center around a traditional forum, with various software structures in place that shape the user experience.
For example, prolific library authors may be invited to publish directly to their own subforum and kind of use it as their own website, etc.
When new projects start, spin off, fork, etc, the forum is often the first part of the user experience to see created, frameworked and decorated in depth.
https://www.blaisepascalmagazine.eu/product-tag/lazarus-book...
One advantage of this particular coding ecosystem is that you can use Delphi docs, techniques and tutorials as well, which can be helpful to know.
But if your specification is "cover all aspects of Lazarus itself at confirmed 1:1 functionality with the current major version" then it might be a difficult ask.
There are some really great resources out there, but they are not going to meet every definition of decent docs.
For me it was enough to watch some YouTube tutorials[1] to get the gist, identify some idiomatic workflows, start building, do a bit of searching in different documentation resources, and ask follow-up questions at the forum.
It's nice that we can also ask ChatGPT for help these days too.
1. I thought this was a good example of a set of YouTube tutorials demonstrating working with Lazarus: https://youtube.com/playlist?list=PLYT8oqHJjWzTsIzzGN-Y1wKM9...
The drawback is that there is usually relatively little information outside of the forum and uncommon that code is shared on things like github, instead code sharing is typically done by copy&paste on the forum, which makes it a bit harder to track and standardize conventions.
I wrote the linked article because I wanted to explore dead easy programming environments for people who liked BASIC and VB, partly because 40 years ago, I liked BASIC myself.
C++ is the anti-BASIC. So are virtually all modern programming tools. Vast complex hard languages designed by professionals for professionals. Anything with braces in it wasn't designed for beginners.
Python is also very much a C-ish Unix-ish tool, too. It's just that Unix folks are so used to this that they don't notice.
What does % mean? Oh, well, it depends. Where?
How do you print a number? Oh, well, it depends. You can use %d but also %f but only if you want so many decimal places...
This is ugly crufty stuff, but if you're used to that and grew up with it, it's normal.
Python only looks easy and simple if you're used to C.
The appeal of VB lives on in WinForms with C# as the backing language. Initially MS tried hard to keep VB.Net around as a fully emancipated partner but it turns out everyone just moved over to C#.
I agree completely. The language itself was pretty crap, but there was nothing like it for rapid layout and wiring of a GUI. IMO, even modern tools like the storyboards and visual components in Xcode don't quite make it (they're more powerful, certainly, but also much more complicated to use).
Not very hard[1]; "making Visual Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.
And the sky didn’t seem to fall, not inside Microsoft. VB6 developers were up in arms, but they were disappearing anyway, because most of them were corporate developers who were migrating to web development anyway. The real long term damage was hidden.
With this major victory under their belts, the MSDN Magazine Camp took over. Suddenly it was OK to change things. IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon."
[1] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
https://www.folklore.org/StoryView.py?story=MacBasic.txt
and would give a lot for something contemporary and cross-platform along those lines which was likely to stay around. Thought that was going to be Runtime Revolution/Livecode, but that went back to closed source --- I suppose I should look at Lazarus/FreePascal (but I didn't do well with Delphi back in the day).
Applescript Studio seemed promising --- really wish that that had been opened up to make iOS apps.
As others point out, many hobbyists still use variants of BASIC...I don't think we can claim it's the most practical language for most uses, but it has its niche for sure, and is fun to use.
Visual Basic, however, while at the time representing a _fantastic_ entry point to development (at least it was for me), has been legitimately replaced by other, newer models, some of which the article notes.
Before VB setting up a GUI application was hard and required a lot of specialist knowledge, then VB made it easy, and its replacements on the web are making it hard again :-). I still don't know an easy way to set up a web with a database that also allows you to go into depth if needed.
It is VB, but for Python and for the web!
After the low-level stuff it was MS-DOS 3.3, with DEBUG.com for assembling intel assembler, and later MS-BASIC, Turbo Pascal, C, and all the later languages.
BASIC still has a soft-spot in my life, I wrote a trivial implementation of BASIC in golang which is complete enough to be fun, but missing specific features for running things like the widely-reshared Star Trek game. Maybe I should setup a stretch-goal of completing a bunch of common games/programs and work on it some more.
BASIC was never my cup of tea, but I used it because it was all that was available at the time. And books of programs really helped.
VB was great because it made easy stuff easy but it also made more difficult stuff possible. You could reference other libraries, of course. You could also directly call Win32 APIs. But you didn't need to that. You didn't need any boilerplate or ceremony -- you could drop a button on a form, double-click on it to add code, and make it do something without knowing anything about the infrastructure to make that possible.
As far as I know, there are no tools that do something equivalent now that aren't so sandboxed that it's a dead end.
Maybe, but it certainly isn't the new Visual Basic.
Even in (was Delphi, now) Lazarus, there's much more to know when you need to create a simple application.
QBasic was really cool at the time. I wrote a lot of (very crappy and slow) games in it. The documentation was all readily available and it had a lot of power. QBasic (and VB) were very "batteries included" and that was amazing.
But, and this may sound harsh, I've always felt that BASIC was a language of desperation. You use it because it's the only thing available to you, not because you actually want to use it. There was a time where some form of basic was available on literally every computer. This continued well past the 80s with VBA and gave a lot of people the power of extensibility over their applications.
Back when I was writing a lot of BASIC code, I quickly found myself running into walls and realizing that it just wasn't a great environment to build anything serious in. The lack of a real compiler in DOS was the primary reason I found Linux and C in the mid 90s. Once I had my hands on a C compiler I never wanted to look back ever again.
(I know that QuickBasic and Visual Basic existed and could create binaries. But, I was young and couldn't exactly afford them. Before finding C, I was using a BASIC environment called ASIC, which wasn't quite as nice as QBasic, but could produce binaries.)
It makes me wonder how things might have been different for me if DOS came with a C compiler and something like raylib. The lack of a real (free) compiler drove me to Linux. Would I have still gotten into Linux? I don't really know!
QuickBasic and all the variants filled a niche that exists in multitudes now but did not exist in the early 90s. There weren't many high-level languages with garbage collection in common use.
But all my friends had pirated copies of every development tool. I don't know how we even got it all. We were lucky to be adjacent to a larger city and therefore have closer access to files and information.
Very small binaries. Unfortunately you had to include the rather large run-time libraries with them (BCOM*.LIB or vbrun*.dll respectively). IIRC vbrun300.dll was >300MByte which was rather large at the time, as well as the library functions it contained an interpreter and your executable wasn't fully native code (your code was transpiled to something the interpreter could process more efficiently, and the executable had a small chunk of native code to load the RTL and get it to execute the rest). IIRC VB6 was the first version to properly compile to native code.
https://archive.org/download/vbrunDLL
QuickBasic was a paid-for, commercial compiler. It builds executables.
QBasic is a different product: a freebie with MS-DOS 5 and later. It's an interpreter.
There's even the original BASIC version of Oregon Trail!
For a native BASIC interpreter, there's an enhanced version of Applesoft BASIC built-in to the microM8 Apple II emulator -- it has various enhancements including 3D voxel graphics and the ability to draw in SHR (Super Hi-Res) https://paleotronic.com/microM8
If by BASIC you mean the line-numbered language with single-character global variable names, with no flow control beyond GOTO and maybe GOSUB, which encouraged, nay, demanded humans crunch their own programs by removing as much whitespace as possible to fit them in RAM, then it wasn't a good language.
If by BASIC you mean the block-structured language with most modern flow control features, normal ideas about variable names and scope, which allows people to write GUI applications in a short period of time using GUI builders and easy access to libraries written in other languages, then it is a good language, but still not my favorite.
MS also had some awesome tech around DCOM in VB - transparent RRC was very futuristic at the time.
Did that for a few years before moving on to AMOS (also a BASIC, though definitely more modern and useful -- it even had a compiler) on the Amiga.
The summer after Junior High I started learning C on DOS (Turbo C!) and at that point I was done with BASIC.
I don't think I could have started with C in grade school, BASIC is what got me hooked on programming :)
• no line numbers
• indentation-based code blocks for conditionals, loops etc.
• string/byte/word/float/boolean variables
• pointers
• arrays, hashes and record types
• editor with auto-indenting, code folding and immediate error highlighting
• a super-fast interpreter and the ability to compile programs
• 600+ function library covering hardware/OS calls, matrices, collections etc
Really, it was an amazing language and I was very lucky to start on it, as it made the jump to Turbo Pascal a few years later relatively painless.
GFA Basic v3 Manual - http://www.atarimania.com/st/files/GFA_BASIC_Version_3_Inter... GFA Basic for Windows - https://gfabasic32.blogspot.com/p/about.html