[Info-vax] BASIC (was Re: 64-bit)
Dave Froble
davef at tsoft-inc.com
Fri Jan 12 14:47:13 EST 2024
The first thing I'll admit is that computers are used for far more things than
I've been exposed to.
I have no clue on the design and implementation of GUI stuff.
I have no clue on the design and implementation of real time stuff, self driving
cars, navigation, and such.
I've got friends and relatives that use computers for music, though, they are
users, not developers.
And much more ...
My background has been business applications, database design and
implementation, and sometimes system type stuff, sometimes called system
programming. I've implemented a few interesting tools. Async messaging systems
are interesting, and helpful.
Overall, your post is interesting.
On 1/12/2024 12:26 PM, Dan Cross wrote:
> In article <unqjcn$3c1o2$1 at dont-email.me>,
> Dave Froble <davef at tsoft-inc.com> wrote:
>> On 1/11/2024 2:42 PM, Dan Cross wrote:
>>> In article <unpa1b$3316l$2 at dont-email.me>,
>>> Dave Froble <davef at tsoft-inc.com> wrote:
>>>> On 1/10/2024 9:28 PM, bill wrote:
>>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>>> The world has evolved.
>>>>>
>>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>>
>>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>>
>>> Usually the answer to this is going to be some combination of
>>> better abstraction facilities, better safety properties, more
>>> capable and ergonomic libraries, etc.
>>
>> Which then asks the question, are such really better? Perhaps some of that is
>> more opinion than fact.
>
> Some of it is opinion. Some of it is limitations in the
> language. Some of it is suitability for purpose.
Suitability for purpose is always rather important.
>> Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
>
> Understood.
>
>>> VSI BASIC appears to have a few useful things like static type
>>> definitions, functions, etc, and it frees the programmer from
>>> _having_ to specify e.g. line numbers. But it doesn't seem to
>>> have a lot of support for other abstraction facilities like
>>> modules, classes, or anything of that nature.
>>
>> What amuses me about that is that when people talk about "classes", I don't have
>> a clue what they are talking about. Perhaps I do, if the case is new names for
>> old concepts. That is something I didn't like about Microsoft, they seemed to
>> like re-naming concepts.
>
> I'm not sure what Microsoft has to do with it. The concept of a
> "class" has existed in one form or the others since Simula in
> 1967.
>
>>> String handling
>>> seems anemic.
>>
>> Can't let that one go. Basic in my opinion does strings very well.
>
> What do you like about it?
>
> Consider writing a lexical analyzer for a simple expression
> language; what would such a thing look like, in BASIC? Here I
> want to take a string as input, and emit a list of tokens that
> correspond to the elements of the langauge that are represented
> in that string.
Don't totally understand, perhaps parsing for commands, switches, and such would
be similar.
>>> There doesn't seem to be support for generalized
>>> memory pointers,
A pointer data type can be very useful. A compiler could use such to generate
proper sizing for different systems. But, in the end, it is just a numeric
piece of data. If one can process the numbers, that works. Not as generic,
but, it works. For VAX, it is an unsigned longword. For 64 bit addressing, it
is an unsigned 64 bit integer.
For example, what is the difference between memory pointers and indices in an in
memory resident data structure, such as linked lists? Not much, in concept, right?
>> Correct, Basic does not have any pointer data types. It does have a function to
>> retrieve the value of a pointer.
>
> That makes it challenging to implement dynamically sized data
> structures like trees or graphs where the size is not already
> known, or hash tables that use chaining for collision resolution
> etc.
Not really. There is always LIB$GET_VM.
> How would I do these things in VSI BASIC?
Once you can get the memory, what's the difference between say, linked lists
there, vs using pre-allocated array(s)?
>>> let along non-nullable references, so your
>>> ability to create rich linked data structures seems limited.
>>
>> Not sure what that means ...
>
> Basically, pointers that are always valid in pointing to an
> object of a known type and and that can never be nil.
Seems to me, pointers/indices in use always have a valid value?
>>> I
>>> don't see any support for higher-order functions,
>>
>> Not sure what that means ...
>
> Basically, functions that can be passed as arguments to other
> functions or functions that can be returned from functions.
> These let me do things like write a generic hash table
> implementation, where I can then parameterize calls into the
> resulting data type with functions that implement the actual
> hash for particular types of data. "Hash table of FOO."
Hash tables takes me back to the mid 1970s. :-)
Is what you mean something like:
Z = FIX( SQR( SomeValue ) )
Yeah, rather simple, but is that what you refer to?
>>> lambdas,
>>
>> Not sure what that means ...
>
> Anonymous functions; ie, functions that are unnamed. They're
> very handy in languages that support higher-order functions.
> For example, I can trivially write a projection function that
> will extract a particular member from a data structure to use
> as a sort key.
Not sure if you're making my brain hurt, or discussing something so simple it
doesn't deserve a name. I've built sort keys for longer than I can remember.
>>> or
>>> closures;
>>
>> Not sure what that means ...
>
> Functions that are created dynamically and "close over" part of
> their surrounding environment, e.g., to capture a value that is
> used in the closure itself.
More brain pain ...
>>> no currying of functions.
>>
>> Not sure what that means ...
>
> Partial application of a function, which allows me to create a
> new function that calls some underlying function with some
> arguments already "filled in". An example, from SML:
>
> fun fib' a b 0 = a
> | fib' a b n = fib' (a + b) a (n - 1)
>
> val fib = fib' 0 1
>
> Here `fib` is a function to return the nth Fibonacci
> number.
Why does that require a special name?
> This example demonstrates several of these concepts:
>
> ; sml
> Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
> - val fib =
> = let fun fib' a b 0 = a
> = | fib' a b n = fib' (a + b) a (n - 1)
> = in fn n => fib' 0 1 n
> = end;
> val fib = fn : int -> int
> - fib;
> val it = fn : int -> int
> - fib';
> stdIn:3.1-3.5 Error: unbound variable or constructor: fib'
> - map;
> val it = fn : ('a -> 'b) -> 'a list -> 'b list
> - map (fn n => fib n) [1,2,3,4,5,6,7,8,9];
> val it = [1,1,2,3,5,8,13,21,34] : int list
> - ^D
> ;
>
> Here, we see an example of a closure, in which the anonymous
> function (aka, lambda) returned from the `let` clause that is
> bound to `fib` closes over the `fib'` function, which is not
> visible outside of the `let`. Furthermore, `fib` is an example
> of currying as above. We see the use of higher-order functions
> in the call to `map`, which applies `fib` to each element of the
> given list. We can see it again with a slightly different
> example:
>
> - List.tabulate(10, fn n => fib n);
> [autoloading]
> [library $SMLNJ-BASIS/basis.cm is stable]
> [library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
> [autoloading done]
> val it = [0,1,1,2,3,5,8,13,21,34] : int list
>
> Again, these are all examples from Standard ML, a langauge that
> dates from the 80s, and takes its roots in the 70s.
I'm going to guess that your experience includes labels for certain things,
which might be helpful at times, and exist in subsets of programming practices.
Nothing wrong with that, but might be confusing to some others.
>>> Statement modifiers seem
>>> kind of neat, but I bet they can be easily misused.
>>
>> Statement modifiers are very useful, and in some ways make code easier to
>> understand.
>
> I'm sure they are useful, but I can also imagine that they can
> turn into spaghetti if not used judiciously.
>
> X = X * 0.1 unless FOO != 2;
> X = X * 0.2 unless FOO = 2;
>
> seems strictly less readable than
>
> IF FOO != 2
> X = X * 0.1
> ELSE
> X = X * 0.2
>
> (Apologies for syntax errors.)
The first thing any programmer should learn is, at some time in the future code
will be read by another, and if it is not concise, clear, and understandable, it
is the fault of the original programmer, and he/she should find another occupation.
Yes, if-then-else, select case, and such can be good, and I've also seen such be
hundreds of lines of code, and a real PITA. I tend to favor modular code.
Simple, short, and to the point.
But for a simple true or false, the statement modifiers can be very useful. In
your first example, FOO should be evaluated only once.
>>> All in all, it doesn't look like a terrible language (it's not
>>> COBOL); it looks like an early-1980s-era language. But nothing
>>> about it jumps out at me as being spectacularly amazing, either.
>>
>> It's not amazing, it just works.
>
> Sure. That doesn't mean that it's good by modern standards.
Nor does it mean it is bad either.
>>> I suppose I would turn the question around and ask what's about
>>> BASIC makes it more suitable than other languages for particular
>>> types of programs?
>>
>> For me personally, I really like the syntax of the language. When I have to
>> attempt to read C code I'm easily confused. Many other languages seem to copy
>> the syntax of C.
>
> As has been mentioned, not all "modern" languages have C-like
> syntax. Examples that pop out at me off the top of my head
> include Oberon (Wirth's final language, descendent of Modula-2),
> Ruby, Python, Clojure (a Lisp that targets the JVM), F# (a
> dialect of the OCaml language --- another entry in the ML
> family --- that targets the CLR), OCaml itself (with a native
> compiler). Most of these are 20 years old or more; the youngest
> language on the list is probably Clojure, which is only 17, but
> has its root in Lisp, which dates from the 50s.
>
> Simply preferring the syntax, however, doesn't feel like
> sufficient reason to claim that other languages haven't passed
> BASIC, even VSI BASIC, by. I'm sure it was a decent business
> data processing langauge in the 80s; not so much now days.
>
> - Dan C.
>
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
More information about the Info-vax
mailing list