Live data from Hacker News

Forth: The programming language that writes itself

ratfactor.com

131–140 of 174 posts

Re: Forth: The programming language that writes itself

#131
post #36

I used to be a fan of these languages like Lisp and Forth and Joy (and Factor and Haskell), but then I found that what I a really long for is just (untyped) lambda calculus (as a universal language). (Combinatory logic is just a similar representation of lambda calculus, but the differences go away quickly once you start abstracting stuff.) I think expressing semantics of all (common) programming languages in lambda…

It's a real cool idea to compile everything down to lambda calculus and then you solve all semantics issues. (If something fits) you can convert 1:1, use general libraries in one language in others without loss etc. Ah, what a beautiful world it could be!

Re: Forth: The programming language that writes itself

#132
post #73

Earlier quoted context omitted.

> And we should aim for that, the babel tower of languages doesn't really help anyone. What exactly do you mean with this? That the amount of programming languages available isn't actually helpful, it's detrimental?

Well, I feel that lot of code is written again and again, just in different languages. If we could automatically compare and translate different implementations, I think it would be beneficial for finding bugs. Everytime somebody comes up with a new programming language, I am like, yeah, so you added these abstraction, just in a different syntax. I think people who come up with new languages should implement the prim…

Racket is at least related to the kind of metalanguage system you're talking about. I've never actually done it, but to implement a new "#lang" in Racket, your job is essentially to write a "reader" for it that transliterates it to the classic Schemey Racket language. Libraries written in one #lang can then be called from one another (or not, if that's what you want -- a lot of the point of this in Racket is building little restricted teaching languages that have limited capabilities).

Re: Forth: The programming language that writes itself

#133
post #123
post #18

Earlier quoted context omitted.

I think those other languages have real advantages you aren't seeing. —·— The other day akkartik wrote an implementation of the program Knuth used to introduce literate programming to the CACM readers: https://basiclang.solarpunk.au/d/7-don-knuths-original-liter... It just tells you the top N words by frequency in its input (default N=100) with words of the same frequency ordered alphabetically and all words converte…

> And it doesn't really want to talk to the rest of the world—you can forget about calling a Squeak method from the Unix command line. You seem absolutely certain! Here's an example of a Pharo Smalltalk program call on the Ubuntu command line, with the calculation result written to stdout -- /opt/src/pharo-vm-Linux-x86_64-stable/pharo --headless nbody.pharo_run.image Include/pharo/main.st 50000000 -0.169075164 -0.169…

Thanks! I'll take a look.

Re: Forth: The programming language that writes itself

#134
In early 80s when I was a wee nerd in college a gentleman named Ray who owned Laboratory Microsystems was nice enough to give a poor college kid a copy of his excellent Forth implementation for the then-nascent IBM PC.

I breadboarded a little EPROM programmer (driven by a parallel printer port with the programming code done in Forth because I couldn't afford a real one). Then breadboarded implemented a little Z80 system with a bunch of general purpose I/O and a Forth "OS" in EPROM.

Used that little setup as the basis for a number of projects, including a home alarm system with phone-based control plus voice synthesis phone-based alert calling (which a couple silicon valley VCs were gracious enough to take a meeting about).

Forth gave me wings. Despite it's reputation as a "write-only language". Good times.

Re: Forth: The programming language that writes itself

#135
post #130
post #8

This is, I think, the best overview of Forth, and computing as a whole, that I've ever seen.

Big compliment, coming from you. (I wish you would write again. I have immensely enjoyed the stuff on your website)

Thanks! You might want to git clone http://canonical.org/~kragen/sw/pavnotes2.git/.

Re: Forth: The programming language that writes itself

#136
post #36

I used to be a fan of these languages like Lisp and Forth and Joy (and Factor and Haskell), but then I found that what I a really long for is just (untyped) lambda calculus (as a universal language). (Combinatory logic is just a similar representation of lambda calculus, but the differences go away quickly once you start abstracting stuff.) I think expressing semantics of all (common) programming languages in lambda…

Grounding programming languages in mathematics like this is essentially the goal of Strachey and Scott's denotational semantics, which has been very influential in programming language theory: https://en.wikipedia.org/wiki/Denotational_semantics

Not really a big fan, because the formalization of DS always left something desired, but I think a big difference with formalization in ULC is that ULC is (mostly) materialist while DS is structuralist.

So the initial formalization into ULC can be automated - if you have semantics of your language already implemented as an interpreter in another language, you can use this as a starting point.

With DS - I am not sure. I feel most people who build new languages don't provide DS specification.

Re: Forth: The programming language that writes itself

#137
Like many here, the annual "language" issue of Byte Magazine in 1980 introduced me to Forth. Although I was enrolled as an engineer in college, I was a frustrated (mediocre) programmer but my upstate NY institute did not offer a Comp Sci degree at that time. Forth was a gateway drug for me and demystified the concept of compiling for me. Prior to Forth, when a thousand Freshman engineers were writing their Fortran IV projects for an 8am class the next morning on mainframe 3270 terminals, we imagined that the operators must have to continuously pour water on the compiler to keep it cool. Yeah, it was 1980 and computers were still a little magic.

But Forth and threaded code was a life changer; it explained so much! My 3rd year, I partially implemented a 32-bit Forth in IBM S360 Assembler but getting I/O to work was my downfall (mostly due to my poor skills and lack of experience.) But the threaded interpreter and the basic stack ops all worked. But then I was introduced to Lisp...

But my love of Forth never left me. I make my living with C in the early days, but predominantly SQL and Bash these days. When I had my second (third?) midlife crisis, I got two tattoos on my arm: one is the Y Combinator in Lisp (I 'lost' a trailing parenthesis due to a cut-n-paste error in the template given to the tattoo artist, so I had to go back and get another tattoo with an error message pointing out the missing parenthesis.), the second tattoo is the implementation of an ANSI Forth word:

    : ? @ . ;
The fact that I could write an entire function with only punctuation characters was mind-blowing and reminds me to approach problems in unique ways. The tattoos are also great ways to start up conversations in bars...

Re: Forth: The programming language that writes itself

#138
"There is absolutely no reason we have to use increasingly inefficient and poorly-constructed software with steeper and steeper hardware requirements in the decades to come."

The term "we" as used here hopefully means individual, free-thinking computer users, not so-called "tech" companies

If Silicon Valley companies want to use increasingly-inefficient, poorly-constructed, resource-insatiable software, then nothing stops them from doing do

"Forth is not easy. It may not always even be pleasant. But it is certainly simple."

Complex isn't easy, either

That is why (a) "insecurity", unreliability, expense, etc. and (b) complexity generally go hand-in-hand

Re: Forth: The programming language that writes itself

#139

Stepping away from Forth in particular, one of the benefits of a stack-based / concatenative language is that it's easy to implement on constrained hardware. uxn [1] is a great example of that. And shameless self-promotion, if you're interested in how these kinds of languages compare with more traditional named-based languages, with more theoretical constructs like the lambda calculus and combinatory logic, and with…

TL;DR: I'm trying to Forth a Lisp.

This is long winded, but maybe you have some thoughts here.

I've been building a DOM-builder API recently in Rust. The existing options (there are many) tend to use textual templating, which can't reason well about anything, or basic macros, which never support indentation. I wanted something that was just code, where I'd be in full control on the indentation (or lack thereof) programmatically. The closest equivalent is Python's Dominate [1], though its indentation mechanisms are buggy.

So I built a system using the traditional tree where Nodes own other Nodes at random addresses, and I built a renderer that renders those nodes and concatenates their strings recursively. It ended up working but it was hacky and very slow for the large inputs. In release mode, it was taking almost a minute to render 70 files, and I want about two orders of magnitude lower.

I ran it through profilers and optimized it a bit, but wanted to see if I could simplify the architecture and reduce the amount of work the computer could do. I read about flattening ASTs [2] and how through optimizing that format, you can end up with a sort of bytecode [3]. I also looked into Data-Oriented Design, watching Mike Acton's famous talk [4], Andrew Kelley's talk about DoD in Zig [5], and reading through the DoD book by Richard Fabian [6].

I ended up with something that works quite well for traversing and rendering, which is a stack that can be traversed and rendered in O(n), but I lost my nice Dominate-like API. As in, I can build these beautiful, flat trees, but to embed those trees in my code, I need to either materialize a tree in the traditional style first and then push it onto these stacks, or do some sort of macro magic to make these stack pushes.

I wonder if this is a common issue with stack-based programming. It is, in my case, quite simple for the computer, but hard to fit into an API without building up the stack manually!

---

1. https://pypi.org/project/dominate/

2. https://www.cs.cornell.edu/~asampson/blog/flattening.html

3. https://old.reddit.com/r/ProgrammingLanguages/comments/mrifd...

4. [Mike Acton] https://www.youtube.com/watch?v=rX0ItVEVjHc

5. [Zig] https://www.youtube.com/watch?v=IroPQ150F6c

6. https://www.dataorienteddesign.com/dodbook.pdf

Re: Forth: The programming language that writes itself

#140
post #133
post #123

Earlier quoted context omitted.

> And it doesn't really want to talk to the rest of the world—you can forget about calling a Squeak method from the Unix command line. You seem absolutely certain! Here's an example of a Pharo Smalltalk program call on the Ubuntu command line, with the calculation result written to stdout -- /opt/src/pharo-vm-Linux-x86_64-stable/pharo --headless nbody.pharo_run.image Include/pharo/main.st 50000000 -0.169075164 -0.169…

Thanks! I'll take a look.

If you have questions, I'll try to answer.
Post reply on HN