Re: Forth Frustrations

John Doty wrote:
But that's not the issue. The issue is that I can tell users that *all* words consume zero or more items on the stack and return zero or more items. Once they understand that rule, they then know what to expect of all other words. There are zero exceptions to complicate the discussion.

But that describes the *implementation* not the *language*.

No, it clearly describes the language and says little if anything about the underlying implementation. The language offers words that only ever consume and leave items on the stack. That is a point of both linguistic and conceptual simplicity that has a direct impact on learning and using the language.

It's also not an issue that your users or Forth users "have trouble" understanding how Forth or LSE64 works. There are lots of computer languages which have insane syntax that programmers have learned to internalize. The question is conceptual simplicity. Syntax is just a way to encode intent.

Absolutely. But the *intent* relates to the *application*, not to the programming system. That's the trouble with so many Forth dialects: they demand attention to their internal machinery rather than the application, at least until you have the application abstractions defined.

I'm not sure how (or if) this relates to my description of Tester. Tester is very driven by the needs of the application.

It's the underlying intent of the programmer that matters more than syntax, and by eliminating concepts that get in the way of that intent, I end up with a simpler language.

A worthy goal, but I'm not sure you're there.

By what metric are you judging that?

Tester doesn't need immediate words and certainly doesn't need "sooner" words. I spend zero time explaining the concept because it doesn't enter into the language. You spend non-zero time.

No, it's zero time unless somebody's interested in the implementation.

Nope, even there it's zero time. Just as the Tester language doesn't have words that read forward in the input buffer, the underlying primitives don't do it either. The language is consistent at all levels-- syntax, implementation, and conceptual model.

You're assuming that you have to explain the implementation to everyone, but most users don't care and don't need to care. Those who do can read the code, just like I did with Goeke's original implementation.

I'm not sure why you keep going back to the implementation. The implementation doesn't matter. Nobody who uses Tester cares about the implementation.

So which is it? Am I not explaining Tester well, or are you just going with your standard set of assumptions and ignoring what I'm writing.

But I've explained that the trouble is that you need multiple implementations for pretty much everything. You don't disagree, yet somehow that's still practical to you. It doesn't seem so to me. That has little to do with experience.

I don't remember saying I agreed that there would be a need for "multiple implementations." You were also conversing with a couple other people, maybe they agreed to that, but I don't.

The model I would use to implement LSE64 in Standard Forth is to construct a thin portability layer. All code above that layer (and that would be nearly all the code) would be independent.

> But try just doing LSE64's "swap" in Standard Forth, you'll see.

That's just it-- I wouldn't. I would first create a thin portability layer and express the swap in terms of that layer, not the raw Forth. What that portability layer looks like depends on your goals for size, speed, and other factors.


.

Relevant Pages

  • Re: Forth Frustrations
    ... *all* words consume zero or more items on the stack and return zero or more items. ... it clearly describes the language and says little if anything about the underlying implementation. ... The language offers words that only ever consume and leave items on the stack. ... The model I would use to implement LSE64 in Standard Forth is to construct a thin portability layer. ...
    (comp.lang.forth)
  • Re: May the Fourth be with you
    ... Pick zero ... I'm an above-average programmer, but hardly unique. ... Employers are looking for someone younger. ... programming language. ...
    (rec.arts.sf.fandom)
  • Re: Setting based 1 Arrays
    ... However after the inconsistancies of vb6 I'm quite happy to have everything in zero based if it's consistant. ... For BASIC-like language, in principal these are based 1 indexing. ... VB.net developers might accept 1 based arrays but C# developers will be anything from annoyed to outraged. ... I am 100% sure that he will want to re-use some of the WCC code in his VB.NET code. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Forth Frustrations
    ... implementation simplicity is paramount because the code has to be as ... viewpoint there is no "input buffer": there is only language. ... words consume zero or more items on the stack and return zero or more ... way to encode intent. ...
    (comp.lang.forth)
  • Re: sumproduct not working
    ... Could I add a rider to limit the row length to only completed rows ... "Tester" wrote: ... but it returns zero value and i'm guessing its the OR function, ...
    (microsoft.public.excel.worksheet.functions)
Loading