Rendered at 12:08:51 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
WorldMaker 20 hours ago [-]
> I like how weird it is. I might use it for my site, who knows?
If there's a place to use a weird and fun language it is certainly one's own personal blog. Sounds like a great opportunity, I think you should do it.
Someone 17 hours ago [-]
> Something like this:
> : h1 ( s -- ) "<h1>" emit . "</h1>" emit ;
> "Hello, World!" h1
So, what’s the difference between . and emit? It seems both take a string and output it to the HTML of the page. If so I don’t see why that couldn’t be
where, I think, the idea is to always have the two strings consistent with each other. If so, why require the blog writer to do that conversion?
nine_k 16 hours ago [-]
There's no docs or implementation, but I'd say that `.` in Forth is a generic way to print something, and `emit` may do more work, like HTML escaping.
wizzwizz4 16 hours ago [-]
It looks like it's the opposite: `.` does HTML escaping, whereas `emit` is raw.
FarmerPotato 9 hours ago [-]
Dot is Forth convention for "print" where a single . means print integer.
.S (pronounced "dot S" or "print S") is for strings.
Both expect input from the stack.
." Begins a literal string you want printed immediately.
.S is a word that prints the stack (not destructively) pronounced "print stack"
EMIT in Forth prints one ASCII character (which byte value comes from the stack).
You are free to redefine whatever you like --it's your own language! Most of the punctuation in Forth has conventional meanings that help (a little) reading comprehension.
Forth's postfix model is genuinely underrated for DSL design
jng 20 hours ago [-]
LLM-based coding is enabling so much! The crazy weekend project now can have compilation to native code and web assembly, allow server-side or client-side rendering, manage multiple types of persistence, include adaptive compression, and do all of this without breaking a sweat.
It's scary but I love it.
moregrist 14 hours ago [-]
I didn’t see anything about LLMs here.
If you’ve never written or worked in a Forth-like language, it’s not a hard system to bootstrap up. If you’ve done it before and know assembly, you can even get something that compiles to (stack-heavy and pretty unoptimized) native code in essentially a weekend. No LLM needed.
Forth-likes are almost magical in ways that are hard to describe. You start with primitives and literally build the language out of them. The interpreter and compiler are two different modes of the same REPL loop.
It’s just a very different paradigm than most programmers know.
19 hours ago [-]
okkdev 3 hours ago [-]
Fuck LLMs. People should focus on actually learning stuff instead of destroying their brain and environment with LLMs. Especially a Forth is really doable.
embedding-shape 50 minutes ago [-]
Fuck umbrellas, people should focus on actually enjoying swimming and being at the beach, instead of destroying the environment by eventually throwing away their umbrellas.
coliveira 20 hours ago [-]
For all its worth this could just be an AI generated blog post. There is no code, no repository, no link to any use.
killerstorm 20 hours ago [-]
And yet people keep using React, relying on a fractal pattern of kludges.
PaulHoule 19 hours ago [-]
This post isn't offering anything better.
nine_k 16 hours ago [-]
React (and the unidirectional FRP approach in general) is the only known sane way to describe complex GUIs. It's the same approach that powers spreadsheet calculations.
Most websites are not complex GUIs though, and do not need React.
killerstorm 15 hours ago [-]
React is very different from dataflow computation - it rebuilds a component subtree upon a property update; it also doesn't quite understand what "property update" means because it's defined on top of JS semantics. It's a hodgepodge of leaky abstractions and outright insanity.
I've been making GUIs (among other things) for 25 years, including 12 years using React, so you don't need to tell me how amazing it is. There's nothing particularly wrong with using React for rendering (although there's a whole lot of gotchas), the real problem is when people use React hooks for business logic - that's like you decide you need to fetch something in a middle of rendering screen.
wizzwizz4 16 hours ago [-]
It's not "the only known sane way". In many cases, it's not even an appropriate approach! MVC, PAC, and self-contained widgets which make asynchronous calls to an API surface, are perfectly cromulent alternatives, each with their own strengths, but I've yet to see a situation where React was actually the best way to go.
If there's a place to use a weird and fun language it is certainly one's own personal blog. Sounds like a great opportunity, I think you should do it.
> : h1 ( s -- ) "<h1>" emit . "</h1>" emit ;
> "Hello, World!" h1
So, what’s the difference between . and emit? It seems both take a string and output it to the HTML of the page. If so I don’t see why that couldn’t be
We also have: where, I think, the idea is to always have the two strings consistent with each other. If so, why require the blog writer to do that conversion?.S (pronounced "dot S" or "print S") is for strings.
Both expect input from the stack.
." Begins a literal string you want printed immediately.
.S is a word that prints the stack (not destructively) pronounced "print stack"
EMIT in Forth prints one ASCII character (which byte value comes from the stack).
You are free to redefine whatever you like --it's your own language! Most of the punctuation in Forth has conventional meanings that help (a little) reading comprehension.
DECIMAL
: STAR 42 EMIT ;
: STARS ( n -- )
Type5 STARS
***** ok
It's scary but I love it.
If you’ve never written or worked in a Forth-like language, it’s not a hard system to bootstrap up. If you’ve done it before and know assembly, you can even get something that compiles to (stack-heavy and pretty unoptimized) native code in essentially a weekend. No LLM needed.
Forth-likes are almost magical in ways that are hard to describe. You start with primitives and literally build the language out of them. The interpreter and compiler are two different modes of the same REPL loop.
It’s just a very different paradigm than most programmers know.
Most websites are not complex GUIs though, and do not need React.
I've been making GUIs (among other things) for 25 years, including 12 years using React, so you don't need to tell me how amazing it is. There's nothing particularly wrong with using React for rendering (although there's a whole lot of gotchas), the real problem is when people use React hooks for business logic - that's like you decide you need to fetch something in a middle of rendering screen.