4 ms·

If you wonder: How does it write itself? Isn’t it just the ability to write functions? In a way, yes, but it's a bit more than that. Many programming languages

If you wonder: How does it write itself? Isn’t it just the ability to write functions? In a way, yes, but it's a bit more than that. Many programming languages allow you to define functions or methods, but Forth takes this concept further by allowing you to define new "words" that can become part of the language itself. These words can be used just like built-in operations, and they can even change the way the language behaves. Also, because Forth is an extensible language, you can create words that define new control structures or modify the language's syntax. This is a level of flexibility that's not commonly found in other languages. In this sense, Forth can be seen as a language that "writes itself" because it allows programmers to customize and extend the language in a very fundamental way. The ability to extend Forth by defining new words is somewhat similar to the macro system in Lisp. Both provide a way to extend the language and customize it to suit your needs. In Lisp, macros allow you to define new syntactic constructs in the language. They work by transforming your program at compile-time, essentially letting you create your own domain-specific language within Lisp. This is a powerful feature that makes Lisp highly flexible and adaptable. Similarly, in Forth, you can define new words that become part of the language and can be used just like built-in words. This allows you to extend the language's syntax and functionality, making Forth highly extensible and customizable.

AnimalMuppet 3y ago
Neat, I suppose, but... In nearly 40 years as a professional programmer, the problem has never been the syntax. It's always the semantics. (I mean, yes, if you're doing something like matrix multiplication it's nicer to be able to say A = B + C * D; rather than having to explicitly spell out which functions you're calling. I have never actually hit that situation, though.) Do I just lack imagination? Is this domain-specific, and I've just never been in the domain where it was useful? Is Forth so crippled in syntax that you need to be able to extend it to make it something more useful? Do people just want to be able to customize their language, the way some people do their cars? Why do people really care about this?
- t-3 3y ago
  A lot of the focus on simplicity is about ease of implementation. A compiler/interpreter for a language without syntax (Forth) is much faster/easier/simpler to write than one with syntax. Originally Forth was an OS as much as a programming language, and the strength of the concatenative paradigm for command languages can be seen in the enduring popularity of pipes in *nix shell. The syntax is not considered a problem because it will be invented as you go along and write the words that implement your application.
- whartung 3y ago
  Because most semantics manifest through syntax. Syntax is how the programmer communicates their intent and gets access to the semantics of the underlying system. A contrived case is the construction and use of lists built of CONS cells in lisp style languages. You can certainly do this in most any language, but creating CONS cells readily without something like an S-expression would be tedious and awkward indeed, to the point that folks would drift to something else more naturally represented in their language than something based on CONS cells.
- syntheweave 3y ago
  What makes computer languages odd is in having syntax persistently be "born" in tandem with a desire for a certain semantics, and the two being hard to separate upon close inspection. You have to know the domain and have the experience to see when and where it occurs, but a need for additional syntax always appears beyond a certain point. The reason why this is the case is because the computer's ultimate use lies in automation of some task: to automate you have to define the problem domain, and to define the problem domain you have to configure something, and as you expand the amount of configuration taking place from a single-use app like your usual batch-processing shell script towards a more bespoken front-end for a certain kind of task, you end up with valid and invalid ways of configuration. If you define an input mechanism that automates a configuration with "good defaults and helpful rules", you haven't concretely changed the underlying semantics - and this sort of thing is in the realm of what a linter does - but you have changed the syntax by which the problem is approached, and pushed the train of thought onto a certain rail. And most of the time we ultimately aim to shove that concern into a graphical front-end, a form of syntax that is easy to browse through and discover your configuration options with, and enables some unique semantics with data visualization and inputs. But it's a layered process with multiple entry points - sometimes you change a configuration not by clicking around, but by editing a text file, and sometimes you change it by writing a different program. You also rely on having an operating system, files, sockets, etc. The concepts are made within an ecosystem of software and dependencies are assumed. And this is a predictable outcome of Algol. In Algol-derived languages you have one, general-purpose syntax(and maybe an extra one, like the C preprocessor), and it does a bunch of things that are hard to enforce just with programmer discipline, so it gives you your structured loops and function calls and class methods and such. And you get access to libraries and those all expose the same kind of syntax with new vocabulary. But then when you have to extend an Algol, you often end up in a place where you have enough configuration taking place to want it to be parsed in some degree. Maybe you decide you will generate code during the build process, or you have a little interpreter that enforces business rules, or something of that sort. You access it by calling a function, but that doesn't describe how you talk to it. You've started using a different protocol, all of the sudden, and your language tools correspondingly change. The boundaries are pretty hard. And the way in which both Lisps and Forths differ from the Algol approach is in making it really easy to grab the metaprogramming you want, when you need it, so if you need a little compiler for a thing, the barrier to it is a modest "set a toggle so the logic occurs when compiling this other function, instead of at runtime". This is a thing that newer Algol-likes have chipped away at, but in general the priority is "common things are easy, hard things are possible", vs "you have the expressive power to design ideal solutions". Forth's approach is more low-level than Lisp in that what it gives you to start with is almost nothing except the raw tools to define that syntax in a dictionary, enter the compilation mode, access memory and manipulate some bits. No safety or anything - you build that yourself when and where you want it. It's a useful "bring-up" language for new hardware because it's very permissive in that sense: you have a REPL available from the get-go and it can let you start banging bits. But it lacks the kind of standardization and collaboration that would result in an ecosystem like a C or Java, and that's also by definition: Forth has the expressive power to monopolize the entire path between the final application and the hardware, and if you aim to make it exist in a standardized context like a "web app" or a "Windows app", it suddenly does little of interest - that means you are defining the problem in web terms or Windows terms, and not as a mapping of hardware to solution. It's a very isolated way of working on software, and a "software company" is nearly allergic to it, since the human factors dictate that the software should be collaborative and often hegemonic.

AnimalMuppet 3y ago

Neat, I suppose, but... In nearly 40 years as a professional programmer, the problem has never been the syntax. It's always the semantics. (I mean, yes, if you're doing something like matrix multiplication it's nicer to be able to say A = B + C * D; rather than having to explicitly spell out which functions you're calling. I have never actually hit that situation, though.) Do I just lack imagination? Is this domain-specific, and I've just never been in the domain where it was useful? Is Forth so crippled in syntax that you need to be able to extend it to make it something more useful? Do people just want to be able to customize their language, the way some people do their cars? Why do people really care about this?

t-3 3y ago
A lot of the focus on simplicity is about ease of implementation. A compiler/interpreter for a language without syntax (Forth) is much faster/easier/simpler to write than one with syntax. Originally Forth was an OS as much as a programming language, and the strength of the concatenative paradigm for command languages can be seen in the enduring popularity of pipes in *nix shell. The syntax is not considered a problem because it will be invented as you go along and write the words that implement your application.
whartung 3y ago
Because most semantics manifest through syntax. Syntax is how the programmer communicates their intent and gets access to the semantics of the underlying system. A contrived case is the construction and use of lists built of CONS cells in lisp style languages. You can certainly do this in most any language, but creating CONS cells readily without something like an S-expression would be tedious and awkward indeed, to the point that folks would drift to something else more naturally represented in their language than something based on CONS cells.
syntheweave 3y ago
What makes computer languages odd is in having syntax persistently be "born" in tandem with a desire for a certain semantics, and the two being hard to separate upon close inspection. You have to know the domain and have the experience to see when and where it occurs, but a need for additional syntax always appears beyond a certain point. The reason why this is the case is because the computer's ultimate use lies in automation of some task: to automate you have to define the problem domain, and to define the problem domain you have to configure something, and as you expand the amount of configuration taking place from a single-use app like your usual batch-processing shell script towards a more bespoken front-end for a certain kind of task, you end up with valid and invalid ways of configuration. If you define an input mechanism that automates a configuration with "good defaults and helpful rules", you haven't concretely changed the underlying semantics - and this sort of thing is in the realm of what a linter does - but you have changed the syntax by which the problem is approached, and pushed the train of thought onto a certain rail. And most of the time we ultimately aim to shove that concern into a graphical front-end, a form of syntax that is easy to browse through and discover your configuration options with, and enables some unique semantics with data visualization and inputs. But it's a layered process with multiple entry points - sometimes you change a configuration not by clicking around, but by editing a text file, and sometimes you change it by writing a different program. You also rely on having an operating system, files, sockets, etc. The concepts are made within an ecosystem of software and dependencies are assumed. And this is a predictable outcome of Algol. In Algol-derived languages you have one, general-purpose syntax(and maybe an extra one, like the C preprocessor), and it does a bunch of things that are hard to enforce just with programmer discipline, so it gives you your structured loops and function calls and class methods and such. And you get access to libraries and those all expose the same kind of syntax with new vocabulary. But then when you have to extend an Algol, you often end up in a place where you have enough configuration taking place to want it to be parsed in some degree. Maybe you decide you will generate code during the build process, or you have a little interpreter that enforces business rules, or something of that sort. You access it by calling a function, but that doesn't describe how you talk to it. You've started using a different protocol, all of the sudden, and your language tools correspondingly change. The boundaries are pretty hard. And the way in which both Lisps and Forths differ from the Algol approach is in making it really easy to grab the metaprogramming you want, when you need it, so if you need a little compiler for a thing, the barrier to it is a modest "set a toggle so the logic occurs when compiling this other function, instead of at runtime". This is a thing that newer Algol-likes have chipped away at, but in general the priority is "common things are easy, hard things are possible", vs "you have the expressive power to design ideal solutions". Forth's approach is more low-level than Lisp in that what it gives you to start with is almost nothing except the raw tools to define that syntax in a dictionary, enter the compilation mode, access memory and manipulate some bits. No safety or anything - you build that yourself when and where you want it. It's a useful "bring-up" language for new hardware because it's very permissive in that sense: you have a REPL available from the get-go and it can let you start banging bits. But it lacks the kind of standardization and collaboration that would result in an ecosystem like a C or Java, and that's also by definition: Forth has the expressive power to monopolize the entire path between the final application and the hardware, and if you aim to make it exist in a standardized context like a "web app" or a "Windows app", it suddenly does little of interest - that means you are defining the problem in web terms or Windows terms, and not as a mapping of hardware to solution. It's a very isolated way of working on software, and a "software company" is nearly allergic to it, since the human factors dictate that the software should be collaborative and often hegemonic.