Some comments in this group have recently been espousing functional
programming. I was going to comment in replies but it seems better to
start a new thread.

My suggestion is that the functional style of programming can be useful
if it is applied in a limited way within an imperative language but it
does not necessarily offer the purity that its proponents suggest.

Over-recommendation of the functional paradigm tends to annoy me because
AISI there are different levels of functional purity.

0. The really pure would accomplish absolutely nothing because it could
not update files and could not write output.

1. Allow slight impurities and you could generate output, which might be
handy. Then there are successive levels of increasing impurity:

2. Allow external storage (i.e. state) to be updated.

3. Allow functions to update internal state as long as that cannot
possibly (i.e. the compiler can check) ever affect what they return.

4. Allow functions to update internal state if you are fairly sure (i.e.
the compiler cannot be sure) it will never affect what they return.

5. Allow functions to modify external state as long as they are are
guaranteed always to return consistently, although something else may
respond differently due to the change in external state.

6. Allow function to modify external state if you are fairly sure that
will never affect what they return, etc.

And suchlike.

A good example of case 4 that someone may wrongly think is a case 3 is a
supposedly pure function to which someone adds an internal count of the
number of times it has been called. It may work billions of times
successfully but then throw an overflow exception as its counter is updated.

So functional programming is not a panacea. At the end of the day,
computers have to update state. That's how they work and that's why
programs are run.

IMO the ideal position is a balance in a program between functions which
are genuinely pure (and thus easier to reason about) and functions which
are not. But the paradigm of a language in which that balance can take
place has to be imperative. Imperative languages are the best! :-)

Rant over!

--
James Harris

James Harris <james.harris.1@gmail.com> writes:
>0. The really pure would accomplish absolutely nothing because it could
>not update files and could not write output.

Yes, there must be at least a kind of REPL that prints the
value of the functional program, which would be an update.

>2. Allow external storage (i.e. state) to be updated.

Possibly there is some technique by which this can be emulated
in a functional program as with the I/O monad in Haskell.
The problem with this approach: I don't understand it!

Web:

|The I/O system in Haskell is purely functional, yet has all
|of the expressive power found in conventional programming
|languages.
Web.

On 2022-11-15 13:13, James Harris wrote:
> Some comments in this group have recently been espousing functional
> programming. I was going to comment in replies but it seems better to
> start a new thread.
>
> My suggestion is that the functional style of programming can be useful
> if it is applied in a limited way within an imperative language but it
> does not necessarily offer the purity that its proponents suggest.
>
> Over-recommendation of the functional paradigm tends to annoy me because
> AISI there are different levels of functional purity.
>
> 0. The really pure would accomplish absolutely nothing because it could
> not update files and could not write output.
>
> 1. Allow slight impurities and you could generate output, which might be
> handy. Then there are successive levels of increasing impurity:
>
> 2. Allow external storage (i.e. state) to be updated.
>
> 3. Allow functions to update internal state as long as that cannot
> possibly (i.e. the compiler can check) ever affect what they return.
>
> 4. Allow functions to update internal state if you are fairly sure (i.e.
> the compiler cannot be sure) it will never affect what they return.
>
> 5. Allow functions to modify external state as long as they are are
> guaranteed always to return consistently, although something else may
> respond differently due to the change in external state.
>
> 6. Allow function to modify external state if you are fairly sure that
> will never affect what they return, etc.
>
> And suchlike.

It is more complex than you describe. Purity is a halting problem. So
there are cases that cannot be proved. E.g.

if HALT (p) then
External := 0;
end if;

A pragmatic solution is a provable contract that is stronger than the
actual behavior. E.g. even if an impure code is not reachable the
function considered impure.

Then you have a problem with the prover's strength. If different
implementations of the compiler have different provers then the same
program might turn legal or illegal depending on the strength. Thus you
have to put the strength in the language definition, which is not simple.

Then there is conditional purity as you describe in in #4 but also the
effects on the arguments, the effects caused by the subprograms and
closures passed as arguments, the effects of recursive calls etc. You
have to sort that out. A conditionally [im]pure function might be OK in
some contexts and not in others.

> A good example of case 4 that someone may wrongly think is a case 3 is a
> supposedly pure function to which someone adds an internal count of the
> number of times it has been called. It may work billions of times
> successfully but then throw an overflow exception as its counter is
> updated.
>
> So functional programming is not a panacea. At the end of the day,
> computers have to update state. That's how they work and that's why
> programs are run.

Side effects are avoided because of the functional programming paradigm.
The paradigm itself is not about states. It is about lambdas and recursion.

> IMO the ideal position is a balance in a program between functions which
> are genuinely pure (and thus easier to reason about) and functions which
> are not. But the paradigm of a language in which that balance can take
> place has to be imperative. Imperative languages are the best! :-)

Yes, imperative paradigm is in general simpler that a declarative one.
Functional paradigm falls under declarative.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 15/11/2022 12:13, James Harris wrote:
> Some comments in this group have recently been espousing functional
> programming. I was going to comment in replies but it seems better to
> start a new thread.
>
> My suggestion is that the functional style of programming can be useful
> if it is applied in a limited way within an imperative language but it
> does not necessarily offer the purity that its proponents suggest.
>
> Over-recommendation of the functional paradigm tends to annoy me because
> AISI there are different levels of functional purity.
>
> 0. The really pure would accomplish absolutely nothing because it could
> not update files and could not write output.
>
> 1. Allow slight impurities and you could generate output, which might be
> handy. Then there are successive levels of increasing impurity:
>
> 2. Allow external storage (i.e. state) to be updated.
>
> 3. Allow functions to update internal state as long as that cannot
> possibly (i.e. the compiler can check) ever affect what they return.
>
> 4. Allow functions to update internal state if you are fairly sure (i.e.
> the compiler cannot be sure) it will never affect what they return.
>
> 5. Allow functions to modify external state as long as they are are
> guaranteed always to return consistently, although something else may
> respond differently due to the change in external state.
>
> 6. Allow function to modify external state if you are fairly sure that
> will never affect what they return, etc.
>
> And suchlike.
>
> A good example of case 4 that someone may wrongly think is a case 3 is a
> supposedly pure function to which someone adds an internal count of the
> number of times it has been called. It may work billions of times
> successfully but then throw an overflow exception as its counter is
> updated.
>
> So functional programming is not a panacea. At the end of the day,
> computers have to update state. That's how they work and that's why
> programs are run.
>
> IMO the ideal position is a balance in a program between functions which
> are genuinely pure (and thus easier to reason about) and functions which
> are not. But the paradigm of a language in which that balance can take
> place has to be imperative. Imperative languages are the best! :-)

I lay into functional languages a bit in my recent post (some 20 minutes
ago).

I really don't care for them, but will not argue for people to stop
using them; they can do what they like.

Personally I'd find them totally unsuitable for the software I write.
How do you change even one pixel in a image buffer, which supposedly is
immutable. You are supposed to generate a new image with that one
difference. But it's all a pretence really since doing it by the book
would be hopelessly inefficient.

I open to some functional features within small areas, like inside an
arithmetical expression. Then most languages are functional to some degree!

But not when they take over the whole language and do away with
everything that makes coding convenient and intuitive.

On 15/11/2022 13:13, James Harris wrote:
> Some comments in this group have recently been espousing functional
> programming. I was going to comment in replies but it seems better to
> start a new thread.
>

I am sorry you have misunderstood so much of what I have written.

I have espoused taking advantage of certain techniques and features that
are common in functional programming languages. I have not suggested
you develop a functional programming language. That would have been an
absurd suggestion for someone who has no experience in such languages
from before, and is not interested in making one.

Different types of language are useful for different purposes. But it
would be foolish and a waste of time to start making a new language
knowing only one or a few similar languages, and making yet another in
the same genre. Learn from other kinds of language - take inspiration
and ideas. Ask what makes other languages /better/ in certain ways, and
whether that can make /your/ language better - or if such features would
cost too much.

You should be familiarising yourself with a range of different existing
languages. Learn what is new and interesting about them, or what makes
them special. What features do users like in practice, and what do they
dislike? What can fit with the goals of your own language (which I
admit I really do not understand as yet)? Look at things that are
common in other newer languages, and ask /why/ these features are
common. Are these things that you should have in your own language?
You don't know if you are not aware of them, or have not considered them
properly, or have rejected them out of hand as unfamiliar, too
difficult, or contrary to decisions you made before you heard of them.

> My suggestion is that the functional style of programming can be useful
> if it is applied in a limited way within an imperative language but it
> does not necessarily offer the purity that its proponents suggest.

My suggestion is that you don't know nearly enough about functional
programming to give a sound judgement on the matter. If you think that
is unfair, tell us what experience you have with writing code in
functional programming languages (or at least in using functional
programming features in languages that support the paradigm). Opinions
are all well and good (and I fully respect your right to make a language
that fits with your own opinions and preferences!) but /qualified/
opinions are a lot more useful.

>
> Over-recommendation of the functional paradigm tends to annoy me because
> AISI there are different levels of functional purity.

There are indeed - as I have said repeatedly. And nobody has suggested
you should be considering pure functional programming.

>
> 0. The really pure would accomplish absolutely nothing because it could
> not update files and could not write output.
>
> 1. Allow slight impurities and you could generate output, which might be
> handy. Then there are successive levels of increasing impurity:
>
> 2. Allow external storage (i.e. state) to be updated.
>
> 3. Allow functions to update internal state as long as that cannot
> possibly (i.e. the compiler can check) ever affect what they return.
>
> 4. Allow functions to update internal state if you are fairly sure (i.e.
> the compiler cannot be sure) it will never affect what they return.
>
> 5. Allow functions to modify external state as long as they are are
> guaranteed always to return consistently, although something else may
> respond differently due to the change in external state.
>
> 6. Allow function to modify external state if you are fairly sure that
> will never affect what they return, etc.
>
> And suchlike.

Your categories don't match anything I have ever seen. No one
classifies anything with "fairly sure" as a criterion.

"Pure" functional programming languages such as Haskell and Mercury
allow IO, external storage, networking, etc. (As I mentioned, Facebook
uses Haskell for content analysis on posts - that's pretty IO intensive.
There is a perfectly good working X Window manager written in Haskell.)

But the way they do so, using "linear types" or "monads" is undoubtedly
very unfamiliar to people coming from the world of imperative
programming. In its absolute purest form, a "print" procedure would
take the world before the output as an input, and return the world after
the output - nothing is changed. (Real, practical pure functional
programming languages handle things a little differently.)

"Impure" functional programming languages such as OCaml, Erlang/Elixir
and Lisp are predominantly functional, but also support imperative
styles for occasions when that is a better choice - perhaps for
lower-level work, interfacing with other languages, or just where it is
clearer.

Then there are imperative (or other paradigm) languages that support
functional programming techniques to a greater or lesser extent,
including Python, C++, and Javascript.

And there are imperative languages with no functional support at all
(function pointers don't count). And of course there are vast numbers
of other programming paradigms, not just imperative and functional.

Most of my own coding on small microcontrollers is purely imperative,
with a bit of functional style in my C++. In PC programming, I again
use primarily imperative but much more functional code (such as in
Python). That's what best suits the tasks I do these days - mix and
match, take the best of all that is available. It's a long time since I
did much pure functional programming, but I have done so sometimes. And
I have also used functional programming when I have done programmable
hardware design - it is /so/ much better suited to that than the
traditional Verilog and VHDL hardware description languages.

>
> A good example of case 4 that someone may wrongly think is a case 3 is a
> supposedly pure function to which someone adds an internal count of the
> number of times it has been called. It may work billions of times
> successfully but then throw an overflow exception as its counter is
> updated.

That would not be a pure function. Compilers can check if functions are
pure or not.

>
> So functional programming is not a panacea.

Of course not. Different types of languages are good for different
purposes.

> At the end of the day,
> computers have to update state. That's how they work and that's why
> programs are run.

No, that's just how /you/ are used to thinking about them.

How they operate internally need bear no resemblance to how they appear
or the logical program they execute.

The solid majority of programmers - you included - are used to
micro-managing your code to a large degree. It is not actually
necessary to tell computers what to do all the time - tools can handle
that, and leave your time and energy to concentrate on the interesting
stuff.

People figured out long ago that for most programming, you don't need to
manage memory resources manually. You can use garbage collection, or
RAII rather than using malloc/free and keeping track of everything.
They figured out that you don't need to track overflows and multiple
parts of large numbers - you can make languages with unlimited range
integers. Programming is about abstraction and layers.

Now, sometimes you /do/ want to go to these low layers and deal with the
bits and bytes. But often you don't, and you can work at a higher level.

Note that higher level does not necessarily mean slower. While C, Rust
and C++ are typically considered the fastest languages, OCaml is
regularly very close in benchmarks. And working at a higher level gives
compilers more information, letting them do more optimisation. Instead
of messing about with pointers and increment operators, code written in
clearer array syntax with loops gives the compiler more chance to use
SIMD vectorisation. When the compiler knows functions are pure, it can
re-arrange and optimise better. When it knows there are no pointers, it
can analyse data flow and access patterns better. When it knows there
are no side-effects, it can split code up into multiple threads. These
are all real speed benefits from real programming languages and tools.

And while you are messing about with pointers and trying to make sure
you don't leak memory in your implementation of a linked list, a Haskell
programmer could make a Fibonacci heap priority queue in fewer lines -
and know that it is correct.

Different languages have their pros and cons, as do different
programming paradigms. But it is foolish to dismiss things as bad
simply because you are unfamiliar with them or don't understand them.
It's fine to say you don't have the time or interest to learn about them
- but not to condemn them without apparently understanding the first
thing about them.

Do you actually know the "first" thing about functional programming
languages? The clue is in the name - "functions". Given what you have
written above, I believe you are completely unaware of the fact that the
defining feature of a functional programming language is that functions
are first-class objects - they can be manipulated, combined, modified
and passed around just like objects. It is not the feature that has
been most relevant to discussions so far, but maybe that will come too!

On 15/11/2022 12:13, James Harris wrote:
> Some comments in this group have recently been espousing functional
> programming. I was going to comment in replies but it seems better to
> start a new thread.

This Reddit thread summarises some new languages:

https://www.reddit.com/r/ProgrammingLanguages/comments/yvuvuv/lets_collect_relatively_new_research_programming/

Look especially at the post by 'gasche' (or sort by Best, it might be at
the top).

Those languages are not so much functional; that can be assumed for most
of these. Look instead at their features, if you can even understand
what they mean.

There are some really advanced languages being produced now; there's no
shortage of them! I guess some are research projects so they need to be
seen to be doing something different.

This is the sort of thing that made me decide to stick with my own
stuff. Of priority there is a language I can understand, and that is
simple and conservative enough that it would look like pseudocode to
anyone else, and could be easily ported.

And, of course, that can used to write actual, practical programs (40
years experience of that shows they can be).

Where my languages are weak is in being so insular; working with other
software is always a big obstacle (I can forget about running on Android
for example, as you need to get through about 27 layers of software and
bureaucracy first, plus I think you need to write in Java anyway).

Here, functional features would be no help at all.

On 15/11/2022 18:18, Bart wrote:
> On 15/11/2022 12:13, James Harris wrote:

....

> Where my languages are weak is in being so insular; working with other
> software is always a big obstacle (I can forget about running on Android
> for example, as you need to get through about 27 layers of software and
> bureaucracy first, plus I think you need to write in Java anyway).

If you are concerned that your languages are too insular why not compile
for JVM or for Web Assembly?

--
James Harris

On 15/11/2022 21:32, James Harris wrote:
> On 15/11/2022 18:18, Bart wrote:
>> On 15/11/2022 12:13, James Harris wrote:
>
> ...
>
>> Where my languages are weak is in being so insular; working with other
>> software is always a big obstacle (I can forget about running on
>> Android for example, as you need to get through about 27 layers of
>> software and bureaucracy first, plus I think you need to write in Java
>> anyway).
>
> If you are concerned that your languages are too insular why not compile
> for JVM or for Web Assembly?

I'd find JVM very restrictive (how would I map inline assembler for
example into JVM?). And WASM I found was poorly documented at the level
I wanted to use it (I'm not into web stuff anyway.)

But what usually happens here, is whatever I need to download for JVM
etc dwarfs my own product in size and complexity. Also I don't know how
either of those would help me in using GTK for example, where the
obstacle would be in writing bindings for its 10,000 functions within my
syntax.

What I can do right now is target C code when I need to. Because I know
that there, a complete C backend can be provided in the form of Tiny C,
totalling 0.22MB.

This helps me get a foothold on Linux, but it still doesn't help with
the binding problem.

James Harris <james.harris.1@gmail.com> writes:

> My suggestion is that the functional style of programming can be
> useful if it is applied in a limited way within an imperative language
> but it does not necessarily offer the purity that its proponents
> suggest.

I think you're making the mistake of thinking that programming
that is free of side effects is synonymous with functional
programming. It isn't. There is some correlation but neither
property necessarily implies the other.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Possibly there is some technique by which this can be emulated
>in a functional program as with the I/O monad in Haskell.
>The problem with this approach: I don't understand it!

I now believe that Haskell "avoids effects" by talking about
"I/O operations" instead of I/O. Those I/O operations seem
to be, effectively, the instructions that perform I/O. I.e.,
instead of "doing X" it talks about "the operations that do X"
(one level of indirection added).

However, to really have IO working, a system then is needed
that really does perform the IO operations. (See the use
of the expression "when performed" in the quotation below.)

Please let me quote from the Haskell Report 2010:

|A value of type IO a is a computation which, when performed,
|does some I/O before returning a value of type a.
| |There is really only one way to "perform" an I/O action:
|bind it to "Main.main" in your program. When your program
|is run, the I/O will be performed.
| "41.1 The IO monad" in "Haskell 2010, Language Report"
(2010-11-17) - Simon Marlow

This is akin to have values of expressions printed
in a REPL (=Main.main).

I can only say: "If it walks like an effect and it
quacks like an effect, then it must be an effect."

This is like a official who issues notes that say that
certain trees have to be cut down. The official can always
say, "I never cut down any tree. I only write notes.
If someone else then interprets these as requests for
action, what do I have to do with it?"

What Haskell seems to do is: Moving the effects out
of the functional program into its environment. But either
one accepts this enviroment as part of the semantics of
the language, then one does have /effects/ in the language,
or one does not accept it, then one cannot print from
a Haskell program (only calculate print operations).

On 2022-11-16 09:44, Stefan Ram wrote:

> This is like a official who issues notes that say that
> certain trees have to be cut down. The official can always
> say, "I never cut down any tree. I only write notes.
> If someone else then interprets these as requests for
> action, what do I have to do with it?"

That is the idea of declarative vs. imperative approach. You say "let
there be light" and somebody else (guess who?) begins pushing photons...
(:-))

P.S. The whole idea of computing is the side effects of. Though it is
possible to express computing in mathematical terms, the actual work
still need to be done nevertheless.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 16/11/2022 00:06, Tim Rentsch wrote:
> James Harris <james.harris.1@gmail.com> writes:
>
>> My suggestion is that the functional style of programming can be
>> useful if it is applied in a limited way within an imperative language
>> but it does not necessarily offer the purity that its proponents
>> suggest.
>
> I think you're making the mistake of thinking that programming
> that is free of side effects is synonymous with functional
> programming. It isn't. There is some correlation but neither
> property necessarily implies the other.

Well, AISI the essential characteristic of functional programming is to
produce results without side effects (aka without changing state?).

How that tends to be used, though, typically involves recursion and
first-class functions used in higher-order ways.

Do you see it differently?

--
James Harris

James Harris <james.harris.1@gmail.com> writes:
>Do you see it differently?

We should ask the one who coined that term.
I don't know who did this. Maybe John Backus?

Backus created "FP" (short for "functional programming)
in 1977 and wrote the influential Turing Award paper
"Can Programming Be Liberated from the von Neumann Style?".
But FP supports what today is called "function-/level/
programming" (point-free programming), not what today
is called "functional programming".

Web:

|In computer science, functional programming is a programming
|paradigm where programs are constructed by applying and
|composing functions. It is a declarative programming paradigm
|in which function definitions are trees of expressions that
|map values to other values, rather than a sequence of imperative
|statements which update the running state of the program.
Web.

On 15/11/2022 23:21, Bart wrote:
> On 15/11/2022 21:32, James Harris wrote:
>> On 15/11/2022 18:18, Bart wrote:
>>
>> ...
>>
>>> Where my languages are weak is in being so insular; working with
>>> other software is always a big obstacle (I can forget about running
>>> on Android for example, as you need to get through about 27 layers of
>>> software and bureaucracy first, plus I think you need to write in
>>> Java anyway).
>>
>> If you are concerned that your languages are too insular why not
>> compile for JVM or for Web Assembly?
>
> I'd find JVM very restrictive (how would I map inline assembler for
> example into JVM?). And WASM I found was poorly documented at the level
> I wanted to use it (I'm not into web stuff anyway.)

Don't use or allow inline asm! It ties object code to a certain
architecture.

>
> But what usually happens here, is whatever I need to download for JVM
> etc dwarfs my own product in size and complexity.

Why do you need such a download? Just produce bytecodes and add a header.

I'm kidding a little. I am sure there's a lot involved in working out
what bytecodes to use and how to make the correct file format; but I
would guess one could do enough with one's own software to avoid
downloading large Java/JVM build tools.

--
James Harris

On 15/11/2022 17:15, David Brown wrote:
> On 15/11/2022 13:13, James Harris wrote:
>> Some comments in this group have recently been espousing functional
>> programming. I was going to comment in replies but it seems better to
>> start a new thread.

> Do you actually know the "first" thing about functional programming
> languages?  The clue is in the name - "functions".  Given what you have
> written above, I believe you are completely unaware of the fact that the
> defining feature of a functional programming language is that functions
> are first-class objects - they can be manipulated, combined, modified
> and passed around just like objects.

This is what I don't get at all. You earlier had a go at spending too
much effort at manually managing memory or messing with pointers.

But here you extol the virtues of messing about with functions. It's
just micromanaging in a different way.

Functions should be solid blocks of code, known at compile time, that
you can rely on: I should be able to see what they do without having to
run the program.

Like you prefer a clear separation between expressions and statements, I
like a clear separation between code and data.

Anyway I would have said the defining feature was to represent any bit
of code as a formula: some single expression, instead of a sequence of
steps.

With some kinds of coding, you can do that. With most, you can't; it's a
poor fit.

On 2022-11-16 13:10, Bart wrote:

> But here you extol the virtues of messing about with functions. It's
> just micromanaging in a different way.
>
> Functions should be solid blocks of code, known at compile time, that
> you can rely on: I should be able to see what they do without having to
> run the program.

Hey, the very first time I agree with you! We must drink some milkshake
for that!

BTW, it is a bit weaker than you say. I would still allow function body
composition out of well-defined parts, e.g. overriding upon inheritance
and some, very limited, parametrization as in generics. But that is the
limit to me.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 16/11/2022 11:59, James Harris wrote:
> On 15/11/2022 23:21, Bart wrote:
>> On 15/11/2022 21:32, James Harris wrote:
>>> On 15/11/2022 18:18, Bart wrote:
>>>
>>> ...
>>>
>>>> Where my languages are weak is in being so insular; working with
>>>> other software is always a big obstacle (I can forget about running
>>>> on Android for example, as you need to get through about 27 layers
>>>> of software and bureaucracy first, plus I think you need to write in
>>>> Java anyway).
>>>
>>> If you are concerned that your languages are too insular why not
>>> compile for JVM or for Web Assembly?
>>
>> I'd find JVM very restrictive (how would I map inline assembler for
>> example into JVM?). And WASM I found was poorly documented at the
>> level I wanted to use it (I'm not into web stuff anyway.)
>
> Don't use or allow inline asm! It ties object code to a certain
> architecture.

Compiler backends, Interpreters with accelerators or JIT, and of course
assemblers, are necessarily tied to an architecture!

Anyway, in the past I might have spent a decade on a specific
architecture. When I switched to a new one, it was usually time to
upgrade my apps anyway.

So I don't think it's a big deal. But I also tend to keep assembler code
sections optional: it won't work when using a C target for example.

>>
>> But what usually happens here, is whatever I need to download for JVM
>> etc dwarfs my own product in size and complexity.
>
> Why do you need such a download? Just produce bytecodes and add a header.
>
> I'm kidding a little. I am sure there's a lot involved in working out
> what bytecodes to use and how to make the correct file format; but I
> would guess one could do enough with one's own software to avoid
> downloading large Java/JVM build tools.

Have you ever tried WASM?

I tried something on a small scale once, and got something simple
working, but there just wasn't enough information to proceed. The chance
of getting it usefully working back end seemed small.

It's just easier to do you own thing (just like I've always done) than
trying to do battle with these systems.

(I anyway support a C target, and somebody could generate WASM that way.
But how it would cope with the libraries I might call via the C, I've no
idea.)

On 16/11/2022 22:39, Bart wrote:
> On 16/11/2022 11:59, James Harris wrote:
>> On 15/11/2022 23:21, Bart wrote:
>>> On 15/11/2022 21:32, James Harris wrote:
>>>> On 15/11/2022 18:18, Bart wrote:
>>>>
>>>> ...
>>>>
>>>>> Where my languages are weak is in being so insular; working with
>>>>> other software is always a big obstacle (I can forget about running
>>>>> on Android for example, as you need to get through about 27 layers
>>>>> of software and bureaucracy first, plus I think you need to write
>>>>> in Java anyway).
>>>>
>>>> If you are concerned that your languages are too insular why not
>>>> compile for JVM or for Web Assembly?
>>>
>>> I'd find JVM very restrictive (how would I map inline assembler for
>>> example into JVM?). And WASM I found was poorly documented at the
>>> level I wanted to use it (I'm not into web stuff anyway.)
>>
>> Don't use or allow inline asm! It ties object code to a certain
>> architecture.
>
> Compiler backends, Interpreters with accelerators or JIT, and of course
> assemblers, are necessarily tied to an architecture!

Things like compiler backends might /produce/ asm. They shouldn't need
to /execute/ any inline asm to do so!

Just my gripe. I hate inline asm: it corrupts HLL code, making something
which has the appearance of portability into something non-portable.
Where asm is needed I put it in separate modules - separate asm modules.
The idea is that one set of asm modules will be used on x86-32, another
on Arm64, etc.

>
> Anyway, in the past I might have spent a decade on a specific
> architecture. When I switched to a new one, it was usually time to
> upgrade my apps anyway.
>
> So I don't think it's a big deal. But I also tend to keep assembler code
> sections optional: it won't work when using a C target for example.

I'd keep asm /libraries/ separate, not just sections or even files but
entire libraries.

>
>>>
>>> But what usually happens here, is whatever I need to download for JVM
>>> etc dwarfs my own product in size and complexity.
>>
>> Why do you need such a download? Just produce bytecodes and add a header.
>>
>> I'm kidding a little. I am sure there's a lot involved in working out
>> what bytecodes to use and how to make the correct file format; but I
>> would guess one could do enough with one's own software to avoid
>> downloading large Java/JVM build tools.
>
> Have you ever tried WASM?

No, not yet.

>
> I tried something on a small scale once, and got something simple
> working, but there just wasn't enough information to proceed. The chance
> of getting it usefully working back end seemed small.
>
> It's just easier to do you own thing (just like I've always done) than
> trying to do battle with these systems.

I agree. Learning systems that other people have produced can be
surprisingly time consuming. And, frankly, a lot of stuff that others
produce tends to be too limiting, to be overly heavyweight and to get
even more bulky over time.

I often find it best to work with my own simpler data structures and
formats for most processing and only to convert to other standards as a
final step.

>
> (I anyway support a C target, and somebody could generate WASM that way.
> But how it would cope with the libraries I might call via the C, I've no
> idea.)

Nor have I. But a web browser can be a 'universal client'. Users don't
have to download anything specific to use one's software.

--
James Harris

On 16/11/2022 13:10, Bart wrote:
> On 15/11/2022 17:15, David Brown wrote:
>> On 15/11/2022 13:13, James Harris wrote:
>>> Some comments in this group have recently been espousing functional
>>> programming. I was going to comment in replies but it seems better to
>>> start a new thread.
>
>> Do you actually know the "first" thing about functional programming
>> languages?  The clue is in the name - "functions".  Given what you
>> have written above, I believe you are completely unaware of the fact
>> that the defining feature of a functional programming language is that
>> functions are first-class objects - they can be manipulated, combined,
>> modified and passed around just like objects.
>
> This is what I don't get at all. You earlier had a go at spending too
> much effort at manually managing memory or messing with pointers.
>
> But here you extol the virtues of messing about with functions. It's
> just micromanaging in a different way.
>

There is always going to be effort somewhere in the programming! And
there is no doubt that different languages, and some paradigms, are more
or less suited to different tasks.

Pointers may be more suited to manipulating a single pixel in an image
buffer than, say, using a list and working through it with a recursive
function (I am /not/ saying that is how you would handle the task in a
functional programming language!). But pointers are also more suited to
making mistakes and changing the wrong data, overrunning your buffers,
or generally being unsure of what your data is because things can change
all the time.

Take one step away, and use an array for the image buffer with all
access via the array (no pointers), and you have made a big step towards
eliminating most of the pointer-related problems. You can have bounds
checking on the array access (and the compiler can optimise away most
checks for efficiency) - no more overruns, no more random writes to the
stack or other data through erroneous pointers. If your code looks like
it changes the image buffer, then the image buffer is all it ever
changes - or it throws an "out of bounds" error. Still, your data can
change - "x" may be one thing at one place in the function, and
something different at another place. However, you can at least find
the place it changes.

Two steps away and the data never changes - you can rely on things,
reason about them, prove them in a completely different way. That is
the benefit of functional programming.

There's a lot to be said for picking the middle ground choice here. But
again, there are good reasons for different choices.

> Functions should be solid blocks of code, known at compile time, that
> you can rely on: I should be able to see what they do without having to
> run the program.

That's your biases shining through loud and clear.

In a great many programming languages, and a great many implementations
of other languages, they are not nearly as "solid" and simplistic as you
describe. Even C has never had a precise one-to-one relationship
between functions in source code and functions in object code - and it
certainly does not now with modern tools.

If you want to know what a function does before running it, look at its
definition - along with the definition of any other functions it calls,
what data it has, what constants it uses, and so on. That applies to
all languages.

>
> Like you prefer a clear separation between expressions and statements, I
> like a clear separation between code and data.
>

I don't think such a clear distinction between code and data is either
possible or useful. If you have a table of pointers to initialisation
functions to run - is that code or data? It looks like data, but acts
like a function that calls a bunch of other functions.

> Anyway I would have said the defining feature was to represent any bit
> of code as a formula: some single expression, instead of a sequence of
> steps.
>
> With some kinds of coding, you can do that. With most, you can't; it's a
> poor fit.
>

In C programs, you can - it's all in the single expression "main(...)".

A key difference between functional languages and imperative languages
is that imperative languages are a list of commands - you are asking the
computer to do things. With functional programming languages, you are
asking the computer to give you things - you are not as concerned about
the implementation methods, only the results. It is looking at the task
from a different perspective.

On 2022-11-18 13:36, David Brown wrote:

> If you want to know what a function does before running it, look at its
> definition - along with the definition of any other functions it calls,
> what data it has, what constants it uses, and so on.  That applies to
> all languages.

That is exactly the problem. In mathematics and in declarative
approaches that follow closely, definition is the function itself. E.g.
all sorts of recursive definitions. Analysis of function behavior is in
the core of mathematics. Basically it presents something, you do not
know what, though its definition is before your eyes! Your objective is
to figure it out, to study it. This is because mathematical functions
exist on their own.

This is not how engineering and programming as engineering activity
work. There you create something in order to achieve something.

Pragmatically, separation of specification and implementation is
difficult when functions become first class objects.

Another issue is treatment of types when each function is an operation
on some types and nothing else.

P.S. Nothing above would worry Bart, but it worries me, which is why I
agree with him.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 18/11/2022 12:36, David Brown wrote:
> On 16/11/2022 13:10, Bart wrote:

>> Functions should be solid blocks of code, known at compile time, that
>> you can rely on: I should be able to see what they do without having
>> to run the program.
>
> That's your biases shining through loud and clear.

Take any large code base. If you were to analyse the functions, how
proportion do you think would exactly fit my description?

That is, there are functions F, G, H plainly defined in the source code,
and there calls F(), G(), H() are multiple call sites.

In mine the figure would be near to 100%. While some calls would be done
indirectly via function references, those references would still point
to one of those F, G, H function.

My recollection of other codebases is that it would still be the vast
majority, except where the language has classes, and now of course
everything must be inside a class, and function calls becomes methods calls.

It's a bit murkier, but still, a call A.F() still ends up calling a
fixed, solid function typeof(A).F.

It the emphasis of the 1% of cases I don't like, and those languages
that strive to get you to increase that to near 100%.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Pragmatically, separation of specification and implementation is
> difficult when functions become first class objects.

That's nonsense. Programs written in functional languages
do it all the time.

James Harris <james.harris.1@gmail.com> writes:

> On 16/11/2022 00:06, Tim Rentsch wrote:
>
>> James Harris <james.harris.1@gmail.com> writes:
>>
>>> My suggestion is that the functional style of programming can be
>>> useful if it is applied in a limited way within an imperative language
>>> but it does not necessarily offer the purity that its proponents
>>> suggest.
>>
>> I think you're making the mistake of thinking that programming
>> that is free of side effects is synonymous with functional
>> programming. It isn't. There is some correlation but neither
>> property necessarily implies the other.
>
> Well, AISI the essential characteristic of functional programming is
> to produce results without side effects (aka without changing state?).

Let me suggest that you focus less on how you see things and
focus more on how the functional programming community sees
things.

On 18/11/2022 14:14, Dmitry A. Kazakov wrote:
> On 2022-11-18 13:36, David Brown wrote:
>
>> If you want to know what a function does before running it, look at
>> its definition - along with the definition of any other functions it
>> calls, what data it has, what constants it uses, and so on.  That
>> applies to all languages.
>
> That is exactly the problem. In mathematics and in declarative
> approaches that follow closely, definition is the function itself. E.g.
> all sorts of recursive definitions. Analysis of function behavior is in
> the core of mathematics. Basically it presents something, you do not
> know what, though its definition is before your eyes! Your objective is
> to figure it out, to study it. This is because mathematical functions
> exist on their own.
>

"Functions" in functional programming and in mathematics are not the
same thing.

In mathematics, the functions "sin(x)" and "cos(x + π/2)" are exactly
the same thing. They are indistinguishable. Any definition that gives
the same mapping from the source domain to the destination domain is the
same function.

In functional programming languages - real, practical functional
programming languages, that is not the case. You might argue that in a
hypothetical sense two functional programming language functions that
give the same results are the same function - but you can argue exactly
the same about any kind of programming language. In reality, functional
programming language functions are much like functions in imperative
languages - compilers can manipulate them to make variants that give the
same results more efficiently (this is "optimisation"), but otherwise
they do what the function definition says.

A difference, perhaps, is that imperative functions go from the bottom
up (or start to finish) while functional programming language functions
are often more top-down (describe the end result that you want, and then
the partial results to get there).

> This is not how engineering and programming as engineering activity
> work. There you create something in order to achieve something.

Sorry, but you are completely wrong in your distinction.

Programming with FP languages is as much "engineering" as programming
with imperative languages or any other paradigm. When telephone
switching systems are programmed in the functional programming language
Erlang (which was developed with that application in mind), do you think
it is not "achieving something"? When people make programmable logic
designs using FP languages such as Lava (build on Haskell), Confluence
(from OCaml), or SpinalHDL (from Scala), it is as clear and solid
engineering as you can get. And of course, "normal" functional
programming is programming just like any other programming.

>
> Pragmatically, separation of specification and implementation is
> difficult when functions become first class objects.

Again, that is an imaginary distinction.

Whether the language supports first-class functions or not makes no
difference as to how well specified functions are, or whether the
implementation follows that specification or not. The only difference
is that with functional programming, it is often easier to see that the
function implements the specification - but regardless of the paradigm,
this depends on the complexity of the function.

>
> Another issue is treatment of types when each function is an operation
> on some types and nothing else.
>

I can't understand what you mean. Functional programming language
functions are not operations on types. Conversely, all functions in all
languages operate on some types and nothing else.

On 2022-11-21 16:23, David Brown wrote:
> On 18/11/2022 14:14, Dmitry A. Kazakov wrote:
>> On 2022-11-18 13:36, David Brown wrote:
>>
>>> If you want to know what a function does before running it, look at
>>> its definition - along with the definition of any other functions it
>>> calls, what data it has, what constants it uses, and so on.  That
>>> applies to all languages.
>>
>> That is exactly the problem. In mathematics and in declarative
>> approaches that follow closely, definition is the function itself.
>> E.g. all sorts of recursive definitions. Analysis of function behavior
>> is in the core of mathematics. Basically it presents something, you do
>> not know what, though its definition is before your eyes! Your
>> objective is to figure it out, to study it. This is because
>> mathematical functions exist on their own.
>
> "Functions" in functional programming and in mathematics are not the
> same thing.
>
> In mathematics, the functions "sin(x)" and "cos(x + π/2)" are exactly
> the same thing.  They are indistinguishable.  Any definition that gives
> the same mapping from the source domain to the destination domain is the
> same function.
>
> In functional programming languages - real, practical functional
> programming languages, that is not the case.  You might argue that in a
> hypothetical sense two functional programming language functions that
> give the same results are the same function - but you can argue exactly
> the same about any kind of programming language.  In reality, functional
> programming language functions are much like functions in imperative
> languages - compilers can manipulate them to make variants that give the
> same results more efficiently (this is "optimisation"), but otherwise
> they do what the function definition says.

Yes. In short. Functional paradigm does not stand for its promises. That
is an open secret... (:-))

> A difference, perhaps, is that imperative functions go from the bottom
> up (or start to finish) while functional programming language functions
> are often more top-down (describe the end result that you want, and then
> the partial results to get there).

Well, not really. Whether the ultimate program is

do_it;

or

let_it_be_done;

makes little difference. Levels of indirection not necessary translate
into higher abstraction and conversely. Imperative approach has one
level less.

>> This is not how engineering and programming as engineering activity
>> work. There you create something in order to achieve something.
>
> Sorry, but you are completely wrong in your distinction.
>
> Programming with FP languages is as much "engineering" as programming
> with imperative languages or any other paradigm.  When telephone
> switching systems are programmed in the functional programming language
> Erlang (which was developed with that application in mind), do you think
> it is not "achieving something"?  When people make programmable logic
> designs using FP languages such as Lava (build on Haskell), Confluence
> (from OCaml), or SpinalHDL (from Scala), it is as clear and solid
> engineering as you can get.  And of course, "normal" functional
> programming is programming just like any other programming.

You confuse application with intent. Yes, you can achieve something by
programming in awful languages in awful manner. I do not mean here FPL
specifically. Just for the sake of argument. You will wonder to know
what software was written in VisualBasic...

>> Pragmatically, separation of specification and implementation is
>> difficult when functions become first class objects.
>
> Again, that is an imaginary distinction.

In is not imaginary. If you cannot use functions as a vehicle do define
interface you need to come up with something else or drop the idea
altogether.

> Whether the language supports first-class functions or not makes no
> difference as to how well specified functions are, or whether the
> implementation follows that specification or not.

Specification is a declarative layer on top of the object language. In
imperative procedural languages that layer is declaration of
subprograms. In OOPL it is types (classes) defined in terms of methods
(members are built-in getter/setter methods). In FPL, typically, there
is none, unless you introduce some meta functions, whatever. E.g.
generics/templates exist for infinity and still have no reasonable
specifications, and thus, are fundamentally non-testable. I do not care
even a little bit about FP, but, my guess is that it must have similar
issues.

>> Another issue is treatment of types when each function is an operation
>> on some types and nothing else.
>
> I can't understand what you mean.  Functional programming language
> functions are not operations on types.

Yep.

> Conversely, all functions in all
> languages operate on some types and nothing else.

No, in OOPL a method operates on the class. A "free function" takes some
arguments in unrelated types.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de