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

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

Software's Weak Link is Code

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

Contents

  Software's Weak Link is Code visualforth@rocketmail.com - 2014-07-23 09:59 -0700
    Re: Software's Weak Link is Code Roger Levy <roger.levy@gmail.com> - 2014-07-23 10:32 -0700
      Re: Software's Weak Link is Code JUERGEN <epldfpga@aol.com> - 2014-07-23 11:40 -0700
        Re: Software's Weak Link is Code Celeros <kerneels@gmail.com> - 2014-07-25 16:10 +0200
          Re: Software's Weak Link is Code Roger Levy <roger.levy@gmail.com> - 2014-07-25 07:22 -0700
            Re: Software's Weak Link is Code Roger Levy <roger.levy@gmail.com> - 2014-07-25 07:28 -0700
            Re: Software's Weak Link is Code Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-07-25 18:06 +0100
            Re: Software's Weak Link is Code rickman <gnuarm@gmail.com> - 2014-07-25 15:16 -0400
              Re: Software's Weak Link is Code Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-07-25 22:19 +0100
              Re: Software's Weak Link is Code Celeros <kerneels@gmail.com> - 2014-07-26 23:42 +0200
                Re: Software's Weak Link is Code rickman <gnuarm@gmail.com> - 2014-07-26 22:44 -0400
          Re: Software's Weak Link is Code "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-25 16:45 -0400
            Re: Software's Weak Link is Code Celeros <kerneels@gmail.com> - 2014-07-26 23:08 +0200
      Re: Software's Weak Link is Code "Alex McDonald" <blog@rivadpm.com> - 2014-07-24 00:04 +0100
        Re: Software's Weak Link is Code Roger Levy <roger.levy@gmail.com> - 2014-07-24 08:25 -0700
    Re: Software's Weak Link is Code "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-24 03:26 -0400
      Re: Software's Weak Link is Code Mark Wills <markwills1970@gmail.com> - 2014-07-24 01:32 -0700
      Re: Software's Weak Link is Code Unknown <dog@gmail.com> - 2014-07-26 08:17 +0000
        Re: Software's Weak Link is Code "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 05:39 -0400
          Re: Software's Weak Link is Code visualforth@rocketmail.com - 2014-07-26 17:37 -0700
    Re: Software's Weak Link is Code anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-24 13:45 +0000

Page 1 of 2  [1] 2  Next page →

#32577 — Software's Weak Link is Code

Software's Weak Link is Code... - this is the title of an 'electronic design' article which I just read: 
http://electronicdesign.com/embedded/software-s-weak-link-code

Peter Thorne writes about a paradigm shift in which we are living now - leaving 'hand-coding' behind us, switching to automated code generation using system-diagram-based tools and the like. "They are at approximately the same stages of their lifecycles as 3D CAD when it was starting to eliminate the need for separately crafted 2D mechanical drawings and parts lists. It was the same in electronics as EDA systems transformed hardware design workflows away from manual layout of circuit boards and chips", he writes, and he added links to already existing tools of this kind at the end of this article.

This is a chance for Forth to stay alive. Using Forth is an excellent choice for building such kind of tools. Forth has all the features needed for automatic software generation. 

VisualFORTH uses automatic software generation, and that's the way to go.

[toc] | [next] | [standalone]

#32581

> VisualFORTH uses automatic software generation, and that's the way to go.

How does it work?  Why should I trust automatic software generation to be efficient enough for general programming?

Anyway I had problems installing it.  During installation the Win32Forth build failed. (I'm on Windows 8 btw).  

In the meantime, it'd be nice to see some screenshots and bullet points describing what it's about.

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

#32583

On Wednesday, July 23, 2014 6:32:26 PM UTC+1, Roger Levy wrote:
> > VisualFORTH uses automatic software generation, and that's the way to go.
> 
> 
> 
> How does it work?  Why should I trust automatic software generation to be efficient enough for general programming?
> 
> 
> 
> Anyway I had problems installing it.  During installation the Win32Forth build failed. (I'm on Windows 8 btw).  
> 
> 
> 
> In the meantime, it'd be nice to see some screenshots and bullet points describing what it's about.

Well, a Forth Compiler can be fully verified, (more difficult for C) which would mean (I think) that all the words up to the fully verified level can be re-used and are verified. As modules they are better than any newly written words. This would be the most re-used approach I can see. Proven to work according to the spec. Might be against some approaches where a new compiler is written first ...

And looking at efficiency? What is achieved now, what can be achieved, what is required? This might be going in the direction of the better mouse trap. It is probably cheaper to use a faster processor than to pay for optimisation - and it can be done anyway - uncertified though then.  And verified words are like Gold - why change a running system?

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

#32645

On 2014-07-23 08:40 PM, JUERGEN wrote:
>
> Well, a Forth Compiler can be fully verified, (more difficult for C) which would mean (I think) that all the words up to the fully verified level can be re-used and are verified. As modules they are better than any newly written words. This would be the most re-used approach I can see. Proven to work according to the spec. Might be against some approaches where a new compiler is written first ...
>
> And looking at efficiency? What is achieved now, what can be achieved, what is required? This might be going in the direction of the better mouse trap. It is probably cheaper to use a faster processor than to pay for optimisation - and it can be done anyway - uncertified though then.  And verified words are like Gold - why change a running system?
>

What does it mean when you say that a forth compiler can be fully 
verified, and that verified words are like gold? I'm quite new to forth.

I read the rest of this thread, and it reminds me of passages from our 
prescribed computer science texts, where it talked about the 
disappointment of the reality of coding by means of diagrams - it never 
delivered on it's promise of opening up programming to the visually 
inclined.
The texts I'm referring to is now over 15 years old, and they refer to 
the even older attempts at coding by diagram, so the state of the art 
today might be much different, yet, the expressive power of text  in my 
opinion, will never give way to graphical systems much in the same way 
that the command line still rules today.

Even just introducing additional symbols into a programming language 
like that language that John Backus , the inventor of Fortran tried to 
popularised failed, and here we are talking about only a set of 
additional sort of mathematical symbols into the code (think it was the 
language F). I'm sure there was more to it than that, but any language 
that introduced additional symbols above and beyond ASCII really 
struggled historically.

Nevertheless, just like the touch screen idea was dismissed as 
impractical way back in the 70's (saw this on a TED talk by Nicholas 
Negroponte) because people thought that the screen would get too dirty, 
and how can you interact with it while your fingers are obstructing the 
display!?, just in that same manner, perhaps the time has come for large 
adoption of program by diagramming - who knows.....

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

#32647

> What does it mean when you say that a forth compiler can be fully 
> verified, and that verified words are like gold? I'm quite new to forth.

I think he meant fully tested against all practical inputs.

> I read the rest of this thread, and it reminds me of passages from our 
> prescribed computer science texts, where it talked about the 
> disappointment of the reality of coding by means of diagrams - it never 
> delivered on it's promise of opening up programming to the visually 
> inclined.

Haha.  Yep!

The reason I think this is, is because "visual programming" doesn't actually solve or change anything, just present the code in a different way.    And often a LESS intuitive way if you ask me.

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

#32648

This is how I see visual programming:

http://letatoubleu.com/OLcomposer_files/image001.jpg

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

#32650

Roger Levy wrote:

> 
>> What does it mean when you say that a forth compiler can be fully
>> verified, and that verified words are like gold? I'm quite new to forth.
> 
> I think he meant fully tested against all practical inputs.
> 
>> I read the rest of this thread, and it reminds me of passages from our
>> prescribed computer science texts, where it talked about the
>> disappointment of the reality of coding by means of diagrams - it never
>> delivered on it's promise of opening up programming to the visually
>> inclined.
> 
> Haha.  Yep!
> 
> The reason I think this is, is because "visual programming" doesn't
> actually solve or change anything, just present the code in a different
> way.    And often a LESS intuitive way if you ask me.

Forth Code can have attain a fully meaningful Certificate of Conformity 
which is as sound as the CofC applied to hardware components. The process by 
which this is applied requires that each component is subject to inspection 
for compliance against the specification for functionality, quality and 
operability within defined limits.

I am not sure if Roger Levy's link was for something in NI's LabView or not 
(detail a bit too small to be sure). LabView is one such graphically 
represented programming environment. The components graphical representation 
is probably a significant proportion of the programmers view programming. 
The function compiled could be quite insignificant in comparison.

The question would be whether or not the overhead is worth it.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#32657

On 7/25/2014 10:22 AM, Roger Levy wrote:
>
>> What does it mean when you say that a forth compiler can be fully
>> verified, and that verified words are like gold? I'm quite new to forth.
>
> I think he meant fully tested against all practical inputs.
>
>> I read the rest of this thread, and it reminds me of passages from our
>> prescribed computer science texts, where it talked about the
>> disappointment of the reality of coding by means of diagrams - it never
>> delivered on it's promise of opening up programming to the visually
>> inclined.
>
> Haha.  Yep!
>
> The reason I think this is, is because "visual programming" doesn't actually solve or change anything, just present the code in a different way.    And often a LESS intuitive way if you ask me.

Funny, over the years I have come to realize that nearly all of my 
thought processes are graphical in nature.  I excel at things that can 
be manipulated as an image in the mind.  I find that I can do lots of 
math in my mind by forming pictures of it.  To me 7 * 24 is an image of 
blocks of 25 arranged in two rows of four (100 per row) with one missing 
and one square missing from each block of 25.  I can "see" the missing 
block of 25 and the seven missing squares so 7 *  24 = 200 - 25 - 7 = 
168.  To me *everything* is visual.

I struggled a bit when I had to start designing FPGAs in HDL rather than 
schematics.  I found written code to convey little understanding or 
form.  In fact, the indentation and white space are the most important 
part of code to me... the "picture" of structure of the code.

Yes, diagrams for complex things can be complex, but only if you don't 
manage them properly.  Just as good code is hierarchical and regular, a 
diagram of that will be well presented and clear.  I always start with a 
block diagram even if it is just in my mind.  So continuing with a 
diagram would be second nature to me.

I think perhaps Dirk is right in that it may be time to consider what 
visual programming can do for us.  It has been used in signal processing 
for some time now and I believe there is a tool from National 
Instruments which produces code for data acquisition and control.  These 
are mainstream products which have been successful for some time now. 
Yes, it is likely overdue to look for better ways to program.

-- 

Rick

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

#32660

rickman wrote:

[%X]

> I think perhaps Dirk is right in that it may be time to consider what
> visual programming can do for us.  It has been used in signal processing
> for some time now and I believe there is a tool from National
> Instruments which produces code for data acquisition and control.  These
> are mainstream products which have been successful for some time now.
> Yes, it is likely overdue to look for better ways to program.

Like you I think quite graphically too. I even have quite a graphical view 
in my head (not on-screen) for some of the Forth code I have written. I was 
with Gordon Charlton when he came up with the Stack-flow idea (see a back 
issue of Forthwrite for an article on that). So, Forth would, I think, lend 
itself to fairly graphical representation. The development platform would 
need the resources to handle all the connections unless you can reverse up 
to graphically represent the code you already have.

Regards

Paul E. Bennett IEng MIET
Systems Engineer

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#32700

On 2014-07-25 09:16 PM, rickman wrote:
> On 7/25/2014 10:22 AM, Roger Levy wrote:
>
> Funny, over the years I have come to realize that nearly all of my
> thought processes are graphical in nature.  I excel at things that can
> be manipulated as an image in the mind.  I find that I can do lots of
> math in my mind by forming pictures of it.  To me 7 * 24 is an image of
> blocks of 25 arranged in two rows of four (100 per row) with one missing
> and one square missing from each block of 25.  I can "see" the missing
> block of 25 and the seven missing squares so 7 *  24 = 200 - 25 - 7 =
> 168.  To me *everything* is visual.
>

Funny indeed! I can totally identify with that rows of blocks mental 
picture for visualising numbers and operations on them. I'm going to try 
that approach a bit more and see where it leads me....
For me, even just trying to remember 8 items or so I would place each 
item in it's own box, with two rows of 4 boxes, or for 15 items 3 rows 
of 5 boxes.

> I struggled a bit when I had to start designing FPGAs in HDL rather than
> schematics.  I found written code to convey little understanding or
> form.  In fact, the indentation and white space are the most important
> part of code to me... the "picture" of structure of the code.
>
> Yes, diagrams for complex things can be complex, but only if you don't
> manage them properly.  Just as good code is hierarchical and regular, a
> diagram of that will be well presented and clear.  I always start with a
> block diagram even if it is just in my mind.  So continuing with a
> diagram would be second nature to me.
>
> I think perhaps Dirk is right in that it may be time to consider what
> visual programming can do for us.  It has been used in signal processing
> for some time now and I believe there is a tool from National
> Instruments which produces code for data acquisition and control.  These
> are mainstream products which have been successful for some time now.
> Yes, it is likely overdue to look for better ways to program.
>
I agree that for engineering type, very hardware bound systems, where 
everything (inputs, outputs, transformations) can be described 
completely (and mathematically even), that for those systems it should 
be possible to code by diagramming and evolve the system by alterations 
to the diagrams (but admittantly this is not my field, so I'm probably 
talking nonsens!).

Where I have my doubts is when the system being developed is at a higher 
level, more business system like, where UML and ERDs can describe things 
and perhaps speedup the initial state of the system, but any further 
development, how can that be accomplished by diagramming?

If it is possible to stay completely in the diagramming realm, then yes 
perhaps, but how would things work when at some point the ability of the 
diagram to express a specific meaning breaks down, and the generated 
code needs to be altered - those alterations per definition cannot now 
go back into the diagram.

It almost feels like diagramming can only aid comprehension and speed up 
development, but who knows, maybe that is just a view that stems from 
the fact that diagrams usually appear in specifications, and then is 
translated into code, and then perhaps updated rarely to reflect 
subsequent changes in the code.

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

#32704

On 7/26/2014 5:42 PM, Celeros wrote:
> On 2014-07-25 09:16 PM, rickman wrote:
>> On 7/25/2014 10:22 AM, Roger Levy wrote:
>>
>> Funny, over the years I have come to realize that nearly all of my
>> thought processes are graphical in nature.  I excel at things that can
>> be manipulated as an image in the mind.  I find that I can do lots of
>> math in my mind by forming pictures of it.  To me 7 * 24 is an image of
>> blocks of 25 arranged in two rows of four (100 per row) with one missing
>> and one square missing from each block of 25.  I can "see" the missing
>> block of 25 and the seven missing squares so 7 *  24 = 200 - 25 - 7 =
>> 168.  To me *everything* is visual.
>>
>
> Funny indeed! I can totally identify with that rows of blocks mental
> picture for visualising numbers and operations on them. I'm going to try
> that approach a bit more and see where it leads me....
> For me, even just trying to remember 8 items or so I would place each
> item in it's own box, with two rows of 4 boxes, or for 15 items 3 rows
> of 5 boxes.
>
>> I struggled a bit when I had to start designing FPGAs in HDL rather than
>> schematics.  I found written code to convey little understanding or
>> form.  In fact, the indentation and white space are the most important
>> part of code to me... the "picture" of structure of the code.
>>
>> Yes, diagrams for complex things can be complex, but only if you don't
>> manage them properly.  Just as good code is hierarchical and regular, a
>> diagram of that will be well presented and clear.  I always start with a
>> block diagram even if it is just in my mind.  So continuing with a
>> diagram would be second nature to me.
>>
>> I think perhaps Dirk is right in that it may be time to consider what
>> visual programming can do for us.  It has been used in signal processing
>> for some time now and I believe there is a tool from National
>> Instruments which produces code for data acquisition and control.  These
>> are mainstream products which have been successful for some time now.
>> Yes, it is likely overdue to look for better ways to program.
>>
> I agree that for engineering type, very hardware bound systems, where
> everything (inputs, outputs, transformations) can be described
> completely (and mathematically even), that for those systems it should
> be possible to code by diagramming and evolve the system by alterations
> to the diagrams (but admittantly this is not my field, so I'm probably
> talking nonsens!).
>
> Where I have my doubts is when the system being developed is at a higher
> level, more business system like, where UML and ERDs can describe things
> and perhaps speedup the initial state of the system, but any further
> development, how can that be accomplished by diagramming?
>
> If it is possible to stay completely in the diagramming realm, then yes
> perhaps, but how would things work when at some point the ability of the
> diagram to express a specific meaning breaks down, and the generated
> code needs to be altered - those alterations per definition cannot now
> go back into the diagram.
>
> It almost feels like diagramming can only aid comprehension and speed up
> development, but who knows, maybe that is just a view that stems from
> the fact that diagrams usually appear in specifications, and then is
> translated into code, and then perhaps updated rarely to reflect
> subsequent changes in the code.

Yeah, sometimes even things that you think are inherently graphical, 
like schematics break down.  Board level schematics for modern devices 
with hundreds or even thousands of pins portray nothing of the flow of 
the design.  Usually each device is broken into a set of blocks, each 
block containing an interface or few.  They are placed next to the 
device on the other end of the wire... or sometimes not, the other 
device is on a different page of the schematic and connected by a 
reference to the net name and page number requiring a multi-sheet search 
to find all the components on a net.

This is no different from a net list and often portrays the information 
in a manner more difficult to understand.  The only reason people think 
net lists are difficult to work with directly is because they are 
usually generated by machine without human oriented formatting and 
organization.  If they are written for human consumption they can be 
just as good as a complex schematic if not better since everything on 
one net is listed together.

-- 

Rick

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

#32658

On Fri, 25 Jul 2014 10:10:19 -0400, Celeros <kerneels@gmail.com> wrote:
> On 2014-07-23 08:40 PM, JUERGEN wrote:

>> Well, a Forth Compiler can be fully verified, (more difficult for C)  
>> which would mean (I think) that all the words up to the fully verified  
>> level can be re-used and are verified.
>
> What does it mean when you say that a forth compiler can be fully  
> verified, and that verified words are like gold? I'm quite new to forth.

I'm not sure what he meant, but what I took that to mean was different
 from Roger.  Some interpreted Forths are built up from a small set
of low-level Forth words or "primitives".  These Forths will have only
35 low-level words or so on average, but can have more or less.  All
the other high-level words are built up from this correct low-level set.
So, you only have to verify that the small set of "primitives" are
correctly implemented to ensure that all other high-level words _can be_
correctly implemented.  Of course, the high-level words have to be coded
correctly too, but they can't do anything the low-level words can't do,
i.e., it's fully verifiable.

Alternately, he might've meant that both the high-level and low-level
Forth source code is generally available to Forth users.  So, all or
almost all of Forth can be checked or corrected by anyone and everyone,
i.e., it's fully verifiable.


Rod Pemberton

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

#32699

On 2014-07-25 10:45 PM, Rod Pemberton wrote:
>
> I'm not sure what he meant, but what I took that to mean was different
> from Roger.  Some interpreted Forths are built up from a small set
> of low-level Forth words or "primitives".  These Forths will have only
> 35 low-level words or so on average, but can have more or less.  All
> the other high-level words are built up from this correct low-level set.
> So, you only have to verify that the small set of "primitives" are
> correctly implemented to ensure that all other high-level words _can be_
> correctly implemented.  Of course, the high-level words have to be coded
> correctly too, but they can't do anything the low-level words can't do,
> i.e., it's fully verifiable.
>
> Alternately, he might've meant that both the high-level and low-level
> Forth source code is generally available to Forth users.  So, all or
> almost all of Forth can be checked or corrected by anyone and everyone,
> i.e., it's fully verifiable.
>
>
> Rod Pemberton

Both those interpretations are to me fundamentally brilliant 
characteristics. Thanks, that makes sense.

	

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

#32589

on 23/07/2014 18:32:24, Roger Levy wrote:

> 
> Anyway I had problems installing it. During installation the
> Win32Forth build failed. (I'm on Windows 8 btw).

What was the problem?

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

#32624

> 
> What was the problem?

Sorry, I already deleted the folder - the Win32Forth console popped up and reported errors finding files during metacompilation and keeled.

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

#32604

On Wed, 23 Jul 2014 12:59:42 -0400, <visualforth@rocketmail.com> wrote:

> Software's Weak Link is Code... - this is the title of an 'electronic  
> design' article which I just read:
> [link]
>
> Peter Thorne writes about a paradigm shift in which we are living now -  
> leaving 'hand-coding' behind us, switching to automated code generation  
> using system-diagram-based tools and the like.

Someone must still code the "system-diagram-based tools" via 'hand-coding'.

Once the "system-diagram-based tools" are coded correctly, then anything
compiled using them could solve the problem of code being the weak link,
if code really is such a problem, which I doubt.

The big advantage isn't the elimination of code, but the elimination of
coding skills.  They've replaced skilled programming with point-and-click
diagramming where you don't need an education or skills in programming,
math, engineering, problem solving, or much intelligence to code, etc,
although you may need some skills of the specific domain, say PLDs or
EFT or OLTP or whatever.

Using diagrams would offer tremendous advantages to those who are
especially visual as compared to those who are verbal.  Unfortunately,
verbal people account for 75% of the populace.  So, you diminish the
number of people who would work as effectively with the new tools.  I'm
not saying verbal people can't use visual tools.  Visual people use
verbal tools every day.  I'm just saying that one group is likely more
effective with specific tools than the other.

Another advantage is that an image or "visual code" can represent far
more information than some lines of written code.  If anything, the
"image is worth a thousand words" belief is comparable to a language
with a high, average level of "function points" per code statement.

> This is a chance for Forth to stay alive. Using Forth is an excellent  
> choice for building such kind of tools. Forth has all the features  
> needed for automatic software generation.

Compilers, including C compilers, have "all the features" that are
needed for "automatic software generation" too.  There are also many
programs which do automatic code generation, e.g., Lex, Yacc, etc.

> VisualFORTH uses automatic software generation, and that's
> the way to go.

Ok.  But, it seems that Forth would be very "late to the party" to me,
especially considering that VisualBasic has been around since 1991 ...
I.e., timing, advantage, etc issues.


Rod Pemberton

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

#32607

On Thursday, 24 July 2014 08:26:58 UTC+1, Rod Pemberton  wrote:
> The big advantage isn't the elimination of code, but the elimination of
> coding skills.  They've replaced skilled programming with point-and-click
> diagramming where you don't need an education or skills in programming,
> math, engineering, problem solving, or much intelligence to code, etc,
> although you may need some skills of the specific domain, say PLDs or
> EFT or OLTP or whatever.

Fully agree. There's a desire to dumb the art down, presumably so that
the "programming" jobs can be given to the "undocumented citizens" that
are walking across the southern border courtesy of the Dream Act, for
two thirds of the going rate.

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

#32674

On Thu, 24 Jul 2014 03:26:58 -0400, Rod Pemberton wrote:

> On Wed, 23 Jul 2014 12:59:42 -0400, <visualforth@rocketmail.com> wrote:
> 
>> Software's Weak Link is Code... - this is the title of an 'electronic
>> design' article which I just read:
>> [link]
>>
>> Peter Thorne writes about a paradigm shift in which we are living now -
>> leaving 'hand-coding' behind us, switching to automated code generation
>> using system-diagram-based tools and the like.
> 
> Someone must still code the "system-diagram-based tools" via
> 'hand-coding'.
> 
The fact that someone had to make the stone-ax to..to dig the coal, to
make the electricity, to make the aluminum..to  ;doesn't stop you from
useing the airliner?

> Once the "system-diagram-based tools" are coded correctly, then anything
> compiled using them could solve the problem of code being the weak link,
> if code really is such a problem, which I doubt.
> 
> The big advantage isn't the elimination of code, but the elimination of
> coding skills.

You are just rephrasing the issue.

>  They've replaced skilled programming with
> point-and-click diagramming where you don't need an education or skills
> in programming, math, engineering, problem solving, or much intelligence
> to code, etc, although you may need some skills of the specific domain,
> say PLDs or EFT or OLTP or whatever.
> 
"point & klik" sees only what-is-physically-done.
"recognise & select, instead of DUMB/inefficient remembering" is the 
ADVANTAGE.
> Using diagrams would offer tremendous advantages to those who are
> especially visual as compared to those who are verbal.  Unfortunately,
> verbal people account for 75% of the populace.  So, you diminish the
> number of people who would work as effectively with the new tools.

Yes: the econamy doesn't NEED them; like the 95% population that used
to be farmers. Now they can all be politicians, lawers and Maidox.

>  I'm
> not saying verbal people can't use visual tools.  Visual people use
> verbal tools every day.  I'm just saying that one group is likely more
> effective with specific tools than the other.
> 
Yes.

> Another advantage is that an image or "visual code" can represent far
> more information than some lines of written code.  If anything, the
> "image is worth a thousand words" belief is comparable to a language
> with a high, average level of "function points" per code statement.
> 
>> This is a chance for Forth to stay alive. Using Forth is an excellent
>> choice for building such kind of tools. Forth has all the features
>> needed for automatic software generation.
> 
> Compilers, including C compilers, have "all the features" that are
> needed for "automatic software generation" too.  There are also many
> programs which do automatic code generation, e.g., Lex, Yacc, etc.
> 
>> VisualFORTH uses automatic software generation, and that's the way to
>> go.
> 
I like that idea. Where did color-forth "go".
I've been using 'very visual' [can work without a keybrd] ETHOberon,
since 90's. For me, anything else is like tying your shoes-laces
wearing boxing-gloves. But the kiddies don't use ETHO.
 
> Ok.  But, it seems that Forth would be very "late to the party" to me,
> especially considering that VisualBasic has been around since 1991 ...
> I.e., timing, advantage, etc issues.
> 
> 
Wasn't VB very popular?

> Rod Pemberton

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

#32682

On Sat, 26 Jul 2014 04:17:27 -0400, Unknown <dog@gmail.com> wrote:
> On Thu, 24 Jul 2014 03:26:58 -0400, Rod Pemberton wrote:
>> On Wed, 23 Jul 2014 12:59:42 -0400, <visualforth@rocketmail.com> wrote:

>> Using diagrams would offer tremendous advantages to those who are
>> especially visual as compared to those who are verbal.  Unfortunately,
>> verbal people account for 75% of the populace.  So, you diminish the
>> number of people who would work as effectively with the new tools.
>
> Yes: the econamy doesn't NEED them; like the 95% population that used
> to be farmers. Now they can all be politicians, lawers and Maidox.

The "economy" (personified) only needs so many mininions such as ditch
diggers, street pavers, truckers, porn stars, strippers, lawyers, drug
dealers, and cops.  What is everyone else supposed to do?  Riot?  Go to
prison?  Be deported? Become a terrorist?  Become a militant?  Take
extreme risks?  Be a drunk?  Call Death?  There is a certain natural
level of necessity for occupations, once reached represents saturation.

>> But, it seems that Forth would be very "late to the party" to me,
>> especially considering that VisualBasic has been around since 1991 ...
>> I.e., timing, advantage, etc issues.
>>
>>
> Wasn't VB very popular?
>

Was VB popular or unpopular?  I think corporations used it to obtain
people who could be pushed into programming for minimal salary.

This isn't necessarily a bad thing.  Reducing the costs of companies
increases their profit, which can boost their wealth, and indirectly,
sometimes their stock price.  It allows resources, such as people and
capital, to be free'd up for other purposes.  The problem is that work
is needed to keep people complacent and content.  Without jobs, people
take paths that prove destructive to a society, such as the hypotheticals
and historically proven options listed in the paragraph above.

If VB was very popular, then what's left for a visual Forth to
do in this area?  Replace it?


Rod Pemberton

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

#32702

On Saturday, July 26, 2014 5:39:54 AM UTC-4, Rod Pemberton wrote:
> 
> Was VB popular or unpopular?  I think corporations used it to obtain
> people who could be pushed into programming for minimal salary.

Most of my life I worked self employed. Forth helped me to survive.
When I worked as consultant for Lucent Technologies, I had to write a program for manufacturing - writing production data into I2C memory - using VB, because VB was a standard there. It only needed a short time to learn so much of VB that I could do this project. I wrote the BASIC routines the Forth way with factoring and so on. After a while BASIC was totally boring to me, because I didn't have the freedom of programming which I have with Forth. So I started hoping that soon I will get a notice that Visual Forth is available somewhere.

> This isn't necessarily a bad thing.  Reducing the costs of companies
> increases their profit, which can boost their wealth, and indirectly,
> sometimes their stock price.  It allows resources, such as people and
> capital, to be free'd up for other purposes.  The problem is that work
> is needed to keep people complacent and content.  Without jobs, people
> take paths that prove destructive to a society, such as the hypotheticals
> and historically proven options listed in the paragraph above.
 
I waited for ten years. No Visual Forth in site. There was a Win32Forth application called 'ForthForm' - it was possible to place buttons etc., but I didn't have a clue how to tell these buttons to do something for me, to start a function or something like that. I got one example running, but it was really hard work.

So, after these ten years I assumed I have to do it by myself. And so I did. You can read the whole story at http://visualforth.blogspot.com - it starts in May 2009. 

> If VB was very popular, then what's left for a visual Forth to
> do in this area?  Replace it?

If C was very popular, then what's left for Forth to do in this area? Replace it?

For me VisualFORTH is invaluable. I start with a graphic template and I use it as an organizing element for project management. VisualFORTH automatically generates the code for this graphic template, and my Forth code is interwoven with it.

I am sure you know how long it does take to convert a running GUI program to an executable. With VB back then it needed a long time, and the result was a bunch of files. This is different with vF. With vF it is fast, and the result is one file only.

To get an executable file, one click only is needed, and VisualFORTH puts everything together automatically, code, pictures, everything. Within seconds this is done and can run immediately on every Windows computer including Windows 7 - Windows 8 will follow as soon as I have a Windows 8 computer at hand.

VisualFORTH has features which the VB I did know didn't have. For example, with vF it is possible to automatically make button arrays with up to 256 buttons - or picture arrays with up to 256 pictures. I did some research, and the answers I got, show me that with VB you have to set every button separately. Of course VB is offering a lot of stuff nowadays which vF doesn't offer. But it is not needed - it is Forth, and you can control all your applications using vF. 

You know the power of Forth, and with VisualFORTH the power of Forth is unleashed. And everything is written in Forth, so extensions can be done easily. To see a demo: the 4E4th-IDE is written in VisualFORTH.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web