Visiting the ancestors

In a discussion about the most difficult programming languages somewhere else, one participant mentioned Basic.
Considering Xojo has evolved from RealBasic and it is a very easy language, this felt weird. I simply had forgotten how awful “real Basic” (not to be confused with REALBasic) was, mostly because of the lack of structures. This was a nice read to remember the beginnings …

Published listings at the time were very poorly structured, often by very amateurish programmers.

Even in AppleSoft Basic, or BASICA or GWBasic, it was possible to structure a program, although with subroutines and not real methods. But a good programmer would in general have a fairly simple main listing, and a collection of subroutines accessed with Gosub.

The most annoying thing was the need for line numbers. In that respect, when QuickBasic came in 1985, routines labels were a real God Send. That too has made it into Xojo, will labels for Goto destination (label:), and line number optional.

I have ported an ancient 1986 Basic program to Xojo earlier this year : Eliza, the ancestor of all chatbots. I was glad to have Goto at my disposal, because the original program was using no Gosub at all :slight_smile:

It was QuickBasic that was the real “breakthrough” for me. Subroutines instead of line numbers and goto, gosub etc.

I also remember having to load up mouse.com or mouse.sys in a batch file to get the mouse working. Although the mouse didn’t really do much except enable to select the code text instead of using the keyboard.

There are two words that made/make BASIC or any language a probable mess

GOSUB and GOTO

I knew a guy who thought he was being super clear by over-using both of these to obsfucate his code… Needless to say it bit him in the backside big time.

And while in those older dialecs it wasn’t always possible to NOT use them… it WAS possible to miniminze at least the use of GOTO… GOSUB was still acceptable in lieu of the lack of named functions/subroutines.

Nah, I disagree. GOSUB and GOTO enabled a numbskull like me to create somethink that did somethink.

we can agree to disagree… but in todays world, if I had a developer on staff who used either of those keywords in a program, they had better be prepared to prove to me it could not have been done otherwise.

Yeah, Ok Dave, but I think Ulrich was talking about the evolution of programming. Of course we have newer methods now, ie. Xojo.

The fact and reality is that programming now, is more about ideas than pure code.

Well, first of all I was amazed how right that guy was: Original Basic was almost as legible as Assembly code. I simply had forgotten.
Then I wanted to share some nostalgia. I really had fun reading some of the game listings. And I am glad the code today looks very different than in the old times.

I agree. I do believe it enables a different kind of mindset too. You had to force your thinking into that goto spaghetti mode to create something workable. With modern languages, especially Xojo, programming is much closer to natural patterns derived from everyday routines. Which can save you from nerdization. :wink:

Well, my previous experience of Machine language and Assembly code for electronics made me discover Basic with a lot of joy, because it was extremely close to English, more abstract and more synthetic.

In QuickBasic, with labels, a Gosub was very convenient, almost as much as a method. Unfortunately with only global variables, it was not as safe as what we use today.

That guy must be working at Microsoft to create the example programs for developers. The UWP example of print in VB is so convoluted, I was never able to print in VB for the new API.

Remember, GOTO lives in more languages than BASIC. Also, many opponents of GOTO also claim that BREAK, CONTINUE, and RETURN in the middle of a loop are bad.

It all depends on how you code and the reason behind your flow decisions. One thing that I’ve learned in over 40 years of programming (I started in 76) in 14 different languages and their myriad variants, is that style decisions are a personal thing. So long as your resulting application achieves its design goal, the manner in which you coded it is not wrong. It may not be elegant or best-practice, but it’s not wrong.

Indeed, computer or human language have that in common that the same collection of words can produce different results according to the locutor.

It is possible to produce monsters in such a structured language as Xojo (without using Goto), just as it is possible to create elegant programs in pretty much any language, with a bit of talent.

I never quite appreciated dogmatism in matter of such thing as using Goto, or returning in the middle of a procedure. After all, it is possible they become handy in some circumstances. I do tend to avoid returns in the middle of a method or event, just because it can render debugging more difficult.

A commonly accepted motto in Perl, “There Is More Than One Way To Do It”. I still love working with that language, too.

As an “old school” programmer like yourself, I do still try to keep my code as tight as possible, even though I realize the resources currently at our disposal have increased exponentially. But I still agree with your sentiment that it’s not wrong to do it differently, if it achieves the same goal.

We restricted the use of GOTO to the creation of loop constructs. It was fairly straight forward to translate those programs into Xojo since we were already using the equivalent of DO and WHILE. I think that was a paradigm I learned from Assembler, where the goal was to segregate your code into easily understandable sections, such as loops and subroutines. You can write spaghetti assembler, and you can also write very structured assembler, just as you can with BASIC. I wouldn’t dream of using GOTO in a high level language like Xojo, though, with proper loop constructs built in.

Isn’t “Return” a similar outcome to GOTO?

I only discovered the Return (and Return True) functions in Xojo 6 or so months ago. Before that I created flags because I didn’t think such a function existed and thought it was bad programming. Sad, but true. I’ve since refactored parts, but my code still works though :slight_smile:

Also doesn’t “Select Case” essentially do the same thing? It allows you to break out of the current method/subroutine and GOTO, or I guess GOBACKTO where it was called.

I like to use “Select Case True” because you can have many scenarios and they don’t have to be of the same type. Providing that you can work out the hierarchy of the “True Case” or the most important case, then it just flows through to the end.

But isn’t that still just a more sophisticated version of GOTO or GOSUB?

Actually, return is an integral part of many method. It happens automatically at the end of any sub, function, event handler.

It is not similar to goto, since goto goes to a label and starts execution there.

Return, which indeed dates back to Gosub, marks the end of the subroutine and returns to where that subroutine was called.

The only similarity between goto, gosub and select case is that they are branchings. But Select case is special, since it is conditional.

Thanks Michel and very good in the way that you have explained it.

I guess I still have in the back of my mind the good old GOTO.

What about PushButton? I’ve used this a few times but I know it’s best not to, but it has served my purpose.

What could be wrong with Pushbuttons ? ? ? Whose crazy told you not to use them ? ? ?

i used both bevelbutton and pushbutton without any problem.

I thought he was talking about the Pushbutton.Push command.

That is exactly where IMHO dogmatism becomes toxic. PushButton.Push is here to be used. I probably did it twice in 16 years, but I fail to see the logic in propagating a spirit closer to bible stompers than to science. It is not necessary a sin to use documented features, even if they don’t comply to the narrow logic of some.

Of course there will always be tenants of the dogma that it is better to have a method that can be called indifferently from the button Action event or from somewhere else. Let them suit themselves.

There is no one single way to code. There are as many styles as there are programmers. People without an open mind are often people without humor. Sad, sad, sad…