Comment by bioemerl | Hacker News Reader

Comment by bioemerl | Hacker News Reader

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.

> It wasn't that easy to understand

Out of all the complaints I've seen about BASIC/Visual Basic, this has never been one of them.

Reading and debugging code filled with gotos can be a real nightmare.

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.

OK, then what about "On Error Resume Next"? ;)

try / catch replaces that today

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.

The absolute smelliest of code smells.

Chad move.

Something broke but we still moving to the next line.

It's easy for a programming language.

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.

Well yeah, but remember the context here. We're not talking about programming languages today.

BASIC was invented in 1963 and exploded in popularity in the late 70s. Python 1.0 didn't come out until 1991.

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.

Invisible spaces and/or tabs are important in Python which makes it more difficult.

Yeah, but that's the sort of thing you more or less learn about on the first day and a decent editor/IDE mostly removes it as an obstacle.

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.

> Obviously, newer languages are going to tend to be easier to work with for beginners, that should be a given.

The whole point of this comment chain is to discuss whether BASIC was easy to use so it's clearly not a given.

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.

> How does BASIC being easy to use or not have anything to do with newer languages being easier to use?

Because "easy" is a somewhat relative term. The category will shift over time.

Did you bother to even remotely read the comment you replied to, which says the same thing?

The category shifts over time, sure. But what does that have to do with BASIC being easy or not? They're two separate topics.

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).

And don't forget subroutines vs functions. Yet another pointless distinction that makes things harder and resists refactoring.

Functions return a value.

Subroutines don't.

Is that a pointless distinction? Why?

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.

We're talking about BASIC here. A beginners' training language. And it's 2023.

Who ever needs to refactor BASIC!?

Refactoring is a large part of programming, full stop. Yes, even if you're making a silly training game.

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.

On all these 8-bit platforms, you could only do so much until RAM was full. So there was a built in escape hatch for complexity.

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.

> It wasn't that easy to understand

Yes it was.

https://www.dartmouth.edu/basicfifty/basicmanual_1964.pdf

These vintage BASIC games' code looks clear as mud to me.

http://www.vintage-basic.net/bcg/superstartrek.bas

https://www.atariarchives.org/basicgames/showpage.php?page=1...

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.

Yeah those goto's also caused what we called spaghetti code.

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

You are talking about different BASIC of different era, a decade before VB.

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.

Exactly. For example, GFA Basic, mentioned in the article, was quite fast, especially when compiled.

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.

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.

Reply on news.ycombinator.com