On Mon, Mar 17, 2008 at 7:01 PM, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: > > Bob La Quey wrote: > > On Mon, Mar 17, 2008 at 3:05 PM, Andrew Lentvorski <[EMAIL PROTECTED]> > wrote: > > > >> The problem I have with Forth (and many of Chuck's tools) is that they > >> never seem like a force multiplier. > > > > Why don't you amplify the idea of a force multiplier. You > > need not discuss Forth. Perhaps an example of what you mean. > > A force multiplier lets me do more than I could before. It lets me > think closer to the problem level than the computer level. It moves me > from conception to result far faster than other tools.
OK. > For example, in engineering, Matlab and Mathematica are force > multipliers. I can conceive of something, but I don't have to get > bogged down in the details of simulating or calculating it unless I need > to. I can let Matlab and Mathematica handle that. Stuff that used to > take 20 people now takes 1. I came to programming from first electronics then physics. I was used to creating and using abstraction, which is after all a lot of what physics was about. The reason I gravitated to Forth was it allowed me to create (actually very high level) abstractions with ease. The problem I have with most of the sorts of things you are talking about is that they impose "glass ceilings" because the particular level of abstraction that they have decided to focus on is often not appropriate to the next level of the problem. I get stuck with the level I started with often becuase the syntax is just so messy as to hide what is going on. Forth was designed to make implementing a Problem Oriented Language (POL) easy. That is where the force multiplication comes from. Unfortunately this approach is rarely taught. Nor is it a common way to think. As a consequence few people are much good at language design. A corollary is that functional programming seems wierd to many, while it is a very natural way to go for huge chunks of Forth code. The first time I ever used C I broke the macro facility within a week. I had created a little Forth like collection of graphics macros, a small graphics POL ... unfortunately the expansion of the macros ran up against the amount of space alloted by the compiler for them. Gradually I learned how to do things in a more conventional C like way. It did not make me especially happy though. > Similar things hold for computer languages. Assembly lets me get the > job done, but C lets me do more with less grunt work. Python and Lisp > let me do more with even less grunt work than C. > > Graphics and sound libraries let me create games in hours that used to > take months. I do agree about the existence of libraries. Two ways to multiply force. Libraries and abstraction. Reuse and nonuse. The think about abstraction properly used is that one can write far fewer lines of code. This is one reason good Forth programs seem absurdly short compared to programs written in more conventional langauges. > All of these things allow me to focus more on what I want to do rather > than how I want to do it. That is the entire point of a Problem Oriented Language. Do we really need Yet Another General Purpose Language with more and more features thrown in? I am far from sure. I like what Chuck Esterbrook is doing with Cobra, but is that really the right way to go? Maybe what we need is 1000's of little POLs that fit millions of problems well. For example, I am spending a fair amount of time right now reviewing web based APIs and reviewing mashups. See, for instance, the Programmable Web, which lists over 600 such APIs. http://www.programmableweb.com/apis One approach to building mashups with these APIs is to build a light weight scripting POL that groups a few of the together for the purpose of tackling some specific problem arena. It is not hard to conceive of a simple POL that would enable mashing YouTube videos and Google Maps together. All kinds of local services could be built quickly by ordinary people with such a thing. It might well have no more than a dozen or so keywords. If one thinks of HTML as such a simple POL then one can understand the power of such a thing when put into the hands of ordinary people. > It's like a table saw or a planer in woodworking. Sure, I can cut the > boards by hand or plane them to shape by hand. However, the power tools > let me get there faster with less effort. I can move from conception of > the result to the actual result far easier than with hand tools. This is a poor analogy. It just means doing the same thing faster. Not much more than simply saying, crank up the clock speed. Of course, I am happy to be using 2 GHz PCs instead of 10 MHz ones ... but it is not much in the way of intellectual progress. > Of course, some people enjoy the old ways. There is a visceral pleasure > in using more primitive tools for a project. However, then the goal is > the trip, not the destination. Forth on a high speed processor is certainly a visceral pleasure. I am looking forward to using the SeaForth chip to make a smart golf club. See United States Patents 7,308,818 and 7,264,555 I have a feeling that 18 billion even small operations/sec will be Good clean fun, BobLQ BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
