Progress!

[Ray St. Marie]

Hi all, Ray here...

I've decided to take a listing of MASM colorForth, closely related to
the very first public version, and annotate it. This will help me
develop more content for the wiki and blog. See my signature below for
the links to these resources.

The annotated list is very informal. It is being added to the Blog a
piece at a time as it is developed. A finished version will appear at
the wiki. That version will be broken down into several pages of
specific info, as it is added into the wiki.

If you would like something specifically explained, see something I
missed, got totally wrong, or missed the point... Please either
contact me directly thru this mailing list, comment the blog, use my
email address, or beat drums if you are in the neighborhood. You will
find me to be very reasonable and willing to be wrong for the sake of
clarity of this information. No one benefits from this exercise more
than selfish old me. :-)

Ray

--
Raymond St. Marie ii,
a quickstart guide http://colorforthray.info
THE Community Blog http://colorForth.net
THE community wiki http://ForthWorks.com/c4th

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[kloro]

what's the forth community thinking about objects these days?






---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[vido]

On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall wrote:
>
> what's the forth community thinking about objects these days?

What's the object community thinking about words these days?

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall wrote:
>
> what's the forth community thinking about objects these days?

Well while I can not speak for the community at large, I can say that there is a growing recognition within the Smalltalk VM developer community that they need to break their bad habits.  A lot of the JIT solutions are focusing on breaking out of the "objects must be represented directly in code" mindset and are starting to think a lot more like forth programmers.

Further more, if you look at what the PEG people have been working on, with their parsing executable grammars, as a forth programmer you'll see how a bunch of object people go about implementing Forth.  It is really quite fun to watch them struggle with concepts that would be easy if they simply adopted a directly manipulable return stack.

At the heart of nearly every ML dialect is a forth implementation screaming for air too!  (SML NJ is a perfect example, its dictionary would make any Forth programmer feel right at home).

So while the views of the forth community may be more or less the same as they were years ago, the other communities, that are actively struggling with simplicity, are starting to think more and more like forth programmers.  At the current rate of "progress", most programmers on the planet will have no concept how their programs work, and the few who do will grok forth.

People who get excited about 'objects' simply don't understand indirect / vectored execution.  Mistaking a conceptual model / metaphor for an implementation strategy / design has never been particularly good idea.  Although those who understand OO only as a matter of faith, will still see this issue only according to their dogma, those who understand forth are free of the messy ideological restrictions.

My personal thoughts on OO is that it is a good model for describing interfaces between pieces of software that reside in separate process spaces.  However, as a model for factoring code or designing components, it is horrible.  As for how we train new programmers in "OO Patterns", without any of the historical perspective, all we are doing is creating a new religion;  a religion in which new programmers take on faith programming techniques as design dogma, rather than understanding them for what they really were.




---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Nick Maroudas-2]

Quoting vido@...:

>... " On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall
>... " wrote:
>... " >
>... " > what's the forth community thinking about objects
>... " these days?
>... "

[to which vido@... replied]
>... " What's the object community thinking about words these
>... " days?
>... "

Nick here:  All I know is that, long ago, Chuck said that
objects seemed to him just good programming.  He was talking
about factoring - making programs out of little reusable stubs
of words.

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Albert van der Horst]

On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall wrote:
>
> what's the forth community thinking about objects these days?

There are quite some implementations. I have a very
simple one (a generalisation of DOES>) and are happy with it.
For instance. The problem of eulerproject.net has a couple of
thousand cuboids. Those have 3 start point and 3 sizes.
It is hard if not impossible to make a reasonable program
without structures of some sort, classes, objects, whatever.


Groetjes Albert.

P.S. I'm currently one of 3 Forthers who have solved more
100 of the 229 problems on the euler project.
There is a colorforther, but he has solved 2 problems only.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[vaded]

"However, as a model for factoring code or designing components, it is
horrible."

Could you elaborate on that point a bit?

Thanks

On Mon, 26 Jan 2009 13:00:18 -0500, "David J. Goehrig"
<dave@...> said:

> On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall wrote:
> >
> > what's the forth community thinking about objects these days?
>
> Well while I can not speak for the community at large, I can say that
> there is a growing recognition within the Smalltalk VM developer
> community that they need to break their bad habits.  A lot of the JIT
> solutions are focusing on breaking out of the "objects must be
> represented directly in code" mindset and are starting to think a lot
> more like forth programmers.
>
> Further more, if you look at what the PEG people have been working on,
> with their parsing executable grammars, as a forth programmer you'll see
> how a bunch of object people go about implementing Forth.  It is really
> quite fun to watch them struggle with concepts that would be easy if they
> simply adopted a directly manipulable return stack.
>
> At the heart of nearly every ML dialect is a forth implementation
> screaming for air too!  (SML NJ is a perfect example, its dictionary
> would make any Forth programmer feel right at home).
>
> So while the views of the forth community may be more or less the same as
> they were years ago, the other communities, that are actively struggling
> with simplicity, are starting to think more and more like forth
> programmers.  At the current rate of "progress", most programmers on the
> planet will have no concept how their programs work, and the few who do
> will grok forth.
>
> People who get excited about 'objects' simply don't understand indirect /
> vectored execution.  Mistaking a conceptual model / metaphor for an
> implementation strategy / design has never been particularly good idea.
> Although those who understand OO only as a matter of faith, will still
> see this issue only according to their dogma, those who understand forth
> are free of the messy ideological restrictions.
>
> My personal thoughts on OO is that it is a good model for describing
> interfaces between pieces of software that reside in separate process
> spaces.  However, as a model for factoring code or designing components,
> it is horrible.  As for how we train new programmers in "OO Patterns",
> without any of the historical perspective, all we are doing is creating a
> new religion;  a religion in which new programmers take on faith
> programming techniques as design dogma, rather than understanding them
> for what they really were.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

On Mon, Jan 26, 2009 at 04:06:14PM -0700, vaded@... wrote:
> "However, as a model for factoring code or designing components, it is
> horrible."
>
> Could you elaborate on that point a bit?

Certainly.  Quick point of reference, my formal training heavily influences my view of this. Having been a Classicist in a former life, I've studied more human languages than most programmers have programming languages.  And when it come to programming, I've used about 16 programming languages in production over the years.

The meaning of any word in any language is entirely dependent on context.  In a language like Forth, that context is the order in which that word was defined / compiled.  In a language like C, the context that determines the meaning is the way in which the program was linked.  And in a language like Smalltalk, the meaning of the word depends both on the Smalltalk dictionary, the definitions within a class, and any binding in the particular BlockContext you're running.

In all three languages any given WORD can have more than 1 meaning.  The problem of determining the meaning of any given word is dependent on the context at a particular point in time.  As you increase the amount of indirection in the naming of these elements, the basis of object orientation, and push the binding to later and later in the process, the harder it is to know at the time of reading what a given word means.

In Forth with early binding, the context is generally the same at edit, compile, and run time.  In a language like C, the context can change depending on the scope and link time binding.  A word may have different meanings in different function definitions, but also globally depending on the libraries linked.  In an OO language like Smalltalk, the context is only really defined at runtime, and much to the dismay of many Smalltalkers, can often cause immense pain when trying to run older code in newer systems.  If you need an example, read the Squeak mailing list for several months after they roll out a new release, and lots of old software breaks.  There is even a project called "Level Playing Field" which normalizes the behavior across the past few major releases.  Much of "test driven development" is a response that tries to deal with the problems created by this uncertainty.

From a design point of view, treating linguistic constructs as objects, when they are clearly not objects, is simply disingenuous.  Words in any programming language are still words.  As such, they are merely symbols that stand for things that exist within the experience of the programmer, and the context of the program.  Confusing the idiom you use to talk about those things with the thing itself, doesn't make for good design; merely a muddled understanding of the problem you are trying to solve.  Much like Chuck's revelation about the map is not the territory, but is a useful representation of it.  Good design recognizes the underlying reality, as well as, the limitations of the language we use.

A friend of mine recently sent me a beauty of a code snippet from a project he inherited from a former employee:

        public static void setCustomerName(String customer_name) {
                customerID = customer_name.toInt();
        }

        public static int getCustomerName() {
                return customerID;
        }

These two accessor methods merely operate on an customer record object that has fields customerID and customerName as entities within it.  However, the programmer in question, deep in the belly of this beast, was at cross purposes with herself, and mixed the concepts of customerName and the definition of these accessors.  All of the tests in the test suite worked, the application did basically what it was supposed to do, but without reading the guts of this seemingly simple object, the meaning of the words you read in English are contrary to the definition in the code.  This lead to hours of wasted time by later programmers extending the code.

This is not to say that this one example of programming invalidates the usefulness of OO.  It merely illuminates how a programer's inability to choose the correct words is not solved by using OO techniques.  Finding the correct refactoring, and using the correct terminology to convey both the purpose and meaning of the code, is independent of the mental model you use to think about the relationship between code and data.  That mental model, however, can often help to confuse the issue by muddying the contextual waters to an extent that the actual meaning at run time and the intended meaning at edit time diverge.

I personally feel that OO design doesn't belong within a program.  If you can't envision the complete state of memory at every stage in your code, you've outprogramed your head.  Adding additional layers of complexity to an already complex problem merely make your program less understandable.  Where OO does apply, however, is when you are thinking of the interfaces between programs.  Commands you send to a chip over the bus are messages in the OO sense.  Commands you send between nodes on a network are messages in the OO sense.  But messages you send in a Smalltalk sense, are actually just function calls and indirect jumps.  And such a mixed metaphor is just disingenuous design.



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[vaded]

Dear David J. Goehrig,

Thank you for your thoughtful and effective reply.  Well a lot of what
you
said came from a higher level of functioning than I am at in terms of
programming, it was still clear and understandable.  I'm grateful to
anyone
who exposes me to something that I don't know but that I can come to
know.

I need to spend some more time digesting your comments and playing them
out
in manifest ways so I better understand and remember the proposals you
made.

One last question: what are you doing with Forth?  You mentioned in a
prior
post that you had a lot of ARM dev. kits around -- how did that come
about
if you don't mind me saying?  I was sorry to hear that you don't find
ARM to
be well suited to Forth.  It is my ultimate goal (desire? -- dream?) to
be
able to thoughtfully program in Forth for smart phones.  

My regards.

On Tue, 27 Jan 2009 19:59:51 -0500, "David J. Goehrig"
<dave@...> said:

> On Mon, Jan 26, 2009 at 04:06:14PM -0700, vaded@... wrote:
> > "However, as a model for factoring code or designing components, it is
> > horrible."
> >
> > Could you elaborate on that point a bit?
>
> Certainly.  Quick point of reference, my formal training heavily
> influences my view of this. Having been a Classicist in a former life,
> I've studied more human languages than most programmers have programming
> languages.  And when it come to programming, I've used about 16
> programming languages in production over the years.
>
> The meaning of any word in any language is entirely dependent on context.
>  In a language like Forth, that context is the order in which that word
> was defined / compiled.  In a language like C, the context that
> determines the meaning is the way in which the program was linked.  And
> in a language like Smalltalk, the meaning of the word depends both on the
> Smalltalk dictionary, the definitions within a class, and any binding in
> the particular BlockContext you're running.
>
> In all three languages any given WORD can have more than 1 meaning.  The
> problem of determining the meaning of any given word is dependent on the
> context at a particular point in time.  As you increase the amount of
> indirection in the naming of these elements, the basis of object
> orientation, and push the binding to later and later in the process, the
> harder it is to know at the time of reading what a given word means.
>
> In Forth with early binding, the context is generally the same at edit,
> compile, and run time.  In a language like C, the context can change
> depending on the scope and link time binding.  A word may have different
> meanings in different function definitions, but also globally depending
> on the libraries linked.  In an OO language like Smalltalk, the context
> is only really defined at runtime, and much to the dismay of many
> Smalltalkers, can often cause immense pain when trying to run older code
> in newer systems.  If you need an example, read the Squeak mailing list
> for several months after they roll out a new release, and lots of old
> software breaks.  There is even a project called "Level Playing Field"
> which normalizes the behavior across the past few major releases.  Much
> of "test driven development" is a response that tries to deal with the
> problems created by this uncertainty.
>
> From a design point of view, treating linguistic constructs as objects,
> when they are clearly not objects, is simply disingenuous.  Words in any
> programming language are still words.  As such, they are merely symbols
> that stand for things that exist within the experience of the programmer,
> and the context of the program.  Confusing the idiom you use to talk
> about those things with the thing itself, doesn't make for good design;
> merely a muddled understanding of the problem you are trying to solve.
> Much like Chuck's revelation about the map is not the territory, but is a
> useful representation of it.  Good design recognizes the underlying
> reality, as well as, the limitations of the language we use.
>
> A friend of mine recently sent me a beauty of a code snippet from a
> project he inherited from a former employee:
>
> public static void setCustomerName(String customer_name) {
> customerID = customer_name.toInt();
> }
>
> public static int getCustomerName() {
> return customerID;
> }
>
> These two accessor methods merely operate on an customer record object
> that has fields customerID and customerName as entities within it.
> However, the programmer in question, deep in the belly of this beast, was
> at cross purposes with herself, and mixed the concepts of customerName
> and the definition of these accessors.  All of the tests in the test
> suite worked, the application did basically what it was supposed to do,
> but without reading the guts of this seemingly simple object, the meaning
> of the words you read in English are contrary to the definition in the
> code.  This lead to hours of wasted time by later programmers extending
> the code.
>
> This is not to say that this one example of programming invalidates the
> usefulness of OO.  It merely illuminates how a programer's inability to
> choose the correct words is not solved by using OO techniques.  Finding
> the correct refactoring, and using the correct terminology to convey both
> the purpose and meaning of the code, is independent of the mental model
> you use to think about the relationship between code and data.  That
> mental model, however, can often help to confuse the issue by muddying
> the contextual waters to an extent that the actual meaning at run time
> and the intended meaning at edit time diverge.
>
> I personally feel that OO design doesn't belong within a program.  If you
> can't envision the complete state of memory at every stage in your code,
> you've outprogramed your head.  Adding additional layers of complexity to
> an already complex problem merely make your program less understandable.
> Where OO does apply, however, is when you are thinking of the interfaces
> between programs.  Commands you send to a chip over the bus are messages
> in the OO sense.  Commands you send between nodes on a network are
> messages in the OO sense.  But messages you send in a Smalltalk sense,
> are actually just function calls and indirect jumps.  And such a mixed
> metaphor is just disingenuous design.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Panthera Altaica]

--- On Mon, 1/26/09, David J. Goehrig <dave@...> wrote:

> At the heart of nearly every ML dialect is a forth
> implementation screaming for air too!  (SML NJ is a perfect
> example, its dictionary would make any Forth programmer feel
> right at home).
>
> So while the views of the forth community may be more or
> less the same as they were years ago, the other communities,
> that are actively struggling with simplicity, are starting
> to think more and more like forth programmers.  At the
> current rate of "progress", most programmers on
> the planet will have no concept how their programs work, and
> the few who do will grok forth.

The main goal of OOD is ignorance(they call "encapsulation")
OOD doesn't like 'inheritance', the problem is stated as follows: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'".

It is the whole hide it in a black box and it will just magicaly work idea.

To quote Good Ideas, through the Looking Glass:
"5.6. Wizards We have discussed the great leaps forward in parsing technology originating in the 1960s. The results are ever-present since those years. Hardly anybody now constructs a parser by hand. Instead, one buys a parser generator and feeds it the desired syntax. This brings us to the topic of automatic tools, now being called wizards. The idea is that they are to be considered as black boxes, and that the user would not have to understand their innards, as they were optimally designed and laid out by experts. The idea is that they automate simple routine tasks, relieving computer users from bothering about them. Wizards supposedly help you – and this is the key – without your asking, as a faithful, devoted servant.
...
If at least they could easily be deactivated, but typically they are obstinate and immortal like devils. So much for clever software for dummies: a bad idea!

And you are surprized that they all idiots teaching others how to be idiots?

> Further more, if you look at what the PEG people have been
> working on, with their parsing executable grammars, as a
> forth programmer you'll see how a bunch of object people
> go about implementing Forth.  It is really quite fun to
> watch them struggle with concepts that would be easy if they
> simply adopted a directly manipulable return stack.

And break encapsulation! Are you mad? :P


> My personal thoughts on OO is that it is a good model for
> describing interfaces between pieces of software that reside
> in separate process spaces.  

http://query.nytimes.com/gst/abstract.html?res=9E06EFD8103EE73BBC4E51DFB6678382669FDE

Of course the ones pushing for it know that wants are bad.  since you don't give a damn I'll just tell you to read
Henry George's Progress and Poverty.
http://www.henrygeorge.org/pcontents.htm



But as Edmund Burke, I think it was, said, "All that is required for evil to prevail is for good men to help it."

I'm sure you (never) heard the tale: "In the early days of The Pennsylvania Gazette a contribution was brought into the office with the request that Franklin publish it... Franklin asked that the piece should be left to the following day, when he would decide about printing it. The person returned at the time appointed, and received from Franklin this communication: 'I have perused your piece and found it to be scurrilous and defamatory. To determine whether I should publish it or not, I went home in the evening, purchased a twopenny loaf at the baker's, and with water from the pump made my supper; I then wrapped myself up in my great-coat, and laid down on the floor and slept till morning, when, on another load and a mug of water, I made my breakfast. From this regiment I feel no inconvenience whatever. Finding I can live in this manner, I have formed a determination never to prostitute my press to the purposes of corruption, and abuse of this kind, for
 the sake of gaining a more comfortable subsistence."





---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

Well the question was asked, what am I doing with Forth.

The short answer is I'm writing a MMORPG platform for mobile phones, laptops, & desktops, and also building robots.

The long answer is I have been writing my own implementation of a colorforth, and will release it into the wild as soon as it is done.  This "colorforth" has several implementations so far, as it needs to run on a variety of processors.  The core idea behind it was a simplification of Chuck's idea of spaces:

* a newline followed by a word creates a red defining word
* a newline followed by a tab  creates a new gray comment
* a newline followed by a word followed by a tab creates a purple "multivariable"
* a tab separated list of words creates a blue "table" of values to populate a multivariable

A few other things break with Forth tradition, but owe their roots to colorforth optimizations.  I've also integrated a look ahead optimizer, that uses the punctuation marks . , ; : ! to perform various stack and flow control options.  Code that is run at compile time is contained in parenthetical phrases ( ) which get colored in yellow.  All of the punctuation marks can be attached to the end of the word,  but floating is also fine.

I also have a very simple "object system" which is merely tables of key : value pairs that allows you to write label methods for the elements in a multivariable.

The resulting language is easy to read, has a bit more punctuation than Chuck's colorforth, but tends to look a lot like plain english with fancy colors.  And the importance of white space works a bit like Python, making the code very consistent.

Right now I have a C implementation, and an Intel assembler implementation.  I am working on ARM and AVR32 compilers.  The editor is written in OpenGL + GLUT and edits 4096 character pages, and uses two different font faces for code and comments.  I'm currently in the process of getting the code to run on iPhone as well.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

On Sat, Jan 31, 2009 at 12:21:58AM -0800, Panthera Altaica wrote:
>
> The main goal of OOD is ignorance(they call "encapsulation")
> OOD doesn't like 'inheritance', the problem is stated as follows: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'".
>

Oh I agree with this to an extent.  This is true of the Java crowd for sure.  Not all OO-ers fully believe in this nonsense though.

> It is the whole hide it in a black box and it will just magicaly work idea.

Well, most Smalltalkers tend to avoid this black box idea.  They are generally more than willing to go in and modify a low level class like Object just to make their idiom work correctly.  For example it is standard practice to add a method like:

        isMyClass
                ^ false

to the root level Object class, and then in your own class implement the corresponding method

        isMyClass
                ^ true

Just so you can test if an object is a member of your class or not, without triggering the debugger at runtime.  So the general concept isn't so much mandatory ignorance, but rather results in a culture of willful ignorance, because one doesn't need to think about what they're doing.  It doesn't actually have to be that way.

That said, when you jump through hoops just to make your idiom work, your idiom is probably broken.  But hey, that's why the Gang of Four wrote the Patterns book, to describe all the different hoops they typically encounter.

> And you are surprized that they all idiots teaching others how to be idiots?

Actually, judging by one of my friend's experiences as an associate professor at one of the best Comp Sci Universities in the country (a top 20 school for sure), he's got PhD students who don't know how to open files off a CD.  So I'd avoid saying we've got idiots teaching idiots, just that we have CompSci people who know nothing about real world computers.   Theoretical computers they understand, real computers we should probably keep them far away from.  And you know this is getting bad, when even professors are complaining they can't find any students competent enough to program their research projects!

In my opinion, the structure of academia is to blame for decline in programming.  We have a culture that engenders a whole range of behaviors and thought processes that are contrary to developing a fundamental understanding of actual reality.  Academia simply over values theoretical generality and experiments in an idealized world.  When combined with the pressure to publish specialized research, it produces programmers who over focus on narrow aspects of problems, (in order to get published), and then attempt to produce the most generalized solution (to qualify as academic).

When we train PhDs to narrowly focus on a small aspect of the problem, and they carry that behavior into the real world.  As a result, you see people generate huge XML documents to transfer data to client apps, (consisting of largely redundant and irrelevant data), and then add a layer of complexity to solve that problem by compressing the feed.  Eventually, all of the processing necessary is too much, so they implement a ASN.1-like solution, and spend a lot of time trying to compress that data say by using variable bytewise integers.  Eventually, this too grows too large, so they add compression layers on top of that too.  At no point does anyone ask, "Why do we really need all this data?"  Because none of them have been trained to look at the whole picture.  Rather they all live in little boes.

http://www.youtube.com/watch?v=ONEYGU_7EqU

My experiences contracting for a certain large company, that is known for hiring PhDs, has been a painful exercise in fighting that culture war.  At one point I was handed a portablilty layer of 16k LOC for a library they wanted ported to a new hardware platform.  I turned around and instead reverse engineered their undocumented proprietary protocol and provided them an implementation in 300 LOC, tooled specifically for the platform.  Had I attempted to port their code, I estimated I would have had to write 2600 LOC just to port the underlying classes.  Removing the abstraction layers, resulted in less work, less testing, and less cost.  But that's not what the PhDs ever thought of doing.

Dave

PS. full disclosure, I too have a post-graduate degree, but in Useless Studies :)



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[vaded]

Out of curiosity, given your justified lack of faith in academia, how
would you recommend a young adult in today's world went about learning
to program?  It would be a hard task because the world has adopted
insane paradigms in computing, but most the money is in those insane
paradigms.  Do you learn the new Forths and hope that somehow you will
find employment with that, and thus not "sell out"?

I noticed Jeff Fox made two good points about learning Forth.  1) To be
an expert at something takes 10 years of dedicated work, and 2) To excel
it can greatly help to be trained by a "master" in the art you are
trying to perfect.  

Should people still be learning assembly for the PC and going from
there?  Is that the best starting point?  Should the PC be skipped
altogether?  What books could even be recommended?  

On Mon, 2 Feb 2009 17:05:22 -0500, "David J. Goehrig"
<dave@...> said:

> On Sat, Jan 31, 2009 at 12:21:58AM -0800, Panthera Altaica wrote:
> >
> > The main goal of OOD is ignorance(they call "encapsulation")
> > OOD doesn't like 'inheritance', the problem is stated as follows: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'".
> >
>
> Oh I agree with this to an extent.  This is true of the Java crowd for
> sure.  Not all OO-ers fully believe in this nonsense though.
>
> > It is the whole hide it in a black box and it will just magicaly work idea.
>
> Well, most Smalltalkers tend to avoid this black box idea.  They are
> generally more than willing to go in and modify a low level class like
> Object just to make their idiom work correctly.  For example it is
> standard practice to add a method like:
>
> isMyClass
> ^ false
>
> to the root level Object class, and then in your own class implement the
> corresponding method
>
> isMyClass
> ^ true
>
> Just so you can test if an object is a member of your class or not,
> without triggering the debugger at runtime.  So the general concept isn't
> so much mandatory ignorance, but rather results in a culture of willful
> ignorance, because one doesn't need to think about what they're doing.
> It doesn't actually have to be that way.
>
> That said, when you jump through hoops just to make your idiom work, your
> idiom is probably broken.  But hey, that's why the Gang of Four wrote the
> Patterns book, to describe all the different hoops they typically
> encounter.
>
> > And you are surprized that they all idiots teaching others how to be idiots?
>
> Actually, judging by one of my friend's experiences as an associate
> professor at one of the best Comp Sci Universities in the country (a top
> 20 school for sure), he's got PhD students who don't know how to open
> files off a CD.  So I'd avoid saying we've got idiots teaching idiots,
> just that we have CompSci people who know nothing about real world
> computers.   Theoretical computers they understand, real computers we
> should probably keep them far away from.  And you know this is getting
> bad, when even professors are complaining they can't find any students
> competent enough to program their research projects!
>
> In my opinion, the structure of academia is to blame for decline in
> programming.  We have a culture that engenders a whole range of behaviors
> and thought processes that are contrary to developing a fundamental
> understanding of actual reality.  Academia simply over values theoretical
> generality and experiments in an idealized world.  When combined with the
> pressure to publish specialized research, it produces programmers who
> over focus on narrow aspects of problems, (in order to get published),
> and then attempt to produce the most generalized solution (to qualify as
> academic).
>
> When we train PhDs to narrowly focus on a small aspect of the problem,
> and they carry that behavior into the real world.  As a result, you see
> people generate huge XML documents to transfer data to client apps,
> (consisting of largely redundant and irrelevant data), and then add a
> layer of complexity to solve that problem by compressing the feed.
> Eventually, all of the processing necessary is too much, so they
> implement a ASN.1-like solution, and spend a lot of time trying to
> compress that data say by using variable bytewise integers.  Eventually,
> this too grows too large, so they add compression layers on top of that
> too.  At no point does anyone ask, "Why do we really need all this data?"
>  Because none of them have been trained to look at the whole picture.
> Rather they all live in little boes.
>
> http://www.youtube.com/watch?v=ONEYGU_7EqU
>
> My experiences contracting for a certain large company, that is known for
> hiring PhDs, has been a painful exercise in fighting that culture war.
> At one point I was handed a portablilty layer of 16k LOC for a library
> they wanted ported to a new hardware platform.  I turned around and
> instead reverse engineered their undocumented proprietary protocol and
> provided them an implementation in 300 LOC, tooled specifically for the
> platform.  Had I attempted to port their code, I estimated I would have
> had to write 2600 LOC just to port the underlying classes.  Removing the
> abstraction layers, resulted in less work, less testing, and less cost.
> But that's not what the PhDs ever thought of doing.
>
> Dave
>
> PS. full disclosure, I too have a post-graduate degree, but in Useless
> Studies :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

On Mon, Feb 02, 2009 at 10:29:33PM -0700, vaded@... wrote:
> Out of curiosity, given your justified lack of faith in academia, how
> would you recommend a young adult in today's world went about learning
> to program?

There's this wonderful place known as the library :)  Actually, most of the best people programming in the Valley got their starts as children.  I started programming at the age of 7, with the aid of a few books my parents bought for me, and a collection of books borrowed from the library.

> Do you learn the new Forths and hope that somehow you will
> find employment with that, and thus not "sell out"?

Well, personally, I got my formal training in History, Mathematics, and Classical Languages.  I have found that this has been a positive boon when getting hired, as most of the companies I focused on early in my career were typically looking for people who had more skills than just programming.  That said, it isn't enough to just learn Forth, you do need to learn to hate mainstream languages for all the right reasons :)

> Should people still be learning assembly for the PC and going from
> there?  Is that the best starting point?  Should the PC be skipped
> altogether?  What books could even be recommended?  

Wow what a setup!  I've actually been writing a book that details exactly that strategy and process.  The book began because we've been having problems finding students who know enough about systems level programming and bare metal to even be trainable!  I'm currently working with an editor, a sympathetic academic, and a few willing test subjects who need to learn to program this summer.

The way I typically teach programming to newbies, and reteach people who've acquired a theoretical education, is I start off with the bit, and move up from there.  By the end a few days, they've learned enough to do basic assembler.  I then work with them to build a C or Lisp or Smalltalk.  At that point, if they're willing I introduce them to Forth.  There's no point arguing about the merits of Forth with someone who doesn't understand how C operates on the machine level.  Usually at that point, you end up with a novice programmer, who has a firm handle on what C does, and can read/write any C code.  They also are pretty easy to sway to the benefits of Forth, as the multi-level properties blow away the limited world view of C, and everything written on top of it.  Further more, because they typically understand OO programming on the low low level, they know when and how to break from the metaphor.

As with all things, it will be announced when it is done.

Until then, I recommend reading in no particular order:

The Little Schemer
The Seasoned Schemer
On Lisp

Starting Forth
Thinking Forth

The C Programming Language

I think it is important not to forget that Chuck well aware of what McCarthy was doing in 1958 when Lisp was formulated, and the Germans and Americans developed Algol in a comittee that same year.  That was really the critical year in the history of programming, and we've basically been stuck with the idioms formalized in that year.  In many ways, we're still fighting that battle, and sadly the Algol people are winning. :)

Dave

PS. Lisp is just Polish Notation Forth, it about think :)



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Albert van der Horst]

On Wed, Feb 04, 2009 at 01:10:46PM -0500, David J. Goehrig wrote:
> On Mon, Feb 02, 2009 at 10:29:33PM -0700, vaded@... wrote:
<SNIP>
>
I think it is important not to forget that Chuck well aware of what
McCarthy was doing in 1958 when Lisp was formulated, and the Germans and
Americans developed Algol in a comittee that same year. That was really
the critical year in the history of programming, and we've basically
been stuck with the idioms formalized in that year. In many ways, we're
still fighting that battle, and sadly the Algol people are winning. :)
>

Please limit your lines to 72 char's. I had to reformat.

There is a crucial difference between C FORTH FORTRAN PERL
on one side and PASCAL ALGOL ADA PYTHON on the other.
Only Americans don't seem to appreciate the difference.
The US languages are disorganized and full of oddities, irregularities
and add hoc constructions, unsafe allbeith practical.
The European languages have a theoretical base, are regular, easier to
understand and memorize and safer.

Yes! Algol is winning. At long last runtime array bounds checking is
added to the GCC compiler. And guess what? It only costs a few
percent in performance.

Most people thing PYTHON is way superior over PERL.

Why are you sad?

>
> Dave
>
> PS. Lisp is just Polish Notation Forth, it about think :)

Forth is reverse polish LISP.

Groetjes Albert

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

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Jecel Assumpcao Jr]

David J. Goehrig wrote:

> The way I typically teach programming to newbies, and reteach people
> who've acquired a theoretical education, is I start off with the bit, and
> move up from there.  By the end a few days, they've learned enough
> to do basic assembler.  I then work with them to build a C or Lisp or
> Smalltalk.  At that point, if they're willing I introduce them to Forth.

You might find this course interesting:

http://www1.idc.ac.il/tecs/

It is better known as "From Nand to Tetris in 12 steps". The authors
make some silly mistakes, like in their explanation of Harvard versus
Von Neuman architectures. And their machine language is more horrible
than I would like. But in general it seems to be a good course.

About the subject, I worked on hardware for OO Color Forth in 2001/2002
and so have an opinion about this. But it will have to wait until
tomorrow (Friday is more likely...).

-- Jecel


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[vaded]

I remember Jeff Fox saying something to the point of that the engineers
he worked with who knew ASM had a very easy time picking up the 1X
Forths (machine forth, etc.).  But those who were firmly entrenched in
the C and related paradigms had a much harder time seeing the virtues of
1X forth and adopting its methodologies.  So I'm wondering if the
approach of learning C or Lisp or Small Talk first may prime the mind in
a ineffecient way when it comes to forth?


On Wed, 4 Feb 2009 22:33:42 -0300 , "Jecel Assumpcao Jr"
<jecel@...> said:

> David J. Goehrig wrote:
>
> > The way I typically teach programming to newbies, and reteach people
> > who've acquired a theoretical education, is I start off with the bit, and
> > move up from there.  By the end a few days, they've learned enough
> > to do basic assembler.  I then work with them to build a C or Lisp or
> > Smalltalk.  At that point, if they're willing I introduce them to Forth.
>
> You might find this course interesting:
>
> http://www1.idc.ac.il/tecs/
>
> It is better known as "From Nand to Tetris in 12 steps". The authors
> make some silly mistakes, like in their explanation of Harvard versus
> Von Neuman architectures. And their machine language is more horrible
> than I would like. But in general it seems to be a good course.
>
> About the subject, I worked on hardware for OO Color Forth in 2001/2002
> and so have an opinion about this. But it will have to wait until
> tomorrow (Friday is more likely...).
>
> -- Jecel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[bishop-11]

(One might note, without rancor, that Unix folk and their 72 character requirement splattered all over the world of computers is precisely the sort of thing that Chuck has been reviling, forever.
Geof Bishop)

On Wed, 04 Feb 2009 17:37:47 -0700, Albert van der Horst <albert@...> wrote:

>
> On Wed, Feb 04, 2009 at 01:10:46PM -0500, David J. Goehrig wrote:
>> On Mon, Feb 02, 2009 at 10:29:33PM -0700, vaded@... wrote:
> <SNIP>
>>
> I think it is important not to forget that Chuck well aware of what
> McCarthy was doing in 1958 when Lisp was formulated, and the Germans and
> Americans developed Algol in a comittee that same year. That was really
> the critical year in the history of programming, and we've basically
> been stuck with the idioms formalized in that year. In many ways, we're
> still fighting that battle, and sadly the Algol people are winning. :)
>>
>
> Please limit your lines to 72 char's. I had to reformat.
>
> There is a crucial difference between C FORTH FORTRAN PERL
> on one side and PASCAL ALGOL ADA PYTHON on the other.
> Only Americans don't seem to appreciate the difference.
> The US languages are disorganized and full of oddities, irregularities
> and add hoc constructions, unsafe allbeith practical.
> The European languages have a theoretical base, are regular, easier to
> understand and memorize and safer.
>
> Yes! Algol is winning. At long last runtime array bounds checking is
> added to the GCC compiler. And guess what? It only costs a few
> percent in performance.
>
> Most people thing PYTHON is way superior over PERL.
>
> Why are you sad?
>
>>
>> Dave
>>
>> PS. Lisp is just Polish Notation Forth, it about think :)
>
> Forth is reverse polish LISP.
>
> Groetjes Albert
>
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[John R. Strohm]

Learning C first will probably do some damage.

Learning Smalltalk first will probably do some serious damage.

Learning LISP first, if you learn it RIGHT (i.e., from SICP), will probably help
a lot more than it hurts.

Recall that there are two categories of computer languages:  LISP, and
everything else.

----- Original Message -----
From: <vaded@...>
To: <colorforth@...>
Sent: Wednesday, February 04, 2009 7:02 PM
Subject: Re: [colorforth] objects and forth

>I remember Jeff Fox saying something to the point of that the engineers
> he worked with who knew ASM had a very easy time picking up the 1X
> Forths (machine forth, etc.).  But those who were firmly entrenched in
> the C and related paradigms had a much harder time seeing the virtues of
> 1X forth and adopting its methodologies.  So I'm wondering if the
> approach of learning C or Lisp or Small Talk first may prime the mind in
> a ineffecient way when it comes to forth?
>
>
> On Wed, 4 Feb 2009 22:33:42 -0300 , "Jecel Assumpcao Jr"
> <jecel@...> said:
>> David J. Goehrig wrote:
>>
>> > The way I typically teach programming to newbies, and reteach people
>> > who've acquired a theoretical education, is I start off with the bit, and
>> > move up from there.  By the end a few days, they've learned enough
>> > to do basic assembler.  I then work with them to build a C or Lisp or
>> > Smalltalk.  At that point, if they're willing I introduce them to Forth.
>>
>> You might find this course interesting:
>>
>> http://www1.idc.ac.il/tecs/
>>
>> It is better known as "From Nand to Tetris in 12 steps". The authors
>> make some silly mistakes, like in their explanation of Harvard versus
>> Von Neuman architectures. And their machine language is more horrible
>> than I would like. But in general it seems to be a good course.
>>
>> About the subject, I worked on hardware for OO Color Forth in 2001/2002
>> and so have an opinion about this. But it will have to wait until
>> tomorrow (Friday is more likely...).
>>
>> -- Jecel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: colorforth-unsubscribe@...
>> For additional commands, e-mail: colorforth-help@...
>> Main web page - http://www.colorforth.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David Goehrig]

On Wed, Feb 04, 2009 at 10:33:42PM -0300, Jecel Assumpcao Jr wrote:
>
> You might find this course interesting:
>
> http://www1.idc.ac.il/tecs/

Thanks Jecel, it does look interesting. I got to say, I disagree 100% with their approach on the software side.  Any student is better off learning on real hardware, or at least an emulator of real hardware like Bochs.

> About the subject, I worked on hardware for OO Color Forth in 2001/2002

Do you have anything on it on your sites?  I'm guessing you were looking to use it to power your Self port?

> and so have an opinion about this. But it will have to wait until
> tomorrow (Friday is more likely...).

Tease... :)  I'm looking forward to seeing some more details on the new silicon.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com