[HN Gopher] An introduction to Programming with ECMA-55 Minimal ...
       ___________________________________________________________________
        
       An introduction to Programming with ECMA-55 Minimal BASIC [pdf]
        
       Author : ingve
       Score  : 43 points
       Date   : 2021-02-23 12:49 UTC (1 days ago)
        
 (HTM) web link (buraphakit.sourceforge.io)
 (TXT) w3m dump (buraphakit.sourceforge.io)
        
       | Mister_Snuggles wrote:
       | It's amazing how many completely different languages are called
       | BASIC.
       | 
       | Personally, I've used:
       | 
       | * GW-BASIC / BASICA
       | 
       | * QBasic / QuickBasic
       | 
       | * Visual Basic 6
       | 
       | * Visual Basic.NET
       | 
       | * UniVerse BASIC / Unidata BASIC - these are quite similar and
       | both descend from Pick BASIC
       | 
       | Each of these is a distinctly different language with very
       | different capabilities, but they all share the BASIC name.
        
         | pjmlp wrote:
         | Because they all share the common roots of BASIC.
         | 
         | Just like C, C++, Objective-C, C#, C--, C@+ do in regards to C.
        
       | starik36 wrote:
       | The compiler for it is quite triggering.
       | https://buraphakit.sourceforge.io/Learn_BASIC.pdf
       | 
       | The Linked List example has an unbelievable number of GOTO 120
       | and GOSUB 380 type of statements. Even QuickBasic didn't have to
       | do that.
        
         | dragonwriter wrote:
         | > Even QuickBasic didn't have to do that.
         | 
         | QuickBasic is from 1990. ECMA-55 is from 1978, _and_ even then
         | it 's explictly "Minimal BASIC", not a remotely comprehensive
         | language in that family even for the time.
        
           | starik36 wrote:
           | Ahh, I see. The change log for the compiler led me to believe
           | that it was a recent thing.
           | 
           | Thanks.
        
       | tonylemesmer wrote:
       | Anyone recommend a good basic interpreter for Windows? Or even
       | one that would work in Dosbox with text and graphics modes?
        
         | WorldMaker wrote:
         | Small Basic was built to be a good teaching tool:
         | http://www.smallbasic.com/default.aspx
        
         | rainburg wrote:
         | Perhaps, QB64? https://www.qb64.org
         | 
         | There's also a GUI toolkit with an interface designer being
         | developed for it: https://www.qb64.org/inform/
        
         | RcouF1uZ4gsC wrote:
         | I actually use QBasic in Dosbox. It works and you can find a
         | ton of old tutorials and books.
         | 
         | You can find the MSDos images you need on archive.org.
        
           | tonylemesmer wrote:
           | Qbasic and GWBasic/Basica are what I started on as a kid.
           | Thanks!
        
         | retrac wrote:
         | FreeBASIC https://en.wikipedia.org/wiki/FreeBASIC is a modern,
         | GPL'd compiler that implements nearly all of Microsoft
         | QuickBASIC along with a bunch of extensions. Runs on *nix and
         | Windows.
         | 
         | QuickBASIC was a rather nice BASIC dialect for its era, and you
         | can write well-structured and modular procedural code. Along
         | with a bunch of 2450 GOTO 410 lines, if you really want.
        
         | EamonnMR wrote:
         | I have fond memories of Blitz Basic which still seems to be
         | maintained: https://www.blitzcoder.org/forum/
        
         | tonyedgecombe wrote:
         | Windows ships with VBScript, it's available via WSH (Windows
         | Scripting Host) and has access to any COM objects you might
         | need.
         | 
         | It isn't a great language but it will go a fair way.
        
       | mhd wrote:
       | That's an interesting post. Minimal BASIC really deserves its
       | name, being quite a bit more limited than even the ZX80s or
       | VIC-20's BASIC variants.
       | 
       | Especially in the educational context, this lead to a lot of
       | languages seemingly forgotten -- BASIC being too little, and the
       | computers not having enough power for Pascal/Algol-W/C. LOGO was
       | quite popular, of course, but anyone remember COMAL? It had line
       | numbers, but mostly for editing interactively. Beyond that, you
       | had full structured programming, a decent enough allowance for
       | variable names and a rather verbose syntax to help you remember
       | where you are. No semicolons required, turtle graphics included
       | in most implementations. Short example:                   0100
       | draw'circle(160,100,100,2)         0110         0120 PROC
       | draw'circle(xc,yc,r,color)         0130   pencolor(color)
       | 0140   circle(xc,yc,r)         0150   paint(xc,yc)         0160
       | IF r > 10 THEN draw'circle(xc,yc,r-10,color+1)         0170
       | ENDPROC draw'circle
       | 
       | One of my favorite languages of that era was Elan. Which, like
       | most others, was slightly pascal-ish, too, but introduced
       | refinements, a feature rarely seen since (literate programming
       | preprocessors excepted). Also allowed ample usage of spaces in
       | identifiers.                   problem of pascal:
       | read the maximum;             start with the number 1;
       | begin with the sum 0;             WHILE number <= max
       | REP add number to sum;                 take the next number;
       | ENDREP;             show the result.              read the
       | maximum:             INT VAR max;             get(max).
       | start with the number 1:             INT VAR number:: 1.
       | start with the sum 0:             INT VAR sum:: 0.
       | add number to sum:             sum := sum + number.
       | take the next number:             number := number + 1.
       | show the result:             line;             put (sum).
       | 
       | We tend to do similar things with (maybe nested) functions and
       | comments, but this puts it all on the language level, which also
       | would make it easy to have the system prompt you for your missing
       | refinements, and of course get by without passing parameters.
       | 
       | Now, replacing all that or more contemporary equivalents (like
       | Scratch or Python) with a didactic approach that's pretty much
       | centered on writing flowcharts beforehand is quite an idea.
       | Which, by the way, is something we shouldn't forget when we
       | compare languages: It's not just about its syntax alone, but how
       | students are taught to construct and revise them. REPLs vs file-
       | based, for example. This would have them draw the general
       | structure and then encode that in GOTOs. I bet Dijkstra would
       | feel torn about this...
        
         | QuesnayJr wrote:
         | Algol 60 allowed spaces in identifiers. It's interesting that
         | so few languages since then have allowed it.
        
           | mhd wrote:
           | It's easier to parse, especially if your language has lots of
           | keywords that might be part of identifiers, like "begin",
           | "end", "for" and "and" or "or". I think with the Algol-like
           | languages it was mostly required to specially treat the
           | keywords, either by quoting them, uppercasing them or writing
           | them in bold (if supported).
           | 
           | But beyond that, I'm not sure that I want that in a "modern"
           | idiom, where I get a whole bunch of compound words on the
           | screen, like classes, objects, methods and variables. Spaces
           | are quite easy to pick out as delimiters -- and I've actually
           | heard that as an argument for CamelCase against snake_case.
           | 
           | Then again, I'm German so I might have a high tolerance for
           | long strings and syntactical pain.
        
             | retrac wrote:
             | > Then again, I'm German so I might have a high tolerance
             | for long strings and syntactical pain.
             | 
             | You're certainly used to stropping your Nouns. Maybe `all`
             | that `keyword` stropping `in` ALGOL 60 isn't so bad `if`
             | you're used to that. 8-)
        
             | QuesnayJr wrote:
             | Change frightens me, so I find the idea of spaces in
             | identifies shocking, but I'm curious if once you got used
             | to the idea if there are upsides. Especially now with
             | syntax highlighting, you could visually tell whether it was
             | distinguishing keywords from your identifiers correctly.
        
           | retrac wrote:
           | The ALGOL family marks reserved words specially. _How_ to
           | mark them is implementation specific. Some require `all
           | `keywords `be `marked `with `a `symbol. Others Require
           | Keywords Be Capitalized. Some use a different font. (Yes,
           | italics or bold can be semantically important in programming,
           | it turns out.)
           | 
           | If all your keywords are specially marked, everything between
           | them can be vacuumed up by the parser as-is. It's actually
           | easier to parse than modern languages with space delimiters.
           | But arguably worse to write.
        
       ___________________________________________________________________
       (page generated 2021-02-24 23:03 UTC)