> Okay. But Fredric Jameson establishes that in postmodernism we have experienced a weakening sense of historisity such that what is, what was, and what will be all exist as presents in time. 1970, 1991, 1992, and 2017 all happen simultaneously.
Okay with the postmodernism, but relying on a memory unsafe language to implement a server-side web framework in 1970, 1991, 1992, and 2017 is equally anachronistic. That being said much love to Forth! – Or, as the post-modern philosopher Slavoj Žižek is used to say: "and so on and so Forth".
That's the implementation thing, not the language. You can implement an ANSI Forth standard like GForth in a memory safe way without a lot of issues. Even the memory allocation words[0] are easily implemented in a garbage collected language. Of course that makes it useless for embedded purposes which is where Forth usually works well, but that's not an issue as you are not doing that here.
Half correct. It's true that you can improve the safety that way, but what proponents of memory safety consider a no-go is pointer arithmetic and crafting - basically not what C allows.
You can forbid yourself to do these things and implement a "safety layer" for string handling, array handling with bound checking etc. but at the end of the day, it's more a a cultural thing than a technical thing. IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.
Well, you see the result: smartphones that can't make emergency calls when you need it etc. But hey, it's written in a memory safe language and our bus factor is 0.00004 !
You can do fake pointer arithmetic which won't hurt this use case (server-side web framework); if you implement Gforth as an interpreter on the JVM/CLR or running it with Emscripten, there is no issue for server-side web frameworks like this while being safe.
That's been done for C a few times (this [0] and there are a few others); if you don't depend on the actual physical memory addresses you are using (which, in embedded, you often are counting on, but not in a server-side framework).
> it's more a a cultural thing than a technical thing.
I agree with that
> IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.
Oh you're the Forth expert? Well you wouldn't know if I were one or not, nor how likely. But what a little clique you make it sound like; a very exclusive club.
I'm no Forth expert, yet I know which type of company is more likely to use Forth, and also who to try to talk to in the community. For a niche language which is not taught in schools, it is unavoidable to getting to know the community because it provides part of the material you need to teach yourself the paradigm; at some point you know better places to ask this question than HN.
Still, if I'm asking and you know--why not just reply, with that information? Rather than some elitist snobbery, like "If you even ask that you wouldn't be good enough" or pretend you're somehow better or some bs that you made up. That's not very nice, not to mention not in the spirit of HN, to respond to curiosity with a low-effort, low-info response. Disappointed in you! :) but you can still do better
Is that the point...for you? If that's it for you don't pretend it's the same for me. :)
Still no answer tho? I'm starting to doubt you actually knew in the first place...That would not be the first time someone posted some arrogant bs but actually had no fucking idea what they were talking about. I literally gave you the benefit of the doubt and didn't think you were like that. Hah! Until now. Ugh...
Okay with the postmodernism, but relying on a memory unsafe language to implement a server-side web framework in 1970, 1991, 1992, and 2017 is equally anachronistic. That being said much love to Forth! – Or, as the post-modern philosopher Slavoj Žižek is used to say: "and so on and so Forth".