Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Why Forth is good (long) Keywords: stacks, programming glue, functional programming Message-ID: <2853@pt.cs.cmu.edu> Date: 1 Sep 88 15:51:47 GMT Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 78 We've had a bit of discussion on why Forth is "better" than other languages. I think I have found a good argument in favor of Forth. The reasoning is couched in terms of functional programming, but the arguments apply equally well to Forth, because they hinge on implicit parameter passing and the use of a stack. (Functional programming languages are like Forth in some ways, and some work has been done implementing functional extensions to Forth.) I especially like the reference to glueing pieces of programs together. The following text is borrowed without permission from: John Hughes, "Why Functional Programming Matters", Programming Methodology Group, University of Goteborg and Chalmers University of Technology, 41296 Goteborg, SWEDEN, November 1984 (in English). Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor. I don't even own up to my own opinions... ----------------------------------------------------- It's helpful to draw an analogy between functional and structured programming. In the past, the characteristics and advantages of structured programming have been summed up more or less as follows. Structured programs contain no 'goto' statements. Blocks in a structured program do not have multiple entries or exits. Strucuted programs are more tractable mathematically than their unstructured counterparts. These "advantages" of structured programming are very similar in spirit to the "advantages" of functional programming we dis- cussed earlier. They are essentially negative statements, and have led to much fruitless argument about "essential 'gotos'" and so on. With the benefit of hindsight, it's clear that these properties of struc- tured programs, although helpful, do not go to the heart of the matter. The most important difference between structured and unstructured programs is that structured programs are designed in a modular way. Modular design brings with it great productivity improvements. First of all, small modules can be coded quickly and easily. Secondly, general purpose modules can be re-used, leading to faster development of subsequent programs. Thirdly, the modules of a pro- gram can be tested independently, helping to reduce the time spent debugging. The absence of 'gotos', and so on, has very little to do with this. It helps with "programming in the small", whereas modular design helps with "pro- gramming in the large". Thus one can enjoy the benefits of structured program- ming in FORTRAN or assembly language, even if it is a little more work. It is now generally accepted that modular design is the key to successful programming, and recent languages such as Modula-II and Ada include features specifically designed to help improve modularity. However, there is a very important point that is often missed. When writing a modular program to solve a problem, one first divides the problem into sub-problems, then solves the sub-problems and combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase ones ability to modularise a problem conceptually, one must provide new kinds of glue in the programming language. Complicated scope rules and provision for separate compilation only help with clerical details, they can never make a great contribution to modu- larisation. One can appreciate the importance of glue by an analogy with carpentry. A chair can be made quite easily by making the parts - seat, legs, bach etc. - and stiching them together in the right way. But this depends on an ability to make joints and wood glue. Lacking that ability, the only way to make a chair is to carve it in one piece out of a solid block of wood, a much harder task. This example demonstrates both the enormous power of modularisation and the vital importance of having the right glue. Now let us return to functional programming. We shall argue in the remainder of this paper that functional languages provide two new, very important kinds of glue. We shall give many examples of programs that can be modu- larised in new, exciting ways, and thereby grealy simplified. This is the key to functional programming's power - it allows greatly improved modularisation. It is also the goal for which functional programmers must strive - smaller and simpler and more general modules, glued togehter with the new glues we shall describe. -------------------------------------------------------------