BASIC was meant to be easy to learn, read and understand

[BasicCoder2]

http://www.freebasic.net/forum/viewtopi ... 17&t=25257

Re: FreeBASIC syntax challenge games
Postby fxm » Dec 20, 2016 12:11
Everyone can propose here a FreeBASIC syntax challenge.
Take care to increment the identification number 'Enigma #id' for each new challenge (some challenges may be interlaced).

The reason I used FreeBASIC was because it was not a syntactic challenge. Plain BASIC is an easy to learn, read and use language for the everyday person interested in programming without needing them becoming an expert in computer programming or as in my case the need at the time to program electronic hardware. A language passes that test to the extent it mimics a real human language and doesn't make use of exotic or special purpose symbols and idiosyncratic ways of expressing an idea. The closer to a plain human language the better in my opinion. As I wrote elsewhere FreeBASIC is developing into an obscure non intuitive language in its race to become C++ for its more advanced users.

However yourself and others with a deep knowledge computer languages has over the years has been appreciated by us lesser mortals when it comes to programming with FreeBASIC.
.

[Tourist Trap]

As I wrote elsewhere FreeBASIC is developing into an obscure non intuitive language in its race to become C++ for the more its more advanced users

Hi BasicCoder2,

nice to see you again with this now classical topic re-edition. If you are talking about @ symbol, you should use macro to do text replacement. Example

Code: Select all

#define thisistheaddressof(x)      @x

I agree with you that we need even more powerful macros however.

edited: basiccoder2 author

[St_W]

FreeBasic syntax has not been changed, it has been extended. So all the syntactical stuff you already know from BASICs from the 70's and 80's is practically present in FreeBasic (except line numbers). All the new stuff that has been added is fully optional, and if you don't understand it or think that it's too complicated for you, then you don't have to use it.

The thing is that people who know QBASIC or other old/older basic dialects are becoming less and for today's newcomers FreeBasic's dated syntax is not as easy to learn because computers, operating systems and a lot of other environmental things have changed since QBASIC meant to be easy. What I want to say is that easy back then doesn't mean easy nowadays and that the language must evolve.

[Boris the Old]

A language passes that test to the extent it mimics a real human language and doesn't make use of exotic or special purpose symbols and idiosyncratic ways of expressing an idea. The closer to a plain human language the better in my opinion.

You could always program in COBOL. But even COBOL has evolved to implement pointers, a GUI, and OOP. :)

I've been using BASIC since it was invented, and wrote and executed my first programs on a teletype machine that was connected by phone to the computer at Dartmouth college. I can assure you that FreeBASIC is quite capable of creating "real" BASIC code, even though it has evolved to use modern features. However, one is not obliged to use the modern stuff.

I've been programming since the early 1960's, on both 2nd and 3rd generation systems, and in many different languages - mostly in Assembler, COBOL, and BASIC. And I agree with you that ease of use and readability are important in a language. However, there are ways of making life easy, even with complex language features. I'm a lazy programmer and prefer to use the simplest code to get the job done. Modular code and macros are a big help. But most of all, I never write the same code twice.

Here's a code fragment that I wrote 30 years ago using MS Assembler, but using macros to make the code look like COBOL. This code is still in use today, as part of some DOS packages that some of my customers are still using:

Code: Select all

  ENTER ComplexUpdate  <Update record having alternate keys>

    MOVE <userbuffer,userlen> TO <savebuffer,userlen>  ; save user buffer
    PERFORM ReadUserData                               ; read existing record from file

    MOVE NO TO keyflag                                 ; assume alternate keys have not changed

    LOOP ON fcbindex FROM 2 TO indexcount     ; scan alternate keys
      PERFORM PointToIcb                      ; point to icb and kcb
      PERFORM ExtractUserKey                  ; get key from existing record
      PERFORM ExtractSaveKey                  ; get key from new record
      WHEN savekey NE userkey
        TRUE
          MOVE YES TO keyflag                 ; an alternate key has changed
          LEAVE
      ENDWHEN
    ENDLOOP

    WHEN keyflag EQ NO
      TRUE                                                 ; no keys have changed
        MOVE <savebuffer,userlen> TO <userbuffer,userlen>  ; restore user buffer
        PERFORM SimpleUpdate
      FALSE
        PERFORM DeleteRequest                              ; delete old record
        MOVE <savebuffer,userlen> TO <userbuffer,userlen>  ; restore user buffer
        PERFORM AddRequest                                 ; add new record
    ENDWHEN

  EXIT ComplexUpdate

And here's the same code today, but written in FreeBASIC, which also uses macros to improve readability. This newer code is used in my modern Linux and Windows versions of those old DOS packages. I use about 400 macros to help simplify the syntax and to make the code more readable:

Code: Select all

'-----------------------------------------------
'  Procedure 76 : update a record having alternate keys
BeginPrivateSubroutine (subComplexUpdate) _
  ParmEnd
'
  LocalField (iIndex,                       typInt32)                ' 12061 : generic index number
  LocalField (iRetCode,                     typInt32)                ' 13784 : generic return code
  LocalField (cKeyFlag,                     typChar)                 ' 14880 : Y = an alternate key has changed
'
  pruSaveUserX                              = pruRecordX             ' save current user data
  subReadUserData                           (pruRecordX, priRecNum)  ' read existing record from file
  cKeyFlag                                  = cFLAG_NO               ' assume alt keys have not changed
  For iIndex = 2 To pruFcb.uHeadX.bIndexCountX                       ' scan alternate indexes
    subPointToIndex                         (iIndex)                 ' point to Icb and Kcb
    subExtractUserKey                       ()                       ' get key from existing record
    subExtractSaveKey                       ()                       ' get key from new record
    If prsSaveKey <> prsKeyWork Then
      cKeyFlag                              = cFLAG_YES              ' an alternate key has changed
      Exit For
    End If
  Next
  If cKeyFlag = cFLAG_NO Then                                        ' no keys have changed
    pruRecordX                              = pruSaveUserX           ' restore current user data
    subSimpleUpdate                         ()
  Else
    subDeleteRequest                        (iRetCode)               ' delete old record from file: dummy return
    pruRecordX                              = pruSaveUserX           ' restore current user data
    subAddRequest                           (iRetCode)               ' add current record to file: dummy return
  End If
'
EndPrivateSubroutine

[BasicCoder2]

It is just that it seems to me from reading about OO in other languages including VB.NET that it shouldn't be all that hard with tricky syntax to trip you up.
OO should be a means to easily solve a problem not a problem to be solved.
Perhaps if anyone was interested they could explain it as simply as tutorials found on the internet explain OO for VB.NET
Is FreeBASIC OO VB like or C++ like?
.

[Tourist Trap]

For me the main difference between VB.net and FB is not at all in term of simplicity or power at the core level. FB is more powerful due to its access to memory via c like pointers. And at core level VB is mainly made of windows API calls at a scale that only microsoft can imagine , and even there, I've read here or there that ms engineer were in pain with a so big library of stuff.

But where VB wins is that the classes are already programmed, you just have to use or inherit any of the very involved objects, quite documented and often well shaped (not always). But if one the provided object doesn't match your needs for a low level reason, you are like a sitting duck, FB would allow you to find a solution even faster because you won't stick playing longly with a faulty object. Because some of the objects VB provides are very processor consumming for instance, or hide to much the api calls on which they rely. And so on. In one word, it's rich but not universal.

One example here where I'm using the kind of encapsulation of simple types that one may find in VB. For instance providing a GetType method, or ToString. The problem is just that it would require development time for a first level of encapsulation, allowing then a second level and so on. However it's possible of course. So I think that FB is really a nice choice, above all if it stays of the sharp line providing low level and consistent syntax (not too much arbitrary but rather something meaningful for the code reader).

Example (with a clean solution by fxm): http://www.freebasic.net/forum/viewtopi ... nt#p224105

[Boris the Old]

It is just that it seems to me from reading about OO in other languages including VB.NET that it shouldn't be all that hard with tricky syntax to trip you up. OO should be a means to easily solve a problem not a problem to be solved.

Hi BC2

Once again I agree with you, but the trick to using OOP is to not get tricky. This was the problem when Structured Programming was invented. Programmers were applying it in ways that were not always appropriate. Structured spaghetti code is not a pretty sight, and is impossible to maintain. The same is true of OOP if not approached in a sensible manner.

I have 5 simple rules about using OOP:

1) Don't use it if the program can be written using simple modules or namespaces. There's no glory in making things complicated, and years from now maintainers of your code will thank you.

2) If you must use OOP, then restrict classes to handling things that need multiple instances - such as buttons on a GUI. Don't create a class to do what a simple module will do. It just adds complications to the application.

3) Classes should be simple and should perform a specific function. Avoid inheritance if you can. It's often better to duplicate common features in each class, so that each class is truly a "black box". In the real world, classes will need to change over time, and this can create major maintenance problems in a complex hierarchy of derived classes.

4) And like all good rules, there are exceptions, but only for inheritance. I sometimes allow a base class and one level of derived classes. For example, box-like controls in a GUI, where the controls are essentially the same except for a few properties or methods. But the similarity has to be high in order to justify this approach - say, 80% or more, shared functionality.

5) All the other scary OOP stuff is strictly forbidden.

I have lots of other rules for other aspects of programming, but these are the only ones that apply to OOP. I've found they allow me to write well structured and bug-free code as easily as using Structured Programming techniques.

Rod

[greenink]

Those are 5 very good rules.

[BasicCoder2]

Hi Boris,

Programming has been one of my part time interests which evolved from an interest in electronics and robotics. I am entirely self taught from books and it remained an interest all my life although I never earned my living from it. My first language was Z80 assembler. I also used Assembler on the PC along with QBASIC until I discovered C was a good replacement with regards to readability and speed all in the one package. Later I tried to learn OO with the C++ compiler but it just seemed to make hard work out of something I had found easy with the old C way of doing it. All my OO attempts since then have caused me to come to the same conclusion. Maybe if someone wants to redo the FreeBASIC examples I have posted over the years on this forum to show how much better and easier they would be to read, understand and modify I might be convinced. Also I notice that some programmers (they claim to be about 5% of all programmers) have a negative view to all the OO hype, this being one of them,

https://www.youtube.com/watch?v=QM1iUe6IofM

If there are any FreeBASIC OO experts then I think a good set of tutorials on how use FreeBASIC to make use of these features would be useful to any beginners without any OO experience.
.

[Boris the Old]

Also I notice that some programmers (they claim to be about 5% of all programmers) have a negative view to all the OO hype, this being one of them,

https://www.youtube.com/watch?v=QM1iUe6IofM.

An interesting discussion, and one that seems to agree with my 5 rules of OOP.

In general I avoid OOP, but sometimes use it if it fits well with my code. Usually, rather than use embed data in classes, I create a global "cloud" of linked UDT (Type) arrays that exist outside the program modules. Each array entry represents what would normally be the class instance data, and each program module contains the code that would normally be the class methods. Only array element subscripts are passed to the modules, which then manipulate the data and return the results back into the arrays. Then, based on the results of its actions, the module passes control to another module using the appropriate array element parameters.

This arrangement operates as a Finite State Machine (FSM), which I find much easier to visualize than classes and their embedded data. I have Spacial Sequence Synaesthesia (SSS) -- to me, numbers and concepts are positions in multi-dimensional space, rather than words on a piece of paper. So a FSM is much easier for me to work with, since I can mentally navigate between the data cloud and the modules as I construct the program logic.

Rod

[anonymous1337]

My personal take is that the principles of "object-oriented design" are cooler than "object-oriented programming". By that, I mean I care about things like SOLID more than I do the semantics of OOP languages.

[BasicCoder2]

...And at core level VB is mainly made of windows API calls at a scale that only Microsoft can imagine , and even there, I've read here or there that ms engineer were in pain with a so big library of stuff.

In the past, over 6 years ago, I played with using the window's api using the Bloodshed Dev-C++ Development Environment. Not so long ago I tried using the CODE:BLOCK ide and MingW but was unable to configure it to use any graphic libraries (SFML, SDL) despite painfully stepping through tutorials on how to do it. However with the WIN32 API and DevCPP doing graphics and sound becomes doable without having to configure anything!! I have just fired it up again and it is all working so I might spend any free time over the xmas break to get back up to speed with C++ and OOP. Maybe after that I will be in a better position to play with FB's OO features. At least popular languages like C++ have many tutorials on how to use OOP unlike FB.
.

[marcov]

The closer to a plain human language the better in my opinion.

A patently wrong opinion of course, since plain human language is hopelessly inexact.

However if you meant keywords rather than abusing symbolic interpunction, then I completely agree.

[BasicCoder2]

The closer to a plain human language the better in my opinion.

A patently wrong opinion of course, since plain human language is hopelessly inexact.
However if you meant keywords rather than abusing symbolic interpunction, then I completely agree.

Perhaps a better way to put it is: The closer it reads like a human language the better in my opinion for a novice or part time user.
That is what the original BASIC syntax aimed for.

Another example is Scratch,
https://scratch.mit.edu/

There are other ways to make programming easier such as GUI editor, moving the robot arm through the desired motions and in the future you may well be able to tell AI software what you want it to do and give in human language feedback.
.

[marcov]

Another example is Scratch,
https://scratch.mit.edu/

I think you can never compared walled garden where every path is preprepared with a general purpose tool like FB. I also think the whole thread heaps the unschooled but continuous users and the various levels of total beginners too much together.

First pick an audience, then make an argument. Don't try to add various audiences in the hope that something sticks.