home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.forth
- Path: sparky!uunet!ftpbox!mothost!isunix.cdx.mot.com!merlin.dev.cdx.mot.com!pjd.dev.cdx.mot.com!peterd
- From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
- Subject: Re: Sampler Forth
- Message-ID: <peterd.716219593@pjd.dev.cdx.mot.com>
- Sender: news@merlin.dev.cdx.mot.com (USENET News System)
- Nntp-Posting-Host: pjd.dev.cdx.mot.com
- Organization: Motorola Codex, Canton, Massachusetts
- References: <4303@wet.UUCP> <1992Sep9.174552.22223@tree.UUCP>
- Date: Fri, 11 Sep 1992 13:53:13 GMT
- Lines: 30
-
- alan@tree.UUCP (Alan) writes:
-
- >Forth programmers seem to be "hung up" on how fast their Forth kernel
- >runs.
-
- This has always surprised me, given that there seems to be a strong
- hostility towards classic optimization techniques in the Forth
- community, and a strong belief - in spite of the evidence - that
- Forth has a time-warping property that allows it to run faster than
- compiled languages in spite of executing more instructions.
-
- > They don't seem to grasp the significance of the programming
- >truism "First get it right. THEN make it smaller, faster, slicker,
- >etc."
-
- In fact, that's a good argument for using Forth in the first place.
- You take a language which allows rapid prototyping, and put your
- solution together in parts. The execution-time inefficiency of
- threaded code is made up for by implementation-time efficiency.
- And if that gives the implementer time to use a better algorithm
- or better tune the implementation, then the final result may
- execute quicker to boot.
-
- However, if you have to prototype basic language elements - like
- structures and arrays - that have been around since before most
- of us were born, then you lose most of the advantages you might
- get.
-
- Peter Desnoyers
- --
-