From: cr88192@gmail.com   
      
   On 10/20/2025 9:19 PM, Janis Papanagnou wrote:   
   > On 20.10.2025 23:44, BGB wrote:   
   >> [...]   
   >>   
   >> Decided to leave off going into a longer topic about language-design   
   >> tradeoffs.   
   >   
   > (I changed the subject for you. But wouldn't it have been better to   
   > just open a new thread?)   
   >   
   >>   
   >> And the seemingly often overlooked practical distinctions between the   
   >> design of serious/implementation languages and light-duty script   
   >> languages,   
   >   
   > An interesting distinction, though I'm exactly sure what you have in   
   > mind when saying "light-duty" here.   
   >   
   > One commonly used script language that I use on a daily basis is the   
   > Unix Shell. Is that "light-duty" in your categories? (Not for me, to   
   > be sure.)   
   >   
      
   Well, one can define "Scripting" as well.   
      
   So, we have:   
   Shell scripts, which typically work with files and invoke programs;   
   Languages like Perl or Python, which are often used for standalone tools;   
   Languages which are primarily used within the context of some other   
   program to implement behaviors within that program.   
      
   For example, a command-line tool written in Python is a different   
   use-case from triggering a certain cutscene to play the first time a   
   user opens a certain door in a video game.   
      
      
   > In some courses I gave in the 1990's my dogma had always been (and   
   > still is) to approach "scripting" as [seriously] "programming"!   
   > And apply all the software development principles also when writing   
   > programs in "scripting" languages.   
   >   
      
   It depends a lot on what you are doing.   
      
   If it is something where software engineering practice matters, it is   
   likely crossing into domains where an implementation language could make   
   sense.   
      
      
   >   
   >> where blurring this line can result in languages that aren't   
   >> particularly well suited to either use-case.   
   >>   
   >> Or, in effect:   
   >>    C, C++, C#, Java, etc:   
   >>      Mostly sensible designs for implementation languages.   
   >>      Where: Language you would actually use for non-trivial code.   
   >>    BASIC, Emacs Lisp, etc:   
   >>      Sensible for script languages.   
   >   
   > (You're probably talking about newer BASIC dialects. - But there's   
   > anyway so many different BASIC dialects existing that it wouldn't   
   > appear to me to choose this thing in the first place.)   
   >   
      
   The more recent BASIC dialect I dealt with were along the lines of, say:   
      INPUT "Give number between 1 and 10"; X   
      IF X<1 THEN GOTO OUTOFRANGE   
      IF X<=5 THEN GOTO ONETOFIVE   
      IF X<=10 THEN GOTO SIXTOTEN   
      GOTO OUTOFRANGE   
      ONETOFIVE:   
      PRINT "X is between 1 and 5, X="; X   
      END   
      SIXTOTEN:   
      PRINT "X is between 6 and 10, X="; X   
      END   
      OUTOFRANGE:   
      PRINT "X is not between 1 and 10, X="; X   
      END   
      
   Though, one could sorta have subroutines:   
      GOSUB FOO   
      ...   
      FOO:   
      PRINT "FOO was called"   
      RETURN   
      
   While crufty, it allows for a fairly simplistic interpreter design.   
      Does it have FOR/NEXT, DO/WHILE, CASE, ...? No.   
      
   Did sort of end up with functions hacked on top of the GOSUB mechanism.   
      
   One other way to write BASIC though is, say:   
      100 PRINT "Hello"   
      200 GOTO 100   
      RUN   
      
      
   Though, it is modern in the sense that it allows keywords to be lower case.   
      
   Also ended up going from global-variables-only to a sort of dynamic scoping:   
      LET X=10   
      PRINT "L0, X="; X   
      GOSUB FOO   
      PRINT "L1, X="; X   
      END   
      FOO:   
      TEMP X=20   
      PRINT "L2, X="; X   
      RETURN   
      
   Will print:   
      L0, X=10   
      L2, X=20   
      L1, X=10   
      
   Since the TEMP will create a new variable in the dynamic environment of   
   the called subroutine.   
      
   Though, if you simply wrote:   
      X=20   
   It would overwrite whatever binding exists.   
   I had been debating whether LET should be reinterpreted as TEMP and if   
   the existence of a separate space for global variables should be eliminated.   
      
   This dialect is dynamically typed, so:   
      X=10   
      Y="FIFTY"   
   Is valid, some others would require suffixes, say:   
      Y$="FIFTY"   
      
   Though, in this sense it more borrows some features from 1990s era   
   dialects (such as the lack of type suffixes on variables), while keeping   
   much of the structure of 1980s dialects.   
      
   One could argue it might make sense for an interactive BASIC interpreter   
   to also function like a line editor. Though, in the contexts I had used   
   it in, there was no line editor.   
      
   There was a console, but the consoles' commands were separate from the   
   BASIC interpreter so one would need to use an "eval" command to send   
   commands to the BASIC interpreter.   
      
   In this case though, parenthesis could be used to give expressions,   
   which would be evaluated in place and the result would be printed on the   
   console.   
      
   When scripts were run, typically also a label would be supplied, in   
   which case it would start running at that label. If no label is given,   
   it starts running at the top of the script.   
      
      
   In the use-case in question, scripts could be triggered (among other   
   ways) from events embedded into the dialog system.   
      
   By default, PRINT would be routed to the console, but if invoked inside   
   a dialog box the PRINT could be routed to the text printed in the dialog   
   box.   
      
      
   Some types of types this dialect had:   
      Floating point numbers;   
      Integer numbers;   
      Strings;   
      Arrays, variable sized, dynamically typed.   
        Created with "DIM" command.   
          DIM ARR(128)  //create array with 128 items.   
      Vectors, nominally holding 4 floating-point numbers;   
      CSG solids/brushes or CSG unions;   
      ...   
      
   The latter types were partly because I started also using it for 3D   
   model creation. A lot of the CSG related commands started with "CSG".   
      
      
   The CSG stuff is mostly used for scripts that are used for 3D model   
   creation (and animation).   
      
   As can be noted, it exists mostly because, formerly, I was using   
   OpenSCAD for some 3D models (mostly for stuff to 3D print), but it has   
   limitations:   
      None of the formats it exports have colors or textures.   
        Even if the SCAD language had colors.   
      No good way to deal with animated 3D models in SCAD.   
      
   Could have written a parser to deal with the SCAD language, with the   
   extended features I wanted, but just sort of ended up bolting similar   
   functionality onto the BASIC dialect instead (path of least effort).   
   But, this is wonky... These things weren't really meant to go together.   
      
      
      
   >>      Or, language used for behaviors or program-control / events.   
   >>    JavaScript, ActionScript, etc:   
   >>      Sort of an awkward middle ground.   
   >>   
   >> Though, JS and AS and similar, are still better than, say:   
   >>    Trying to use Java or similar for high level event scripting;   
   >   
   > I've been using JS in many toy projects because I needed dynamic   
   > web-content and didn't have a managed server. If I've had one I'd   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)