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

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

+DO and programming without stack manipulation words

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

Contents

  +DO and programming without stack manipulation words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 13:41 +0000
    Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-18 17:30 +0100
      Re: +DO and programming without stack manipulation words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 16:50 +0000
        Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-18 18:56 +0100
          Re: +DO and programming without stack manipulation words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 18:25 +0000
            Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-18 22:21 +0100
              Re: +DO and programming without stack manipulation words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-19 11:42 +0000
                Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-19 14:59 +0100
                  Re: +DO and programming without stack manipulation words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-20 02:13 -0500
                  Re: +DO and programming without stack manipulation words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-20 12:50 +0000
              Re: +DO and programming without stack manipulation words Alexander Skobelev <al.skobelev@gmail.com> - 2014-03-19 20:47 -0700
              Re: +DO and programming without stack manipulation words Alexander Skobelev <al.skobelev@gmail.com> - 2014-03-19 21:24 -0700
              Re: +DO and programming without stack manipulation words Alexander Skobelev <al.skobelev@gmail.com> - 2014-03-19 23:35 -0700
            Re: +DO and programming without stack manipulation words Mark Wills <markwills1970@gmail.com> - 2014-03-20 01:27 -0700
          Re: +DO and programming without stack manipulation words Paul Rubin <no.email@nospam.invalid> - 2014-03-18 12:24 -0700
      Re: +DO and programming without stack manipulation words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-18 19:23 +0000
      Re: +DO and programming without stack manipulation words Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-03-19 18:36 +0000
        Re: +DO and programming without stack manipulation words Spam@ControlQ.com - 2014-03-19 17:32 -0400
          Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-19 23:48 +0100
        Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-19 23:17 +0100
          Re: +DO and programming without stack manipulation words Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-03-20 01:47 +0000
            Re: +DO and programming without stack manipulation words Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-20 23:00 +0100
        Re: +DO and programming without stack manipulation words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-20 13:00 +0000

Page 1 of 2  [1] 2  Next page →

#29061 — +DO and programming without stack manipulation words

This year I use Forth in the first part of our introductory
programming course beginners.  You can find the course notes (in
German) on

<http://www.complang.tuwien.ac.at/anton/lvas/pk/>

I don't teach them full Forth.  In particular, I don't teach them
stack manipulation (apart from DROP).  Instead, I use locals in a
static-single-assignment way.  That leads to interesting code such as

: step { xn -- xn1 }
  xn 2 mod 0 = if
    xn 2 /
  else
    xn 3 * 1 +
  endif ;

: steps ( x0 k -- )
  0 ?do { xn }
    xn .
    xn step
  loop drop ;

Locals definitions inside control structures (and sometimes several
locals definitions) are necessary given the restrictions I use.

One disadvantage of using locals (at all) is that I cannot write
traces of execution that can be executed directly.

When I started out, I wanted to make the course not so
Gforth-specific, so I taught them ?DO...LOOP instead of +DO...LOOP and
U+DO...LOOP.  On at least the FAC example this leads to less efficient
code.  A solution that works for n>=0 looks like this with ?DO:

: fac { n -- n! }
  1
  n 1 + 1 ?do ( n1 ) \ n1 = 1*1*2*..*(i-1)=(i-1)!
    i *       ( n2 ) \ n2 = 1*1*2*..*i    = i!
  loop ;

With +DO we can use 

: fac { n -- n! }
  1
  n 1 + 2 +do ( n1 ) \ n1 = 1*2*..*(i-1)=(i-1)!
    i *       ( n2 ) \ n2 = 1*2*..*i    = i!
  loop ;

which is comes out straightforward from my explanation and performs
one iteration less (and therefore is probably more efficient).

- 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 2013: http://www.euroforth.org/ef13/

[toc] | [next] | [standalone]

#29063

Anton Ertl wrote:

> This year I use Forth in the first part of our introductory
> programming course beginners.  You can find the course notes (in
> German) on
> 
> <http://www.complang.tuwien.ac.at/anton/lvas/pk/>

Nice.  Two comments: Your students probably don't use a Nokia 3210, but a 
smartphone, and can get Gforth from the Play Store.  I had some discussions 
with Simon, our local "beginner" (i.e he hasn't used Forth for 10 years), an 
done thing I want to add is embedded help: Ask for help on some Forth word, 
and the browser will open the corresponding part of the documentation.

The other comment is about the 10 years: Recent studies have found that this 
depends on people - this is an average.  It takes on average 10k hours to 
become a chess master, but it takes talent and on average 14k hours to 
become a chess grandmaster (and those who become grandmaster get to the 
master level in just a few k hours).  The others with less talent won't even 
get there.

http://www.newyorker.com/online/blogs/sportingscene/2013/08/psychology-ten-thousand-hour-rule-complexity.html

So yes, complex tasks (programming definitely is) take long to master, *and* 
they require talent. And maybe you really should start at the age of 5.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29065

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> This year I use Forth in the first part of our introductory
>> programming course beginners.  You can find the course notes (in
>> German) on
>> 
>> <http://www.complang.tuwien.ac.at/anton/lvas/pk/>
>
>Nice.  Two comments: Your students probably don't use a Nokia 3210, but a 
>smartphone, and can get Gforth from the Play Store.

There have been several questions about where to get it for MacOS X,
and I could not answer that.  Not sure what the comment about the
Nokia 3210 is about.  The Play Store is about Android smart phones,
right?

>The other comment is about the 10 years: Recent studies have found that this 
>depends on people - this is an average.  It takes on average 10k hours to 
>become a chess master, but it takes talent and on average 14k hours to 
>become a chess grandmaster (and those who become grandmaster get to the 
>master level in just a few k hours).

I think this number comes from the amount of time we have from when we
can start to study a field until our performance lowers because of
age.  That's maybe 20 years in most areas (obviously less for female
gymnasts).  The first things we learn have the most benefit, later the
benefit per learning effort diminishes, so at some point we declare
someone expert (or master or grandmaster).

If we had 5 years until our performance diminishes, people would be
chess grandmasters after maybe 3 years.  If we had 500, maybe after
300; but maybe then the development speed of the field would set the
upper limit of the time for expertise; or maybe the field would
develop slower, because there would be less turnover of experts.

But the comment is mainly aimed at people who have learned Java in
secondary school and now think they know it all.

- 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 2013: http://www.euroforth.org/ef13/

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

#29066

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>
>>> This year I use Forth in the first part of our introductory
>>> programming course beginners.  You can find the course notes (in
>>> German) on
>>> 
>>> <http://www.complang.tuwien.ac.at/anton/lvas/pk/>
>>
>>Nice.  Two comments: Your students probably don't use a Nokia 3210, but a
>>smartphone, and can get Gforth from the Play Store.
> 
> There have been several questions about where to get it for MacOS X,
> and I could not answer that.

I could build a binary distribution, where unpacking and "make install" is 
sufficient.  I haven't checked with recent Xcode how well building Gforth 
works with llvm-gcc, I stayed with the last GCC Xcode version.

> Not sure what the comment about the
> Nokia 3210 is about.  The Play Store is about Android smart phones,
> right?

Yes.  That's the kind of mobile devices your students probably use.

> I think this number comes from the amount of time we have from when we
> can start to study a field until our performance lowers because of
> age.  That's maybe 20 years in most areas (obviously less for female
> gymnasts).  The first things we learn have the most benefit, later the
> benefit per learning effort diminishes, so at some point we declare
> someone expert (or master or grandmaster).
> 
> If we had 5 years until our performance diminishes, people would be
> chess grandmasters after maybe 3 years.  If we had 500, maybe after
> 300; but maybe then the development speed of the field would set the
> upper limit of the time for expertise; or maybe the field would
> develop slower, because there would be less turnover of experts.

One of the comparisons made was "composers", and it took Mozart and 
Beethoven about as long to become good as the others, who started later.  
And the other are these chess masters, where most of them start at the age 
of 5.  For sure they aren't "old" when they achieve master level at 15.

> But the comment is mainly aimed at people who have learned Java in
> secondary school and now think they know it all.

Gerald claimed that it takes a lot longer to reach "master level" in Forth 
than in other languages.  With those, it takes some weeks, and then you 
"know it all", and there's little further progress.  You may learn more 
APIs, but the way you use the language will not significantly change.  I 
think this property is a result of the large demand for programming 
languages which can be learned in three days.

The "master" level is usually not defined by an arbitrary time, but by an 
achievement of understanding, and it's the third level.  The first level is 
that you can follow the instructions of a master, the second level is that 
you can do independent work using what you have learned from your masters, 
and the third level is that you can improve yourself beyond of what you have 
been taught.  A grandmaster then is somebody who has a large unique 
skillset, invented by himself.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29067

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>
>>>> This year I use Forth in the first part of our introductory
>>>> programming course beginners.  You can find the course notes (in
>>>> German) on
>>>> 
>>>> <http://www.complang.tuwien.ac.at/anton/lvas/pk/>
>>>
>>>Nice.  Two comments: Your students probably don't use a Nokia 3210, but a
>>>smartphone, and can get Gforth from the Play Store.
>> 
>> There have been several questions about where to get it for MacOS X,
>> and I could not answer that.
>
>I could build a binary distribution, where unpacking and "make install" is 
>sufficient.

Yes, please.

>> If we had 5 years until our performance diminishes, people would be
>> chess grandmasters after maybe 3 years.  If we had 500, maybe after
>> 300; but maybe then the development speed of the field would set the
>> upper limit of the time for expertise; or maybe the field would
>> develop slower, because there would be less turnover of experts.
>
>One of the comparisons made was "composers", and it took Mozart and 
>Beethoven about as long to become good as the others, who started later.  
>And the other are these chess masters, where most of them start at the age 
>of 5.  For sure they aren't "old" when they achieve master level at 15.

No.  But their rate of improvement has slowed down so much after the
ten years that the improvement from then until the performance starts
to degrade is small.  Of course, if the performance degraded only
after 500 years, the improvement in that time would still be
significant, and that's why we would not consider them masters after
10 years.

Hmm, for chess we might check my theory of a gradual slowdown in
improvement over time by graphing Elo ratings over time for various
grand masters.

>Gerald claimed that it takes a lot longer to reach "master level" in Forth 
>than in other languages.  With those, it takes some weeks, and then you 
>"know it all", and there's little further progress.  You may learn more 
>APIs, but the way you use the language will not significantly change.  I 
>think this property is a result of the large demand for programming 
>languages which can be learned in three days.
>
>The "master" level is usually not defined by an arbitrary time, but by an 
>achievement of understanding, and it's the third level.  The first level is 
>that you can follow the instructions of a master, the second level is that 
>you can do independent work using what you have learned from your masters, 
>and the third level is that you can improve yourself beyond of what you have 
>been taught.  A grandmaster then is somebody who has a large unique 
>skillset, invented by himself.

So your claim (or your take on Gerald's claim) is that in, say, Java,
you only reach the second level, while in Forth you need to reach the
third level until you are considered to have learned the language?  I
have my doubts.  I think mastery in programming includes knowing
several programming languages.  Also, Java is a complex beast (not as
bad as C++, but still), and it's API, too.  They are not made to be
learned in three days, and a few weeks are not sufficient for a
beginner, either. 

Also, I heard about a professional programmer who AFAIK does not do
anything fancy that he considers that he takes on the order of years
(don't remember the exact time) to become fully productive with a
toolset (IDE, compiler etc.).

- 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 2013: http://www.euroforth.org/ef13/

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

#29070

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>
>>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>I could build a binary distribution, where unpacking and "make install" is
>>sufficient.
> 
> Yes, please.

I've uploaded binary distributions for x86_64 Darwin compiled with GCC 4.8.2 
(that's a non-XCode GCC) for both 0.7.3 and the current git head (the latter 
one into Snapshots).  Feedback welcome; the 0.7.3 "make install" reports an 
error, but that concerns the gforth.elc; otherwise it installs fine.  The 
bindist doesn't package precompiled libcc interfaces, that's something we 
should considder doing.

> Hmm, for chess we might check my theory of a gradual slowdown in
> improvement over time by graphing Elo ratings over time for various
> grand masters.

At least for young chessmasters, there are charts online:

http://chessaccount.wordpress.com/wesley-so-2/worlds-top-junior-chess-players-by-age-february-2011/

http://en.chessbase.com/post/wei-yi--youngest-2600-gm-ever-011113

The latter plots show how some of them developed after they were yount chess 
grandmasters, and the plot has two parts: the steep part pre-pubertary, and 
the much slower growth post-pubertary, with sometimes even a bump in between 
the two parts.  In other words: To gain 300 points pre-pubertary, you need 2 
years.  To gain another 300 points post-pubertary, you need 10 years, and 
then you are very likely at your personal peak level.

> So your claim (or your take on Gerald's claim) is that in, say, Java,
> you only reach the second level, while in Forth you need to reach the
> third level until you are considered to have learned the language?  I
> have my doubts.  I think mastery in programming includes knowing
> several programming languages.  Also, Java is a complex beast (not as
> bad as C++, but still), and it's API, too.  They are not made to be
> learned in three days, and a few weeks are not sufficient for a
> beginner, either.

Well, it's probably because the mainstream languages are quite similar.  10 
days ago, I had a meeting with several hackers about building a new 
Internet, at the TU Munich, and they had several students there.  One 
student told me about a course where he had two days to complete some task 
in Java, he didn't know the language, and the other students in his group 
didn't do anything.  He was successful at learning enough Java to complete 
that task in these two days.

And the Java API stuff is usually something nobody is fluent.  My approach 
usually is to read the documentation and then be creative how to use it, but 
then I fail - the Dalvik API is too buggy for that.  After failing, I resort 
to cut&paste the examples, which work.  The examples are usually the only 
way to get the API working (usually, there is some undocumented order of how 
you have to set up things and a bunch of ways to set up the same thing, of 
which only one really works ;-), so cut&paste programming is the only thing 
you can do.  And that's what most Java programmers do.

> Also, I heard about a professional programmer who AFAIK does not do
> anything fancy that he considers that he takes on the order of years
> (don't remember the exact time) to become fully productive with a
> toolset (IDE, compiler etc.).

Sounds more like the "you can stay amateur forever" part of the story: It 
takes some time to become a master, but there is no guarantee that you'll 
ever become a master.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29073

In article <lgadd2$lpq$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
<SNIP>
>
>Well, it's probably because the mainstream languages are quite similar.  10
>days ago, I had a meeting with several hackers about building a new
>Internet, at the TU Munich, and they had several students there.  One
>student told me about a course where he had two days to complete some task
>in Java, he didn't know the language, and the other students in his group
>didn't do anything.  He was successful at learning enough Java to complete
>that task in these two days.
>
>And the Java API stuff is usually something nobody is fluent.  My approach
>usually is to read the documentation and then be creative how to use it, but
>then I fail - the Dalvik API is too buggy for that.  After failing, I resort
>to cut&paste the examples, which work.  The examples are usually the only
>way to get the API working (usually, there is some undocumented order of how
>you have to set up things and a bunch of ways to set up the same thing, of
>which only one really works ;-), so cut&paste programming is the only thing
>you can do.  And that's what most Java programmers do.

That describes my experience with MS-Windows api's of late.
Trying to communicate with a Launchpad is just two API calls,
but things turn out not to work quite as documented.
Then there is no real documentation that could be construed as a
contract. For example, if you read one byte of an emulated serial
line, and there is none available, does it wait, or return with
a zero count? And this is about as simple an API as it gets.

Does the same API work the same between CE and NT. There is just one
way, try it!

I've thought about going the direction of defining a test sequence for
the whole of the Windows API's. Then write your own that pass the
test, and require to have those installed before you guarantee your
banking program. The end would be (hopefully) that everybody uses
GPL-ed versions of libraries.

>
>--
>Bernd Paysan

Groetjes Albert
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#29080

Albert van der Horst wrote:

> I've thought about going the direction of defining a test sequence for
> the whole of the Windows API's. Then write your own that pass the
> test, and require to have those installed before you guarantee your
> banking program. The end would be (hopefully) that everybody uses
> GPL-ed versions of libraries.

The way Ulrich Drepper maintained glibc showed that GPL by itself doesn't 
help.  The GPL helps in so far that you can look at the stuff, and decide 
that it's a waste of time, and the maintainer can't be trusted.  Last 
Drepper I was angry about: The glibc has debugging hooks for memory 
allocation.  The default hook is to print a backtrace and terminate the 
program.  This is pretty useless for Gforth, you don't want to see the C 
backtrace, you want to see the Forth backtrace.  So I did set my own 
debugging hooks.

However, these debugging hooks only work on single-threaded programs.  This 
is an undocumented "feature", as Ulrich Drepper stated that this is a 
"wontfix".  Now maybe I can reopen the bug, because Ulrich Drepper is no 
longer the glibc maintainer...

Bugs do happen.  High quality libraries have good isolation of features, and 
do a lot of tests on them.  This is all expensive, and we programmers like 
to write code, not to write tests.  Usually, programmers are ok when they 
have a proof that their program does the required functionality.  Proof by 
existence (you know, the way mathematicians say "for condition A, there 
exists a B in the number space C, but we haven't found it yet").

From the quality point of view, Dalvik reminds me a lot of Windows.  This is 
very likely the result of a large corporate team working on it.  If you 
consider that many companies in America drive their employees into at least 
some burnout syndromes within years, and it takes a decade to become 
actually good at programming, you can see why this is like that: The 
programmer has no time to become good, because once burned out, he's not 
able to improve his skills (rather the contrary).  Google is a very typical 
"we want young people, because everybody else is bad" shop, with a few 
exceptions like Ken Thompson.  And I'm sure, compared to the average 
Googler, Ken is like Bai Mei in Kill Bill Volume II.  "Hahaha, you so-called 
fine art of Java programming is only good for fat bloatware!"

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29093

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Albert van der Horst wrote:
> 
>> I've thought about going the direction of defining a test sequence for
>> the whole of the Windows API's. Then write your own that pass the
>> test, and require to have those installed before you guarantee your
>> banking program. The end would be (hopefully) that everybody uses
>> GPL-ed versions of libraries.
> 
> The way Ulrich Drepper maintained glibc showed that GPL by itself doesn't 
> help.  The GPL helps in so far that you can look at the stuff, and decide 
> that it's a waste of time, and the maintainer can't be trusted.  Last 
> Drepper I was angry about:

I know what you mean about Uli, but I think the GPL does help:
projects can be forked, and indeed glibc was.

> From the quality point of view, Dalvik reminds me a lot of Windows.
> This is very likely the result of a large corporate team working on
> it.  If you consider that many companies in America drive their
> employees into at least some burnout syndromes within years, and it
> takes a decade to become actually good at programming, you can see
> why this is like that: The programmer has no time to become good,
> because once burned out, he's not able to improve his skills (rather
> the contrary).  Google is a very typical "we want young people,
> because everybody else is bad" shop, with a few exceptions like Ken
> Thompson.

Really?  The Googlers I know aren't like that, and last time I visited
the campus it looked like a normal mix of programmers.

Andrew.

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

#29096

In article <lgc7se$1uk$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Albert van der Horst wrote:
>
>> I've thought about going the direction of defining a test sequence for
>> the whole of the Windows API's. Then write your own that pass the
>> test, and require to have those installed before you guarantee your
>> banking program. The end would be (hopefully) that everybody uses
>> GPL-ed versions of libraries.
>
>The way Ulrich Drepper maintained glibc showed that GPL by itself doesn't
>help.  The GPL helps in so far that you can look at the stuff, and decide
>that it's a waste of time, and the maintainer can't be trusted.  Last
>Drepper I was angry about: The glibc has debugging hooks for memory
>allocation.  The default hook is to print a backtrace and terminate the
>program.  This is pretty useless for Gforth, you don't want to see the C
>backtrace, you want to see the Forth backtrace.  So I did set my own
>debugging hooks.
>
>However, these debugging hooks only work on single-threaded programs.  This
>is an undocumented "feature", as Ulrich Drepper stated that this is a
>"wontfix".  Now maybe I can reopen the bug, because Ulrich Drepper is no
>longer the glibc maintainer...

I was appalled at a bug closed with "there is unsufficient data to work
on it" in Debian. The bug is that GIMP installs itself as as a default
pdf reader. You can't uninstall it either.
The only reasonable work around was to uninstall gimp.
(Always do "open with" ? No way.)
But how on earth can one say there is something unclear about that bug.
So maybe the people at Canonical are pressed to close as many bugs as possible.
(I see that this has started in 2008!)

>
>Bugs do happen.  High quality libraries have good isolation of features, and
>do a lot of tests on them.  This is all expensive, and we programmers like
>to write code, not to write tests.  Usually, programmers are ok when they
>have a proof that their program does the required functionality.  Proof by
>existence (you know, the way mathematicians say "for condition A, there
>exists a B in the number space C, but we haven't found it yet").

ciforth has one source for code, test and documentation.
Testing as an afterthought Just Doesn't Work. The testing for e.g.
DROP is cavalier, but a stupid mistake will be stopped in its tracks.

>
>From the quality point of view, Dalvik reminds me a lot of Windows.  This is
>very likely the result of a large corporate team working on it.  If you
>consider that many companies in America drive their employees into at least
>some burnout syndromes within years, and it takes a decade to become
>actually good at programming, you can see why this is like that: The
>programmer has no time to become good, because once burned out, he's not
>able to improve his skills (rather the contrary).  Google is a very typical
>"we want young people, because everybody else is bad" shop, with a few
>exceptions like Ken Thompson.  And I'm sure, compared to the average
>Googler, Ken is like Bai Mei in Kill Bill Volume II.  "Hahaha, you so-called
>fine art of Java programming is only good for fat bloatware!"

Why then came Google hunting after my grey head?

But anyway, there is a problem with the crowd support a la linux and
wikipedia.
You can see it in wikipedia. You can reach a certain level, but then
people start deproving things, because they can't understand what the
experts have written. To an extent is a good thing for wikipedia (we
don't want entries that only an expert can understand). For programs
probably not so good.


>
>--
>Bernd Paysan

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#29090

On Wednesday, March 19, 2014 1:21:38 AM UTC+4, Bernd Paysan wrote:

> I've uploaded binary distributions for x86_64 Darwin compiled with GCC
> 4.8.2 (that's a non-XCode GCC) for both 0.7.3 and the current git head
> (the latter one into Snapshots).  Feedback welcome; the 0.7.3 "make
> install" reports an error, but that concerns the gforth.elc; otherwise
> it installs fine.  The bindist doesn't package precompiled libcc
> interfaces, that's something we should considder doing.
> 

Just to let you know: I was able to install it (with the gforth.elc
error message) only after I installed GNU libtool from Homebrew. And just in
case you don't know - Homebrew has gforth 0.7.2.

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

#29091

On Wednesday, March 19, 2014 1:21:38 AM UTC+4, Bernd Paysan wrote:

> I've uploaded binary distributions for x86_64 Darwin compiled with GCC
> 4.8.2 (that's a non-XCode GCC) for both 0.7.3 and the current git head
> (the latter one into Snapshots).  Feedback welcome; the 0.7.3 "make
> install" reports an error, but that concerns the gforth.elc; otherwise
> it installs fine.  The bindist doesn't package precompiled libcc
> interfaces, that's something we should considder doing.
> 

It looks like the archive misses the lib folder so 'make install' fails
with message:

...
if test -n "glibtool --tag=CC"; then for i in cstr.fs unix/socket.fs; do \
		   glibtool --tag=CC --silent --mode=install /usr/bin/install -c lib/gforth/0.7.3/libcc-named/`basename $i .fs`.la /usr/local/lib/gforth/0.7.3/libcc-named/`basename $i .fs`.la; \
		done; fi
glibtool: install: `lib/gforth/0.7.3/libcc-named/cstr.la' is not a valid libtool archive
glibtool: install: Try `glibtool --help --mode=install' for more information.
glibtool: install: `lib/gforth/0.7.3/libcc-named/socket.la' is not a valid libtool archive
glibtool: install: Try `glibtool --help --mode=install' for more information.
make: *** [install] Error 1

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

#29092

On Wednesday, March 19, 2014 1:21:38 AM UTC+4, Bernd Paysan wrote:

> I've uploaded binary distributions for x86_64 Darwin compiled with GCC
> 4.8.2 (that's a non-XCode GCC) for both 0.7.3 and the current git head
> (the latter one into Snapshots).  Feedback welcome; the 0.7.3 "make
> install" reports an error, but that concerns the gforth.elc; otherwise
> it installs fine.  The bindist doesn't package precompiled libcc
> interfaces, that's something we should considder doing.
> 

I was able to compile the both versions by installing GNU libtool and
gcc-4.2 from Homebrew. The git head refers to sincos() that absents on
Mac OS X and there is no sincos.c file in the sources yet. I just
changed the definition if fsincos to use sin() and cos() and removed
reference to sincos.o from Makefile.
Thanks for the build. The Homebrew has gforth-0.7.2 but it looks like
it requires pre-built gforth executable to be compiled.

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

#29094

</lurk>
Meh. All this talk about "mastery" is a load of wishy washy bollocks in my opinion! (Not that anybody asked for it)

Getting your product out of the door, on time, and bug free. That's what it's all about. If you can do that, you may not be a "master" but you will be a professional.
<lurk>

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

#29068

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Gerald claimed that it takes a lot longer to reach "master level" in
> Forth than in other languages.

Depends on prior experience and the languages in question, but generally
probably true.  It seems to me that the Forth approach is often to seek
a different goal than with other languages.  That is one of the things
that makes Forth interesting.

> The "master" level is usually not defined by an arbitrary time, but by an 
> achievement of understanding, and it's the third level.  The first level is 
> that you can follow the instructions of a master, the second level is that 
> you can do independent work using what you have learned from your masters, 
> and the third level is that you can improve yourself beyond of what you have 
> been taught.  A grandmaster then is somebody who has a large unique 
> skillset, invented by himself.

That's an interesting analysis and I think the levels you mention mean
something, but those labels don't really apply.  Most programmers have
to be taught a few things at beginner level, and then immediately engage
in a lot of self-improvement by practice and exploring.  I would not
call that phase "mastery".  I'd say it's more like:

1. Beginner - faced with a problem (e.g. how to code something), you
don't know how to do it except with a lot of unsuccessful attempts or
with outside help.  You are likely to get the answer wrong without being
able to tell that it's wrong.

2. Intermediate - you know enough to figure out the answer by careful
and explicit reasoning.  If you don't find the right answer, you are at
least aware that you haven't found it.  This is like knowing a foreign
natural language well enough to write grammatically by having studied
its grammar rules, and carefully considering them while you write.

3. Mastery - you know the answer immediately and intuitively, like
reaching fluency with a natural language.

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

#29069

In article <lg9sbg$6of$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Anton Ertl wrote:
>
>> This year I use Forth in the first part of our introductory
>> programming course beginners.  You can find the course notes (in
>> German) on
>>
>> <http://www.complang.tuwien.ac.at/anton/lvas/pk/>
>
>Nice.  Two comments: Your students probably don't use a Nokia 3210, but a
>smartphone, and can get Gforth from the Play Store.  I had some discussions
>with Simon, our local "beginner" (i.e he hasn't used Forth for 10 years), an
>done thing I want to add is embedded help: Ask for help on some Forth word,
>and the browser will open the corresponding part of the documentation.

Interesting idea, I discover that from a shell
firefox 'file:ci86.lina64.html#DROP'
just works, and even if I replace DROP by $@ are other weird Forth sequences.
[I do have the habit to make the node names (in info too) equal to the
Forth names.]

WANT GET-ENV
: HELP
   "firefox 'file:" PAD $!
   "HOME" GET-ENV PAD $+!
   "/Desktop/ci86.lina64.html" PAD $+!
   &# PAD $C+
   NAME PAD $+!
   &' PAD $C+
   PAD $@ SYSTEM ;

doesn't work if started from a console Forth, but the idea is nice.

>
>The other comment is about the 10 years: Recent studies have found that this
>depends on people - this is an average.  It takes on average 10k hours to
>become a chess master, but it takes talent and on average 14k hours to
>become a chess grandmaster (and those who become grandmaster get to the
>master level in just a few k hours).  The others with less talent won't even
>get there.
>
>http://www.newyorker.com/online/blogs/sportingscene/2013/08/psychology-ten-thousand-hour-rule-complexity.html
>
>So yes, complex tasks (programming definitely is) take long to master, *and*
>they require talent. And maybe you really should start at the age of 5.

I start at age 21 and I have no talent for programming.
With > 10K hours invested I now manage.

>
>--
>Bernd Paysan
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#29081

On Tue, 18 Mar 2014 17:30:40 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

> can get Gforth from the Play Store.


Bernd:

I saw this and downloaded GForth for Android onto my Samsung phone.

Well, after starting up nothing happened for a while, so I killed the
program...  and appear to have crashed my phone -- as it it does not
work or boot.

A little googling came up with the following:

"Starting the app first time unpacks the Gforth sources to the SD
card. That's a few megabytes, and therefore it takes its time.
Gforth's loader can't display any status at this stage, and won't
respond to inputs, so just be patient."
(http://www.forth-ev.de/wiki/doku.php/en:projects:gforth-android:start)

Ahhh...  now I am told ;)

So, a suggestion: perhaps have the start screen show a small message
like "Please Wait - this may take a few minutes the first time..."
and an (!) warning icon, perhaps even -- while unpacking do NOT exit
the application...

That could potentially save a few less patient souls like myself
several hours of having to figuring out now how to get my phone to
turn on and restored to a working state  ;)



(But I look forward to trying GForth for Android once that's done... )

Cheers
-
Assad

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

#29085

On Wed, 19 Mar 2014, Assad Ebrahim wrote:

> Date: Wed, 19 Mar 2014 18:36:27 +0000
> From: Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu>
> Newsgroups: comp.lang.forth
> Subject: Re: +DO and programming without stack manipulation words
> 
> On Tue, 18 Mar 2014 17:30:40 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
>
>> can get Gforth from the Play Store.
>
>
> Bernd:
>
> I saw this and downloaded GForth for Android onto my Samsung phone.
>
> Well, after starting up nothing happened for a while, so I killed the
> program...  and appear to have crashed my phone -- as it it does not
> work or boot.
>
> A little googling came up with the following:
>
> "Starting the app first time unpacks the Gforth sources to the SD
> card. That's a few megabytes, and therefore it takes its time.
> Gforth's loader can't display any status at this stage, and won't
> respond to inputs, so just be patient."
> (http://www.forth-ev.de/wiki/doku.php/en:projects:gforth-android:start)
>
> Ahhh...  now I am told ;)
>
> So, a suggestion: perhaps have the start screen show a small message
> like "Please Wait - this may take a few minutes the first time..."
> and an (!) warning icon, perhaps even -- while unpacking do NOT exit
> the application...
>
> That could potentially save a few less patient souls like myself
> several hours of having to figuring out now how to get my phone to
> turn on and restored to a working state  ;)
>
>
>
> (But I look forward to trying GForth for Android once that's done... )
>
> Cheers
> -
> Assad


My understanding is that the Android SDK comes with an emulator which is 
pretty good.  The installation on Linux of the SDK is also pretty easy.  I 
believe that I will give Gforth a try on Android, but I will download the 
SDK and use the emulator to develop code ... and go from there ... no 
reason to risk a cell phone or expensive tablet when emulation will do.

Cheers,
Rob.

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

#29088

Spam@ControlQ.com wrote:
> My understanding is that the Android SDK comes with an emulator which is
> pretty good.  The installation on Linux of the SDK is also pretty easy.  I
> believe that I will give Gforth a try on Android, but I will download the
> SDK and use the emulator to develop code ... and go from there ... no
> reason to risk a cell phone or expensive tablet when emulation will do.

According to the play store statistics, Gforth runs on more than 500 
devices, and the worst thing I heard before is "you need to start Gforth 
twice to get it to run".

However, I've added this spinner (not published yet, making sure the spinner 
doesn't show up if there's no unpacking going on is more work - the spinner 
itself is really easy ;-), and it will for sure improve impatient user 
experience on slow devices.  However, it will not fix the "device is 
bricked" thing Assad saw, because this is so far completely irreproducible.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29087

Assad Ebrahim wrote:

> On Tue, 18 Mar 2014 17:30:40 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>> can get Gforth from the Play Store.
> 
> 
> Bernd:
> 
> I saw this and downloaded GForth for Android onto my Samsung phone.
> 
> Well, after starting up nothing happened for a while, so I killed the
> program...  and appear to have crashed my phone -- as it it does not
> work or boot.

Not even boot?  You've got it bricked?  Wow ;-).

You can kill Gforth just fine, it does no harm to the phone (I kill it 
frequently, after all, it's a Forth system and there's a chance crashing 
even Gforth so hard that you need to kill it), and then you start it again, 
and you don't need to wait for unpacking.

> A little googling came up with the following:
> 
> "Starting the app first time unpacks the Gforth sources to the SD
> card. That's a few megabytes, and therefore it takes its time.
> Gforth's loader can't display any status at this stage, and won't
> respond to inputs, so just be patient."
> (http://www.forth-ev.de/wiki/doku.php/en:projects:gforth-android:start)
> 
> Ahhh...  now I am told ;)
> 
> So, a suggestion: perhaps have the start screen show a small message
> like "Please Wait - this may take a few minutes the first time..."

On any reasonable phone you won't even notice this time.  This "just be 
patient" is for people who have /sdcard on a slow extern real SD-card.

> and an (!) warning icon, perhaps even -- while unpacking do NOT exit
> the application...

It is totally harmless to exit the application while unpacking.  If it 
hasn't completed, it will so next time.  If it has completed, it will know 
that and not unpack next time (this is trivial to do: as last step, I write 
a file containing a sha256-checksum of all the files - to verify that the 
unpacking did work, I read that file in and check for the correct checksum).  
This stuff is meant to be fool-proof.  Your story is the weirdest thing I've 
heard.  No, you can't brick a phone by installing an app that writes a few 
megabytes into /sdcard.  Ok, maybe if /sdcard is already almost full, and 
the rest of the system needs some free space there.

About displaying something: As I wrote, at that point in time I have 
absolutely *nothing*.  Not even control over the screen, just a small 
program that can unpack stuff.  So I can't display anything.  To gain 
control, I must unpack all this stuff and then load it into the Forth 
system.  You know, I need OpenGL, I need JNI, I need a Gforth image, all 
that stuff has to be unpacked before it can be used.

> That could potentially save a few less patient souls like myself
> several hours of having to figuring out now how to get my phone to
> turn on and restored to a working state  ;)

Did you manage it?  But you didn't find the root cause?  What I can imagine 
is that your /sdcard was full, and the files couldn't be extracted correctly 
- and then trying to run a corrupted Gforth image caused some harm.

> (But I look forward to trying GForth for Android once that's done... )

I probably can fix that with the recent changes, since I've got rid of the 
native activity and have my own activity.  This activity could display 
something (a popup window showing a spinning wheel or so) while the 
unpacking is going on, at least if it's taking more than 0.3s.  On my Galaxy 
Note 2 I see no difference between the unpacking start and the non-unpacking 
start; it's probably completely hidden in the animation (I can unpack during 
animation, but I have to wait for the animation to finish to display 
something).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web