Are computer languages meaningfully... in english?

[bradrn]

But declarative functional languages (like haskell and elm) have thought about this redundancy, and have either discouraged or ridded themselves of the first SVO type of function call:

Code: Select all

man `eat` apple -- works in haskell, but not elm
eat man apple -- note that in haskell and elm, the "subject" of the function/verb is traditionally the /last/ parameter of the function, not the first
eat apple man -- preferred style, because it makes making useful closures easier

2 + 3
(+) 2 3 -- useful when you need to pass the addition function to another function

Meanwhile, Lisps go the other direction by making all function calls prefix, while Forth does the opposite by pushing functions to the end. Smalltalk and derivatives take a third approach, by expressing everything as a message to the ‘subject’… itself an odd notion when you think about it, given that natural-language subjects tend to be least affected by an action, whereas OOP message receivers tend to be most affected by a message. Perhaps a better natlang-like analysis would be to consider ‘receiver’ to be a vocative-like category, in apposition to a message formulated somewhat like an imperative with elided subject.

Yeah, this could happen. I do some scripting for my job, and I can tell you I wouldn't want to type "means" instead of "=" every time I needed to assign something. It's 5x the work! (I didn't even feel like writing out "times" there.... crap. I just did...) "=" is an already available symbol that means something very close to what it's doing in programming, so why not use it? Also, when you're scanning code, I'd say that the "=" signs will just out a little bit from the surrounding text, making it easier to ready.

But what about the order ? Why not instead write ? :

Code: Select all

= 21 myVar

Lisp and Forth (and derived languages) take this approach, though with the ‘arguments’ flipped:

Code: Select all

(defun div-check (a b) (when (/= b 0) (/ a b)))

: /CHECK ?DUP IF / THEN ;

(3) I think that "for" loops are awkward in most proglangs, and would probably have a different form if the programmers that created them had a different natlang phrase for what they do.

That’s specifically a C thing, I think. The ALGOL equivalent was much neater, at least according to Wikipedia:

Code: Select all

for i = first to last do statement
(* or just *)
for i = first..last do statement

Meanwhile, Python, C# and other languages use a for–each loop:

Code: Select all

for item in iterable:
    # do something

[alice]

For completeness, there's also the Ruby idiom, which was influenced by Smalltalk:

Code: Select all

iterable.each do |item|
    # do something
end

[bradrn]

For completeness, there's also the Ruby idiom, which was influenced by Smalltalk:

Code: Select all

iterable.each do |item|
    # do something
end

That’s not really different to the others, though; you can do the same in many languages. It’s just that Ruby allows elision of some of the syntactic clutter. Haskell is comparably light on syntax, though the function goes at the beginning:

Code: Select all

for_ list $ \item ->
    _something

[rotting bones]

I think alternative syntactic ideas like Forth's postfix notation never caught on in the world of general programming because programmers have different concerns than players of social language games:

1. In scripting, you want to send the computer a brief list of instructions. The fundamental features of this imperative paradigm are sequences, branches and loops. Any linguistic idea that gets in the way of conceptualizing these features hinders your ability to write code.

2. When the codebase gets large, you have to start worrying about code reusability. In the procedural paradigm, code is easy to read when procedures and functions stand out prominently.

3. The next stage in the evolution of mainstream programming involved large banks of formatted data. To ensure regularity in accessing and converting formatted data, it helps to implement data structures as classes. This led to the object oriented paradigm.

[Travis B.]

To me the reason Forth is less popular than it, well, ought to be is its tendency towards write-only code and its reputation for this. However, this is simple to solve - there are Forths such as gforth and my zeptoforth with support for block-scoped local variables, and IMO these, when actually used, really solve Forth's readability problems. Liberal usage of local variables greatly reduces the stack twiddling that bedevils more traditional Forths. From looking at my Forth code from before I added local variables to zeptoforth and my code afterwards the difference is like night and day; the latter code is infinitely more readable.

OTOH, I think the thing that people like to complain about, RPN, is much less of an issue in reality. Once you have local variables, it really is just like if you took Lisp, flipped the order of everything, and deleted all the parentheses. Once you are used to it it really is a non-issue.

[rotting bones]

To me the reason Forth is less popular than it, well, ought to be is its tendency towards write-only code and its reputation for this. However, this is simple to solve - there are Forths such as gforth and my zeptoforth with support for block-scoped local variables, and IMO these, when actually used, really solve Forth's readability problems. Liberal usage of local variables greatly reduces the stack twiddling that bedevils more traditional Forths. From looking at my Forth code from before I added local variables to zeptoforth and my code afterwards the difference is like night and day; the latter code is infinitely more readable.

OTOH, I think the thing that people like to complain about, RPN, is much less of an issue in reality. Once you have local variables, it really is just like if you took Lisp, flipped the order of everything, and deleted all the parentheses. Once you are used to it it really is a non-issue.

I like Forth. When I wanted to try zeptoforth, you said something about niche hardware.

My understanding is that Forth is mainly used for low level coding. If I wanted to write a neural network in Forth, I might have to juggle millions of values on the stack. These values will have complex, structured relationships among themselves. My headache is coming back just thinking about it. Almost makes me want to try it. GForth has classes, doesn't it? Can I get GPU support? I don't suppose any Forth has AI libraries already?

[alice]

Not so very long ago I created a Forth-like language (which I called "Sixth"), which had classes. It wasn't that hard to do, as it turned out.

[rotting bones]

Not so very long ago I created a Forth-like language (which I called "Sixth"), which had classes. It wasn't that hard to do, as it turned out.

What's hard is not making the language. What did you use it for?

[Travis B.]

Classes are by no means incompatible with Forth, even though they are rather untraditional as Forth features go. Both gforth and zeptoforth have support for classes - I am using them right now in my driver layer for talking to the ESP8285 radio on my new Seeed Wio RP2040 dev board, and confusingly gforth comes with more than one object system.

[Travis B.]

To me the reason Forth is less popular than it, well, ought to be is its tendency towards write-only code and its reputation for this. However, this is simple to solve - there are Forths such as gforth and my zeptoforth with support for block-scoped local variables, and IMO these, when actually used, really solve Forth's readability problems. Liberal usage of local variables greatly reduces the stack twiddling that bedevils more traditional Forths. From looking at my Forth code from before I added local variables to zeptoforth and my code afterwards the difference is like night and day; the latter code is infinitely more readable.

OTOH, I think the thing that people like to complain about, RPN, is much less of an issue in reality. Once you have local variables, it really is just like if you took Lisp, flipped the order of everything, and deleted all the parentheses. Once you are used to it it really is a non-issue.

I like Forth. When I wanted to try zeptoforth, you said something about niche hardware.

My understanding is that Forth is mainly used for low level coding. If I wanted to write a neural network in Forth, I might have to juggle millions of values on the stack. These values will have complex, structured relationships among themselves. My headache is coming back just thinking about it. Almost makes me want to try it. GForth has classes, doesn't it? Can I get GPU support? I don't suppose any Forth has AI libraries already?

As niche hardware goes, zeptoforth runs on RP2040-based boards (in theory it is dependent on the particular flash used, but no one I know who's tried it on an RP2040 board has not gotten in it to boot, even though the flash has better performance on some boards than others, and there are compatibility issues with LED support due to it being board-specific), and RP2040-based boards are cheap and plentiful at the present. I recommend getting one of these. It is known to run best on the Raspberry Pi Pico, for which RP2040 support was originally developed and which has very good flash performance, and boards which integrate a Raspberry Pi Pico such as the Cytron Maker PI PICO. However, it has been confirmed to work on the Seeed XIAO RP2040 and Seeed Wio RP2040, and because the the Seeed Wi RP2040 has an ESP8285 radio on it, and ESP8285 radio support is in the works at this very moment, if you want to try out WiFi support in the near future you might consider it. The main downsides of these are that they have poorer flash performance in practice than the Raspberry Pi Pico, and the Seeed XIAO RP2040 exposes very few pins. Do not bother with the Raspberry Pi PIco W, though, because it will be a while before its WiFi chip is supported, and there are key features of the Raspberry Pi Pico which do not work on it and will not work on it in the immediate future such as the LED (as the LED on the Raspberry Pi Pico W is tied to a pin on the WiFi chip, so it will not work until I develop a working WiFi chip driver).

zeptoforth runs on an number of STM32 boards as well. If you get these you probably will get an STM32F411 board such as the STM32F411 "Black Pill", which I was able to actually buy during the worst part of the Great Chip Shortage despite being STM32; it also unofficially supports the STM32F411 Nucleo 64, but you have to do a minor bit of hackery to really get it to work on there. It also runs on STM32F407, STM32F746, and STM32L476 DISCOVERY boards, which at the present are not cheap or plentiful at all.

About Forth being for low level coding, as I like to put it, Forth is what you get when assembly and Lisp love each other very much... It is what you want when you want direct access to the physical hardware yet have a REPL and be able to compile code on the fly all at the same time. In the case of zeptoforth, considering that it runs on embedded systems leads to low level coding unto itself. However, zeptoforth also has a wide variety of higher level constructs atypical of many Forths, ranging from a user-friendly module/namespace system (which uses traditional wordlists internally but abstract them away), to the aforementioned block-scoped local variables, to an object system and (if that is too heavyweight for you) structures, to lambdas and closures, to a fully-featured preemptive multitasker and intertask communication constructs such as semaphores, locks, channels, streams, etc. more typical of traditional RTOS environments, to optional heap and pool allocators (with support for multiple heaps if the user so desires), to lightweight "action" scheduler constructs for when tasks are just too heavyweight, to hashmap constructs, to SDHC/SDXC card and FAT32 support, and so on.

As for doing the kinds of high-level tasks you mention, there are higher-level PC Forths out there, and these often expose outside code via foreign function interfaces so if you are writing a program in Forth on a PC, you can call libraries such as SDL and OpenGL, or the AI libraries you mention, from within Forth. A good high-level (and mind you, very untraditional) Forth to take a look at is Retro. If you want to get really high-level, I would also consider taking a look at Factor - I would not consider Factor to be a Forth per se, but is is an RPN concatenative language with a lot of good high-level ideas and significant standard libraries. (Too bad most of the core developers of Factor got snapped up by a variety of companies once they completed their degrees...)

[bradrn]

I think alternative syntactic ideas like Forth's postfix notation never caught on in the world of general programming because programmers have different concerns than players of social language games:

1. In scripting, you want to send the computer a brief list of instructions. The fundamental features of this imperative paradigm are sequences, branches and loops. Any linguistic idea that gets in the way of conceptualizing these features hinders your ability to write code.

2. When the codebase gets large, you have to start worrying about code reusability. In the procedural paradigm, code is easy to read when procedures and functions stand out prominently.

3. The next stage in the evolution of mainstream programming involved large banks of formatted data. To ensure regularity in accessing and converting formatted data, it helps to implement data structures as classes. This led to the object oriented paradigm.

These are non-issues:

1. Forth is about nothing but giving instructions. The average Forth tutorial starts out with an example (often involving washing machines, for some reason) of how good it is at this.
2. Forth is better at code reusability than pretty much every other language: all commands act on the stack, and you can compose them however you want.
3. OOP is not the be-all and end-all of everything. That being said, as Travis mentioned, you can definitely implement OOP in Forth if you want (largely as a consequence of 1 and 2).

The real issues are:

1. As Travis said, Forth is ridiculously low-level — more than C, even. There are no data types and no data structures; everything is simply a collection of bytes. This makes things very easy when you want to do low-level stuff, and practically impossible when you want to do anything else.
2. Forth is overly customisable: this is a consequence of (2) above. As with Lisps, making new reusable operations in Forth is so easy that most programs end up pretty much creating their own variant of the language. In Lisp it isn’t such a problem since the base library is relatively high-level, but for Forth anything not part of the few primitive operations is usually custom-defined for that particular program. This makes it fantastic for a single person to develop programs, and a nightmare if you have any more people than that, since every program is written in what looks like a different language which then needs to be learnt.

[alice]

Not so very long ago I created a Forth-like language (which I called "Sixth"), which had classes. It wasn't that hard to do, as it turned out.

What's hard is not making the language. What did you use it for?

I reimplemented the Unix kernel in it, and I use it for all my conworlding and conlanging needs; what did you think?

[rotting bones]

Not so very long ago I created a Forth-like language (which I called "Sixth"), which had classes. It wasn't that hard to do, as it turned out.

What's hard is not making the language. What did you use it for?

I reimplemented the Unix kernel in it, and I use it for all my conworlding and conlanging needs; what did you think?

For maximum impact against my argument, anything high level. But that's impressive too. Is it available online?

[rotting bones]

These are non-issues:

1. Forth is about nothing but giving instructions. The average Forth tutorial starts out with an example (often involving washing machines, for some reason) of how good it is at this.
2. Forth is better at code reusability than pretty much every other language: all commands act on the stack, and you can compose them however you want.
3. OOP is not the be-all and end-all of everything. That being said, as Travis mentioned, you can definitely implement OOP in Forth if you want (largely as a consequence of 1 and 2).

1. "Giving instructions" is not the same as making it easy to conceptualize sequences, branches and loops. By the way, this is not an ad hoc list of features. It's drawn from my reading of the mathematical foundations of computer science.

2. "Code reusability" is not the same as making procedures and functions prominent.

3. Travis mentioned that classes are untraditional in Forth. Having (3) without (1) and (2) certainly helps, but I don't know if it's enough. Forth's postfix syntax was just one example.

The real issues are:

These are consequences of (1) and (2).

[rotting bones]

As for doing the kinds of high-level tasks you mention, there are higher-level PC Forths out there, and these often expose outside code via foreign function interfaces so if you are writing a program in Forth on a PC, you can call libraries such as SDL and OpenGL, or the AI libraries you mention, from within Forth. A good high-level (and mind you, very untraditional) Forth to take a look at is Retro. If you want to get really high-level, I would also consider taking a look at Factor - I would not consider Factor to be a Forth per se, but is is an RPN concatenative language with a lot of good high-level ideas and significant standard libraries. (Too bad most of the core developers of Factor got snapped up by a variety of companies once they completed their degrees...)

I'll try Retro and Factor. I think I've seen Factor before.

[bradrn]

1. "Giving instructions" is not the same as making it easy to conceptualize sequences, branches and loops. By the way, this is not an ad hoc list of features. It's drawn from my reading of the mathematical foundations of computer science.

Forth does make it easy to conceptualise those things, though. Here’s a branch:

Code: Select all

( numerator denominator -- quotient )
: /CHECK
  DUP 0= IF ." invalid " DROP
       ELSE /
       THEN ;

And here’s a loop:

Code: Select all

: DECADE  10 0 DO  I .  LOOP ;

(Both from Brodie’s Thinking Forth.) The syntax is a bit eccentric thanks to the stack-based paradigm, but it’s very easy to get used to.

Also, note that neither of these constructs are special; the user can easily define new control flow.

(And by the way, ‘the mathematical foundations of computer science’ is an extremely broad field. Turing machines are even more fundamental than branches and loops. And arguably the lambda and iota calculi are even more fundamental.)

2. "Code reusability" is not the same as making procedures and functions prominent.

I never said it was. Procedures and functions are not the only mechanism to achieve code reusability.

However, note that both my examples above can be seen as function definitions, hence achieve reusability already. And compared to other programming languages, it’s very easy to add even more reusability. For instance, here’s a variant of DECADE which takes two integral arguments:

Code: Select all

: COUNTDOWN  DO  I .  LOOP ;

Note that it needed barely any change. (In actual fact, it required less code!)

I’d recommend looking up ‘concatenative programming’ for more details on how Forth achieves this kind of reusability — Forth predates the term, but it’s applicable to Forth too.

3. Travis mentioned that classes are untraditional in Forth. Having (3) without (1) and (2) certainly helps, but I don't know if it's enough. Forth's postfix syntax was just one example.

I don’t care if classes are non-traditional. In fact, I personally think OOP is totally unsuited to most problems; functional programming is much better. And Forth is already extremely close to functional programming. (Again, I’d recommend looking up concatenative programming.)

I think I've seen Factor before.

It’s a nice language and environment.

[rotting bones]

The syntax is a bit eccentric thanks to the stack-based paradigm, but it’s very easy to get used to.

The stack flipping alone makes it difficult to keep track of these features. As Travis mentioned, conceptualizing sequences may have been improved by the introduction of local variables.

(And by the way, ‘the mathematical foundations of computer science’ is an extremely broad field. Turing machines are even more fundamental than branches and loops. And arguably the lambda and iota calculi are even more fundamental.)

Having fully general sequences, branches and loops is what makes an imperative language Turing-complete. The same effect can be achieved with primitive recursive functions, etc. But Lambda Calculus, eg, is not a physical model of computation.

I never said it was. Procedures and functions are not the only mechanism to achieve code reusability.

But that's what makes code readable. I thought Forth being unintuitive is a fairly uncontroversial position. I'm reminded of one dude who took a few classes in Urbit extolling its virtues. If he, a non-programmer, could write a few short programs, he didn't understand why engineers say the runes make programs unreadable. Same with the people who don't understand the problem with an overuse of goto. Same with pointers to an extent.

There is a tremendous difference that comes with high level, secure, production quality code written by large teams.

I’d recommend looking up ‘concatenative programming’ for more details on how Forth achieves this kind of reusability — Forth predates the term, but it’s applicable to Forth too.

I agree that Forth has its benefits.

I don’t care if classes are non-traditional.

You should care in the context of which paradigms gained popularity in the mainstream.

In fact, I personally think OOP is totally unsuited to most problems; functional programming is much better. And Forth is already extremely close to functional programming. (Again, I’d recommend looking up concatenative programming.)

The problem with a purely functional paradigm is that side-effects are precisely what we're trying to achieve. The chip's machine code is imperative, so you're leaning more heavily on the interpreter or compiler than in imperative languages. Programmers also conceptualize the program as a list of instructions. Why take the detour through math unless you're mainly interested in proving theorems about your code?

[alice]

What's hard is not making the language. What did you use it for?

I reimplemented the Unix kernel in it, and I use it for all my conworlding and conlanging needs; what did you think?

For maximum impact against my argument, anything high level. But that's impressive too. Is it available online?

It would be, but for certain annoying things getting in the way, such as the realism of one person actually being able to do all that I hope you don't think anyone in their right mind would ever try to write device drivers and filesystems in anything Forth-related.

In actual fact I earmarked it as something to implement on my 1980's-era retrocomputer, but when I had to abandon that, SIxth went too. It was a fun programing exercise but ultimately not usefu lfor much other than being able to say that I had created a new language.

Meanwhile, before this thread degenerates into "my favourite programming paradigm is better than your favourite programming paradigm, so clearly my genitals are larger", I'll note that while both OOP and FP have undoubted merits, both also have serious defects. OOP taken to extremes (see: some varieties of Java) is an unholy mess of abstractions; FP in its purest forms (see: anything handed down from academia) betrays the erroneous belief that programming is a sub-discipline of mathematics.

[Travis B.]

To me, as a fan of both Forth and functional programming (e.g. Haskell, Scheme) am of the view that they both have their place. Functional programs are easier to reason algorithmically about IMO (especially pure functional programs, as then functions do not just do whatever they feel like at any point) but have less predictable memory characteristics (e.g. needing garbage collection, and in the case of lazy functional programs, being prone to space leaks). These things both make them (and most dynamically-typed languages in general) unsuited to small systems, especially where realtime characteristics matter, despite the attempts of some (read: MicroPython, eLua, uLisp) to implement such languages on small systems. Forth, on the other hand, is very well-suited to small systems, but at the same time has a REPL and strong metaprogramming characteristics unlike typical small-system languages such as C (where the closest thing to a REPL you might get is a gdb session on a connected PC, but that is less friendly overall IMO, and C's macros are not nearly as well-suited for metaprogramming). Also, Forth is one of very few languages that one can effectively design an entire system all by oneself and keep it in one's head, yet which is sufficiently powerful for real tasks (as opposed to, say, smaller BASIC's, which, while easy to design oneself, lack practical power).

[bradrn]

The syntax is a bit eccentric thanks to the stack-based paradigm, but it’s very easy to get used to.

The stack flipping alone makes it difficult to keep track of these features. As Travis mentioned, conceptualizing sequences may have been improved by the introduction of local variables.

Yes, I agree that local variables can help considerably. I’m saying that the stack-based paradigm is easy to get used to, not easy to use.

I never said it was. Procedures and functions are not the only mechanism to achieve code reusability.

But that's what makes code readable. I thought Forth being unintuitive is a fairly uncontroversial position.

‘Reusability’, ‘readability’ and ‘intuitivity’ are three totally different things. Saying ‘Forth isn’t readable’ has nothing to do with how Forth achieves code reusability.

I don’t care if classes are non-traditional.

You should care in the context of which paradigms gained popularity in the mainstream.

I have very little interest in the popularity of programming paradigms. Remember, even PHP and R became popular! And both of those were (and are) terrible languages. I find that most of the time classes are practically useless, and serve only to obscure what I’m trying to do.

In fact, I personally think OOP is totally unsuited to most problems; functional programming is much better. And Forth is already extremely close to functional programming. (Again, I’d recommend looking up concatenative programming.)

The problem with a purely functional paradigm is that side-effects are precisely what we're trying to achieve. The chip's machine code is imperative, so you're leaning more heavily on the interpreter or compiler than in imperative languages.

Indeed, which is why I have no problem with Forth (or C or Zig or Rust) for low-level programs. But I’ll note that all of these languages (except perhaps C) support at least some level of FP, whereas they natively have no support at all for OOP.

Programmers also conceptualize the program as a list of instructions.

As I see it, the vast majority of teaching is imperative, and the vast majority of languages are imperative, so naturally programmers end up thinking in terms of imperative instructions without even realising there’s an alternative. But that has nothing to do with what’s most intuitive in general! On the FP Discord server, we often get beginners who need to learn how to ‘think functionally’; they often surprise themselves by how easy it is once they get there. Personally, I find FP a lot more intuitive than imperative programming.

Oh, and as for these:

Why take the detour through math unless you're mainly interested in proving theorems about your code?

FP in its purest forms (see: anything handed down from academia) betrays the erroneous belief that programming is a sub-discipline of mathematics.

This is a common misconception, FP has very little to do with maths! It is true that FP is closer to maths than imperative programming is, but you need no mathematical knowledge whatsoever to write programs functionally.

To me, as a fan of both Forth and functional programming (e.g. Haskell, Scheme) am of the view that they both have their place. Functional programs are easier to reason algorithmically about IMO (especially pure functional programs, as then functions do not just do whatever they feel like at any point) but have less predictable memory characteristics (e.g. needing garbage collection, and in the case of lazy functional programs, being prone to space leaks). These things both make them (and most dynamically-typed languages in general) unsuited to small systems, especially where realtime characteristics matter, despite the attempts of some (read: MicroPython, eLua, uLisp) to implement such languages on small systems. Forth, on the other hand, is very well-suited to small systems, but at the same time has a REPL and strong metaprogramming characteristics unlike typical small-system languages such as C (where the closest thing to a REPL you might get is a gdb session on a connected PC, but that is less friendly overall IMO, and C's macros are not nearly as well-suited for metaprogramming). Also, Forth is one of very few languages that one can effectively design an entire system all by oneself and keep it in one's head, yet which is sufficiently powerful for real tasks (as opposed to, say, smaller BASIC's, which, while easy to design oneself, lack practical power).

I agree with this assessment. Although you may be interested in some of the newer attempts to make low-level FP practical: e.g. the Ante and Koka programming languages, as well as Copilot and Ogma for Haskell.