Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54868 > unrolled thread

Make Forth Great Again!

Back to article view | Back to comp.lang.forth

Contents

  Make Forth Great Again! djc <ciesinger@gmx.net> - 2017-02-15 13:47 -0800
    Re: Make Forth Great Again! Alex <alex@rivadpm.com> - 2017-02-15 22:34 +0000
    Re: Make Forth Great Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-02-15 13:11 -1000
      Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 10:54 -0800
        Re: Make Forth Great Again! Cecil Bayona <cbayona@cbayona.com> - 2017-02-17 13:09 -0600
          Re: Make Forth Great Again! minforth@arcor.de - 2017-02-17 13:55 -0800
            Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 16:37 -0800
      Re: Make Forth Great Again! "HAA" <someone@microsoft.com> - 2017-02-18 11:54 +1100
        Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 18:19 -0800
          Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 19:27 -0800
      Re: Make Forth Great Again! gavino himself <jackvanc3@gmail.com> - 2017-03-14 05:06 -0700
    Re: Make Forth Great Again! Julian Fondren <julian.fondren@gmail.com> - 2017-02-15 15:51 -0800
      Re: Make Forth Great Again! Paul Rubin <no.email@nospam.invalid> - 2017-02-15 15:56 -0800
        Re: Make Forth Great Again! Julian Fondren <julian.fondren@gmail.com> - 2017-02-15 16:14 -0800
          Re: Make Forth Great Again! lehs <skydda.barnen@gmail.com> - 2017-02-16 02:03 -0800
            Re: Make Forth Great Again! minforth@arcor.de - 2017-02-16 02:55 -0800
            Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 10:25 -0800
              Re: Make Forth Great Again! Cecil Bayona <cbayona@cbayona.com> - 2017-02-17 12:55 -0600
                Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 11:31 -0800
                  Re: Make Forth Great Again! hughaguilar96@gmail.com - 2017-02-17 16:32 -0800
                Re: Make Forth Great Again! rickman <gnuarm@gmail.com> - 2017-02-17 16:09 -0500
                  Re: Make Forth Great Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-17 19:39 -0500
        Re: Make Forth Great Again! minforth@arcor.de - 2017-02-16 01:00 -0800
    Re: Make Forth Great Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-16 06:21 -0600
      Re: Make Forth Great Again! john <anon@example.com> - 2017-02-16 15:45 +0000
        Re: Make Forth Great Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-16 10:12 -0600
          Re: Make Forth Great Again! Alex <alex@rivadpm.com> - 2017-02-16 16:36 +0000
            Re: Make Forth Great Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-16 12:03 -0600
              Re: Make Forth Great Again! john <anon@example.com> - 2017-02-16 23:08 +0000
              Re: Make Forth Great Again! gavino himself <jackvanc3@gmail.com> - 2017-03-14 05:08 -0700
    Re: Make Forth Great Again! Whammo <sidciavic@gmail.com> - 2017-02-16 08:14 -0800
    Re: Make Forth Great Again! Igor Maznitsa <rrg4400@gmail.com> - 2017-02-16 13:43 -0800
      Re: Make Forth Great Again! Elliott Chapin <elliott.chapin@gmail.com> - 2017-02-17 07:26 -0800
    Re: Make Forth Great Again! mentificium@gmail.com - 2017-02-16 15:22 -0800
    Re: Make Forth Great Again! Brad Eckert <hwfwguy@gmail.com> - 2017-03-03 13:31 -0800
    Re: Make Forth Great Again! Wolf Wejgaard <wejgaard@holonforth.com> - 2017-03-10 01:10 -0800
      Re: Make Forth Great Again! JUERGEN <epldfpga@aol.com> - 2017-03-10 09:33 -0800
        Re: Make Forth Great Again! Wolf Wejgaard <wejgaard@holonforth.com> - 2017-03-12 09:00 -0700
          Re: Make Forth Great Again! stephen@mpeforth.com (Stephen Pelc) - 2017-03-12 20:50 +0000
          Re: Make Forth Great Again! rickman <gnuarm@gmail.com> - 2017-03-12 19:19 -0400
      Re: Make Forth Great Again! Cecil Bayona <cbayona@cbayona.com> - 2017-03-10 13:59 -0600
        Re: Make Forth Great Again! Wolf Wejgaard <wejgaard@holonforth.com> - 2017-03-11 01:14 -0800
    Re: Make Forth Great Again! polymorph self <jackvanc3@gmail.com> - 2017-03-10 14:20 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#54942

On 2/17/2017 1:55 PM, Cecil Bayona wrote:
> On 2/17/2017 12:25 PM, hughaguilar96@gmail.com wrote:
>> On Thursday, February 16, 2017 at 3:03:47 AM UTC-7, lehs wrote:
>>> The greatness of Forth is the inherent idea and it hasn't changed. Of
>>> course it can be extended by all means, but will most probably not be
>>> the best solution to every new commercial need.
>>>
>>> If you don't like Forth, don't make it to something else! Stop using it!
>>
>> I have heard this many times before --- that the greatness of Forth is
>> that it hasn't changed since the 1970s --- well, I'm friends with a
>> guy who owns a 1967 Pontiac Le Mans that he considers to be an
>> "all-time great car" that will be worth $125,000 after he gets it
>> fixed up...
>>
>> I have also been told many times that I should stop trying to make
>> Forth something that it isn't:
>>
>> On Wednesday, February 1, 2017 at 3:31:46 PM UTC-7, Rod Pemberton wrote:
>>> On Wed, 1 Feb 2017 03:15:26 -0800 (PST)
>>> Mark Wills <markwills1970@gmail.com> wrote:
>>>
>>>> On Wednesday, 1 February 2017 00:16:13 UTC, Rod Pemberton  wrote:
>>>> <snipped>
>>>>> Who exactly will use your <SWITCH construct?
>>>>> It's non-standard and there are other constructs which are widely
>>>>> available.
>>>> <snipped>
>>>>
>>>> It's written in standard ANS Forth, so that claim is wrong.
>>>
>>> No, it's not wrong.  CASE is in the standard.  <SWITCH is not.  So,
>>> <SWITCH is non-standard.  Is it ANS Forth compliant?  Yes.
>>>
>>> Rod Pemberton
>>
>> What Rod Pemberton is saying is that Elizabeth Rather determines on a
>> case-by-case basis what code is standard --- my <SWITCH may be
>> ANS-Forth compliant, but it is not ANS-Forth standard because it
>> hasn't been approved by Elizabeth Rather (she doesn't know what a
>> jump-table is, which is why CASE became standard, and why my <SWITCH
>> will never be approved).
>>
>
> So if switch is not on the Standard but written with ANSI words then
> it's non- standard code? Then no one can't add any of their own words
> because they are not ANSI standard code.
>
> The things said here are so outrageously insane I keep wondering why I
> look at these post,  forever the optimist I keep hoping for a gem, but
> there are few here.

Maybe you should discuss things people have said with the people who 
said them rather than having discussions about what other people have 
said?  Rod is the person who made the statement and his post is here to 
reply to.  It wasn't even some years ago.

Why focus on the pointless things said here?  I know there are tons of 
things said in posts I ignore.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54951

On Fri, 17 Feb 2017 16:09:02 -0500
rickman <gnuarm@gmail.com> wrote:

> On 2/17/2017 1:55 PM, Cecil Bayona wrote:
> > On 2/17/2017 12:25 PM, hughaguilar96@gmail.com wrote:  
> >> On Thursday, February 16, 2017 at 3:03:47 AM UTC-7, lehs wrote:  
> >> On Wednesday, February 1, 2017 at 3:31:46 PM UTC-7, Rod Pemberton
> >> wrote:
> >>> On Wed, 1 Feb 2017 03:15:26 -0800 (PST)
> >>> Mark Wills <markwills1970@gmail.com> wrote:
> >>>> On Wednesday, 1 February 2017 00:16:13 UTC, Rod Pemberton  wrote:
> >>>> <snipped>

> >>>>> Who exactly will use your <SWITCH construct?
> >>>>> It's non-standard and there are other constructs which are
> >>>>> widely available.  
> >>>> <snipped>
> >>>>
> >>>> It's written in standard ANS Forth, so that claim is wrong.  
> >>>
> >>> No, it's not wrong.  CASE is in the standard.  <SWITCH is not.
> >>> So, <SWITCH is non-standard.  Is it ANS Forth compliant?  Yes.
> >>>
> >>
> >> What Rod Pemberton is saying is that Elizabeth Rather determines
> >> on a case-by-case basis what code is standard --- my <SWITCH may be
> >> ANS-Forth compliant, but it is not ANS-Forth standard because it
> >> hasn't been approved by Elizabeth Rather (she doesn't know what a
> >> jump-table is, which is why CASE became standard, and why my
> >> <SWITCH will never be approved).
> >>  
> >
> > So if switch is not on the Standard but written with ANSI words then
> > it's non- standard code? Then no one can't add any of their own
> > words because they are not ANSI standard code.
> >
> > The things said here are so outrageously insane I keep wondering
> > why I look at these post,  forever the optimist I keep hoping for a
> > gem, but there are few here.  
> 
> Maybe you should discuss things people have said with the people who 
> said them rather than having discussions about what other people have 
> said?  Rod is the person who made the statement and his post is here
> to reply to.  It wasn't even some years ago.
> 
> Why focus on the pointless things said here?  I know there are tons
> of things said in posts I ignore.
> 

Maybe you should comment on Hugh distorting what I said for his own
purposes (i.e., attacking Ms. Rather) instead of directing more people
to reply to me?  That would seem to be fair.  It's not like Hugh's
never here and unwilling to respond to or rant about anything and
everything.  He's always looking to "delegitimize" Ms. Rather.  I'm
pretty sure that after that other truly hateful guy left after spewing
out decades worth of verbal abuse, that Hugh is the only one who posts
here, who doesn't seem to like it here.  Why would someone enjoy being
in an environment they dislike?  Why would someone enjoy being among
company they dislike?  Misery loves company, I guess.  Rick, do you
like Hugh's rants?  I seem to recall you don't, in general.  So, welcome
to the misery.  AISI, *your* choices are to 1) encourage Hugh to move
on to something more positive and meaningful, perhaps leading to his
happiness (and possibly ours), or 2) deal with it and accept the
anguish (and become depressed), or 3) leave.  Why bother suffering?


Rod Pemberton
-- 
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

[toc] | [prev] | [next] | [standalone]

#54877

Am Donnerstag, 16. Februar 2017 00:56:40 UTC+1 schrieb Paul Rubin:
> Julian Fondren <julian.fondren@gmail.com> writes:
> > And in my experience as a recovered language dilettante, the easier to
> > port features are the actually better ones.
> 
> The presence of hard-to-port features is what makes languages that have
> them interesting.

Correct. One example here:
https://www.wolfram.com/language/elementary-introduction/18-geocomputation.html

In this context, questions like "isn't Forth great" are nonsensical.

So one has to define the context with the question, e.g. Forth still adequate for modern embedded systems programming?

[toc] | [prev] | [next] | [standalone]

#54881

djc <ciesinger@gmx.net> wrote:
> In the 70ies, Forth was absolute top, leading edge, lots of features and capabilities missing elsewhere, such as
> * self compiling
> * multitasking
> * interpreter AND compiler
> * vectored I/O
> * create-does to give user data types a behaviour
> * fast AND small
> * internal DSLs (domain specific languages)
> 
> Now today, other languages have taken the technical lead, Haskell,
> Ruby etc. These keep impressing people with Lambdas, Closures,
> modifiable class memberships, effective protection mechanisms etc.

Well, yes, but they tend to be rather inflexible.  I'll describe one
example that I'm familiar with from my own work.  I'm sure there are
other examples of this power and flexibility, but I can talk about
this one with confidence.

Haskell, C, and some other language implementations now have software
transactional memory.  Adding this involved a lot of work and teams of
programmers.  On the other hand I wrote a fully-functional Forth
implementation of STM in a few days; I cannot stress enough how much
simpler it is than all the other implementations I've seen.  Much of
the complexity of STM implementations is not the transaction engine
which does the work, but the difficulty of interfacing that engine
with a language and its compiler.

Doing stuff like this in Forth is easier because the implementation is
partly exposed, and because the core of the language can be redefined,
and because there's much less language there.  At the same time as
having all this power, a Forth implementation is (or can be) very
simple.

Andrew.


https://en.wikipedia.org/wiki/Software_transactional_memory
https://sourceforge.net/projects/concurrentforth

[toc] | [prev] | [next] | [standalone]

#54883

In article <qb-dnRMnV-HNBDjFnZ2dnUU7-SnNnZ2d@supernews.com>, 
andrew29@littlepinkcloud.invalid says...

It seems to me that STM is yet another lame excuse for poor design.

.
> 
> Haskell, C, and some other language implementations now have software
> transactional memory.  Adding this involved a lot of work and teams of
> programmers.  On the other hand I wrote a fully-functional Forth
> implementation of STM in a few days; I cannot stress enough how much
> simpler it is than all the other implementations I've seen.  Much of
> the complexity of STM implementations is not the transaction engine
> which does the work, but the difficulty of interfacing that engine
> with a language and its compiler.
> 
> Doing stuff like this in Forth is easier because the implementation is
> partly exposed, and because the core of the language can be redefined,
> and because there's much less language there.  At the same time as
> having all this power, a Forth implementation is (or can be) very
> simple.
> 
> Andrew.
> 
> 
> https://en.wikipedia.org/wiki/Software_transactional_memory
> https://sourceforge.net/projects/concurrentforth



-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

[toc] | [prev] | [next] | [standalone]

#54884

john <anon@example.com> wrote:

> It seems to me that STM is yet another lame excuse for poor design.

Thanks!  I was wondering what the problem was.  :-)

Andrew.

[toc] | [prev] | [next] | [standalone]

#54886

On 2/16/2017 16:12, Andrew Haley wrote:
> john <anon@example.com> wrote:
>
>> It seems to me that STM is yet another lame excuse for poor design.
>
> Thanks!  I was wondering what the problem was.  :-)
>
> Andrew.
>

Very droll.

On a serious note, has it been deployed anywhere?

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#54890

Alex <alex@rivadpm.com> wrote:
>
> Very droll.
> 
> On a serious note, has it been deployed anywhere?

Not as far as I know.  It was more of an experiment to see if I really
understood how STM works.  I'm pretty sure it's correct, but right now
it's more of a solution in search of a problem.

Andrew.

[toc] | [prev] | [next] | [standalone]

#54895

In article <24udnRfmAuAQdDjFnZ2dnUU7-cWdnZ2d@supernews.com>, 
andrew29@littlepinkcloud.invalid says...
> 
> Alex <alex@rivadpm.com> wrote:
> >
> > Very droll.
> > 
> > On a serious note, has it been deployed anywhere?
> 
> Not as far as I know.  It was more of an experiment to see if I really
> understood how STM works.  I'm pretty sure it's correct, but right now
> it's more of a solution in search of a problem.
> 
> Andrew.

andrew
As you offered a story I'll offer another...
some decades ago I was a system enginer for a mini computer manufacturer
that supplied systems to a large well known  parcel delivery company.

Due to the level of work and reliability of service required they demanded
a system bigger than we could supply (or anyone I think in their physical location) 
so we had 2 systems designed working back to back - a live one with it's big
fat disk and its big multitrack tape spool and a  copy recording everything the
front end system did such that the second could take over or swap places. 

Needless to say we spent more time and effort trying the keep the two systems
running together  than we did on 10 other systems and lost a fortune on it  not
to mention my 2 hour call outs and wasted nights and those of other engineers. 

To paraphrase my conclusions at the time - pointless complexity is a bitch.
Or to put it in a better light- do it right, first time, on time, every time.

But I applaud  your efforts to understand a new system even if I don't support
this one myself - it's  a pity more people here aren't doing the same.

Who knows - perhaps your easier to implement method could make the
entire principle functional - or at least live up to some of the hilarious
claims made in other languages.

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

[toc] | [prev] | [next] | [standalone]

#55766

On Thursday, February 16, 2017 at 1:04:03 PM UTC-5, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
> >
> > Very droll.
> > 
> > On a serious note, has it been deployed anywhere?
> 
> Not as far as I know.  It was more of an experiment to see if I really
> understood how STM works.  I'm pretty sure it's correct, but right now
> it's more of a solution in search of a problem.
> 
> Andrew.

e commerce

[toc] | [prev] | [next] | [standalone]

#54885

 I have the sneaking suspicion that FORTH is the industries best kept secret. 

[toc] | [prev] | [next] | [standalone]

#54891

to make FORTH great again is very easy, just write a great application based on FORTH and it is enough in the modern world

[toc] | [prev] | [next] | [standalone]

#54929

On Thursday, February 16, 2017 at 4:43:58 PM UTC-5, Igor Maznitsa wrote:
> to make FORTH great again is very easy, just write a great application based on FORTH and it is enough in the modern world

Is ForthCAD still alive? Is it good?

[toc] | [prev] | [next] | [standalone]

#54898

On Wednesday, February 15, 2017 at 1:47:18 PM UTC-8, djc wrote:
[...] Why not come up with something totally crazy and unseen?
[...]
[...] Daniel

http://dl.acm.org/citation.cfm?doid=307824.307853 -- Mind.Forth AI

http://robots.net/person/AI4U/diary/83.html -- latest AI design ideas.

Arthur

[toc] | [prev] | [next] | [standalone]

#55391

On Wednesday, February 15, 2017 at 2:47:18 PM UTC-7, djc wrote:
> In the 70ies, Forth was absolute top, leading edge, lots of features and capabilities missing elsewhere, such as
> * self compiling
> * multitasking
> * interpreter AND compiler
> * vectored I/O
> * create-does to give user data types a behaviour
> * fast AND small
> * internal DSLs (domain specific languages)
> 
> Now today, other languages have taken the technical lead, Haskell, Ruby etc. These keep impressing people with Lambdas, Closures, modifiable class memberships, effective protection mechanisms etc.
> 
> Ok, so back to the drawing board and bringing up crazy new capabilities which no other language can do...
> 
Bells and whistles. It's not about what's in the box, it's about what you can do. Your application domain, your toolset. How do you like the daily updates that your Eclipse C IDE vendors push on you. I'm waiting for the day one of those magical updates breaks my code. Not a problem with Forth.

The 70s did have a certain style of Forth, compilation on the target, that worked very well. What happened? Native optimizing compilers happened, hosted on a PC separate from the target MCU. Lots of complexity, for Forth anyway. Nobody's completely satisfied with the cross compiler standard.

What do you need to get back to an efficient resident Forth? Maybe not much. If your little MCU has lots of flash or you have a cheap 8-pin SPI Flash hooked up, there's your file system. Or, you can have high enough speed serial to quickly download source code from your PC.

Then there's the compiler. Yup, the clever one from MPE or somewhat less clever one from FORTH Inc. There's probably room for that, right on the MCU. But, suppose you're not very clever. You need a dumb compiler that does a good job. This is where FPGAs come in. If you use a Forth core, like the J1 or something, or a VM, the compiler doesn't have to be very smart.

I've been writing Forth cross compilers for 20 years. Now, I'm wondering what's the big deal. The reason for cross compilers is evaporating. Yeah, they're pretty cool, but at what cost? I'm running VMs on off-the-shelf CPUs these days, super simple to resident-compile for. Turns out C.H.Ting has the right idea. 

[toc] | [prev] | [next] | [standalone]

#55587

Am Mittwoch, 15. Februar 2017 22:47:18 UTC+1 schrieb djc:
> In the 70ies, Forth was absolute top, leading edge, lots of features and capabilities missing elsewhere, such as
> * self compiling
> * multitasking
> * interpreter AND compiler
> * vectored I/O
> * create-does to give user data types a behaviour
> * fast AND small
> * internal DSLs (domain specific languages)
> 
> Now today, other languages have taken the technical lead, Haskell, Ruby etc. These keep impressing people with Lambdas, Closures, modifiable class memberships, effective protection mechanisms etc.
> 
> Ok, so back to the drawing board and bringing up crazy new capabilities which no other language can do...
> 
> That is not about copy-catting features like lambdas and closures (some attempts were seen here), but bringing in novelty.
> 
> Why not have easy defining and training words for neural net elements? Why not use the multitasker for a pulsed and parallel neural net? Why not come up with something totally crazy and unseen?
> 
>    Daniel

You might enjoy a look at holonforth.com/holon86.html - Crazy and still unseen, it seems, just a great way of programming Forth since 1990. Direct action, immediate responses, clear presentation of the project source. Holon86 rips away the classical white blanket with its reassuring "ok" and shows you what lurks below: a great under-explored database known as the dictionary. You have source text browser and code directly accessible without resorting to incantations like LOCATE. And forget about files, the source is included in the DB like the code. A complete IDE. Unbelievably efficient!

HOLON86 is on Github. - You can study its source in HOST86, a Holon86 project that creates (new) versions of Holon86. 

But it is not ANS. 
So what?

Wolf Wejgaard








  

[toc] | [prev] | [next] | [standalone]

#55600

On Friday, March 10, 2017 at 9:10:26 AM UTC, Wolf Wejgaard wrote:
> Am Mittwoch, 15. Februar 2017 22:47:18 UTC+1 schrieb djc:
> > In the 70ies, Forth was absolute top, leading edge, lots of features and capabilities missing elsewhere, such as
> > * self compiling
> > * multitasking
> > * interpreter AND compiler
> > * vectored I/O
> > * create-does to give user data types a behaviour
> > * fast AND small
> > * internal DSLs (domain specific languages)
> > 
> > Now today, other languages have taken the technical lead, Haskell, Ruby etc. These keep impressing people with Lambdas, Closures, modifiable class memberships, effective protection mechanisms etc.
> > 
> > Ok, so back to the drawing board and bringing up crazy new capabilities which no other language can do...
> > 
> > That is not about copy-catting features like lambdas and closures (some attempts were seen here), but bringing in novelty.
> > 
> > Why not have easy defining and training words for neural net elements? Why not use the multitasker for a pulsed and parallel neural net? Why not come up with something totally crazy and unseen?
> > 
> >    Daniel
> 
> You might enjoy a look at holonforth.com/holon86.html - Crazy and still unseen, it seems, just a great way of programming Forth since 1990. Direct action, immediate responses, clear presentation of the project source. Holon86 rips away the classical white blanket with its reassuring "ok" and shows you what lurks below: a great under-explored database known as the dictionary. You have source text browser and code directly accessible without resorting to incantations like LOCATE. And forget about files, the source is included in the DB like the code. A complete IDE. Unbelievably efficient!
> 
> HOLON86 is on Github. - You can study its source in HOST86, a Holon86 project that creates (new) versions of Holon86. 
> 
> But it is not ANS. 
> So what?
> 
> Wolf Wejgaard

Wolf, what is this religous ANS disapproval for? There is a standard - so people can compare and define where they are different - and if nobody asks nobody cares. If somebody cares, then you have at least the possibility to compare with something - the standard and where you are better?. We here should all be old enough to know that an optimized version is always better than the standard - otherwise it would not be optimized.

[toc] | [prev] | [next] | [standalone]

#55704

Am Freitag, 10. März 2017 18:33:54 UTC+1 schrieb JUERGEN:
> On Friday, March 10, 2017 at 9:10:26 AM UTC, Wolf Wejgaard wrote:
>> ...
>>
> > But it is not ANS. 
> > So what?
> > 
> > Wolf Wejgaard
> 
> Wolf, what is this religous ANS disapproval for? There is a standard - so people can compare and define where they are different - and if nobody asks nobody cares. If somebody cares, then you have at least the possibility to compare with something - the standard and where you are better?. We here should all be old enough to know that an optimized version is always better than the standard - otherwise it would not be optimized.


Thank you, Juergen, for your input. I am not against ANS, I just don't use it. I developed 
Holon in FIG-Forth and had the first version working 1989. When ANSForth appeared 1994 
Holon86 had already attained its present shape (the version on GitHub).

Thus, my point is: Why use a Forth standard at all? Both Moore and his enthusiastic follower 
Ting don't seem to need it, instead relying on their private collections of words.  And so do I.  

I understand the need for a standard and wish the Forth system vendors well.  If you prefer 
ANSForth, enjoy it, I certainly don't mind. I only wished the Forth Group would remain aware 
of the fact that we are discussing two different languages: Forth and ANSForth. 

[toc] | [prev] | [next] | [standalone]

#55713

On Sun, 12 Mar 2017 09:00:03 -0700 (PDT), Wolf Wejgaard
<wejgaard@holonforth.com> wrote:

>I understand the need for a standard and wish the Forth system vendors well.
>If you prefer ANSForth, enjoy it, I certainly don't mind. I only wished the
>Forth Group would remain aware of the fact that we are discussing two different
>languages: Forth and ANSForth.

Dialects, not languages. That's why we can talk to each other's
software.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#55715

On 3/12/2017 12:00 PM, Wolf Wejgaard wrote:
> Am Freitag, 10. März 2017 18:33:54 UTC+1 schrieb JUERGEN:
>> On Friday, March 10, 2017 at 9:10:26 AM UTC, Wolf Wejgaard wrote:
>>> ...
>>>
>>> But it is not ANS.
>>> So what?
>>>
>>> Wolf Wejgaard
>>
>> Wolf, what is this religous ANS disapproval for? There is a standard - so people can compare and define where they are different - and if nobody asks nobody cares. If somebody cares, then you have at least the possibility to compare with something - the standard and where you are better?. We here should all be old enough to know that an optimized version is always better than the standard - otherwise it would not be optimized.
>
>
> Thank you, Juergen, for your input. I am not against ANS, I just don't use it. I developed
> Holon in FIG-Forth and had the first version working 1989. When ANSForth appeared 1994
> Holon86 had already attained its present shape (the version on GitHub).
>
> Thus, my point is: Why use a Forth standard at all? Both Moore and his enthusiastic follower
> Ting don't seem to need it, instead relying on their private collections of words.  And so do I.
>
> I understand the need for a standard and wish the Forth system vendors well.  If you prefer
> ANSForth, enjoy it, I certainly don't mind. I only wished the Forth Group would remain aware
> of the fact that we are discussing two different languages: Forth and ANSForth.

Others have pointed out that there are two reasons for a language 
standard.  One is so programs are portable across platforms.  The other 
is so programmers are portable across projects and companies.  The 
latter didn't occur to me until I read that, but that may be the more 
significant reason for Forth to have a standard for many.  I believe 
Forth is already hampered in acceptance because of the lack of available 
programmers.  Having to retrain an existing Forth programmer to be able 
to use a different set of tools would be a non-starter for nearly every 
company rather than just the vast majority as is currently the case.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web