On 7/13/2021 12:55 PM, Stefan Monnier wrote:
>> Python performance tends to be relatively poor, even among dynamic
>> languages, from what I have seen...
>
> Indeed, the main Python implementation is explicitly designed to be
> "clean" rather than "fast", IIUC. Hence the 48bytes for a plain
> old integer.
>

Yeah, that is a bit much...

In my current dynamic typesystem, I generally have:
fixnum / fixint: 62-bits, stored in the tag-ref.
boxint: 128-bits, stored in memory.

The normal 'variant' type is 64 bits, which basically means if I cut off
a few bits for tags, the largest inline encodings are ~ 62 bits.

As such, boxint needs to be stored on the heap.

The exact semantics for fixnum vs boxint (on BGBCC + BJX2) have not been
decided yet. ATM, the fixnum's are 62-bit modular, since the alternative
would require a (slower and more expensive) overflow check.

There are some placeholders for a 128-bit "fat variant" type, which
could potentially allow a larger fixnum, say, 124 bits.

I wouldn't assume going that much bigger though, since it is rarely
necessary. Then again, a case for such a large integer type could be
made on a "well, you are already spending the cost of a heap allocation"
(and "general overhead" is likely to be a bigger factor than "actually
doing the arithmetic operation").

>> Using a Scheme variant as a transpile target actually works reasonably
>> well. Writing code in it directly is usually less enjoyable though, unless
>> one is using the language in a way which can leverage its features.
>>
>> It does suffer an disadvantage in that the syntax hinders putting in various
>> types of side-channel metadata, such as things like source file and line
>> number information, ...
>
> Might be true for Scheme, but Racket specifically addresses this issue
> because instead of having your transpiler output a text file with
> Scheme/Racket code in it (which loses the file&line info), it outputs
> "syntax objects" (exactly like Scheme/Racket's macros) which preserve
> the original source info. That also avoids the need to print only to
> have the backend parse it back.
>
> Of course, this only works if your transpiler is itself a Racket program.
>

Makes sense. I was assuming the use of normal cons-cell lists, as
opposed to some fancier intermediate AST format.

Ironically, I didn't really want cons lists in my current project, but
ended up re-adding them as they are the "lesser evil" in some contexts
(when compared with variant arrays, which have a higher overhead for
"small N"). Still decided yet if they will officially exist in the
dynamic typesystem though.

Mostly they have appeared in the context of dynamic array building and
dynamic varargs, where, say:
For small N ( <= 8), cheapest option is to build an array directly
passing in values as arguments;
For medium N, cheapest option seems to be to build a cons-list, and then
build an array from the list;
For larger N (typically only likely to occur for arrays), fall back to
using unrolled "setindex" operations (more expensive than a "cons"
operation).

Though, this is within the limitations of all this being handled in the
frontend via runtime calls (a more efficient option is possible, but
would require handling this case in the compiler backend).

....

On 7/13/2021 9:40 AM, BGB wrote:
> On 7/13/2021 3:03 AM, George Neuner wrote:
>> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
>> <sfuld@alumni.cmu.edu.invalid> wrote:
>>
>>> I had heard of Racket, but didn't know anything about it, so I did a
>>> little reading.
>>>
>>> I think the issue to which you are referring is that Racket comes from
>>> the Lisp, Scheme family of languages, this has more parentheses and uses
>>> prefix notation when compared to the Fortran/C type syntax.
>>>
>>> For the record, my undergraduate degree was in Chemistry, so I have some
>>> sympathy for the scientists/engineers.
>>>
>>> Without deprecating Racket in any way (I don't know enough to do that),
>>> I disagree with you and agree with the "too many parentheses/prefix
>>> notation" people.
>>>
>>> These people are not computer scientists, and while they are usually
>>> smart people, they want to get some job in science/engineering done, and
>>> want the easiest tool to use to do that.  They don't particularly care
>>> about some arcane aspects of the language they are using.
>>>
>>> They are familiar with formulas.  They use them all the time in their
>>> classes and in their work.  Remember, Fortran is short for Formula
>>> Translator.  So a language that is similar to that is easier for them to
>>> learn, thus a better choice.  In that context, I don't regard their
>>> disdain for Lisp style language syntax as "nonsense".  They want to do
>>> some job and not be distracted by unfamiliar syntax, etc.
>>>
>>> Thus I think Python is a good choice (not counting the 2-3 mess).
>>
>> A little off-topic, but ...
>>
>> Python is great for scripting - but I do /not/ think it is great for
>> application programming.  Particularly for science or engineering.
>>
>> One of the biggest tells is that most of its data processing libraries
>> are written in C - not in Python.  Whether simply for performance, or
>> for the inability of the language to express the solution, many people
>> have decided to bypass the language.
>>
>> So what happens when there is no library for what you want to do.  Can
>> you express your solution in Python?  Yeah, probably ... but will it
>> perform well enough when you point it at large amounts of data?
>> Probably not.
>>
>
> Python performance tends to be relatively poor, even among dynamic
> languages, from what I have seen...
>
>
>>
>>
>> In contrast, most of Racket's libraries are written in Racket.  In
>> fact, most of Racket is written in Racket - there is only a small
>> bootstrap core that still is C/asm.
>>
>> There is a portable bytecode interpreter, but on most platforms Racket
>> applications are compiled: either JIT (long time), or in more recent
>> versions with an AOT compiler.
>>
>> No disputing, Racket has a steeper learning curve than Python - but if
>> there is no existing code that does what you want, you probably can
>> write it in Racket and /still/ get good performance without dropping
>> into a different langauge (which you can, Racket has a full featured
>> FFI if you need it).
>>
>> And if you don't like the default Lisp/Scheme-like syntax or behavior,
>> Racket is a perfect transpile target for DSLs.  Racket provides a YACC
>> work-alike, and a number of other parsers (LL and LR) are available as
>> libraries.  You can create a language using any syntax you like.
>> Transpiled languages can be freely intermixed in the same program.
>>
>> There are a number of such DSLs already: Prolog, Java, Algol-60, ML,
>> even Python [though I don't know which version or how complete it is].
>> And many others.
>>
>
> Using a Scheme variant as a transpile target actually works reasonably
> well. Writing code in it directly is usually less enjoyable though,
> unless one is using the language in a way which can leverage its features.
>
>
> It does suffer an disadvantage in that the syntax hinders putting in
> various types of side-channel metadata, such as things like source file
> and line number information, ... It also doesn't deal as well with
> structures where a lot of members may be optional.
>
> And, by the time one addresses the above issue, it has lost most of what
> advantage it would have had over a more flexible format.
>
>
>>
>>
>> For all that, Racket's developers are concerned that Lisp and/or
>> Scheme has negative connotations and that people will avoid trying
>> Racket simply because of the relationship.  They are seriously
>> considering creating a new language, with similar features but with an
>> infix syntax, and deprecating the existing prefix/sexpr syntax.
>>
>> The problem is, this (IMO bad) idea has been tried before:  Lisp
>> itself was intended to have an infix syntax, but McCarthy backed off
>> when existing Lisp programmers balked at using it.  Apple's Dylan
>> language had a lot to offer, but died tragically when it changed from
>> a Scheme-like to an Algol-like syntax.
>>
>
> It is a tradeoff.
>
> A more traditional syntax is generally easier to work with, but granted
> a lot of Lisp style features will not work nearly as well with a
> different syntax.
>
> One of the main things it has going for it is the ability to work with
> S-Expressions as data and then eval them or similar, or use them as part
> of a procedural macro system, but this ability is quickly lost, and
> doesn't map out nearly as well to a more opaque AST format.
>
>
> This means that in a language with a more conventional syntax, an eval
> mechanism generally needs to work with strings, and then often ends up
> restricted (frequently a target of exploits; some of the major use-cases
> for eval often adding glaring security holes).
>
> In statically compiled versions of a language, eval is often either
> unavailable, or operates within an interpreter with its own environment
> often separate from that of the parent.
>
> ...
>
>
> One could, in theory, have a language which uses a more familiar syntax
> natively, but then switches over to a Lisp style syntax for
> metaprogramming and eval, but this would be kinda wonky and weird.

Here's one vote for SmallTalk.

On 7/13/2021 7:42 PM, Ivan Godard wrote:
> On 7/13/2021 9:40 AM, BGB wrote:
>> On 7/13/2021 3:03 AM, George Neuner wrote:
>>> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
>>> <sfuld@alumni.cmu.edu.invalid> wrote:
>>>
>>>> I had heard of Racket, but didn't know anything about it, so I did a
>>>> little reading.
>>>>
>>>> I think the issue to which you are referring is that Racket comes from
>>>> the Lisp, Scheme family of languages, this has more parentheses and
>>>> uses
>>>> prefix notation when compared to the Fortran/C type syntax.
>>>>
>>>> For the record, my undergraduate degree was in Chemistry, so I have
>>>> some
>>>> sympathy for the scientists/engineers.
>>>>
>>>> Without deprecating Racket in any way (I don't know enough to do that),
>>>> I disagree with you and agree with the "too many parentheses/prefix
>>>> notation" people.
>>>>
>>>> These people are not computer scientists, and while they are usually
>>>> smart people, they want to get some job in science/engineering done,
>>>> and
>>>> want the easiest tool to use to do that.  They don't particularly care
>>>> about some arcane aspects of the language they are using.
>>>>
>>>> They are familiar with formulas.  They use them all the time in their
>>>> classes and in their work.  Remember, Fortran is short for Formula
>>>> Translator.  So a language that is similar to that is easier for
>>>> them to
>>>> learn, thus a better choice.  In that context, I don't regard their
>>>> disdain for Lisp style language syntax as "nonsense".  They want to do
>>>> some job and not be distracted by unfamiliar syntax, etc.
>>>>
>>>> Thus I think Python is a good choice (not counting the 2-3 mess).
>>>
>>> A little off-topic, but ...
>>>
>>> Python is great for scripting - but I do /not/ think it is great for
>>> application programming.  Particularly for science or engineering.
>>>
>>> One of the biggest tells is that most of its data processing libraries
>>> are written in C - not in Python.  Whether simply for performance, or
>>> for the inability of the language to express the solution, many people
>>> have decided to bypass the language.
>>>
>>> So what happens when there is no library for what you want to do.  Can
>>> you express your solution in Python?  Yeah, probably ... but will it
>>> perform well enough when you point it at large amounts of data?
>>> Probably not.
>>>
>>
>> Python performance tends to be relatively poor, even among dynamic
>> languages, from what I have seen...
>>
>>
>>>
>>>
>>> In contrast, most of Racket's libraries are written in Racket.  In
>>> fact, most of Racket is written in Racket - there is only a small
>>> bootstrap core that still is C/asm.
>>>
>>> There is a portable bytecode interpreter, but on most platforms Racket
>>> applications are compiled: either JIT (long time), or in more recent
>>> versions with an AOT compiler.
>>>
>>> No disputing, Racket has a steeper learning curve than Python - but if
>>> there is no existing code that does what you want, you probably can
>>> write it in Racket and /still/ get good performance without dropping
>>> into a different langauge (which you can, Racket has a full featured
>>> FFI if you need it).
>>>
>>> And if you don't like the default Lisp/Scheme-like syntax or behavior,
>>> Racket is a perfect transpile target for DSLs.  Racket provides a YACC
>>> work-alike, and a number of other parsers (LL and LR) are available as
>>> libraries.  You can create a language using any syntax you like.
>>> Transpiled languages can be freely intermixed in the same program.
>>>
>>> There are a number of such DSLs already: Prolog, Java, Algol-60, ML,
>>> even Python [though I don't know which version or how complete it is].
>>> And many others.
>>>
>>
>> Using a Scheme variant as a transpile target actually works reasonably
>> well. Writing code in it directly is usually less enjoyable though,
>> unless one is using the language in a way which can leverage its
>> features.
>>
>>
>> It does suffer an disadvantage in that the syntax hinders putting in
>> various types of side-channel metadata, such as things like source
>> file and line number information, ... It also doesn't deal as well
>> with structures where a lot of members may be optional.
>>
>> And, by the time one addresses the above issue, it has lost most of
>> what advantage it would have had over a more flexible format.
>>
>>
>>>
>>>
>>> For all that, Racket's developers are concerned that Lisp and/or
>>> Scheme has negative connotations and that people will avoid trying
>>> Racket simply because of the relationship.  They are seriously
>>> considering creating a new language, with similar features but with an
>>> infix syntax, and deprecating the existing prefix/sexpr syntax.
>>>
>>> The problem is, this (IMO bad) idea has been tried before:  Lisp
>>> itself was intended to have an infix syntax, but McCarthy backed off
>>> when existing Lisp programmers balked at using it.  Apple's Dylan
>>> language had a lot to offer, but died tragically when it changed from
>>> a Scheme-like to an Algol-like syntax.
>>>
>>
>> It is a tradeoff.
>>
>> A more traditional syntax is generally easier to work with, but
>> granted a lot of Lisp style features will not work nearly as well with
>> a different syntax.
>>
>> One of the main things it has going for it is the ability to work with
>> S-Expressions as data and then eval them or similar, or use them as
>> part of a procedural macro system, but this ability is quickly lost,
>> and doesn't map out nearly as well to a more opaque AST format.
>>
>>
>> This means that in a language with a more conventional syntax, an eval
>> mechanism generally needs to work with strings, and then often ends up
>> restricted (frequently a target of exploits; some of the major
>> use-cases for eval often adding glaring security holes).
>>
>> In statically compiled versions of a language, eval is often either
>> unavailable, or operates within an interpreter with its own
>> environment often separate from that of the parent.
>>
>> ...
>>
>>
>> One could, in theory, have a language which uses a more familiar
>> syntax natively, but then switches over to a Lisp style syntax for
>> metaprogramming and eval, but this would be kinda wonky and weird.
>
> Here's one vote for SmallTalk.
>

Hmm...

Early on, design for my scripting language was also influenced by Self,
which was itself a Smalltalk variant.

I hadn't been a huge fan of Smalltalk syntax, but it did influence a few
minor things in my languages.

Well, as noted, Scheme, Common Lisp, and Erlang had also been design
influences, along with C and JavaScript.

Initially, the Self influence took the form of a delegation feature,
where object fields named in a certain way would delegate to other
objects (IIRC, "foo" was a normal field, but "_foo" would delegate).

In slightly later versions (BS 1.5), this naming trick was replaced by
the use of a 'delegate' keyword, and 'self' was replaced with 'this'.
The 'this' variable was itself defined in terms of a delegate variable
(albeit was special in the VM); and "packages" were also originally
themselves defined in terms of objects and delegation.

In effect, the environment was composed of an interconnected mesh of
dictionary objects (generally with a hash-table used to cache lookups;
and a mechanism to flush the hash table, flush the contents of the JIT,
...., if one of these paths was modified after it had been traversed).
There was also a mechanism to avoid recursing into an object which has
already been visited during the search (the graphs were allowed to be
cyclic).

Meanwhile, JavaScript had used a more limited system where objects could
only have a single 'prototype' field which had this property, and they
didn't really apply it to anything else in the language. Likewise, JS
had used a simpler/plain lexical-scoping model.

On 13/07/2021 18:13, Stephen Fuld wrote:
> On 7/13/2021 1:03 AM, George Neuner wrote:
>> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
>> <sfuld@alumni.cmu.edu.invalid> wrote:
>>
>>> I had heard of Racket, but didn't know anything about it, so I did a
>>> little reading.
>>>
>>> I think the issue to which you are referring is that Racket comes from
>>> the Lisp, Scheme family of languages, this has more parentheses and uses
>>> prefix notation when compared to the Fortran/C type syntax.
>>>
>>> For the record, my undergraduate degree was in Chemistry, so I have some
>>> sympathy for the scientists/engineers.
>>>
>>> Without deprecating Racket in any way (I don't know enough to do that),
>>> I disagree with you and agree with the "too many parentheses/prefix
>>> notation" people.
>>>
>>> These people are not computer scientists, and while they are usually
>>> smart people, they want to get some job in science/engineering done, and
>>> want the easiest tool to use to do that.  They don't particularly care
>>> about some arcane aspects of the language they are using.
>>>
>>> They are familiar with formulas.  They use them all the time in their
>>> classes and in their work.  Remember, Fortran is short for Formula
>>> Translator.  So a language that is similar to that is easier for them to
>>> learn, thus a better choice.  In that context, I don't regard their
>>> disdain for Lisp style language syntax as "nonsense".  They want to do
>>> some job and not be distracted by unfamiliar syntax, etc.
>>>
>>> Thus I think Python is a good choice (not counting the 2-3 mess).
>>
>> A little off-topic, but ...
>>
>> Python is great for scripting - but I do /not/ think it is great for
>> application programming.  Particularly for science or engineering.
>>
>> One of the biggest tells is that most of its data processing libraries
>> are written in C - not in Python.  Whether simply for performance, or
>> for the inability of the language to express the solution, many people
>> have decided to bypass the language.
>
> I took the existence of fast data processing libraries as a plus. :-)
> That is, you use Python proper as glue to do minor minor formatting,
> selection, etc. of data, but the "hard work" is done quickly in proven
> library functions.  I thought that was a typical use case for Python.
>

Yes, if you want to do number crunching with Python you use numpy or
scipy. The hard work is all done with the low-level C libraries, while
the Python lets you write the glue, file handling, network handling,
formatting, and whatever else quickly and simply. Your numeric code has
to fit the libraries, but is otherwise quite flexible and you get
Python-style dynamic typing, list handling, automatic resource
management, etc.

>
>> So what happens when there is no library for what you want to do.  Can
>> you express your solution in Python?  Yeah, probably ... but will it
>> perform well enough when you point it at large amounts of data?
>> Probably not.
>
> Doesn't Python provide an option to output a C program, which is then
> compiled and run?  I view this as sort of an intermediate solution.
> Faster than pure Python though not as fast as purpose written say C, but
> easier to develop and test.
>

There are a few tools and Python extensions for letting you turn some
kinds of Python code into C, but they are limited. And there is little
point in them if you are using numpy or scipy.

The key trick to high speed Python code is to make sure anything
time-consuming is done by C libraries, not Python. That's why Python
programs are fine for networking, text handling, file work, gui programs
- all the hard work is in the libraries.

Everyone has their own favourite statistic about 80% of the program time
being spent in 20% of the code, or variants thereof. For hard numeric
work, it will be more like 98% and 2%. As long as you make sure the 98%
of the time is in C libraries, it doesn't matter if the Python code
takes 10 times as long as C code because it does not affect the end result.

(Python also has a limit on multi-threading - the Global Interpreter
Lock means Python code itself in one program can't use more than one
core. It simplifies making code thread-safe, however. And any
time-consuming C library will release the GIL, meaning that work can be
fully multi-threaded.)

There is also the big JIT Python project pypy. It does JIT compilation
of Python code, and can give large speed boosts to the pure Python
parts. The results are mostly only a few times slower than C, but can
occasionally even be faster as the JIT system can see how the code is
used in practice, and is not limited to one Python function making one
compiled function. (It's similar to template-based C++ sort being
faster than a flexible C qsort function.)

Den 2021-07-13 kl. 18:40, skrev BGB:
> On 7/13/2021 3:03 AM, George Neuner wrote:

[snip]

>>
>> A little off-topic, but ...
>>
>> Python is great for scripting - but I do /not/ think it is great for
>> application programming.  Particularly for science or engineering.
>>
>> One of the biggest tells is that most of its data processing libraries
>> are written in C - not in Python.  Whether simply for performance, or
>> for the inability of the language to express the solution, many people
>> have decided to bypass the language.
>>
>> So what happens when there is no library for what you want to do.  Can
>> you express your solution in Python?  Yeah, probably ... but will it
>> perform well enough when you point it at large amounts of data?
>> Probably not.
>>
>
> Python performance tends to be relatively poor, even among dynamic
> languages, from what I have seen...

I did a quick benchmark of a naive DAXPY written in C, Python, Lua
and JavaScript. I ran 10000 iterations over arrays with 100000 double
precision elements on a down-clocked Zen 2:

+--------------+------------+-------------------+
| | Time (ms) | Comment |
+--------------+------------+-------------------+
| gcc -O3 | 304 | Vectorized (SIMD) |
+--------------+------------+-------------------+
| gcc -O2 | 449 | Scalar |
+--------------+------------+-------------------+
| gcc -O1 | 651 | |
+--------------+------------+-------------------+
| luajit | 941 | |
+--------------+------------+-------------------+
| JS (Chrome) | 1421 | |
+--------------+------------+-------------------+
| PyPy (JIT) | 1576 | |
+--------------+------------+-------------------+
| JS (Firefox) | 1892 | |
+--------------+------------+-------------------+
| gcc -O0 | 6203 | |
+--------------+------------+-------------------+
| lua | 47107 | |
+--------------+------------+-------------------+
| Python 2 | 131612 | |
+--------------+------------+-------------------+
| Python 3 | 134498 | |
+--------------+------------+-------------------+

....so yes, Python raw number crunching performance is bad.

But as others have pointed out, it usually does not matter since that is
not the way you should do number crunching in Python (similar to how you
should avoid for loops at all cost in Matlab).

/Marcus

>
> [snip]
>

On 7/14/2021 3:50 AM, Marcus wrote:
> Den 2021-07-13 kl. 18:40, skrev BGB:
>> On 7/13/2021 3:03 AM, George Neuner wrote:
>
> [snip]
>
>>>
>>> A little off-topic, but ...
>>>
>>> Python is great for scripting - but I do /not/ think it is great for
>>> application programming.  Particularly for science or engineering.
>>>
>>> One of the biggest tells is that most of its data processing libraries
>>> are written in C - not in Python.  Whether simply for performance, or
>>> for the inability of the language to express the solution, many people
>>> have decided to bypass the language.
>>>
>>> So what happens when there is no library for what you want to do.  Can
>>> you express your solution in Python?  Yeah, probably ... but will it
>>> perform well enough when you point it at large amounts of data?
>>> Probably not.
>>>
>>
>> Python performance tends to be relatively poor, even among dynamic
>> languages, from what I have seen...
>
> I did a quick benchmark of a naive DAXPY written in C, Python, Lua
> and JavaScript. I ran 10000 iterations over arrays with 100000 double
> precision elements on a down-clocked Zen 2:
>
> +--------------+------------+-------------------+
> |              | Time (ms)  | Comment           |
> +--------------+------------+-------------------+
> | gcc -O3      |        304 | Vectorized (SIMD) |
> +--------------+------------+-------------------+
> | gcc -O2      |        449 | Scalar            |
> +--------------+------------+-------------------+
> | gcc -O1      |        651 |                   |
> +--------------+------------+-------------------+
> | luajit       |        941 |                   |
> +--------------+------------+-------------------+
> | JS (Chrome)  |       1421 |                   |
> +--------------+------------+-------------------+
> | PyPy (JIT)   |       1576 |                   |
> +--------------+------------+-------------------+
> | JS (Firefox) |       1892 |                   |
> +--------------+------------+-------------------+
> | gcc -O0      |       6203 |                   |
> +--------------+------------+-------------------+
> | lua          |      47107 |                   |
> +--------------+------------+-------------------+
> | Python 2     |     131612 |                   |
> +--------------+------------+-------------------+
> | Python 3     |     134498 |                   |
> +--------------+------------+-------------------+
>
> ...so yes, Python raw number crunching performance is bad.
>
> But as others have pointed out, it usually does not matter since that is
> not the way you should do number crunching in Python (similar to how you
> should avoid for loops at all cost in Matlab).
>

Even for a lot of application scripting tasks, it is pretty bad.

For something, like running NPC AI + world physics + terrain generation
in a game, the performance would be pretty bad.

And for real-time motor control or similar, it would be hopeless...

Though, besides just performance, in some contexts (such as real time
motor control), reliance on a garbage collector may be unacceptable.

....

Though, thinking about it, may need to write a benchmark for the dynamic
typing extensions in BGBCC, and see how much slower they are than using
native types. May follow up with this later if I do so.

For the moment, need to come up with a good benchmark for this use-case.

> /Marcus
>
>>
>>  [snip]
>>

On 7/14/2021 11:01 AM, BGB wrote:
> On 7/14/2021 3:50 AM, Marcus wrote:
>> Den 2021-07-13 kl. 18:40, skrev BGB:
>>> On 7/13/2021 3:03 AM, George Neuner wrote:
>>
>> [snip]
>>
>>>>
>>>> A little off-topic, but ...
>>>>
>>>> Python is great for scripting - but I do /not/ think it is great for
>>>> application programming.  Particularly for science or engineering.
>>>>
>>>> One of the biggest tells is that most of its data processing libraries
>>>> are written in C - not in Python.  Whether simply for performance, or
>>>> for the inability of the language to express the solution, many people
>>>> have decided to bypass the language.
>>>>
>>>> So what happens when there is no library for what you want to do.  Can
>>>> you express your solution in Python?  Yeah, probably ... but will it
>>>> perform well enough when you point it at large amounts of data?
>>>> Probably not.
>>>>
>>>
>>> Python performance tends to be relatively poor, even among dynamic
>>> languages, from what I have seen...
>>
>> I did a quick benchmark of a naive DAXPY written in C, Python, Lua
>> and JavaScript. I ran 10000 iterations over arrays with 100000 double
>> precision elements on a down-clocked Zen 2:
>>
>> +--------------+------------+-------------------+
>> |              | Time (ms)  | Comment           |
>> +--------------+------------+-------------------+
>> | gcc -O3      |        304 | Vectorized (SIMD) |
>> +--------------+------------+-------------------+
>> | gcc -O2      |        449 | Scalar            |
>> +--------------+------------+-------------------+
>> | gcc -O1      |        651 |                   |
>> +--------------+------------+-------------------+
>> | luajit       |        941 |                   |
>> +--------------+------------+-------------------+
>> | JS (Chrome)  |       1421 |                   |
>> +--------------+------------+-------------------+
>> | PyPy (JIT)   |       1576 |                   |
>> +--------------+------------+-------------------+
>> | JS (Firefox) |       1892 |                   |
>> +--------------+------------+-------------------+
>> | gcc -O0      |       6203 |                   |
>> +--------------+------------+-------------------+
>> | lua          |      47107 |                   |
>> +--------------+------------+-------------------+
>> | Python 2     |     131612 |                   |
>> +--------------+------------+-------------------+
>> | Python 3     |     134498 |                   |
>> +--------------+------------+-------------------+
>>
>> ...so yes, Python raw number crunching performance is bad.
>>
>> But as others have pointed out, it usually does not matter since that is
>> not the way you should do number crunching in Python (similar to how you
>> should avoid for loops at all cost in Matlab).
>>
>
> Even for a lot of application scripting tasks, it is pretty bad.
>
> For something, like running NPC AI + world physics + terrain generation
> in a game, the performance would be pretty bad.
>
> And for real-time motor control or similar, it would be hopeless...
>
> Though, besides just performance, in some contexts (such as real time
> motor control), reliance on a garbage collector may be unacceptable.
>
> ...
>
>
> Though, thinking about it, may need to write a benchmark for the dynamic
> typing extensions in BGBCC, and see how much slower they are than using
> native types. May follow up with this later if I do so.
>
> For the moment, need to come up with a good benchmark for this use-case.
>

Quick and dirty prime sieve on BJX2, counting primes below 65536:
Sieve 1A Time 72657us, got 6542
Sieve 1V Time 244500us, got 6542

This is implementing a fairly naive version of the "Sieve of
Eratosthenes" algorithm.

So, 1A is using native types, and 1V is using dynamic types (variant type).

1A takes 72.7ms, and 1V takes 244.5ms, running at 50MHz (in emulator).
So, the overall ratio between them is ~ 3.37x ...

Both find 6542 primes, which agree with the results I can find online.

Was kinda paranoid it might be a little more, given pretty much every
operator in the 1V case is a function call into the runtime, which then
checks the type of the argument and then dispatches to some logic to
actually perform the operator in question.

At least going by this result, they are "probably not completely
useless" (if one is in a situation where type-flexibility matters more
than speed).

Though, a benchmark which runs a more extensive test of the type-system
might be better here.

On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
<ivan@millcomputing.com> wrote:

>On 7/13/2021 9:40 AM, BGB wrote:
>
>> One could, in theory, have a language which uses a more familiar syntax
>> natively, but then switches over to a Lisp style syntax for
>> metaprogramming and eval, but this would be kinda wonky and weird.
>
>Here's one vote for SmallTalk.

I have a fondness for SmallTalk, but ...

The problem with single paradigm languages - regardless of what
paradigm they offer - is having to shoehornevery solutions into it.

Now, it's true that most (nominally) OO languages really are dual
OO/procedural ... and it's also true that that combination covers a
lot of problem space. But still sometimes it forces the programmer
into "unnatural" approaches.

I prefer languages that fully support (at least) OO, procedural, and
functional styles ... they give the most latitude to solve problems in
the most natural way.

In context of this thread:

Python technically does support all 3 paradigms above - but it does so
SLOWLY, and it does not support declarative Prolog-style logic
programming. Paraphrasing Ivan Godard: sometimes you really need
Prolog.

C++ suffers also in not REALLY supporting declarative. Yes ... it is
/possible/ using templates, but it is anything but easy. Creating a
logic programming language using C++ templates is an exercise in
banging your head against a wall ... far harder than the equivalent
macro programming in Lisp or Scheme. [Never mind what can be done in
Racket with its deliberate DSL mix-in support.]

Racket offers all 4 paradigms: OO, procedural, functional, AND
declarative/logic through existing DSLs. Of course, any Lisp can
claim the same: but I happen to prefer Scheme vs Lisp[*], and since
Racket is a Scheme derivative, for me it was a natural choice for a
powerful, "batteries included", cross-platform development tool.

YMMV,
George
[*] "Scheme vs Lisp" is a religious thing not to be discussed

On 7/15/2021 8:46 AM, George Neuner wrote:
> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
> <ivan@millcomputing.com> wrote:
>
>> On 7/13/2021 9:40 AM, BGB wrote:
>>
>>> One could, in theory, have a language which uses a more familiar syntax
>>> natively, but then switches over to a Lisp style syntax for
>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>
>> Here's one vote for SmallTalk.
>
> I have a fondness for SmallTalk, but ...
>
> The problem with single paradigm languages - regardless of what
> paradigm they offer - is having to shoehornevery solutions into it.
>
> Now, it's true that most (nominally) OO languages really are dual
> OO/procedural ... and it's also true that that combination covers a
> lot of problem space. But still sometimes it forces the programmer
> into "unnatural" approaches.
>
> I prefer languages that fully support (at least) OO, procedural, and
> functional styles ... they give the most latitude to solve problems in
> the most natural way.

In general, having more choices is good, as long as it doesn't make the
language too complex such that it hinders usability.

> In context of this thread:
>
> Python technically does support all 3 paradigms above - but it does so
> SLOWLY, and it does not support declarative Prolog-style logic
> programming. Paraphrasing Ivan Godard: sometimes you really need
> Prolog.

Yes, but again, the "typical" scientist/engineer doesn't care about
things like programming paradigms. He/she just wants to get their main
job done.

And for most, given the usage pattern, speed is a minor consideration.
I am concerned about what others have reported about compatibility among
Python versions, other than the 2-3 transition. If they are really
frequently making lots of incompatible changes, that it a problem, not
just for reproduceability, but for usability over time.

> C++ suffers also in not REALLY supporting declarative. Yes ... it is
> /possible/ using templates, but it is anything but easy. Creating a
> logic programming language using C++ templates is an exercise in
> banging your head against a wall ... far harder than the equivalent
> macro programming in Lisp or Scheme. [Never mind what can be done in
> Racket with its deliberate DSL mix-in support.]
>
> Racket offers all 4 paradigms: OO, procedural, functional, AND
> declarative/logic through existing DSLs.

I have mixed feelings about DSLs. Of course, they are well tailored for
solving the problem at hand (that is, the problems they were designed to
address), but it is another language to learn and will typically have
less general applicability thus less usage and support.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/15/2021 10:46 AM, George Neuner wrote:
> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
> <ivan@millcomputing.com> wrote:
>
>> On 7/13/2021 9:40 AM, BGB wrote:
>>
>>> One could, in theory, have a language which uses a more familiar syntax
>>> natively, but then switches over to a Lisp style syntax for
>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>
>> Here's one vote for SmallTalk.
>
> I have a fondness for SmallTalk, but ...
>
> The problem with single paradigm languages - regardless of what
> paradigm they offer - is having to shoehornevery solutions into it.
>

General problem with "simplistic" languages in general.
They work well for one set of tasks, but become awkward or fall on their
face for others.

I think it is telling that an ugly hack-job (Objective-C) is used
significantly more often than SmallTalk.

One of the languages which I took inspiration from when I was younger,
namely Self, seemingly hasn't expanded much beyond being a research toy.

> Now, it's true that most (nominally) OO languages really are dual
> OO/procedural ... and it's also true that that combination covers a
> lot of problem space. But still sometimes it forces the programmer
> into "unnatural" approaches.
>
> I prefer languages that fully support (at least) OO, procedural, and
> functional styles ... they give the most latitude to solve problems in
> the most natural way.
>

Generally agreed.

A language needs to be able to fit the tasks one is using it for, not in
some abstract "you can do anything in anything" sense, but needs to not
have any major drawbacks which hinder its usability.

Features are also not an inherent good, but presumably need to offer
some benefit, and not cause significant harm in other areas.

>
> In context of this thread:
>
> Python technically does support all 3 paradigms above - but it does so
> SLOWLY, and it does not support declarative Prolog-style logic
> programming. Paraphrasing Ivan Godard: sometimes you really need
> Prolog.
>

Though, I guess one possible area of investigation would be comparing
mainline Python with MicroPython. It seems possible MicroPython may have
addressed some of the issues with mainline Python.

> C++ suffers also in not REALLY supporting declarative. Yes ... it is
> /possible/ using templates, but it is anything but easy. Creating a
> logic programming language using C++ templates is an exercise in
> banging your head against a wall ... far harder than the equivalent
> macro programming in Lisp or Scheme. [Never mind what can be done in
> Racket with its deliberate DSL mix-in support.]
>

Sadly, I have not personally found a good way to glue Lisp style macros
onto a C family language.

In the past, with one of my assemblers, I did add some features to allow
limited conditional logic, looping, and recursion within text-based
preprocessor macros (block macros).

Though, arguably, this is still "kinda awful".

In theory, it is also sort of possible to implement conditional and
procedural macros and looping, in the C preprocessor via clever use of
recursive #include, and the fancy block macros mostly just provided an
alternative to the use of recursive include, and some "less absurd"
mechanisms to allow writing looping macros.

In theory, someone could also define a new macro language partly along
vaguely similar lines to using PHP as a macro preprocessor (preferably
in a way which is backwards compatible with the existing C style
preprocessor).

Say, for example:
#macroed
.... blobs of PHP style cruft ...
#endmacroed

The macroed code would use a similar syntax to JS or PHP. These would
turn parts of the C preprocessor into an API, and allow printing out
program code via 'echo' statements or similar.

Possibly, either a new type of define, or a special syntax, could be
used for invoking functions within the macroed space within the main
function.

Though, this does seem a little like a "sledgehammer" solution.

> Racket offers all 4 paradigms: OO, procedural, functional, AND
> declarative/logic through existing DSLs. Of course, any Lisp can
> claim the same: but I happen to prefer Scheme vs Lisp[*], and since
> Racket is a Scheme derivative, for me it was a natural choice for a
> powerful, "batteries included", cross-platform development tool.
>

There are pros/cons, it is not a particularly small dependency.

> YMMV,
> George
> [*] "Scheme vs Lisp" is a religious thing not to be discussed
>

On 7/15/2021 10:16 AM, Stephen Fuld wrote:
> On 7/15/2021 8:46 AM, George Neuner wrote:
>> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
>> <ivan@millcomputing.com> wrote:
>>
>>> On 7/13/2021 9:40 AM, BGB wrote:
>>>
>>>> One could, in theory, have a language which uses a more familiar syntax
>>>> natively, but then switches over to a Lisp style syntax for
>>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>>
>>> Here's one vote for SmallTalk.
>>
>> I have a fondness for SmallTalk, but ...
>>
>> The problem with single paradigm languages - regardless of what
>> paradigm they offer - is having to shoehornevery solutions into it.
>>
>> Now, it's true that most (nominally) OO languages really are dual
>> OO/procedural ... and it's also true that that combination covers a
>> lot of problem space.  But still sometimes it forces the programmer
>> into "unnatural" approaches.
>>
>> I prefer languages that fully support (at least) OO, procedural, and
>> functional styles ... they give the most latitude to solve problems in
>> the most natural way.
>
> In general, having more choices is good, as long as it doesn't make the
> language too complex such that it hinders usability.
>
>
>> In context of this thread:
>>
>> Python technically does support all 3 paradigms above - but it does so
>> SLOWLY, and it does not support declarative Prolog-style logic
>> programming.  Paraphrasing Ivan Godard: sometimes you really need
>> Prolog.
>
>
> Yes, but again, the "typical" scientist/engineer doesn't care about
> things like programming paradigms.  He/she just wants to get their main
> job done.
>
> And for most, given the usage pattern, speed is a minor consideration. I
> am concerned about what others have reported about compatibility among
> Python versions, other than the 2-3 transition.  If they are really
> frequently making lots of incompatible changes, that it a problem, not
> just for reproduceability, but for usability over time.
>
>
>
>> C++ suffers also in not REALLY supporting declarative.  Yes ... it is
>> /possible/ using templates, but it is anything but easy.  Creating a
>> logic programming language using C++ templates is an exercise in
>> banging your head against a wall ... far harder than the equivalent
>> macro programming in Lisp or Scheme. [Never mind what can be done in
>> Racket with its deliberate DSL mix-in support.]
>>
>> Racket offers all 4 paradigms: OO, procedural, functional, AND
>> declarative/logic through existing DSLs.
>
> I have mixed feelings about DSLs.  Of course, they are well tailored for
> solving the problem at hand (that is, the problems they were designed to
> address), but it is another language to learn and will typically have
> less general applicability thus less usage and support.

I want a DSL whose domain is creating DSLs. I find that C++ does so
adequately and has other advantages.

Ivan Godard <ivan@millcomputing.com> writes:

[..]

> Here's one vote for SmallTalk.

The 't' is lower case - Smalltalk.

BGB <cr88192@gmail.com> writes:

[...]

> I think it is telling that an ugly hack-job (Objective-C) is used
> significantly more often than SmallTalk.

Objective-C is a programming language in the conventional sense
of the term.

Smalltalk is both a programming language and a surrounding
development environment. The two are tightly intertwined,
which is a double-edged sword.

After years of being part of the Smalltalk community, I
have the impression that having to work on Smalltalk
programs inside the Smalltalk environment is a large
part of why Smalltalk never caught on as a "serious"
programming language. Its model was just too different.

George Neuner <gneuner2@comcast.net> writes:

> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
> <ivan@millcomputing.com> wrote:
>
>> On 7/13/2021 9:40 AM, BGB wrote:
>>
>>> One could, in theory, have a language which uses a more familiar syntax
>>> natively, but then switches over to a Lisp style syntax for
>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>
>> Here's one vote for SmallTalk.
>
> I have a fondness for SmallTalk, but ...
>
> The problem with single paradigm languages - regardless of what
> paradigm they offer - is having to shoehornevery solutions into it.
>
> Now, it's true that most (nominally) OO languages really are dual
> OO/procedural ... and it's also true that that combination covers a
> lot of problem space. But still sometimes it forces the programmer
> into "unnatural" approaches.
>
> I prefer languages that fully support (at least) OO, procedural, and
> functional styles ... they give the most latitude to solve problems in
> the most natural way.
>
>
> In context of this thread:
>
> Python technically does support all 3 paradigms above - but it does so
> SLOWLY, and it does not support declarative Prolog-style logic
> programming. Paraphrasing Ivan Godard: sometimes you really need
> Prolog.
>
> C++ suffers also in not REALLY supporting declarative. Yes ... it is
> /possible/ using templates, but it is anything but easy. Creating a
> logic programming language using C++ templates is an exercise in
> banging your head against a wall ... far harder than the equivalent
> macro programming in Lisp or Scheme. [Never mind what can be done in
> Racket with its deliberate DSL mix-in support.]
>
> Racket offers all 4 paradigms: OO, procedural, functional, AND
> declarative/logic through existing DSLs. Of course, any Lisp can
> claim the same: but I happen to prefer Scheme vs Lisp[*], and since
> Racket is a Scheme derivative, for me it was a natural choice for a
> powerful, "batteries included", cross-platform development tool.

Wait! You're both right! It's a floor wax _and_ a dessert
topping.

On 15/07/21 22:50, Ivan Godard wrote:
> On 7/15/2021 10:16 AM, Stephen Fuld wrote:
>> On 7/15/2021 8:46 AM, George Neuner wrote:
>>> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
>>> <ivan@millcomputing.com> wrote:
>>>
>>>> On 7/13/2021 9:40 AM, BGB wrote:
>>>>
>>>>> One could, in theory, have a language which uses a more familiar syntax
>>>>> natively, but then switches over to a Lisp style syntax for
>>>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>>>
>>>> Here's one vote for SmallTalk.
>>>
>>> I have a fondness for SmallTalk, but ...
>>>
>>> The problem with single paradigm languages - regardless of what
>>> paradigm they offer - is having to shoehornevery solutions into it.
>>>
>>> Now, it's true that most (nominally) OO languages really are dual
>>> OO/procedural ... and it's also true that that combination covers a
>>> lot of problem space.  But still sometimes it forces the programmer
>>> into "unnatural" approaches.
>>>
>>> I prefer languages that fully support (at least) OO, procedural, and
>>> functional styles ... they give the most latitude to solve problems in
>>> the most natural way.
>>
>> In general, having more choices is good, as long as it doesn't make the
>> language too complex such that it hinders usability.
>>
>>
>>> In context of this thread:
>>>
>>> Python technically does support all 3 paradigms above - but it does so
>>> SLOWLY, and it does not support declarative Prolog-style logic
>>> programming.  Paraphrasing Ivan Godard: sometimes you really need
>>> Prolog.
>>
>>
>> Yes, but again, the "typical" scientist/engineer doesn't care about things
>> like programming paradigms.  He/she just wants to get their main job done.
>>
>> And for most, given the usage pattern, speed is a minor consideration. I am
>> concerned about what others have reported about compatibility among Python
>> versions, other than the 2-3 transition.  If they are really frequently making
>> lots of incompatible changes, that it a problem, not just for
>> reproduceability, but for usability over time.
>>
>>
>>
>>> C++ suffers also in not REALLY supporting declarative.  Yes ... it is
>>> /possible/ using templates, but it is anything but easy.  Creating a
>>> logic programming language using C++ templates is an exercise in
>>> banging your head against a wall ... far harder than the equivalent
>>> macro programming in Lisp or Scheme. [Never mind what can be done in
>>> Racket with its deliberate DSL mix-in support.]
>>>
>>> Racket offers all 4 paradigms: OO, procedural, functional, AND
>>> declarative/logic through existing DSLs.
>>
>> I have mixed feelings about DSLs.  Of course, they are well tailored for
>> solving the problem at hand (that is, the problems they were designed to
>> address), but it is another language to learn and will typically have less
>> general applicability thus less usage and support.
>
> I want a DSL whose domain is creating DSLs. I find that C++ does so adequately
> and has other advantages.

I prefer DSLs, where L==Library. That minimises the learning
curve and maximises the use of existing development tools,
and enables you to hire staff to work on your product.
(Very few want to learn a skill that is worthless elsewhere.)

Over the years (at best), most DSLanguages become cancerous
to the point where even the designer doesn't understand all
the interactions. Not that that is limited to DSLanguages,
of course :(

On 7/16/2021 5:33 AM, Tom Gardner wrote:
> On 15/07/21 22:50, Ivan Godard wrote:
>> On 7/15/2021 10:16 AM, Stephen Fuld wrote:
>>> On 7/15/2021 8:46 AM, George Neuner wrote:
>>>> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
>>>> <ivan@millcomputing.com> wrote:
>>>>
>>>>> On 7/13/2021 9:40 AM, BGB wrote:
>>>>>
>>>>>> One could, in theory, have a language which uses a more familiar
>>>>>> syntax
>>>>>> natively, but then switches over to a Lisp style syntax for
>>>>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>>>>
>>>>> Here's one vote for SmallTalk.
>>>>
>>>> I have a fondness for SmallTalk, but ...
>>>>
>>>> The problem with single paradigm languages - regardless of what
>>>> paradigm they offer - is having to shoehornevery solutions into it.
>>>>
>>>> Now, it's true that most (nominally) OO languages really are dual
>>>> OO/procedural ... and it's also true that that combination covers a
>>>> lot of problem space.  But still sometimes it forces the programmer
>>>> into "unnatural" approaches.
>>>>
>>>> I prefer languages that fully support (at least) OO, procedural, and
>>>> functional styles ... they give the most latitude to solve problems in
>>>> the most natural way.
>>>
>>> In general, having more choices is good, as long as it doesn't make
>>> the language too complex such that it hinders usability.
>>>
>>>
>>>> In context of this thread:
>>>>
>>>> Python technically does support all 3 paradigms above - but it does so
>>>> SLOWLY, and it does not support declarative Prolog-style logic
>>>> programming.  Paraphrasing Ivan Godard: sometimes you really need
>>>> Prolog.
>>>
>>>
>>> Yes, but again, the "typical" scientist/engineer doesn't care about
>>> things like programming paradigms.  He/she just wants to get their
>>> main job done.
>>>
>>> And for most, given the usage pattern, speed is a minor
>>> consideration. I am concerned about what others have reported about
>>> compatibility among Python versions, other than the 2-3 transition.
>>> If they are really frequently making lots of incompatible changes,
>>> that it a problem, not just for reproduceability, but for usability
>>> over time.
>>>
>>>
>>>
>>>> C++ suffers also in not REALLY supporting declarative.  Yes ... it is
>>>> /possible/ using templates, but it is anything but easy.  Creating a
>>>> logic programming language using C++ templates is an exercise in
>>>> banging your head against a wall ... far harder than the equivalent
>>>> macro programming in Lisp or Scheme. [Never mind what can be done in
>>>> Racket with its deliberate DSL mix-in support.]
>>>>
>>>> Racket offers all 4 paradigms: OO, procedural, functional, AND
>>>> declarative/logic through existing DSLs.
>>>
>>> I have mixed feelings about DSLs.  Of course, they are well tailored
>>> for solving the problem at hand (that is, the problems they were
>>> designed to address), but it is another language to learn and will
>>> typically have less general applicability thus less usage and support.
>>
>> I want a DSL whose domain is creating DSLs. I find that C++ does so
>> adequately and has other advantages.
>
> I prefer DSLs, where L==Library. That minimises the learning
> curve and maximises the use of existing development tools,
> and enables you to hire staff to work on your product.
> (Very few want to learn a skill that is worthless elsewhere.)
>
> Over the years (at best), most DSLanguages become cancerous
> to the point where even the designer doesn't understand all
> the interactions. Not that that is limited to DSLanguages,
> of course :(

Quick quiz - what language is this fragment?

Section( .text ) defFunc("find", external);
F("find") %0;
add(b0 %0, 1) %25 ^112,
rsub(b0 %0, 7) %22 ^109;

spill(s[1], b2 %21) ^108,
scratchf(s[3]) ^65, // entry
rd(w(0)) %1 ^66,
leau(dp, gl("fordiag"), b3 %0) %21 ^108,
leau(dp, gl("bakdiag"), b1 %22) %23 ^110,
eqlb(b3 %0, 8) %2 ^67,
rescue(b0 %2, b1 %23, b3 %1, b5 %25, b6 %0) %59/2 %60/23 %61/1
%62/25 %63/0 ^0;

spill(s[7], b1 %62/25) ^112,
spill(s[2], b3 %60/23) ^110,
innertrs(b4 %59/2, "find$1_2", b2 %61/1) ^68;

> Quick quiz - what language is this fragment?

At which level?

At one level it's ASCII, at another it's Mill assembly, and in between
it's C++, right?
(and there's also a CPP level along the way, tho I don't know if you
take advantage of it).

Stefan

On 7/16/2021 7:13 AM, Stefan Monnier wrote:
>> Quick quiz - what language is this fragment?
>
> At which level?
>
> At one level it's ASCII, at another it's Mill assembly, and in between
> it's C++, right?
> (and there's also a CPP level along the way, tho I don't know if you
> take advantage of it).
>
>
> Stefan
>

Yes. It's the ability to create that top level that permits C++ to be
used as a DSL-creating DSL. I find that useful because it means that I
don't have to create that level as a whole new language.

The fragment doesn't show it, but as a created and embedded DSL you can
use any construct of the C++ top level such as looping or CPP.

About CPP: the MillCo programming standard disparages all use of CPP
except "#include". I can count all other CPP uses in our code corpus on
one hand. Really the only places where there is no better way than CPP
is when something must expand to declarations whose scope is beyond that
of the construct itself.

On 7/15/2021 2:50 PM, Ivan Godard wrote:
> On 7/15/2021 10:16 AM, Stephen Fuld wrote:
>> On 7/15/2021 8:46 AM, George Neuner wrote:
>>> On Tue, 13 Jul 2021 17:42:00 -0700, Ivan Godard
>>> <ivan@millcomputing.com> wrote:
>>>
>>>> On 7/13/2021 9:40 AM, BGB wrote:
>>>>
>>>>> One could, in theory, have a language which uses a more familiar
>>>>> syntax
>>>>> natively, but then switches over to a Lisp style syntax for
>>>>> metaprogramming and eval, but this would be kinda wonky and weird.
>>>>
>>>> Here's one vote for SmallTalk.
>>>
>>> I have a fondness for SmallTalk, but ...
>>>
>>> The problem with single paradigm languages - regardless of what
>>> paradigm they offer - is having to shoehornevery solutions into it.
>>>
>>> Now, it's true that most (nominally) OO languages really are dual
>>> OO/procedural ... and it's also true that that combination covers a
>>> lot of problem space.  But still sometimes it forces the programmer
>>> into "unnatural" approaches.
>>>
>>> I prefer languages that fully support (at least) OO, procedural, and
>>> functional styles ... they give the most latitude to solve problems in
>>> the most natural way.
>>
>> In general, having more choices is good, as long as it doesn't make
>> the language too complex such that it hinders usability.
>>
>>
>>> In context of this thread:
>>>
>>> Python technically does support all 3 paradigms above - but it does so
>>> SLOWLY, and it does not support declarative Prolog-style logic
>>> programming.  Paraphrasing Ivan Godard: sometimes you really need
>>> Prolog.
>>
>>
>> Yes, but again, the "typical" scientist/engineer doesn't care about
>> things like programming paradigms.  He/she just wants to get their
>> main job done.
>>
>> And for most, given the usage pattern, speed is a minor consideration.
>> I am concerned about what others have reported about compatibility
>> among Python versions, other than the 2-3 transition.  If they are
>> really frequently making lots of incompatible changes, that it a
>> problem, not just for reproduceability, but for usability over time.
>>
>>
>>
>>> C++ suffers also in not REALLY supporting declarative.  Yes ... it is
>>> /possible/ using templates, but it is anything but easy.  Creating a
>>> logic programming language using C++ templates is an exercise in
>>> banging your head against a wall ... far harder than the equivalent
>>> macro programming in Lisp or Scheme. [Never mind what can be done in
>>> Racket with its deliberate DSL mix-in support.]
>>>
>>> Racket offers all 4 paradigms: OO, procedural, functional, AND
>>> declarative/logic through existing DSLs.
>>
>> I have mixed feelings about DSLs.  Of course, they are well tailored
>> for solving the problem at hand (that is, the problems they were
>> designed to address), but it is another language to learn and will
>> typically have less general applicability thus less usage and support.
>
> I want a DSL whose domain is creating DSLs.

Then you might like Racket, as it seems that was one of the key design
goals. See the second sentence of

https://en.wikipedia.org/wiki/Racket_(programming_language)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/16/2021 6:21 AM, Tim Rentsch wrote:
> BGB <cr88192@gmail.com> writes:
>
> [...]
>
>> I think it is telling that an ugly hack-job (Objective-C) is used
>> significantly more often than SmallTalk.
>
> Objective-C is a programming language in the conventional sense
> of the term.
>

Makes sense.

> Smalltalk is both a programming language and a surrounding
> development environment. The two are tightly intertwined,
> which is a double-edged sword.
>
> After years of being part of the Smalltalk community, I
> have the impression that having to work on Smalltalk
> programs inside the Smalltalk environment is a large
> part of why Smalltalk never caught on as a "serious"
> programming language. Its model was just too different.
>

OK.

I once tried messing with Squeak, but at the time was kinda bewildered
by it. I guess this is possibly a bit of a drawback if this is the
sentiment everyone else has as well.

My first Scheme VM did also try to do the "live image" thing as well,
with a ZUI and everything as well...

I had basically mostly abandoned this, as it didn't take long to realize
there were some serious problems with this approach; that it is
generally better to reload code from files; and that the ability to do a
full restart of a program is, actually, "pretty useful".

In other news, did go and more-or-less implement the funky "doing funky
PHP style stuff as an extension to the C preprocessor" thing, mostly
leveraging that my compiler's frontend actually already had most of the
parts needed to throw together a makeshift script interpreter.

It uses AST walking, which is sort of a horribly inefficient approach,
and in some cases may result in funky semantics, but for its purpose I
don't really expect it to need much in terms of performance...

It reuses the compilers' main parser (also handles C and BS2), and
reuses some of the frontend's constant-folding / constant-propagation
logic for evaluating expressions, ...

Given the way it is implemented, it doesn't yet support mutable objects
or arrays, ..., but alas.

Albeit I decided to go with a more JS style syntax, and using "printf"
for formatting, though its behavior isn't particularly faithful to the C
printf (doesn't support formatting; doesn't really care about types).

The "printf" function in this case feeds its output back into the C
preprocessor, though I am uncertain, and may rename it ("printf" implies
it should send its output to the console).

Had doubts about calling it "echo", given in PHP this is a special
statement with its own syntax.

....

Though, in theory, not sure how difficult it would be for other C-style
compilers to do something similar. Some people had argued for "just
invoke PHP or an external Python script and feed the result back into
the compiler".

But, like, I didn't want to add a dependency on an external tool when
the compiler already contains most of the parts I would need to do this...

> I had basically mostly abandoned this, as it didn't take long to realize
> there were some serious problems with this approach; that it is generally
> better to reload code from files; and that the ability to do a full restart
> of a program is, actually, "pretty useful".

Yeah, I think the 3-way merge of "virtual machine" is a bit problematic ;-)

FWIW, you can do Smalltalk without having to follow the VM/system way:
the GNU Smalltalk implementation provides a "standard" programming
language rather than a VM.

Personally, I find Smalltalk to be a surprisingly complex language
compared to the image it tries to project of a "pure OO language where
everything is a message".

Stefan

On Thu, 15 Jul 2021 10:16:49 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>Yes, but again, the "typical" scientist/engineer doesn't care about
>things like programming paradigms. He/she just wants to get their main
>job done.

The language that offers the most flexibility in programming style is
the one that "gets the job done" most quickly and effectively.

On Friday, July 16, 2021 at 5:06:35 PM UTC-5, George Neuner wrote:
> On Thu, 15 Jul 2021 10:16:49 -0700, Stephen Fuld
> <sf...@alumni.cmu.edu.invalid> wrote:
>
>
> >Yes, but again, the "typical" scientist/engineer doesn't care about
> >things like programming paradigms. He/she just wants to get their main
> >job done.
<
> The language that offers the most flexibility in programming style is
> the one that "gets the job done" most quickly and effectively.
<
I am not sure of that at all. And certainly this does not hold in spoken
languages (although I have told people exactly what to write in FORTRAN
programs over the phone.....) Those languages that have the largest vocab-
ularies are seldom used to emit sentences of high information content and
ease of understanding.
<
One of the most flexible languages is APL--but its complexity is so
large few people ever get their heads around it well enough to use
it effectively.
<
For string handling, Snowball is arguably supereme,...........yet almost
no one uses it.

On Fri, 16 Jul 2021 15:16:56 -0700 (PDT), MitchAlsup
<MitchAlsup@aol.com> wrote:

>On Friday, July 16, 2021 at 5:06:35 PM UTC-5, George Neuner wrote:
>> On Thu, 15 Jul 2021 10:16:49 -0700, Stephen Fuld
>> <sf...@alumni.cmu.edu.invalid> wrote:
>>
>> >Yes, but again, the "typical" scientist/engineer doesn't care about
>> >things like programming paradigms. He/she just wants to get their main
>> >job done.
><
>> The language that offers the most flexibility in programming style is
>> the one that "gets the job done" most quickly and effectively.
><
>I am not sure of that at all. And certainly this does not hold in spoken
>languages (although I have told people exactly what to write in FORTRAN
>programs over the phone.....) Those languages that have the largest vocab-
>ularies are seldom used to emit sentences of high information content and
>ease of understanding.
><
>One of the most flexible languages is APL--but its complexity is so
>large few people ever get their heads around it well enough to use
>it effectively.
><
>For string handling, Snowball is arguably supereme,...........yet almost
>no one uses it.

All true.

However Racket is a small language based on Scheme. While the
/library/ is enormous, the syntax and semantics are simple enough to
be learned in a weekend.

George

On 7/18/2021 12:28 AM, George Neuner wrote:
> On Fri, 16 Jul 2021 15:16:56 -0700 (PDT), MitchAlsup
> <MitchAlsup@aol.com> wrote:
>
>> On Friday, July 16, 2021 at 5:06:35 PM UTC-5, George Neuner wrote:
>>> On Thu, 15 Jul 2021 10:16:49 -0700, Stephen Fuld
>>> <sf...@alumni.cmu.edu.invalid> wrote:
>>>
>>>> Yes, but again, the "typical" scientist/engineer doesn't care about
>>>> things like programming paradigms. He/she just wants to get their main
>>>> job done.
>> <
>>> The language that offers the most flexibility in programming style is
>>> the one that "gets the job done" most quickly and effectively.
>> <
>> I am not sure of that at all. And certainly this does not hold in spoken
>> languages (although I have told people exactly what to write in FORTRAN
>> programs over the phone.....) Those languages that have the largest vocab-
>> ularies are seldom used to emit sentences of high information content and
>> ease of understanding.
>> <
>> One of the most flexible languages is APL--but its complexity is so
>> large few people ever get their heads around it well enough to use
>> it effectively.
>> <
>> For string handling, Snowball is arguably supereme,...........yet almost
>> no one uses it.
>
> All true.
>
> However Racket is a small language based on Scheme. While the
> /library/ is enormous, the syntax and semantics are simple enough to
> be learned in a weekend.
>

Yeah, Scheme is also a nice language for people first learning about
writing a compiler or interpreter:
Its parser can be fairly simple;
It works reasonably well for an AST-walking interpreter design;
...

And, also, it is a lot more usable for writing code than Forth or
PostScript.

Drawbacks tend to be:
S-Expression syntax is kinda awkward;
Working with loops is more awkward than it is with C family languages;
...

Editing code in S-Expression form effectively depends somewhat on editor
features like highlighting parentheses, otherwise keeping track of them
becomes an issue. This hinders its usability with simpler text editors
(Notepad, Nano, ...).

The advantages of its simplicity are lost with the sort of more
complicated VMs one needs to get better performance.

IME, for "fast" interpreters, there tends to be a fairly strong bias for
running on statically-typed 3-address instructions on the backend,
though for bytecode formats, it is more typical to use a stack-machine
model, which requires an intermediate conversion step to get into 3AC.

A similar pattern seems to hold for CPU ISAs as well, though CPU ISAs
tend to use a fixed number of hardware registers (and explicit
save/restore); whereas for interpreters it makes more sense to have a
much bigger register space (effectively unbounded, or at least 256 or
so), with call stack-frames as the basic unit of abstraction.

Making dynamically typed code fast is harder, as short of effectively
implementing the dynamic type-system in hardware, one is mostly limited
to operations which can maybe assist with tag-checking and setting.

Though, I have yet to implement a general set of tag-check/set ops, and
some of this is at present being done using ops I had originally
intended more for 3D rendering tasks and similar (being not sure if
dynamic types are likely to be used enough to justify much in terms of
dedicated ISA extensions).

Then, there is also possible controversy over adding tag check/set
instructions, but then have the ISA essentially mandate a particular
dynamic type-tagging scheme (say, for example, if I optimized for my use
of MSB tagging, but then other people wanted to use LSB tagging or NaN
boxing or similar).

Nevermind the wackiness of me doing binary type dispatch using
repurposed Morton-shuffle ops and similar.

Though, I suspect the overhead may be low enough already that
special-purpose support in hardware may not be needed.

....