Re: Baby X is bor nagain

On 20/06/2024 11:34, David Brown wrote:

On 19/06/2024 23:51, bart wrote:

[Discussing Python]

Pretty much everything can be assigned to (the only exception is reserved words). Because every user identifer (even if declared with def or class or module) is a variable.

 The concept of "variable" in Python is quite different from that of C. You can pretend they are similar for very simple Python snippets, but then you will end up thinking there are lots of arbitrary rules for when assignment and function parameters are by value or by reference.  It is better to think that all "things" in Python are anonymous reference-counted objects on the heap.  When it looks like you have a variable, you actually just have a named reference to such objects. Imagine it more like your "variables" are all "void *" pointers or references, while all other types and structures are malloc'd.  These references have no type information - but the objects they point to are all strongly typed.  And the objects have reference-counted garbage collection.

You haven't given an opinion. I think this is an unnecessary aspect of it, which also makes it harder to optimise, and to reason about.
My languages have perhaps a dozen categories of identifiers, known at compile-time, which include variable names. Python has only one, a 'variable'. It mean this is possible:
     def F(n): return n + 1
     ...
     F = 42
     ....
     F(x)                # will not work when F is 42
In my language (in common with most other sensible ones!), if you really wanted that effect, you do it like this:
     fun F(n) = n + 1    # F is a function name; it cannot change
     G := F              # G is a variable name; its value can change
     ...
     G := 42
     ....
     F(x)                # Will always work
     G(x)                # Will not work when G doesn't refer to
                         # a function

That is a way to make structures for interaction with external code - basically, for when you are connecting to DLLs or so libraries.
 

It's just a big, ugly, kitchen-sink language. They throw in every feature they can think of (like C++, possibly why DB likes it) in the hope that somewhere in the mess is a solution to your needs.
>
I'm not surprised it takes 20MB to embed.
>

 Neither Python nor C++ throws in "every feature they can think of" - for both languages, there is a long process of proposals, discussions, testing, and consideration of the impact on the rest of the language, existing code, and possible future language features, before a feature is included.

And /then/ they include the feature! I've long given up keeping track.

  Yes, these are big languages.  Sometimes big is good, sometimes it is bad - it would be wildly foolish to think that one language, or one style of language, is all that people need or want.

It's a big language that ignores many fundamental features. My scripting language is smaller and simpler, but it takes care of those because I think they are important.
The record example, with variant elements, is defined like this:
     record point =
         var x, y
     end
and the C-compatible version, which can also be used to enforce element types, or to save memory if there are large homogeneous arrays of them, like this:
     type cpoint =
         int32 x, y
     end
Both have mutable elements. Neither allow arbitrary attributes (so impossible to misspell member names). And if the FFI demands it, pointers to structs or ints can be passed:
     p := cpoint(10, 20)
     &p            # low-level pointer to the struct
     &p.x          # low-level pointer to the int32 element
or even:
     q := point(10, 20)
     &q.x          # low-level pointer to the now int64 element
It just works with no fuss, with no need for add-ons, or decorators, and using the same syntax you'd use in static language that uses records and structs.
I was aware of Python during the 1990s. My own scripting language was ungainly; so was Python. At one point I needed to bolt-on byte-arrays; so did Python!
But Python even then completely disregarded performance. In the 1990s, if you wrote a loop like this:
     for i in range(1000000):
         ....
it would actually create an object with a million elements so that you could iterate along it. It sounds absolutely crazy, and it was.
Later they added xrange() which didn't do that, and later on 'xrange' morphed into 'range'.