Re: Recursion, Yo

On 13/04/2024 19:17, Janis Papanagnou wrote:

On 12.04.2024 16:51, David Brown wrote:

On 12/04/2024 15:03, Janis Papanagnou wrote:

>
Another one is that you can write (e.g. in Algol 68 or many other
higher level languages) the equivalent of - again a simple example -
>
    int x = 2 * pi * r
>
without necessity to know whether pi is a constant, the result of a
function (calculation), the result of a function implicitly called
just once on demand, or whatever else. Conceptually as a programming
language user you want the value.
>

>
But is that a good thing?

 In my book it is a good thing (but I wouldn't overestimate it)...
 

For some programming, especially with
higher-level languages, then it is fine.  For other types of
programming, you want to know if functions are called in order to have a
better idea of the flow of control and the efficiency of the code, plus
perhaps thread safety.

 ...because the (in practice valid!) topics you mention _should_ not
be of concern to the programmer. The "idea of the flow" should, IMO,
certainly not depend on parenthesis. I'll try an example from a C++
context... - Say, I want to get the "length" of a container. What I
indeed care about is the complexity of that operation, but that
should be part of the library specification. C++/STL provides me
with O(1), O(N), O(x) information that I can count on. Though the
procedure to determine some length() might depend on the type of
the container; it may be just an attribute access, it might be a
difference computation (last-first+1), or it might be an iteration.
Despite that could be hidden in a function length() you need the
O(x) information to be sure about efficiency. (Or to look into the
function's source code of the function, if available, to analyze
the algorithm.)
 

For most C++ programming, if you read code :
int len = xs.length;
you'll assume that is O(1).  But if you read :
int len = xs.length();
you won't make that assumption.  If you need to know the complexity, you'll check exactly what type of container "xs" is, and look up the complexity guarantees.  (And while I showed a way to make calls in C++ without parentheses, I am not suggesting it's a good idea to invalidate the assumptions readers will typically make about code.)
Again, this stuff is often not important, or at least not critical - but sometimes it is.

What I'm basically trying to say is that length() doesn't provide
the certainty or information that one needs or likes to have. All
it provides is a syntactical, technical detail of the language.
With it you get the uncertainty of "Uh-oh, there's parentheses;
now does it mean that it's expensive to use it?" - But you don't
get relevant information from the parentheses!
 

Agreed.  But it will often lead to assumptions.
However, those assumptions are based on the language.  People who are used to Pascal or Ada would have other assumptions (or lack of assumptions) when reading Pascal or Ada.

For the [general, non-C] programmer it's (IMO) clearer to not put
(unnecessary) syntactical burden on him. He wants a value 'len'?
He just gets the value 'len' (and not len())!
 I think I've already said that it's to a large degree probably
personal experience and preferences whether one comes to the
conclusion that it's a good thing, a bad thing, or even "mostly
harmless" (meaningless).
 (These are the thoughts from someone who did not start his CS life
with C-like languages. From someone who has seen a lot of languages
with good concepts that needed decades to only slowly - if at all -
find their way into the modern, mainstream, or hyped languages. I
thought that evolution in programming languages would benefit from
good concepts. But "Not Invented Here" principle seems to dominate.
<end-of-rant>)

I started with BASIC (a half dozen varieties), then assembly and machine code on multiple systems, brief flirtations with Logo, Forth, and even Prolog and APL (/very/ briefly for these), then Pascal, then university with Orwell (very similar to Haskell), Modula 2, C, Occam, then real life with Pascal, assembly (many types), C, C++, Python, some hardware design languages, and bits and pieces of a number of other languages for fun or profit.  It's nice to have a variety of experiences, even if the great majority of work is in only a few of these languages.

 

>
Just for fun, this is a way to let you define a function-like object
"pi" in C++ that is called automatically, without parentheses :
[...]
I am not giving an opinion as to whether or not this is a good idea (and
obviously it is completely redundant in the case of a compile-time
constant).  Some people might think C++ is great because it lets you use
tricks like this, some people might think C++ is terrible because it
lets you use tricks like this :-)

 (Nice example.) - Well, to me C++ is (or was) great because it
supported what I've learned to love from using Simula; classes
and inheritance, the whole OO paradigm, "living objects" and a
lot more that's still "undiscovered" by other languages. What I
found terrible was that it inherited the whole uncertainty from
using a low level language like C.
 

A lot of C++'s poorer parts are due to compatibility with C. Compatibility with C is of course useful in many ways too, but it has always been a millstone around C++'s neck.