Re: Command Languages Versus Programming Languages

On 1 Apr 2024 14:16:33 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

  In a non-scripting programming language, the types often are
  based on hardware, like "16 bit integer", and typing is often
  handled in a static and rather strict way. Higher types, like
  strings whose size can change at run time, are often missing.

Notwithstanding the fuzziness granted by the use of "often" here, this
doesn't seem like a terribly accurate assessment. Lots of compiled/
"non-scripting" languages - *however* you define that - have dynamic
strings; even C++ provides that as part of the standard library
(admittedly, not as a basic language construct, but that's C for you -
*every* data structure is essentially pointers in a trenchcoat.) AFAIK
it's much rarer to *lack* that capability; C does, for aforementioned
reasons (although you can certainly roll your own,) O.G. Pascal did (as
a hideous misfeature,) probably a few other current systems languages...
but not many spring to mind.

It's also not terribly true that "non-scripting" languages are pre-
dominantly statically-typed. It's more common, certainly, but there are
still a number of compiled applications languages with some kind of
dynamic support. And while the division of number types into floating-
point and integer is very frequently the case, most language standards
don't specify word sizes that strictly (even in C, stdint.h wasn't
introduced until C99 - which lead to headaches of its own, as anyone
who's tried to run old code that makes assumptions about sizeof(int) on
targets that break those assumptions can attest.) Plenty of "non-
scripting" languages include or can be extended with support for
arbitrary bignum types, as well.

  Scripting languages handle the memory for you. In a scripting
  language, you cannot call "malloc" to obtain the obligation to
  free this piece of memory exactly once in the future. They are
  garbage collected.

And while this is pretty true of scripting languages, it doesn't make
for a good point-of-contrast with "non-scripting" languages; *piles* of
them include support for automatic memory management, and some (outside
of the C family) don't even include facilities for doing it "by hand."

Overall, this seems like a very narrow and C-centric view of programming
language design - and while C is definitely *my* language-of-choice for
application development,* let's not pretend it's the absolute be-all
and end-all, as if there *could* be such a thing in a field as vast and
diverse as this!

* (Funnily enough, for a lot of "scripting" type jobs, my go-to is
  actually a compiled language - FreeBasic.)