5 ms·

This [] pair for quotations is pretty common in "modern" concatenative languages. But you actually don't need them that much, at least in Forth. It is not a sol

This [] pair for quotations is pretty common in "modern" concatenative languages. But you actually don't need them that much, at least in Forth. It is not a solution because they have misidentified the problem (due to lack of experience, generally), or created a problem ex nihilo by trying to one-up Forth on RPN purity and do control-flow like Smalltalk does. a priori "must haves" that eventually get in your way. If I had to choose one quote from Chuck Moore (the creator of Forth), it would be "Don't anticipate, solve the problem you've got" [1]. What you need on a daily basis it to be able to reuse names so that you don't clutter your dictionary. But at the same time you do want your Forth to warn you when you define twice the same name, because that could lead to vicious bugs. So all you need to do is to hack your Forth so that e.g. names starting with underscores can be redefined and won't trigger a warning. [1] https://www.ultratechnology.com/1xforth.htm https://www.ultratechnology.com/1xforth.htm

James_K 3y ago
I wouldn't call people stupid just because they made a design decision you disagree with. In my view, it is a bad choice to add additional complexity to the language like compiled "if" when you can do something more simple and in-keeping with its other features. The problem isn't invented; they needed to implement conditionals, had two options for doing so, and they chose the simpler one. Do you have any concrete way that the Forth implementation with compile-only words is better? What are its benefits? > What you need on a daily basis it to be able to reuse names so that you don't clutter your dictionary. But at the same time you do want your Forth to warn you when you define twice the same name, because that could lead to vicious bugs. So all you need to do is to hack your Forth so that e.g. names starting with underscores can be redefined and won't trigger a warning. The problem is already solved. You just spit out a warning message when something is redefined instead of an error.
- astrobe_ 3y ago
  > I wouldn't call people stupid I don't think I did such a thing. > Do you have any concrete [proof] that the Forth implementation with compile-only words is better? What are its benefits? Yes I do : a Smalltalk-style forces to have the code (to be executed if the condition is true) to be on the left side of the if. Additionally, if you don't want the address of the quotation to be in your way, you are also forced to adopt an argument order like condition-quotation-if, which is even less convenient than Forth's syntax. Oh, and the else part could be a lot of fun too. Most likely, you'll add some sort of exception to avoid all that, but exceptions are the archetype of unwanted complexity. You seem to think that Smalltalk-style is simpler, but Smalltalk is an infix language with, granted, rules that are simpler than most other languages - but still more complex than those of Forth. So it is not, actually, simpler when you consider the system as a whole. Also, it makes it more difficult to build loops from that if and recursion like Scheme does (TCO). Chuck Moore's Colorforth does exactly that. Moreover, and perhaps more anecdotally because few people care about this these days, it is more space and CPU efficient - basically the traditional Forth if is one instruction (bytecode or whatever) followed by one parameter (the jump target) that takes one argument on the stack. A Smalltalk-style if is also one instruction, but it has to call the "if-true" code, and this code has to have a return instruction as well. I can understand that people don't care about a few more bytes and cycles here and there - what's the point for a interpreter to be able to run on a bunch of kilobytes today? - but I wonder why those same people would care about a weird RPN thing that seems to be designed to make their head hurt, with or without quotations. It's only slightly less hostile for them than BrainFuck. Computer games and computer languages have something in common: when you design and redesign them, you realize that they are a subtle network of interactions between different parts of the system - even if, in the case of programming languages you look for "orthogonality", which is the opposite; but this concept applies more to features/semantics than to syntax/ergonomics. > The problem is already solved. You just spit out a warning message when something is redefined instead of an error. You didn't get what I wrote. You want the system to keep quiet when you give an hint that you do something on purpose, like casting explicitly an integer into a pointer in C. You also miss the point: of course this problem is easily solved. But I argue like Chuck Moore that you'd rather solve the specific problem you stumble upon in practice, rather than trying to solve the more general problem that you imagine you will have. Sometimes when you try to kill two birds with one stone, you end up with one bird wounded and a broken window.
  - James_K 3y ago
    > I don't think I did such a thing. Yes, you were more subtle about it, calling him inexperienced rather than stupid. I see little difference between the two forms of ad hominem and that is what I wanted to point out. > which is even less convenient than Forth's syntax The two versions are syntactically the same. You can take a piece of Forth code and do the substitution: s/if/[/ s/else/] [/ s/then/] if/ You then have some Stem code that is slightly shorter. The Stem syntax is just a generalised version of the Forth syntax. The only exception I can think of is it being harder to compile, but as you said, that tiny bit of speed doesn't really matter on modern systems and additionally the code would likely be optimised to the same instructions in a JIT. > You want the system to keep quiet when you give an hint that you do something on purpose Why? No code that's saved in production should ever redefine variables, so it's a warning you'd get exclusively during interactive use at the REPL, where you'd be free to ignore it. It's easier to ignore a message than it is to tell the system not to give you that message.
    - ret2pop 3y ago
      To be fair, I am inexperienced. I haven't done much programming in stack based languages and I don't often like to pull the age card but in my defense I have not lived as long as some other people on here as I just turned 18 and have not been programming for that long. Still, it's really cool that some people like my language, and it doesn't really bother me that some people think it's worse -- I just wrote it because I thought it was interesting.
      - incanus77 3y ago
        > Still, it's really cool that some people like my language, and it doesn't really bother me that some people think it's worse -- I just wrote it because I thought it was interesting. Stick with this attitude and you'll go far.
      - astrobe_ 3y ago
        Sorry about that, I usually try to refrain from making negative comments on HN. I was sort of mislead by your comment in the thread that you did not make this (didn't get the joke), and thought that the author was unlikely to read that. Don't take it personally, as I was actually pointing what I think is a common mistake. I did a lot of mistakes in this domain, so I'm trying to share my experience here more than gratuitously criticizing a project.
ColonelPhantom 3y ago
I read the linked article, and found it rather confusing. For example, what does "In order to write a lot of small definitions you have to have a stack" mean? e.g. in Haskell lots of functions are very small compositions of existing functions, like "foo = filter bar . map baz". But it's definitely not stack based! I'm also confused about the "local variables are harmful" mentality. Why? They may not suit concatenative languages, but I find naming things serves as effective 'documentation'. Or is the point that these should be put in separate functions? But that also sounds wrong, because then you greatly complicate the control flow and spread everything to many places. Furthermore, isn't something like that A register 'just' a local variable (or worse: a mutable global variable)? I find the dismissal of things like files and encryption disturbing. Many programs need some form of persistence. How is that useless? Why does 'needed data' not need to be encrypted?!?

James_K 3y ago

I wouldn't call people stupid just because they made a design decision you disagree with. In my view, it is a bad choice to add additional complexity to the language like compiled "if" when you can do something more simple and in-keeping with its other features. The problem isn't invented; they needed to implement conditionals, had two options for doing so, and they chose the simpler one. Do you have any concrete way that the Forth implementation with compile-only words is better? What are its benefits? > What you need on a daily basis it to be able to reuse names so that you don't clutter your dictionary. But at the same time you do want your Forth to warn you when you define twice the same name, because that could lead to vicious bugs. So all you need to do is to hack your Forth so that e.g. names starting with underscores can be redefined and won't trigger a warning. The problem is already solved. You just spit out a warning message when something is redefined instead of an error.

astrobe_ 3y ago
> I wouldn't call people stupid I don't think I did such a thing. > Do you have any concrete [proof] that the Forth implementation with compile-only words is better? What are its benefits? Yes I do : a Smalltalk-style forces to have the code (to be executed if the condition is true) to be on the left side of the if. Additionally, if you don't want the address of the quotation to be in your way, you are also forced to adopt an argument order like condition-quotation-if, which is even less convenient than Forth's syntax. Oh, and the else part could be a lot of fun too. Most likely, you'll add some sort of exception to avoid all that, but exceptions are the archetype of unwanted complexity. You seem to think that Smalltalk-style is simpler, but Smalltalk is an infix language with, granted, rules that are simpler than most other languages - but still more complex than those of Forth. So it is not, actually, simpler when you consider the system as a whole. Also, it makes it more difficult to build loops from that if and recursion like Scheme does (TCO). Chuck Moore's Colorforth does exactly that. Moreover, and perhaps more anecdotally because few people care about this these days, it is more space and CPU efficient - basically the traditional Forth if is one instruction (bytecode or whatever) followed by one parameter (the jump target) that takes one argument on the stack. A Smalltalk-style if is also one instruction, but it has to call the "if-true" code, and this code has to have a return instruction as well. I can understand that people don't care about a few more bytes and cycles here and there - what's the point for a interpreter to be able to run on a bunch of kilobytes today? - but I wonder why those same people would care about a weird RPN thing that seems to be designed to make their head hurt, with or without quotations. It's only slightly less hostile for them than BrainFuck. Computer games and computer languages have something in common: when you design and redesign them, you realize that they are a subtle network of interactions between different parts of the system - even if, in the case of programming languages you look for "orthogonality", which is the opposite; but this concept applies more to features/semantics than to syntax/ergonomics. > The problem is already solved. You just spit out a warning message when something is redefined instead of an error. You didn't get what I wrote. You want the system to keep quiet when you give an hint that you do something on purpose, like casting explicitly an integer into a pointer in C. You also miss the point: of course this problem is easily solved. But I argue like Chuck Moore that you'd rather solve the specific problem you stumble upon in practice, rather than trying to solve the more general problem that you imagine you will have. Sometimes when you try to kill two birds with one stone, you end up with one bird wounded and a broken window.
- James_K 3y ago
  > I don't think I did such a thing. Yes, you were more subtle about it, calling him inexperienced rather than stupid. I see little difference between the two forms of ad hominem and that is what I wanted to point out. > which is even less convenient than Forth's syntax The two versions are syntactically the same. You can take a piece of Forth code and do the substitution: s/if/[/ s/else/] [/ s/then/] if/ You then have some Stem code that is slightly shorter. The Stem syntax is just a generalised version of the Forth syntax. The only exception I can think of is it being harder to compile, but as you said, that tiny bit of speed doesn't really matter on modern systems and additionally the code would likely be optimised to the same instructions in a JIT. > You want the system to keep quiet when you give an hint that you do something on purpose Why? No code that's saved in production should ever redefine variables, so it's a warning you'd get exclusively during interactive use at the REPL, where you'd be free to ignore it. It's easier to ignore a message than it is to tell the system not to give you that message.
  - ret2pop 3y ago
    To be fair, I am inexperienced. I haven't done much programming in stack based languages and I don't often like to pull the age card but in my defense I have not lived as long as some other people on here as I just turned 18 and have not been programming for that long. Still, it's really cool that some people like my language, and it doesn't really bother me that some people think it's worse -- I just wrote it because I thought it was interesting.
    - incanus77 3y ago
      > Still, it's really cool that some people like my language, and it doesn't really bother me that some people think it's worse -- I just wrote it because I thought it was interesting. Stick with this attitude and you'll go far.
    - astrobe_ 3y ago
      Sorry about that, I usually try to refrain from making negative comments on HN. I was sort of mislead by your comment in the thread that you did not make this (didn't get the joke), and thought that the author was unlikely to read that. Don't take it personally, as I was actually pointing what I think is a common mistake. I did a lot of mistakes in this domain, so I'm trying to share my experience here more than gratuitously criticizing a project.

ColonelPhantom 3y ago

I read the linked article, and found it rather confusing. For example, what does "In order to write a lot of small definitions you have to have a stack" mean? e.g. in Haskell lots of functions are very small compositions of existing functions, like "foo = filter bar . map baz". But it's definitely not stack based! I'm also confused about the "local variables are harmful" mentality. Why? They may not suit concatenative languages, but I find naming things serves as effective 'documentation'. Or is the point that these should be put in separate functions? But that also sounds wrong, because then you greatly complicate the control flow and spread everything to many places. Furthermore, isn't something like that A register 'just' a local variable (or worse: a mutable global variable)? I find the dismissal of things like files and encryption disturbing. Many programs need some form of persistence. How is that useless? Why does 'needed data' not need to be encrypted?!?