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

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

Really?

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

Contents

  Really? Mark Wills <markwills1970@gmail.com> - 2017-02-06 06:46 -0800
    Re: Really? foxaudioresearch@gmail.com - 2017-02-06 07:20 -0800
    Re: Really? polymorph self <jackvanc3@gmail.com> - 2017-02-06 08:58 -0800
    Re: Really? rickman <gnuarm@gmail.com> - 2017-02-06 13:06 -0500
    Re: Really? hughaguilar96@gmail.com - 2017-02-06 11:25 -0800
    Re: Really? "HAA" <someone@microsoft.com> - 2017-02-07 11:45 +1100
    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-06 15:38 -1000
      Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:50 -0800
    Re: Really? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-06 23:39 -0500
      Re: Really? Mark Wills <markwills1970@gmail.com> - 2017-02-07 08:04 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 11:04 +1100
        Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:42 -0800
          Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 20:12 +1100
            Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 02:44 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-08 17:48 +0000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 18:43 +0000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 15:24 -0800
              Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 16:26 -0800
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 22:45 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:50 -0800
      Re: Really? clozaga@gmail.com - 2017-02-08 21:03 -0800
        Re: Really? clozaga@gmail.com - 2017-02-08 21:04 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-11 20:01 -0800
          Re: Really? Alex <alex@rivadpm.com> - 2017-02-12 16:26 +0000
            Re: Really? hughaguilar96@gmail.com - 2017-02-12 16:52 -0800
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 09:49 +0000
                Re: Really? minforth@arcor.de - 2017-02-13 07:03 -0800
                Re: Really? hughaguilar96@gmail.com - 2017-02-13 13:41 -0800
                  Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 22:32 +0000
                    Re: Really? hughaguilar96@gmail.com - 2017-02-15 11:42 -0800
                      Re: Really? Alex <alex@rivadpm.com> - 2017-02-15 20:41 +0000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-17 09:42 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-17 22:22 +0000
            Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-12 19:24 -1000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 08:49 +0000
    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 11:01 +0000
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 03:06 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:35 -0800
        Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:35 +0000
          Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:24 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-09 08:57 +0000
              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 13:24 +0100
                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:32 +0000
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:42 +0000
          Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 13:58 -1000
            Re: Really? hughaguilar96@gmail.com - 2017-02-07 21:51 -0800
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 01:47 -0500
                Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:52 -0800
                  Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 03:34 -0500
                    Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 13:43 +0000
                      Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:39 -1000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-08 22:39 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 08:56 +0000
                            Re: Really? hughaguilar96@gmail.com - 2017-02-09 14:36 -0800
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-10 08:33 +0000
                        Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 09:03 +0000
                          Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 10:51 +0100
                            Re: Really? john <anon@example.com> - 2017-02-09 11:54 +0000
                              Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 09:30 -1000
                            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 14:14 +0000
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 14:37 +0000
                                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 15:24 +0000
                                  Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 12:01 -0800
                                    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 01:09 +0000
                                      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 18:19 -0800
                                        Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 16:30 -1000
                                      Re: Really? hughaguilar96@gmail.com - 2017-02-09 19:16 -0800
                                        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 16:29 +0000
                                          OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:30 +0000
                                            Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 11:46 -0600
                                              Re: OT: [ was re: Really?] Foreign aid Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-10 11:54 -0600
                                                Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:05 +0000
                                              Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:55 +0000
                                                Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:04 -0600
                                                  Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:07 +0000
                                                    Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:57 -0600
                                                      Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 19:26 +0000
                                                        Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 14:04 -0600
                                                          Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-11 09:35 +0000
                                          Re: Really? hughaguilar96@gmail.com - 2017-02-10 16:33 -0800
                                      Static type checking (was: Really?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-10 11:07 +0000
                                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:16 +0000
                                  Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-11 10:20 -0600
                                  Re: Really? hughaguilar96@gmail.com - 2017-02-11 19:02 -0800
                              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-10 17:31 +0100
                    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:34 -1000
                Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 21:15 -1000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:46 -0800
          Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:47 -0800
            Re: Really? Ron Aaron <rambamist@gmail.com> - 2017-02-08 08:52 +0200
      Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 06:29 -0500
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:47 +0000
          Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 16:23 -0500
            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 09:47 +0000
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 05:13 -0500
                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 11:23 +0000
      Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-07 09:49 -0600
    Really? Mark Wills <markwills1970@gmail.com> - 2017-02-09 00:30 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-10 10:32 +1100
        Re: Really? hughaguilar96@gmail.com - 2017-02-09 17:22 -0800

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

#54734

The operating system and software was written entirely in Forth and was purportedly bug free. So it is possible.

However from what I can tell the whole thing was written by two people, unlike a large team like Valdocs. Maybe that is telling in some wa.y.

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

#54735

Left out an important detail: Canon Cat.

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

#54801

On Wednesday, February 8, 2017 at 10:03:03 PM UTC-7, clo...@gmail.com wrote:
> The [Canon Cat] operating system and software was written entirely in Forth and was purportedly bug free. So it is possible.
> 
> However from what I can tell the whole thing was written by two people, unlike a large team like Valdocs. Maybe that is telling in some wa.y.

I agree that a large team is problematic. As I said before, the only way that I know of (have personal experience with) in making this successful, is to divide the big project into several small related projects and give each programmer full authority over one project --- this way each programmer works alone --- it is always a good thing for a programmer to work alone, and it is never really going to work for multiple programmers to share responsibility for a single project.

I don't think this is what killed Valdocs or the Canon Cat though. The day of the dedicated computer was rapidly passing. MS-DOS has arrived, at it was represented as being a general-purpose computer. In actuality, it was mostly only good for spreadsheets and databases. 
1.) The Commodore Amiga was better for games.
2.) The Apple Mac was better for desktop publishing and graphics arts.
3.) The Atari ST was better for music.
4.) The Canon Cat was better for word-processing.

All of the above were fully capable of being better than MS-DOS for spreadsheets and databases (spreadsheets need a numerical co-processor and data-bases need a fast hard-drive).

All in all, the MS-DOS machines were the worst! Those TSR programs under MS-DOS were a big mess; every other computer had actual multi-tasking. MS-DOS succeeded primarily because it represented itself as being general-purpose, which people wanted, although it was actually "a jack of all trades and a master of none." Also, MS-DOS succeeded because it had the IBM and MicroSoft names, and people seem to want a big name important company to tell them what to do, mostly because they can't think for themselves.

A Z80-based dedicated computer wasn't going to succeed. The Canon Cat had an MC68000, but it didn't succeed either. To some extent this was because it was only for word-processing. Mostly, Apple told Canon to kill the Cat because it competed against their Mac --- Apple bought a lot of Canon printers so Canon did what Apple told them to do. I would have liked to buy a Canon Cat, but it was too expensive for me, and then it died anyway.

Testra had a computer that used a Forth processor --- they had big hopes of competing successfully against MS-DOS because their computer was a lot faster than the 8088 IBM-PC --- this didn't work out either.

It is pretty depressing, but MS-DOS and then Windows 3.1 were what we got --- neither of these had any technical merit whatsoever --- they were total crap, and we are still living with their legacy over three decades later.

A dedicated computer is unrealistic now. The computers available at WalMart for $300 to $500 have multi-core 64-bit processors and are mighty powerful. They have a low price tag because they are built in China by workers living in poverty --- also, mass production has a lot of economic advantages even if the workers are paid decent wages --- the idea of building dedicated computers one at a time in a small shop with a handful of workers is absurd; this is not going to be competitive.

I think it would be pretty fun to build a Canon Cat nowadays --- it could use the Coldfire (the performance would be only one order of magnitude slower than the WalMart computers) --- rich hobbyists would buy it (the price would be only one order of magnitude higher than the WalMart computers).

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

#54811

On 2/12/2017 04:01, hughaguilar96@gmail.com wrote:
> I agree that a large team is problematic. As I said before, the only
> way that I know of (have personal experience with) in making this
> successful, is to divide the big project into several small related
> projects and give each programmer full authority over one project ---
> this way each programmer works alone --- it is always a good thing
> for a programmer to work alone, and it is never really going to work
> for multiple programmers to share responsibility for a single
> project.

This flies in tha face of the available evidence; agile, DSDM, RAD, 
CMMI, DevOps, you name it, none of these approaches advocates islands of 
isolated development. They do, however, require a cooperative approach 
to develpment that you might find impossible.

-- 
Alex

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

#54821

On Sunday, February 12, 2017 at 9:26:09 AM UTC-7, Alex wrote:
> On 2/12/2017 04:01, hughaguilar96@gmail.com wrote:
> > I agree that a large team is problematic. As I said before, the only
> > way that I know of (have personal experience with) in making this
> > successful, is to divide the big project into several small related
> > projects and give each programmer full authority over one project ---
> > this way each programmer works alone --- it is always a good thing
> > for a programmer to work alone, and it is never really going to work
> > for multiple programmers to share responsibility for a single
> > project.
> 
> This flies in tha face of the available evidence; agile, DSDM, RAD, 
> CMMI, DevOps, you name it, none of these approaches advocates islands of 
> isolated development. They do, however, require a cooperative approach 
> to develpment that you might find impossible.
> 
> -- 
> Alex

You want to be part of a team so you can hide your own incompetence --- you will tell the boss that the team members' code is crap, putting them on the defensive trying to explain that their code isn't crap --- meanwhile you artfully dodge the need to write any code yourself and/or you push through stupid design decisions in order to force the entire team to program at your level of incompetence.

You are doing the same thing here. You have self-promoted yourself into a leadership position in Forth-200x, and you expect people such as myself to kneel before you, and you artfully dodge writing any code yourself. Actually, the Forth-200x mailing list is entirely composed of self-promoted leaders who don't write any code --- all chiefs and no braves.

You have repeatedly claimed that you "do standards for a living" --- how is that working out for you? LOL

The only way this could work, is if there is one team member who is generally acknowledged to be brilliant, and all of the other team members cheerfully accept that they are incompetent and can never be anything except code monkeys who program according to the detailed spec provided by their brilliant leader. If the code monkeys are paid reasonably well, they will stifle their pride and live on their knees. The reason why this doesn't work for Forth-200x is that the supposed code monkeys (Forthers such as myself) aren't getting paid anything and hence don't have any reason to kneel before the Forth-200x committee --- besides that, the Forth-200x committee members aren't brilliant --- Andrew Haley is a clown!

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

#54835

On 2/13/2017 00:52, hughaguilar96@gmail.com wrote:
> You have repeatedly claimed that you "do standards for a living" ---
> how is that working out for you? LOL

Very well thanks. Right now, I'm spending some of my time working with a 
number of companies on developing and promoting new hardware specs and a 
new programming model that the industry needs to support persistent 
memories. PM typically has latencies between current flash and DRAM; in 
the 10s of nS. It's an interesting & challenging development that's 
changing the way we think about providing and using both memory and 
storage. PM bridges the gap between them, and treating it as storage (a 
block based storage device with an I/O stack) or memory (a byte 
addressable load/store memory) doesn't take full advantge of its 
capabilities. It's early days though; we're probably nearly a decade 
away from this stuff being mainstream.

For anyone that's interested;

https://www.snia.org/forums/sssi
http://www.snia.org/tech_activities/standards/curr_standards/npm

> The only way this could work, is if there is one team member who is
> generally acknowledged to be brilliant, and all of the other team
> members cheerfully accept that they are incompetent and can never be
> anything except code monkeys who program according to the detailed
> spec provided by their brilliant leader.

Interesting CV you have.

There are several models for organising and managing software 
development, and I would not claim to be an expert. But I see several 
models; perhaps the most famous of which is the "benevolent dictator" 
model employed by Linux. Even there, the scale of the project is such 
that there are tens of "dictators", for various project parts of the 
whole. One of the teams with which I am familiar has several members, 
many of whom are employed by the same company; but some of whom work for 
other companies and are effectively working remotely.

The persona of genius programmer (and presumably genius project manager 
too) that you describe is one I only see on one-person projects. A few, 
very few, succeed. Apple's Jobs, Torvald's Linux. Most loners are 
destined to write software that will be used by them alone. The 
practicalities of the real world are messy and inefficent and require 
teamwork and compromise at all levels.

-- 
Alex

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

#54838

Am Montag, 13. Februar 2017 10:49:34 UTC+1 schrieb Alex:
> On 2/13/2017 00:52, hughaguilar96@gmail.com wrote:
> > You have repeatedly claimed that you "do standards for a living" ---
> > how is that working out for you? LOL
> 
> Very well thanks. Right now, I'm spending some of my time working with a 
> number of companies on developing and promoting new hardware specs and a 
> new programming model that the industry needs to support persistent 
> memories. PM typically has latencies between current flash and DRAM; in 
> the 10s of nS. It's an interesting & challenging development that's 
> changing the way we think about providing and using both memory and 
> storage. PM bridges the gap between them, and treating it as storage (a 
> block based storage device with an I/O stack) or memory (a byte 
> addressable load/store memory) doesn't take full advantge of its 
> capabilities. It's early days though; we're probably nearly a decade 
> away from this stuff being mainstream.
> 
> For anyone that's interested;
> 
> https://www.snia.org/forums/sssi
> http://www.snia.org/tech_activities/standards/curr_standards/npm
> 
> > The only way this could work, is if there is one team member who is
> > generally acknowledged to be brilliant, and all of the other team
> > members cheerfully accept that they are incompetent and can never be
> > anything except code monkeys who program according to the detailed
> > spec provided by their brilliant leader.
> 
> Interesting CV you have.
> 
> There are several models for organising and managing software 
> development, and I would not claim to be an expert. But I see several 
> models; perhaps the most famous of which is the "benevolent dictator" 
> model employed by Linux. Even there, the scale of the project is such 
> that there are tens of "dictators", for various project parts of the 
> whole. One of the teams with which I am familiar has several members, 
> many of whom are employed by the same company; but some of whom work for 
> other companies and are effectively working remotely.
> 
> The persona of genius programmer (and presumably genius project manager 
> too) that you describe is one I only see on one-person projects. A few, 
> very few, succeed. Apple's Jobs, Torvald's Linux. Most loners are 
> destined to write software that will be used by them alone. The 
> practicalities of the real world are messy and inefficent and require 
> teamwork and compromise at all levels.
> 
> -- 
> Alex

Indeed, the "practicalities" cannot be standardized. I fondly remember a project where brilliant software engineers wrote tons of interface specifications and then failed because they could no more integrate (or really understand) the consequences of automation partial shutdown and reboot sequences (ey, that is hardware...!!)

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

#54842

On Monday, February 13, 2017 at 2:49:34 AM UTC-7, Alex wrote:
> On 2/13/2017 00:52, hughaguilar96@gmail.com wrote:
> > You have repeatedly claimed that you "do standards for a living" ---
> > how is that working out for you? LOL
> 
> Very well thanks. Right now, I'm spending some of my time working with a 
> number of companies on developing and promoting new hardware specs and a 
> new programming model that the industry needs to support persistent 
> memories. PM typically has latencies between current flash and DRAM; in 
> the 10s of nS. It's an interesting & challenging development that's 
> changing the way we think about providing and using both memory and 
> storage. PM bridges the gap between them, and treating it as storage (a 
> block based storage device with an I/O stack) or memory (a byte 
> addressable load/store memory) doesn't take full advantge of its 
> capabilities. It's early days though; we're probably nearly a decade 
> away from this stuff being mainstream.

You said that you are: "developing and promoting" --- since when do developers also do the promoting? --- only salespeople do promoting.

You said: 
"It's an interesting & challenging development that's changing the way we think..."

Yes, that sounds like a sales job to me --- only salespeople claim that they are changing the way that we think about technology.

> For anyone that's interested;
> [snip]

Nobody is interested in your sales pitch --- idiot salesman!

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

#54843

On 2/13/2017 21:41, hughaguilar96@gmail.com wrote:
> On Monday, February 13, 2017 at 2:49:34 AM UTC-7, Alex wrote:
>> On 2/13/2017 00:52, hughaguilar96@gmail.com wrote:
>>> You have repeatedly claimed that you "do standards for a living"
>>> --- how is that working out for you? LOL
>>
>> Very well thanks. Right now, I'm spending some of my time working
>> with a number of companies on developing and promoting new hardware
>> specs and a new programming model that the industry needs to
>> support persistent memories. PM typically has latencies between
>> current flash and DRAM; in the 10s of nS. It's an interesting &
>> challenging development that's changing the way we think about
>> providing and using both memory and storage. PM bridges the gap
>> between them, and treating it as storage (a block based storage
>> device with an I/O stack) or memory (a byte addressable load/store
>> memory) doesn't take full advantge of its capabilities. It's early
>> days though; we're probably nearly a decade away from this stuff
>> being mainstream.
>
> You said that you are: "developing and promoting" --- since when do
> developers also do the promoting? --- only salespeople do promoting.
>
> You said: "It's an interesting & challenging development that's
> changing the way we think..."
>
> Yes, that sounds like a sales job to me --- only salespeople claim
> that they are changing the way that we think about technology.
>
>> For anyone that's interested; [snip]
>
> Nobody is interested in your sales pitch --- idiot salesman!
>

Shorter version: you didn't understand it.

-- 
Alex

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

#54866

On Monday, February 13, 2017 at 3:32:03 PM UTC-7, Alex wrote:
> On 2/13/2017 21:41, hughaguilar96@gmail.com wrote:
> > On Monday, February 13, 2017 at 2:49:34 AM UTC-7, Alex wrote:
> >> On 2/13/2017 00:52, hughaguilar96@gmail.com wrote:
> >>> You have repeatedly claimed that you "do standards for a living"
> >>> --- how is that working out for you? LOL
> >>
> >> Very well thanks. Right now, I'm spending some of my time working
> >> with a number of companies on developing and promoting new hardware
> >> specs and a new programming model that the industry needs to
> >> support persistent memories. PM typically has latencies between
> >> current flash and DRAM; in the 10s of nS. It's an interesting &
> >> challenging development that's changing the way we think about
> >> providing and using both memory and storage. PM bridges the gap
> >> between them, and treating it as storage (a block based storage
> >> device with an I/O stack) or memory (a byte addressable load/store
> >> memory) doesn't take full advantge of its capabilities. It's early
> >> days though; we're probably nearly a decade away from this stuff
> >> being mainstream.
> >
> > You said that you are: "developing and promoting" --- since when do
> > developers also do the promoting? --- only salespeople do promoting.
> >
> > You said: "It's an interesting & challenging development that's
> > changing the way we think..."
> >
> > Yes, that sounds like a sales job to me --- only salespeople claim
> > that they are changing the way that we think about technology.
> >
> >> For anyone that's interested; [snip]
> >
> > Nobody is interested in your sales pitch --- idiot salesman!
> 
> Shorter version: you didn't understand it.

It is not that I didn't understand it --- I didn't read it --- I don't care about whatever product you are selling.

The computer world doesn't need Alex McDonald to teach them to think about mass storage in a new way. I didn't need you to teach me to think about my SORT function in a new way. Maybe later though, you can teach the Eskimo to think about snow in a new way! LOL

This is a common marketing gimmick --- sales-people always want to set the standard for the industry, so the product they're selling becomes the new standard and all of the competition becomes non-standard wanna-be efforts --- ANS-Forth was just a marketing gimmick from Forth Inc.; it only got rubber-stamped by ANSI because Charles Moore's name was listed in the document as a supporter, and ANSI knew that Charles Moore had invented Forth and hence that he alone had the right to define a standard for Forth.

A big clue that this marketing gimmick is being played, is that the salesperson will claim to be "changing the way people think about xxx technology." Also, the salesperson will encourage potential customers to "join the revolution" by buying their product. I don't actually blame Elizabeth Rather for playing this marketing gimmick --- all salespeople do this --- I blame the Forth community for being so naive that they allowed a salesperson to become their "leading expert" and set the Forth standard for them despite having never written a Forth program in her life.

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

#54867

On 2/15/2017 19:42, hughaguilar96@gmail.com wrote:
> On Monday, February 13, 2017 at 3:32:03 PM UTC-7, Alex wrote:

>>
>> Shorter version: you didn't understand it.
>
> It is not that I didn't understand it --- I didn't read it --- I
> don't care about whatever product you are selling.
>

Well, I admire your consistency if nothing else.

> The computer world doesn't need Alex McDonald to teach them to think
> about mass storage in a new way. I didn't need you to teach me to
> think about my SORT function in a new way. Maybe later though, you
> can teach the Eskimo to think about snow in a new way! LOL

You asked a question; I answered it. So how do you know what or if I was 
doing or marketing or promoting or selling? You didn't read it. Your 
loss, not mine.

It obviouly grinds your gears to be told why your SORT has issues, but 
you won't take on board constructive criticism and address it.

But then, why should I care? No-one will use it.

<rant snipped>

>
> A big clue that this marketing gimmick is being played, is that the
> salesperson will claim to be "changing the way people think about xxx
> technology."

Your gimmick is writing huge swathes of gimcrack code and claiming it 
makes things easier/better/etc for novices, and that you're the messiah 
come to throw the money grubbing Forth Inc. and their false god ANS out 
of the temple of Forth.

<more ranting snipped that makes my point>

A prerequisite to understanding is rational thinking, but sadly you 
appear unable to do any more than shout at the world.

-- 
Alex

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

#54934

On Wednesday, February 15, 2017 at 1:41:10 PM UTC-7, Alex wrote:
> On 2/15/2017 19:42, hughaguilar96@gmail.com wrote:
> It obviouly grinds your gears to be told why your SORT has issues, but 
> you won't take on board constructive criticism and address it.
> 
> But then, why should I care? No-one will use it.

There is nothing wrong with my SORT --- it sorts arrays of pointers to structs or arrays of structs --- the only limitation is that the array element size has to be a multiple of the cell size, but FIELD guarantees this anyway for structs, so that should not be a problem.

SORT is actually very basic programming --- sort algorithms were figured out in the 1970s or maybe even the 1960s --- it has been at least four decades since anybody has considered the problem of writing a SORT function to be interesting.

I think the reason why you are attacking my SORT is because you have a novice-programming book at home discussing sort algorithms and it said that QuickSort is best, so you think my use of HeapSort is wrong --- also you have downloaded Wil Baden's SORT function that was limited to arrays of cell-sized elements, so you think that my support for arrays of arbitrary-sized elements is wrong.

This isn't "constructive criticism" --- you are just a clown who has become more annoying than humorous  --- Elizabeth Rather surrounds herself with sycophants such as yourself, so I blame her.

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

#54944

On 2/17/2017 17:42, hughaguilar96@gmail.com wrote:
> On Wednesday, February 15, 2017 at 1:41:10 PM UTC-7, Alex wrote:
>> On 2/15/2017 19:42, hughaguilar96@gmail.com wrote: It obviouly
>> grinds your gears to be told why your SORT has issues, but you
>> won't take on board constructive criticism and address it.
>>
>> But then, why should I care? No-one will use it.
>
> There is nothing wrong with my SORT --- it sorts arrays of pointers
> to structs or arrays of structs --- the only limitation is that the
> array element size has to be a multiple of the cell size, but FIELD
> guarantees this anyway for structs, so that should not be a problem.

It only sorts arrays? You don't even understand the capabilities of your 
own sort.

>
> SORT is actually very basic programming --- sort algorithms were
> figured out in the 1970s or maybe even the 1960s --- it has been at
> least four decades since anybody has considered the problem of
> writing a SORT function to be interesting.

But you still get it wrong.

>
> I think the reason why you are attacking my SORT is because you have
> a novice-programming book at home discussing sort algorithms and it

I have Knuth's Sorting & Searching. It's comprehensive but very theoretical.

> said that QuickSort is best, so you think my use of HeapSort is wrong
> --- also you have downloaded Wil Baden's SORT function that was
> limited to arrays of cell-sized elements, so you think that my
> support for arrays of arbitrary-sized elements is wrong.

You keep repeating this; that Wil Baden's sort is limited to sorting 
arrays of cells. You're wrong. It can sort anything; arrays of cells, 
arrays of arbitrary-sized elements, lists, variable length records, 
discontiguous records, the lot.

And so can your sort -- very inefficently, yes, but it can do it.

But you don't seem able to grasp any of this.

>
> This isn't "constructive criticism" --- you are just a clown who has
> become more annoying than humorous  --- Elizabeth Rather surrounds
> herself with sycophants such as yourself, so I blame her.
>

Obviously, since you are nothing if not consistent.

-- 
Alex

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

#54831

On 2/12/17 6:26 AM, Alex wrote:
> On 2/12/2017 04:01, hughaguilar96@gmail.com wrote:
>> I agree that a large team is problematic. As I said before, the only
>> way that I know of (have personal experience with) in making this
>> successful, is to divide the big project into several small related
>> projects and give each programmer full authority over one project ---
>> this way each programmer works alone --- it is always a good thing
>> for a programmer to work alone, and it is never really going to work
>> for multiple programmers to share responsibility for a single
>> project.
>
> This flies in tha face of the available evidence; agile, DSDM, RAD,
> CMMI, DevOps, you name it, none of these approaches advocates islands of
> isolated development. They do, however, require a cooperative approach
> to develpment that you might find impossible.
>
That approach is part of the trouble with the VALDOCs project we were 
just discussing.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#54834

On 2/13/2017 05:24, Elizabeth D. Rather wrote:
> On 2/12/17 6:26 AM, Alex wrote:
>> On 2/12/2017 04:01, hughaguilar96@gmail.com wrote:
>>> I agree that a large team is problematic. As I said before, the only
>>> way that I know of (have personal experience with) in making this
>>> successful, is to divide the big project into several small related
>>> projects and give each programmer full authority over one project ---
>>> this way each programmer works alone --- it is always a good thing
>>> for a programmer to work alone, and it is never really going to work
>>> for multiple programmers to share responsibility for a single
>>> project.
>>
>> This flies in tha face of the available evidence; agile, DSDM, RAD,
>> CMMI, DevOps, you name it, none of these approaches advocates islands of
>> isolated development. They do, however, require a cooperative approach
>> to develpment that you might find impossible.
>>
> That approach is part of the trouble with the VALDOCs project we were
> just discussing.

Wait, they had Hugh on the team?

>
> Cheers,
> Elizabeth
>


-- 
Alex

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

#54682

On Mon, 6 Feb 2017 06:46:00 -0800 (PST), Mark Wills
<markwills1970@gmail.com> wrote:

>"As for Forth, although it has dedicated advocates, it's 
>explicit stack orientation and its lack of modularity limit
>the scale of Forth programs. One of the largest Forth efforts
>was an integrated operating system called Valdocs (Valuable 
>Document System) on the Epson QX-10. The software remained buggy
>couldn't be updated quickly enough for the machine to remain 
>competitive - although you could just as easilly blame the 
>computer's Z-80 processor (since at the time the 8088 based IBM PC
>and 68000 based Apple Macintosh were being introduced) and difficulty
>in finding experienced Forth programmers. Whatever the cause, this 
>soured the acceptance of Forth for large scale projects."
>
>http://www.cpushack.com/CPU/cpuAppendB.html#Forth

I have met several of the Valdocs people. The critical problems
with the project were project management problems. In any large
project, project management is really, really important.

To give an example of a current large Forth project that has 
evolved over 30 years, see the Candy system at
  http://constructioncomputersoftware.com/
which is currently built on VFX Forth for Windows. Candy consists
of 55 Mb of source code in 1.2 million lines of code and generates
an executable of 27 Mb. I always quote this one because I do a full
rebuild before each VFX Forth release.

For another Forth-based app, see
  http://www.micross.co.uk/micross/tracknet/
Nick Nelson has presented many EuroForth papers over the years.

Leon from Forth Inc has presented several papers on PC projects
in the last couple of years.

We have many clients with embedded systems of over 500 kb in Flash.

Success or failure of projects is mostly down to project management.

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]

#54683

stephen@mpeforth.com (Stephen Pelc) writes:
> Success or failure of projects is mostly down to project management.

Got any advice about how to manage Forth projects?  One thing I notice
with modern interpreted languages (i.e. lots of runtime safety checking)
is that it's fairly quick to fling code against the wall, see if it
sticks, or pull it down and toss up something else.  That leads to a
different development style than Forth or C, where you have to be
careful to not give back hard-earned gains.

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

#54687

On Tuesday, February 7, 2017 at 4:06:47 AM UTC-7, Paul Rubin wrote:
> stephen@mpeforth.com (Stephen Pelc) writes:
> > Success or failure of projects is mostly down to project management.
> 
> Got any advice about how to manage Forth projects?  

I've only been involved in one Forth project that was a success, which was the MiniForth.

The way that this worked, was that the team members had very distinct responsibilities. I just wrote MFX the development system. I didn't get involved in the HDL work (I don't know anything about the subject, so I couldn't if I had wanted to). I also didn't get involved in the motion-control program written in MFX (I was not allowed to have access to the source-code because my boss was afraid that I would steal it, plus I don't know anything about the subject anyway). I communicated with the processor designer, so MFX would work on the hardware. I made suggestions for the hardware design also, some of which (local variables) were done. I also communicated with the programmer porting over the motion-control program and he made suggestions which I put in MFX (getting the motion-control program to run was the only purpose of the MiniForth, so these weren't just suggestions but were demands). 

The important point is that everybody stays out of each other's turf --- this way, instead of one big project developed by a team, there are three small projects each developed by a single person --- all three parts have to work together, of course, so there has to be good communication.

If I had known as much about Forth then what I do now, the MiniForth would have been a better design --- it did what it was supposed to do though.

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

#54689

Paul Rubin <no.email@nospam.invalid> writes:
>One thing I notice
>with modern interpreted languages (i.e. lots of runtime safety checking)
>is that it's fairly quick to fling code against the wall, see if it
>sticks, or pull it down and toss up something else.  That leads to a
>different development style than Forth or C, where you have to be
>careful to not give back hard-earned gains.

If you run into that problem, there probably is something wrong with
your basic architecture or your code, and the "gains" are actually a
burden.  Better don't throw good programming effort after bad (that
may have been the problem with Valdocs).

Concerning run-time checks, if you think that helps, put them into your
code.

Of course, there are some practices that are viable in, say, a
garbage-collected language, that, in Forth, you have to do without.
If you are used to garbage collection, you may find that hard, and
requiring you to think outside the box of your usual practices.
Programming like in a GC language and trying to put in FREEs where
necessary will not lead to good results.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54708

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>different development style than Forth or C, where you have to be
>>careful to not give back hard-earned gains.
> If you run into that problem, there probably is something wrong with
> your basic architecture or your code, and the "gains" are actually a
> burden.

What I've seen with large C programs is that bugs are elusive--they lurk
around for a long time before even being noticed, they they're hunted
for a while before any pattern emerges, and then they're often quite
hard to diagnose and fix.  So old C programs are valuable because
they're "seasoned": much effort has been spent finding and chasing bugs
over the years, that has to be re-done if you toss out the code.

By comparison, the mantra with fancy typed languages like Ocaml is that
once you fix all the compile-time type errors the code tends to work.
With latently typed languages like Python, you avoid every sort of
compile-time error, and in return you get a lot of early runtime errors
that give exact stack traces and are easy to debug.  You don't invest
nearly the debugging time as you do in C so the program doesn't gain as
much value as it ages.

I had a significant change in perspective when I got involved in a
Python project dealing with a large (terabytes) data corpus.  The motto
there was basically that data is gold but code is crap.  I'd been used
to hearing it the other way around.  We were constantly writing
throwaway programs to munch the data one way or another, but replacing
the data (collected over decades) would have been impossible.

> Better don't throw good programming effort after bad (that may have
> been the problem with Valdocs).

I don't know what happened with Valdocs.  I wasn't able to find the
reference HAA mentioned.

> Concerning run-time checks, if you think that helps, put them into your
> code.

The trouble is that errors happen in exactly the places you don't expect
them to, or else they wouldn't be errors ;).  Yes some asserts here and
there are good, but pervasive checking catches a lot of stuff that could
go unnoticed.  Think of all the subscript errors in Fortran and C
programs over the years.  

> If you are used to garbage collection, you may find that hard, and
> requiring you to think outside the box of your usual practices.
> Programming like in a GC language and trying to put in FREEs where
> necessary will not lead to good results.

For lots of purposes, single-ownership pointers (std::unique_ptr) in C++
can take the place of GC with almost no overhead and not too much
programmer effort.  But they rely on the C++'s so-called RAII paradigm,
where a value's type signature can tell the compiler to call
user-supplied code when the value goes out of scope, and also operator
overloading to track the movement of values from one place to another.
It's much easier than manual alloc/free and I don't think it can be done
in Forth.  But, the Boehm GC works pretty well in C and sounds ok for
Forth (you'd know better than me about that).

I think embedded and instrumentation-like programs that are Forth's
specialty avoid the whole problem by not having dynamic memory
allocation at all.  Just some static variables and buffers, maybe a few
ALLOTs at initialization time, plus the stacks.

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

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

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

csiph-web