Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15259 > unrolled thread
| Started by | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| First post | 2012-08-29 23:00 -0700 |
| Last post | 2012-09-07 09:57 -0700 |
| Articles | 20 on this page of 126 — 29 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-08-29 23:00 -0700
Re: Article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-30 01:47 -0700
Re: Article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 12:13 +0000
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-30 11:31 -0400
Missing from USENET - was [Re: Article] Richard Owlett <rowlett@pcnetinc.com> - 2012-08-30 10:37 -0500
Missing from USENET - was [Re: Article] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-30 10:30 -0700
Re: Article hughaguilar96@yahoo.com - 2012-08-30 19:56 -0700
Re: Article awegel@arcor.de (Alex Wegel) - 2012-08-31 12:35 +0200
Re: Article "Greg Bailey" <greg@greenarraychips.com> - 2012-08-31 17:51 -0700
Re: Article Whammo <sidciavic@gmail.com> - 2012-08-31 18:22 -0700
Re: Article Mark Wills <forthfreak@gmail.com> - 2012-09-01 01:04 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-02 16:18 -0700
Re: Article Alex McDonald <blog@rivadpm.com> - 2012-09-01 01:48 -0700
Re: Article rickman <gnuarm@gmail.com> - 2012-09-02 18:38 -0400
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-02 16:59 -0700
Re: Article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-03 13:07 -0500
Re: Article Alex McDonald <blog@rivadpm.com> - 2012-09-03 14:25 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-04 17:04 -0700
Re: Article Ron Aaron <rambamist@gmail.com> - 2012-09-05 06:23 +0300
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 18:17 -0400
Re: Article "Elizabeth D. Rather" <erather@forth.com> - 2012-09-03 12:37 -1000
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-04 04:48 -0400
Re: Article Alex McDonald <blog@rivadpm.com> - 2012-09-04 03:39 -0700
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:48 -0400
Re: Article awegel@arcor.de (Alex Wegel) - 2012-09-04 13:18 +0200
Re: Article Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 16:03 +0200
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 03:29 -0400
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 03:24 -0400
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-04 08:12 -0700
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:06 -0400
Re: Article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-04 11:35 -0500
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:40 -0400
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-05 13:28 -0700
Re: Article "Elizabeth D. Rather" <erather@forth.com> - 2012-09-04 08:32 -1000
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:22 -0400
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-05 10:08 -0700
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:07 -0400
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-05 13:39 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-05 13:35 -0700
Re: Article "Ed" <invalid@nospam.com> - 2012-09-07 17:24 +1000
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-07 05:28 -0400
Re: Article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-07 03:28 -0700
Re: Article Ron Aaron <rambamist@gmail.com> - 2012-09-07 13:31 +0300
Re: Article jacko <jackokring@gmail.com> - 2012-09-07 06:33 -0700
Re: Article Howerd <howerdo@yahoo.co.uk> - 2012-09-07 09:06 -0700
Re: Article Howerd <howerdo@yahoo.co.uk> - 2012-09-07 09:03 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-04 16:45 -0700
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-03 21:38 -0700
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:51 -0400
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-05 10:49 -0700
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:20 -0400
Re: Article "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:06 -0400
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-05 13:32 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-05 13:50 -0700
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-05 22:34 -0700
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-07 14:05 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-08 01:53 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-07 18:22 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 00:08 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-08 17:34 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 15:57 +0200
Re: Forth as a polarising language Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-09 08:12 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 22:07 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-09 15:14 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-10 01:52 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-09 19:17 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-10 15:01 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-10 07:00 -0700
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-11 01:07 +0200
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-10 18:47 -0700
Re: Forth as a polarising language Elizabeth D Rather <erather@forth.com> - 2012-09-10 16:08 -1000
Re: Forth as a polarising language anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-11 07:51 +0000
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-11 19:24 +0200
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-11 21:40 +0200
Re: Forth as a polarising language "Elizabeth D. Rather" <erather@forth.com> - 2012-09-09 14:58 -1000
Re: Forth as a polarising language Paul Rubin <no.email@nospam.invalid> - 2012-09-09 18:24 -0700
Re: Forth as a polarising language Anonymous <nobody@remailer.paranoici.org> - 2012-09-09 13:42 +0000
Re: Forth as a polarising language mhx@iae.nl (Marcel Hendrix) - 2012-09-08 10:34 +0200
Re: Forth as a polarising language Doug Hoffman <glidedog@gmail.com> - 2012-09-08 07:06 -0400
Re: Forth as a polarising language mhx@iae.nl (Marcel Hendrix) - 2012-09-08 16:14 +0200
DEFER (was: Forth as a polarising language) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 16:47 +0000
Re: Forth as a polarising language Doug Hoffman <glidedog@gmail.com> - 2012-09-09 04:22 -0400
OOP (was: Forth as a polarising language) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 11:38 +0000
Re: OOP Doug Hoffman <glidedog@gmail.com> - 2012-09-08 08:19 -0400
Re: OOP mhx@iae.nl (Marcel Hendrix) - 2012-09-08 16:41 +0200
Re: OOP Doug Hoffman <glidedog@gmail.com> - 2012-09-09 04:24 -0400
Re: Forth as a polarising language mhx@iae.nl (Marcel Hendrix) - 2012-09-09 12:03 +0200
Re: Forth as a polarising language "A. K." <akk@nospam.org> - 2012-09-09 13:20 +0200
Re: Forth as a polarising language Doug Hoffman <glidedog@gmail.com> - 2012-09-10 08:33 -0400
Re: OOP mhx@iae.nl (Marcel Hendrix) - 2012-09-08 16:54 +0200
Re: OOP Doug Hoffman <glidedog@gmail.com> - 2012-09-09 04:12 -0400
OOP (was: Forth as a polarising language) mhx@iae.nl (Marcel Hendrix) - 2012-09-08 16:28 +0200
Re: OOP (was: Forth as a polarising language) mhx@iae.nl (Marcel Hendrix) - 2012-09-08 16:56 +0200
Re: OOP (was: Forth as a polarising language) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 15:00 +0000
Re: OOP (was: Forth as a polarising language) Roger Ivie <rivie@ridgenet.net> - 2012-09-08 11:56 -0500
Re: OOP Doug Hoffman <glidedog@gmail.com> - 2012-09-09 04:20 -0400
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 00:15 +0200
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 00:50 +0200
Re: Forth as a polarising language mhx@iae.nl (Marcel Hendrix) - 2012-09-09 03:12 +0200
Re: Forth as a polarising language Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 16:01 +0200
Re: Forth as a polarising language "Elizabeth D. Rather" <erather@forth.com> - 2012-09-09 14:54 -1000
[OT] Newsreader problem - was [Re: Forth as a polarising language] Richard Owlett <rowlett@pcnetinc.com> - 2012-09-10 06:33 -0500
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Doug Hoffman <glidedog@gmail.com> - 2012-09-10 08:16 -0400
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Doug Hoffman <glidedog@gmail.com> - 2012-09-10 08:28 -0400
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-10 12:43 +0000
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Doug Hoffman <glidedog@gmail.com> - 2012-09-10 09:24 -0400
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Richard Owlett <rowlett@pcnetinc.com> - 2012-09-10 08:12 -0500
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Doug Hoffman <glidedog@gmail.com> - 2012-09-10 09:32 -0400
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] "Elizabeth D. Rather" <erather@forth.com> - 2012-09-10 07:40 -1000
Re: [OT] Newsreader problem - was [Re: Forth as a polarising language] Richard Owlett <rowlett@pcnetinc.com> - 2012-09-10 14:42 -0500
Re: Forth as a polarising language Doug Hoffman <glidedog@gmail.com> - 2012-09-10 07:59 -0400
Re: Forth as a polarising language rickman <gnuarm@gmail.com> - 2012-09-10 12:27 -0400
Re: Forth as a polarising language "Elizabeth D. Rather" <erather@forth.com> - 2012-09-10 07:44 -1000
Re: Forth as a polarising language rickman <gnuarm@gmail.com> - 2012-09-10 12:30 -0400
Re: Article "Ed" <invalid@nospam.com> - 2012-09-09 14:13 +1000
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-11 11:26 -0700
Re: Article "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-09-11 21:02 +0100
Re: Article vandys@vsta.org - 2012-09-11 20:37 +0000
Re: Article "Ed" <invalid@nospam.com> - 2012-09-12 20:01 +1000
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-11 16:50 -0700
Re: Article Mark Wills <forthfreak@gmail.com> - 2012-09-12 00:45 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-12 18:44 -0700
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-12 20:26 -0700
Re: Article "Ed" <invalid@nospam.com> - 2012-09-12 20:47 +1000
Re: Article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-06 19:28 -0700
Re: Article John Passaniti <john.passaniti@gmail.com> - 2012-09-07 09:57 -0700
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-09 15:57 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <4730306.fNe2lVOm3c@sunwukong.fritz.box> |
| In reply to | #15545 |
Paul Rubin wrote: > I've never understood what is going on with those UI's. Part of the > problem may stem from the tragedy of X windows. I had no problem creating a non-lagging UI on top of X 15 years ago. X is not the problem. > But I'm sure that > those developers have played video games, and what are video games > other than no-lag GUI's? Indeed. That's why I was quite grumpy at that time with GUIs - games like Doom or Quake had 3D textured environments, without lags, and to show a simple file selector takes seconds? WTF? 15 years later, it still takes awfully long... > Meh, I think the rage these days is 3D printing. I don't know about > wood carving but I know some people making metal stuff, and except for > very simple parts turned on a lathe, everyone uses CNC or printing > now, even for one-off pieces. Maybe. The creative wood carvers I know of still use chainsaws. And the rest uses CNC, but they are not creative. > Take a look at www.bathsheba.com and tell me > how to make stuff like that with hand tools or chainsaws. The tool is named slightly different with this sort of material (it's more something like a dentist drill), but people do quite astonishing things with these tools and their hands. >> I don't consider dynamically typed languages as "strong typed", > > That is a terminology thing--there doesn't seem to be a clear > uniform definition of that term. Luca Cardelli's view is that > dynamic types are strong in the sense that they prevent type errors > from > launching the program into undefined behavior. I would surely say > that Scheme is a safer language than C or Forth for this reason. "Undefined" behavior is something language lawyers tend to use. A computer is a fully deterministic state machine, there is no undefined behavior. If you write outside the bounds of an array, you are overwriting other stuff, it's not undefined. People who do security exploits get very well-defined behavior out of their programs - unwanted, but well-defined. So a Lisp program won't segfault while a C or Forth program will. The Lisp program still prints error messages which disrupt the normal control flow of that program. From the program's point of view, this behavior is still "undefined", it won't know what to do. Termination is a good idea. In contrast, a Haskell program with such a type error even doesn't compile. That's what I consider strong typing. >> because they do try hard to figure out what the programmer wanted, >> and convert data automatically if possible. > > I don't think automatic conversion is characteristic of dynamic types. > It seems pretty horrendous to me that PHP converts digit strings to > numbers if you do arithmetic on them. Scheme and Python raise errors > if you do that. But they treat integers/bignums/floats as interchangeable. >> People in general (BDSM doesn't count) prefer positive >> feedback. > > It's just like a musical instrument, where when you first start > playing all you can get is awful noise. People get good with those > instruments anyway. The more popular instruments are ones where you get a reasonable tune out at first try. There are BDSM-style people who love to be punished or do painful things. They are a minority, they don't count. The majority of people prefers positive to negative feedback. They won't get good on alphorns. > Yeah, interactive shells are a big help for quick prototyping. I > somewhat regret that I never used any of the grand Lisp environments > (i.e. the MIT Lisp machines) back in the era when anybody cared about > them. Python has some nice interactive shells and I do use those. > Paradoxically the current prescription for "serious" Python > programming is test-driven development (TDD): you are supposed to > write a test suite > for the code before you write the code itself. I've the impression that too many people confuse "serious" with "no fun", "hierarchies" and as consequence "BDSM" style stuff. Having tests for your code is good. However, when I write something like the binary heap, it is first explorative coding, and then writing tests. The "writing tests" after all should be explorative, too, because with normal test-driven programming you end up with a test that doesn't test what it should and a program that doesn't deliver what it should. Which means two times the possible bugs, and therefore much longer debugging time. > So that seems like a > beat-back against interactive, exploratory development. If those > tests have a 50% hassle factor and a type system gets rid of half of > it while adding 5% of its own, That's an optimistic assumption. My experience is that the type system gets rid of 5%, while adding 200% of its own. Yes, I've used the "wrong" strong typed languages, like VDHL. Where even the test were bugged by VDHL - the programmer wrote something like i := i + 1; and then had to rewrite that into i := when i = 15 then 0 else i + 1; or whatever the correct syntax is (it's too long ago), because VHDL otherwise caused an exception (it *did* compile). This lot of own hassle added makes people feel that they have achieved a lot when the program finally compiles, but in fact it was all only introduced by the type system itself. >> The thing I was doing was a battery monitor... On a tiny micro deeply >> embedded in some small device. > > Sure, that's an important thing to be doing, but it's a niche; and > sure, it's a reasonable place for Forth, but it could also be > programmed directly in assembly code. Forth is the assembly code of the b16, and yes, I've done something like that using "real" microcontroller assembly code (PIC17): It is a nightmare. >> The only larger chip without embedded micro is the power management >> circuit from Dialog, and it has no micro for mere stupidity. > > I wonder if it's actually there but inaccessible? I've been working there, trust me, they didn't have one. The other micros are mostly inaccessible, either. I forgot that the audio processor (to drive the headphone and the speaker) also has a micro/dsp, this one is even quite accessible. >> The price budget for a battery monitor of course is more in the 30¢ >> region or even below. Forget about your $3 ARM. > > In a high volume device like a phone, I'm surprised the battery > monitor isn't jammed into a corner of some multi-function ASIC rather > than being a separate part. That was the project I was doing. > I don't think such niches are uninteresting. There just aren't all > that many progammers (compared to the general programmer population) > working in them. That's what makes them niches. >> (Ti apparently uses an MSP430 in their battery monitor, and they >> write >> the program in C. It's more than 16k long as resoult, which means >> the chip exceeds the 30¢ budget). > > I don't understand why the code bloat. Are you comparing against your > B16 processor? Are you really saying there's an 8x difference in code > density for B16 Forth vs. MSP430 C when the applications are doing the > same things? Not exactly. I had the figures from Ti's part and how large their program was. It's not "same thing" as in 1:1 translated program, it is "same thing" as in "same resulting precision" of the battery monitor. I'm sure the Ti guys are not stupid and know what they are doing. I'm however convinced that their approach has flaws which they then need to work around. > I'm pretty doubtful there is that big a difference, and > I suspect that either the MSP430 code is using libraries carelessly, > or else it's doing fancier stuff than the B16 code. I don't have a source listing of Ti's program. It just was that Apple made pretty clear that they don't believe at all I will fit the program into 2k, not at all, and meeting the specs. We therefore added another 2k RAM to the prototype, which I then didn't use. The sort-of same program written in PIC17 assembly language was 8k long. Of course, the b16 program was a complete rewrite from scratch. I've heard this "it's not possible", "you must be comparing apples to bananas" and all that stuff often enough. Redefining the problem until a small program can solve it is part of Forth's philosophy, it's not just the code density of 5 bit per instruction that matters. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-09-09 08:12 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <c4673e27-9eac-49c8-a335-f113b75fa227@googlegroups.com> |
| In reply to | #15556 |
Does this mean we could be seeing a Forth micro in Apple products, even if it is just a lowly battery monitor?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-09 22:07 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <2569434.TxyZk32Hkh@sunwukong.fritz.box> |
| In reply to | #15558 |
Mark Wills wrote: > Does this mean we could be seeing a Forth micro in Apple products, > even if it is just a lowly battery monitor? Maybe. I left that company when it still was a prototype, and I don't know if they can finish that to a real product, having no expert and being generally hostile to experts. All I know is that the last prototype I worked on before leaving worked as expected. Apple is very secretive, and enforces the same level of secretivity on the suppliers, so I don't get much information out. In the end, even when it ends up in an Apple product, you will not know. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-09 15:14 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <7xehmax2rm.fsf@ruckus.brouhaha.com> |
| In reply to | #15556 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> "Undefined" behavior is something language lawyers tend to use. A
> computer is a fully deterministic state machine, there is no undefined
> behavior.
Undefined in the sense that it can't be deduced just from the program
text. It depends on the complete state of the machine including the OS,
compiler output, etc, which are outside the programmer's control. And
the machine state at bottom is truly nondeterministic, because it
depends on what order things have happened in, which depends on things
like disk latency variations and external I/O events. Disk latency is
controlled in part by physically random, turbulent airflow inside the
disk drive. This is sometimes used as a source of entropy for
cryptographic RNG's.
> So a Lisp program won't segfault while a C or Forth program will. The
> Lisp program still prints error messages which disrupt the normal
> control flow of that program. From the program's point of view, this
> behavior is still "undefined", it won't know what to do. Termination is
> a good idea.
Of course it knows what to do: termination is well-defined. In a
long-running system you probably want to add some failover mechanism to
recover from the crash.
> In contrast, a Haskell program with such a type error even doesn't
> compile. That's what I consider strong typing.
OK, fair enough.
>> Scheme and Python raise errors if you do that.
> But they treat integers/bignums/floats as interchangeable.
Scheme doesn't:
guile> (/ 5 3)
5/3
guile> (/ 5.0 3.0)
1.66666666666667
Python treated 5/3 as truncating integer division in version 2 but as
giving a floating result in version 3, because apparently the integer
result confused beginners. I think I'd prefer raising an exception so I
can make sure the program does exactly what I intended. Haskell doesn't
do any automatic conversions and I find it actually reassuring that it
doesn't. Supplying a manual conversion is trivial when it's what you
want.
> The more popular instruments are ones where you get a reasonable tune
> out at first try.
The most popular instrument around here is probably the guitar, and it's
much harder for beginners to get good sound from a guitar from than a
piano or a wind instrument, or maybe even a violin (no idea about
alphorn). Or the flute: it's hard to get any sound at all at first,
whether good or bad. I think people play what they like to listen to,
and if they're into it enough to get any good, they'll also persist
through rough spots at the beginning.
> My experience is that the type system gets rid of 5%, while adding
> 200% of its own. Yes, I've used the "wrong" strong typed languages,
Well, it's also partly subjective, and partly a matter of style, and
maybe also partly a matter of how much of your programming day is spent
dealing with code that you wrote yourself, versus code (even good,
well-documented code) written by other people. If you're hired to add a
new feature that intersects significant chunks of an existing,
million-line program, a type system may help you more than it would help
if you're developing a small program from scratch.
> and then had to rewrite that into
> i := when i = 15 then 0 else i + 1;
> ... because VHDL otherwise caused an exception (it *did* compile).
Oh man, I wonder if what was really needed was some kind of declaration
of a 4-bit binary counter, i.e. the variable really was indeed the wrong
type. What does it mean for VHDL to throw a runtime exception
anyway????
> Forth is the assembly code of the b16, and yes, I've done something
> like that using "real" microcontroller assembly code (PIC17): It is a
> nightmare.
Meh, the PIC instruction set is ugly but it's tractable. I know a guy
who programmed those things and did amazing stuff with them. Yeah,
Forth was probably easier, but if you're making 10 million of something,
1 cent saved on the hardware per unit is $100,000 which is worth some
extra development time.
>>> MSP430 ... in C. It's more than 16k long...
> The sort-of same program written in PIC17 assembly language was 8k long...
> I've heard this "it's not possible", "you must be comparing apples to
> bananas" and all that stuff often enough. Redefining the problem until
> a small program can solve it is part of Forth's philosophy, it's not
> just the code density of 5 bit per instruction that matters.
I'm having trouble figuring out what a battery monitor needs to do that
wants that much code space (16k or 8k). I think we have to treat this
MSP430 thing as indeterminate. The MSP430 has 16-bit instructions but
they are like the PDP-11, with enough registers and addressing modes
that each instruction can do the equivalent of multiple 5-bit
operations. So I doubt there's a huge difference in code density,
whether it's better or worse. In an ASIC, the b16 core is probably
smaller by enough to make up for some code space disadvantage anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-10 01:52 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <2370419.WlZCQYq3kg@sunwukong.fritz.box> |
| In reply to | #15560 |
Paul Rubin wrote: > And > the machine state at bottom is truly nondeterministic, because it > depends on what order things have happened in, which depends on things > like disk latency variations and external I/O events. External events (and a disk drive is external to the CPU) don't really count... I'd say that current CPUs are still fully deterministic in normal operating conditions, though they may have deliberately added non-deterministic parts e.g. to generate random numbers for cryptography. Some parts are way too complicated to be considered "deterministic" for the programmer like cache warmup behavior or branch prediction. > Of course it knows what to do: termination is well-defined. In a > long-running system you probably want to add some failover mechanism > to recover from the crash. I usually want a good debug message like backtraces, what inputs failed, and termination/going back to the prompt, and a way to use catch/throw to let the program take control (e.g. print additional useful debugging informations the system doesn't know about). >>> Scheme and Python raise errors if you do that. >> But they treat integers/bignums/floats as interchangeable. > > Scheme doesn't: > > guile> (/ 5 3) > 5/3 > guile> (/ 5.0 3.0) > 1.66666666666667 Yes, Scheme has even fractions as one of these number types - so when you divide two integers, you get a fraction (implicit type conversion). You can use further operations on these fractions like guile> (/ (/ 3 5) (/ 7 2)) $1 = 6/35 guile> (+ (/ 3 5) (/ 7 2)) $2 = 41/10 But when you do guile> (+ (/ 5 3) 0.33333333333333333333333) $3 = 2.0 you get a floating point number. That's an automatic conversion. > Python treated 5/3 as truncating integer division in version 2 but as > giving a floating result in version 3, because apparently the integer > result confused beginners. I think I'd prefer raising an exception so > I can make sure the program does exactly what I intended. Raising an exception to a division that is not by 0 is clearly not what I would think as reasonable default. Confusing beginners is sometimes necessary, because beginners need some lessions. Especially about integer division, which is not something they might know. > Supplying a manual conversion is trivial when it's what you want. Forth has no overloading, so you have to be precise about what you mean there, too. Different people prefer different things, and PHP with its "convert strings to numbers and operate on them" is... hm... well, apparently the target audience of PHP likes that... >> The more popular instruments are ones where you get a reasonable tune >> out at first try. > > The most popular instrument around here is probably the guitar, and > it's much harder for beginners to get good sound from a guitar from > than a piano or a wind instrument, or maybe even a violin (no idea > about alphorn). I've played the guitar, because it was cheaper than a piano, and needed less space (when I was a child, electronic keyboards were rare and large, too) but I had more fun with the neighbor's piano. I tried an alphorn, and got no sound out, it's a lot harder than a flute. A guitar gets at least some sound out... >> My experience is that the type system gets rid of 5%, while adding >> 200% of its own. Yes, I've used the "wrong" strong typed languages, > > Well, it's also partly subjective, and partly a matter of style, and > maybe also partly a matter of how much of your programming day is > spent dealing with code that you wrote yourself, versus code (even > good, > well-documented code) written by other people. If you're hired to add > a new feature that intersects significant chunks of an existing, > million-line program, a type system may help you more than it would > help if you're developing a small program from scratch. I'm not sure, what for? To get the calling conventions right? A million-line program should be fairly well modularized, so whatever feature you want to add, you should treat most of the program as library, which you won't change. >> and then had to rewrite that into >> i := when i = 15 then 0 else i + 1; >> ... because VHDL otherwise caused an exception (it *did* compile). > > Oh man, I wonder if what was really needed was some kind of > declaration of a 4-bit binary counter, i.e. the variable really was > indeed the wrong type. The problem is that VHDL makes it rather difficult to have such a 4-bit binary counter that can be used as integer, too... I'd say, VHDL gets the basics wrong. But they follow your design principle to rather fail and require an explicit conversion instead of doing it implicitely and correct. In Verilog, you declare a 4 bit variable, and it will wrap around on additions (the compiler actually tells you that you stripped the carry off, but it is a warning), and you can use it as integer to index arrays and such. In VHDL? It's all explicit, and you either get the easy array index *or* the easy wraparound, but not both. > What does it mean for VHDL to throw a runtime exception > anyway???? The simulator prints an error and stops. This was test code, so never ran through the synthesis tool. The majority of HDL code you write does not end up in silicon, it only runs through a simulator. > Meh, the PIC instruction set is ugly but it's tractable. I know a guy > who programmed those things and did amazing stuff with them. Yeah, > Forth was probably easier, but if you're making 10 million of > something, 1 cent saved on the hardware per unit is $100,000 which is > worth some extra development time. That's why I developed the b16. Get a controller which is smaller than a PIC17, has a considerable denser instruction set, *and* is a lot easier to program is worth a few days of work. > I'm having trouble figuring out what a battery monitor needs to do > that > wants that much code space (16k or 8k). Me, too. The Ti code is about as old as the code I inherited, as it came from Benchmarq. Over time, such a code base grows and accumulates cruft. > I think we have to treat this > MSP430 thing as indeterminate. The MSP430 has 16-bit instructions but > they are like the PDP-11, with enough registers and addressing modes > that each instruction can do the equivalent of multiple 5-bit > operations. The MSP430 is certainly a lot better than the PIC17. > So I doubt there's a huge difference in code density, > whether it's better or worse. In an ASIC, the b16 core is probably > smaller by enough to make up for some code space disadvantage anyway. At least for the b16, the program memory is significantly larger than the processor ;-). For Chucks F18, the memory is about as large as the processor, and he only has 64 words of RAM + 64 words of ROM. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-09 19:17 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <7xzk4y8vuu.fsf@ruckus.brouhaha.com> |
| In reply to | #15561 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > I usually want a good debug message like backtraces, what inputs failed, > and termination/going back to the prompt, and a way to use catch/throw > to let the program take control (e.g. print additional useful debugging > informations the system doesn't know about). Yeah, logging helps, and the restart mechanism may be able to inspect the carcass of the crashed program before restarting. You can use catch/throw but the idea is that if there's an unexpected throw, the program is in some confused state and you can't really trust it, so it's better to blow away the whole process and at least get to a known state by restarting. > Raising an exception to a division that is not by 0 is clearly not what > I would think as reasonable default. One can reasonably say that the ring of integers does not have division, so dividing integers is simply an invalid operation. I used to like the automatic conversion approach but I no longer think it gains anything worthwhile. >> Supplying a manual conversion is trivial when it's what you want. > Forth has no overloading, so you have to be precise about what you mean > there, too. Yeah, and in Forth I think I'd be happier getting an error message and backtrace in the event of a mismatch. > PHP with its "convert strings to numbers and operate on them" > is... hm... well, apparently the target audience of PHP likes that... Yeah, and thedailywtf.com is full of PHP code for a reason... > I'm not sure, what for? To get the calling conventions right? You often have to refactor large chunks of code to get data from one place to another where there was no path before. > The problem is that VHDL makes it rather difficult to have such a 4-bit > binary counter that can be used as integer, too... I'd say, VHDL gets > the basics wrong. But they follow your design principle to rather fail > and require an explicit conversion instead of doing it implicitely and > correct. I guess for something like VHDL, I don't see how this is a big deal, since some extra keystrokes and simulation passes are insignificant compared to the cost of actually printing a design in silicon. > The simulator prints an error and stops. This was test code, so never > ran through the synthesis tool. The majority of HDL code you write does > not end up in silicon, it only runs through a simulator. Cool. I want to try some HDL programming one of these days, probably with an FPGA kit. > At least for the b16, the program memory is significantly larger than > the processor ;-). For Chucks F18, the memory is about as large as the > processor, and he only has 64 words of RAM + 64 words of ROM. I wonder whether Chuck could have gotten better code density by using 6-bit instructions and making the ALU a little bigger. The F18 die photo is mostly memory and stacks. Every time I want a literal "1" in an F18 program, it burns between 1 and 2 full instruction words and it's maddening.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-10 15:01 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <44911562.uCePkysVEk@sunwukong.fritz.box> |
| In reply to | #15567 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> I usually want a good debug message like backtraces, what inputs >> failed, and termination/going back to the prompt, and a way to use >> catch/throw to let the program take control (e.g. print additional >> useful debugging informations the system doesn't know about). > > Yeah, logging helps, and the restart mechanism may be able to inspect > the carcass of the crashed program before restarting. You can use > catch/throw but the idea is that if there's an unexpected throw, the > program is in some confused state and you can't really trust it, so > it's better to blow away the whole process and at least get to a known > state by restarting. I can see that this sort of thinking makes sense in other languages, where inspecting the program is difficult, but in Forth, no. >> Raising an exception to a division that is not by 0 is clearly not >> what I would think as reasonable default. > > One can reasonably say that the ring of integers does not have > division, so dividing integers is simply an invalid operation. I assure you, the / operation in Forth is a very useful operation. It's actually not a division in the ring of integers, it's a rounded division in the subset of N. > Yeah, and in Forth I think I'd be happier getting an error message and > backtrace in the event of a mismatch. Yes, you usually do get that. >> I'm not sure, what for? To get the calling conventions right? > > You often have to refactor large chunks of code to get data from one > place to another where there was no path before. A result from the "bury your tool" mentality in other languages. > I guess for something like VHDL, I don't see how this is a big deal, > since some extra keystrokes and simulation passes are insignificant > compared to the cost of actually printing a design in silicon. Not really. There is a limited time budget for getting the product out. Simulation passes can take quite a while, VHDL is not a fast language (slow compiles, slow runs). If your language makes it harder to get something done, it takes longer to develop, or less time is spent to actually do productive work... Some people back then had statistics that Verilog was about 3 times as productive than VHDL. By being right first time on simple things like counters, instead of having to add extra keystrokes and do extra simulation runs. Verilog also compiles significantly faster than VHDL, because it doesn't need to check all these things... For Verilog vs. VHDL, the strong typing gives you 5% and takes you 200%. > Cool. I want to try some HDL programming one of these days, probably > with an FPGA kit. With my FGPA stuff, I often end up doing as much as possible in Forth on the b16 instead of writing new HDL code, because doing it in Forth has the "flow" (less than 3s response to every change), while doing it in Verilog means waiting 3 minutes or so per change. Breaking the flow is very counter-productive. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-10 07:00 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <7xa9wy6kqv.fsf@ruckus.brouhaha.com> |
| In reply to | #15576 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> Yeah, logging helps, and the restart mechanism may be able to inspect >> the carcass of the crashed program before restarting.... > I can see that this sort of thinking makes sense in other languages, > where inspecting the program is difficult, but in Forth, no. What do you mean about inspecting the program being easier in Forth than other languages? I just meant letting the recovery mechanism collect some debugging info beyond the crash dump. (I'll confess I don't know how Erlang/OTP programs usually handle this situation and now I'm kind of wondering.) > I assure you, the / operation in Forth is a very useful operation. It's > actually not a division in the ring of integers, it's a rounded division > in the subset of N. Right, something like /MOD NIP which is a purely integer operation. There's no attempt by Forth to automatically choose between / and (e.g.) S>F F/ and it doesn't seem Forth-like to do so. >> in Forth I think I'd be happier getting an error message and >> backtrace in the event of a mismatch. > Yes, you usually do get that. I don't remember the backtraces being terribly useful, and often they didn't happen at the actual point of the error. What happens with the backtrace when there's user data on the return stack? >> You often have to refactor large chunks of code to get data from one >> place to another where there was no path before. > A result from the "bury your tool" mentality in other languages. I don't understand this. You're saying it doesn't happen in Forth? > Simulation passes can take quite a while, VHDL is not a fast language > (slow compiles, slow runs). Hmm, ok. I wonder why compiles intended to run a simulator are slow: are they slower than, say, C++ compilations for the same amount of source text? ( Joke: http://xkcd.com/303/ ) Slow simulations I can understand, but that argues for more error checks at compile time. > Some people back then had statistics that Verilog was about 3 times as > productive than VHDL. Wow, that's interesting, I had thought they were pretty comparable, with mostly stylistic differences. > With my FGPA stuff, I often end up doing as much as possible in Forth on > the b16 instead of writing new HDL code, This makes sense, and probably saves hardware a lot of the time, if the b16 code is in a RAM block re-using the b16 logic, instead of using up CLB's.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-11 01:07 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <1651452.CLfWVFRu8b@sunwukong.fritz.box> |
| In reply to | #15583 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Yeah, logging helps, and the restart mechanism may be able to >>> inspect the carcass of the crashed program before restarting.... >> I can see that this sort of thinking makes sense in other languages, >> where inspecting the program is difficult, but in Forth, no. > > What do you mean about inspecting the program being easier in Forth > than other languages? You have an interactive shell. You have self-inspecting capability like SEE. There are other languages like Lisp with similar self-inspecting capabilities, and those tend to not quit on errors, too. Guile launches a debug shell, which is pretty cool, because you are still in the context of the program right where it "crashed". However, in most Algol-like languages, you have nothing, and therefore, you can only print a backtrace and quit. > Right, something like /MOD NIP which is a purely integer operation. > There's no attempt by Forth to automatically choose between / and > (e.g.) S>F F/ and it doesn't seem Forth-like to do so. No, you exactly specify what you want. There might be some problems with / being either floored or symmetric in different implementations... >>> in Forth I think I'd be happier getting an error message and >>> backtrace in the event of a mismatch. >> Yes, you usually do get that. > > I don't remember the backtraces being terribly useful, and often they > didn't happen at the actual point of the error. What happens with the > backtrace when there's user data on the return stack? The backtrace guesses what is user data, and prints that. : test 1 >r 2 >r 3 >r 0 @ ; ok test :2: Invalid memory address >>>test<<< Backtrace: $7FA9FFBBF720 @ $3 $2 $1 I find this quite useful. It tells me that @ failed with an invalid memory address, and that there are 3, 2, and 1 pushed on the return stack. I often run my programs with gforth-fast, which doesn't have a precise recording of where the crash happend, and then curse me, because there, the backtrace is not meaningful - which means I have to rerun with the debugging engine, and hope that the same error condition arises. >>> You often have to refactor large chunks of code to get data from one >>> place to another where there was no path before. >> A result from the "bury your tool" mentality in other languages. > > I don't understand this. You're saying it doesn't happen in Forth? People still can make mistakes in Forth, but our mentality is not to bury tools, and therefore, this sort of refactoring isn't necessary that often. Writing a Forth program is about finding good factors. I think I know what thing you mean, I've found something in that direction in Android. I'm using native activity for Gforth (as Gforth isn't implemented in Java, it is an obvious choice). However, native activities don't get reasonable non-ASCII key events. Why? Because some jerk at Google didn't convert the string that is part of the KeyEvent Java object into a C string. The string is only used for non- ASCII things. The whole data starts in a Java object, gets converted to a C++ object, and then is accessed by C functions, which presume this C++ object is a struct. Nobody sane would do it that way in Forth, especially not with this middle layer in between, which is of no real use. We hate writing "onion code", where you have layers and layers on top of each others, and the smell alone makes you cry. >> Simulation passes can take quite a while, VHDL is not a fast language >> (slow compiles, slow runs). > > Hmm, ok. I wonder why compiles intended to run a simulator are slow: > are they slower than, say, C++ compilations for the same amount of > source text? ( Joke: http://xkcd.com/303/ ) I don't have current figures at hand. The last time I touched VHDL was more than 10 years ago. Verilog was considerably faster. > Slow simulations I can understand, but that argues for more error > checks at compile time. No, this is that fallacy. The error checks at compile time don't find the logical errors you make, and especially with a proper set of types in your HDL, you aren't prone to type errors. After all, the only thing you can do in real hardware are bits and vectors of bits, which are treated as variable sized integers (two's complement). Verilog checks if you make size mismatches, that's all. And that's also sufficient. You don't have any complicated types in an HDL. >> Some people back then had statistics that Verilog was about 3 times >> as productive than VHDL. > > Wow, that's interesting, I had thought they were pretty comparable, > with mostly stylistic differences. I introduced Verilog to my coworkers shortly after I started at Mikron, now 14 years ago. We had a legacy project running, and once we finished that, they all switched over to Verilog, and were quite happy. From a 10000ft point of view, they seem to be pretty similar. But you don't programm hardware at 10000ft height. You program it lying flat on the floor. >> With my FGPA stuff, I often end up doing as much as possible in Forth >> on the b16 instead of writing new HDL code, > > This makes sense, and probably saves hardware a lot of the time, if > the b16 code is in a RAM block re-using the b16 logic, instead of > using up CLB's. Indeed. IMHO the most valuabe layer of abstraction when programming hardware is the instruction pattern. Implement the different operations you want to do as instructions, and then write the program using these instructions. A lot of hardware developer have no software background, and use the state machine abstraction instead. It is a guarantee for horribly long code, many, many gates, and awful bugs (the typical bug of a state machine is the "stuck" bug: it enters a state, but the exit event never happens). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-10 18:47 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <7x1ui9tjoa.fsf@ruckus.brouhaha.com> |
| In reply to | #15595 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> What do you mean about inspecting the program being easier in Forth > You have an interactive shell. You have self-inspecting capability like > SEE. There are other languages like Lisp with similar self-inspecting > capabilities, and those tend to not quit on errors, too. OK, but that presumes there's a person around to interact with the stopped program. I was thinking more of the situation where your embedded box crashes in the field. There's not much to do but restart it, and try to figure out later what happened. > However, in most Algol-like languages, you have nothing, and therefore, > you can only print a backtrace and quit. That's why we have debuggers. Just run the program under one. In ITS, the standard shell was a debugger and all programs ran under it. > Backtrace: > $7FA9FFBBF720 @ ... > I find this quite useful. It tells me that @ failed with an invalid How do you map $7FA9FFBBF720 back to a Forth word so you can know where the error happened? > People still can make mistakes in Forth, but our mentality is not to > bury tools, and therefore, this sort of refactoring isn't necessary that > often. Writing a Forth program is about finding good factors. I would have expected it to be worse in Forth, because there are so many more nested words, communicating through the stack. Maybe you have to pass a new parameter from a higher level to a lower level, and that means all the intervening words change their signature. Or maybe you combine a few variables or stack slots into a structure or object, and again everything that touches that data has to change. > The whole data starts in a Java object, gets converted to a C++ > object, and then is accessed by C functions, which presume this C++ > object is a struct. Is it so awful to write some Forth code that pulls the relevant fields out of the struct? > We hate writing "onion code", where you have layers and layers on top > of each others, and the smell alone makes you cry. I thought the opposite: the Forth approach is to factor everything into tiny little words, nested much more deeply than subroutines of traditional languages, with data abstraction implicit in the factoring. >> Slow simulations I can understand, but that argues for more error >> checks at compile time. > > No, this is that fallacy. The error checks at compile time don't find > the logical errors you make, The exception in your example with the 4-bit binary counter would have been spotted by a totality checker, that makes sure there is a meaningful output for every possible input. I'm pretty sure there are Ada tools for that.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2012-09-10 16:08 -1000 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <d_WdnRbm5-K-ANPNnZ2dnUVZ_jednZ2d@supernews.com> |
| In reply to | #15596 |
On 9/10/2012 3:47 PM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>> What do you mean about inspecting the program being easier in Forth >> You have an interactive shell. You have self-inspecting capability like >> SEE. There are other languages like Lisp with similar self-inspecting >> capabilities, and those tend to not quit on errors, too. > > OK, but that presumes there's a person around to interact with the > stopped program. I was thinking more of the situation where your > embedded box crashes in the field. There's not much to do but restart > it, and try to figure out later what happened. True. That's why you want your program well-tested before the device gets buttoned up. When developing an embedded device with an interactive Forth cross-compiler, you have all the debugging facilities you would have with a PC program, while you're in the lab. >> However, in most Algol-like languages, you have nothing, and therefore, >> you can only print a backtrace and quit. > > That's why we have debuggers. Just run the program under one. In ITS, > the standard shell was a debugger and all programs ran under it. > >> Backtrace: >> $7FA9FFBBF720 @ ... >> I find this quite useful. It tells me that @ failed with an invalid > > How do you map $7FA9FFBBF720 back to a Forth word so you can know where > the error happened? Again, while you're debugging in the lab, you know where everything is (including the executable parts of all definitions and their data space, if any). >> People still can make mistakes in Forth, but our mentality is not to >> bury tools, and therefore, this sort of refactoring isn't necessary that >> often. Writing a Forth program is about finding good factors. > > I would have expected it to be worse in Forth, because there are so many > more nested words, communicating through the stack. Maybe you have to > pass a new parameter from a higher level to a lower level, and that > means all the intervening words change their signature. Or maybe you > combine a few variables or stack slots into a structure or object, and > again everything that touches that data has to change. A word only cares about the top stack items that it will use. It cares nothing about what's below it, if anything. Words are context-independent in this way, so their "signature" doesn't change in that sense. And so long as you're referring to data objects by name, it really doesn't matter where they are or how they're defined so long as they have the specified behavior. >> The whole data starts in a Java object, gets converted to a C++ >> object, and then is accessed by C functions, which presume this C++ >> object is a struct. > > Is it so awful to write some Forth code that pulls the relevant fields > out of the struct? The point is that if you reference an element by name, it doesn't matter whether it's a component of a struct, a variable, or whatever, so long as invoking its name returns the address of its data space (or whatever behavior you're expecting). It's the behavior that counts. >> We hate writing "onion code", where you have layers and layers on top >> of each others, and the smell alone makes you cry. > > I thought the opposite: the Forth approach is to factor everything > into tiny little words, nested much more deeply than subroutines of > traditional languages, with data abstraction implicit in the factoring. I think what Bernd means by "onion code" is a great mass of code that doesn't have individual components that you can easily access. Forth words are all accessible at the surface, regardless of how other words call them. They aren't "nested" in the sense that a particular section of a huge program is. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-11 07:51 +0000 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <2012Sep11.095145@mips.complang.tuwien.ac.at> |
| In reply to | #15596 |
Paul Rubin <no.email@nospam.invalid> writes:
>> Backtrace:
>> $7FA9FFBBF720 @ ...
>> I find this quite useful. It tells me that @ failed with an invalid
>
>How do you map $7FA9FFBBF720 back to a Forth word so you can know where
>the error happened?
This is a return address (or in this case, it is a fake return
address), i.e., the address of the code where one should continue
after the return. So go back one cell, and find the PFA of the colon
definition, or, in this case, with the simulated return address, the
code address of a primitive. Translate that back to the word name
with the mechanisms we have already for SEE.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-11 19:24 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <2863600.V8nVyGh4k8@sunwukong.fritz.box> |
| In reply to | #15598 |
Anton Ertl wrote: > Paul Rubin <no.email@nospam.invalid> writes: >>> Backtrace: >>> $7FA9FFBBF720 @ ... >>> I find this quite useful. It tells me that @ failed with an invalid >> >>How do you map $7FA9FFBBF720 back to a Forth word so you can know >>where the error happened? > > This is a return address (or in this case, it is a fake return > address), i.e., the address of the code where one should continue > after the return. So go back one cell, and find the PFA of the colon > definition, or, in this case, with the simulated return address, the > code address of a primitive. Translate that back to the word name > with the mechanisms we have already for SEE. The question was probably more like "how do I quickly find out which of my 5 @s in that word caused the crash. In Gforth, you would use simple- see for that: : test 1 >r 2 >r 3 >r 0 @ ; ok test :2: Invalid memory address >>>test<<< Backtrace: $7F166052C720 @ $3 $2 $1 simple-see test $7F166052C6C0 lit $7F166052C6C8 <1> $7F166052C6D0 >r $7F166052C6D8 lit $7F166052C6E0 <2> $7F166052C6E8 >r $7F166052C6F0 lit $7F166052C6F8 <3> $7F166052C700 >r $7F166052C708 lit $7F166052C710 <0> $7F166052C718 @ $7F166052C720 ;s ok The IP address at the time of failure is already incremented, so it point after the offending word. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-11 21:40 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <1353004.qjrzDksSNn@sunwukong.fritz.box> |
| In reply to | #15598 |
Paul Rubin wrote: >> People still can make mistakes in Forth, but our mentality is not to >> bury tools, and therefore, this sort of refactoring isn't necessary >> that often. Writing a Forth program is about finding good factors. > > I would have expected it to be worse in Forth, because there are so > many more nested words, communicating through the stack. As Elizabeth already said: I think you are missing the point here. Good factoring is when you have decomposed the words into meaningful parts. So to access a particular information, you don't have many nested words which communicate through the stack. > Maybe you have to > pass a new parameter from a higher level to a lower level, and that > means all the intervening words change their signature. You very likely won't do it that way. > Or maybe you > combine a few variables or stack slots into a structure or object, and > again everything that touches that data has to change. That's why OOP systems like BerndOOF use a "current object" pointer, which allows you to do these changes without changing much of the rest of the code. You can change global variables into instance variables and words into methods, without affecting the rest of the code. That's a general pattern to do it that way, and the fact that even simple things like a variable are normal words (with a ( -- addr ) stack effect) makes that possible. IMHO, good style is when most words have at most one or two inputs and outputs. >> The whole data starts in a Java object, gets converted to a C++ >> object, and then is accessed by C functions, which presume this C++ >> object is a struct. > > Is it so awful to write some Forth code that pulls the relevant fields > out of the struct? No, it would be totally trivial, but this is not a public exported interface and may change at will. You have to treat it as opaque type, the struct members are not declared in the interface .h file. The Java object is a stable interface, and using JNI to access it would be possible, too. But that object is already lost when Gforth gets the keyboard event. >> We hate writing "onion code", where you have layers and layers on top >> of each others, and the smell alone makes you cry. > > I thought the opposite: the Forth approach is to factor everything > into tiny little words, nested much more deeply than subroutines of > traditional languages, with data abstraction implicit in the > factoring. The coworker who wrote the PIC17 implementation of the battery monitor more than a decade ago said something similar about Forth - his programming style was a typical Fortran style - long programs, few subroutines, shallow nesting. What you put into tiny little words are factors, either common things you reuse, or conceptual actions you can easily test. By doing so, you make the inner workings of your program accessible. By not factoring, the inner working of your program is inside a larger function. If you want to access it, you have to refactor your program. If the program is already well-factored, the likelyhood that the functionality you want is already exposed is much higher. Also, refactoring a Forth word is really easy: Usually, you can just cut the factor out, make it a definition, and insert its name where you got it from. Writing the correct stack effect might be the hardest part ;-). >>> Slow simulations I can understand, but that argues for more error >>> checks at compile time. >> >> No, this is that fallacy. The error checks at compile time don't >> find the logical errors you make, > > The exception in your example with the 4-bit binary counter would have > been spotted by a totality checker, that makes sure there is a > meaningful output for every possible input. I'm pretty sure there are > Ada tools for that. You are right that "there should be" or something. The fact is: there isn't, not as part of the normal VHDL compilation. Maybe run through yet another tool, and you get it. This is completely pointless, as the whole exercise is totally trivial, and needs no check at all to be right first time in Verilog. The non-meaningful output is inserted through the type system, following Ada. For a complicated state machine, the "meaningful output" and "no stuck- in state" check can be helpful, but these are rather complex tools, and they do exist both for VHDL and Verilog. Writing these checks is far from trivial (similar to Coq, these systems can't make such proofs by themselves, they need user assistance), and most people are more happy with simulations. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-09-09 14:58 -1000 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <eZqdnbHq4YO3ptDNnZ2dnUVZ_oudnZ2d@supernews.com> |
| In reply to | #15545 |
This is another repost of a reply that went to the person rather than the newsgroup, as I intended. On 9/8/12 2:34 PM, Paul Rubin wrote: ... > Yeah, interactive shells are a big help for quick prototyping. I > somewhat regret that I never used any of the grand Lisp environments > (i.e. the MIT Lisp machines) back in the era when anybody cared about > them. Python has some nice interactive shells and I do use those. > Paradoxically the current prescription for "serious" Python programming > is test-driven development (TDD): you are supposed to write a test suite > for the code before you write the code itself. So that seems like a > beat-back against interactive, exploratory development. If those tests > have a 50% hassle factor and a type system gets rid of half of it while > adding 5% of its own, you're at 30%, which is an improvement over 50%. > The experience is really quite different from that, though--it's more > qualitative. A TDD is very helpful for major projects, because it helps remove a lot of the ambiguities in the spec. But it certainly doesn't preclude the kind of low-level unit testing at which Forth excels. You do a lot of unit testing before running the Big Test Program, and afterwards to find out why it blew up :-) > >>> Yeah, that type of programming still exists, but it's a very >>> specialized niche by now ... Phones have megabytes, not kilobytes. > >> The thing I was doing was a battery monitor... On a tiny micro deeply >> embedded in some small device. > > Sure, that's an important thing to be doing, but it's a niche; and sure, > it's a reasonable place for Forth, but it could also be programmed > directly in assembly code. Sure. And which would you rather be writing and testing, this code in assembler (get out your logic analyzer...) or Forth? ... > >> Yes, but I consider low-volume sales as "uninteresting niches". Just >> like you seem to consider high-volume sales, where it pays off to spend >> some extra effort to get along with 0.01% of the power consumption or so >> as "uninteresting niches". > > I don't think such niches are uninteresting. There just aren't all that > many progammers (compared to the general programmer population) working > in them. That's what makes them niches. Hmm, what kind of volume are you talking about? These tiny devices are produced in amazing quantities compared with PCs (which typically include dozens of the low-level devices already). The vast, vast majority of CPUs are in embedded devices of some sort. Your average modern automobile has hundreds. And I don't know how you're counting "programmers", either. It may be that there are more people who call themselves "programmers" in desk-type applications, but I'll bet if you look at the number of folks developing soft/firmware, you'll get a surprise. It's just that a lot of firmware developers call themselves "engineers". The dividing line is pretty fuzzy in this niche. The majority of folks at FORTH, Inc. can read a circuit diagram, and a lot of them can find the bugs in one, not to mention the bugs in the "fully tested" board our customer just sent us to program! >> (Ti apparently uses an MSP430 in their battery monitor, and they write >> the program in C. It's more than 16k long as resoult, which means the >> chip exceeds the 30¢ budget). > > I don't understand why the code bloat. Are you comparing against your > B16 processor? Are you really saying there's an 8x difference in code > density for B16 Forth vs. MSP430 C when the applications are doing the > same things? I'm pretty doubtful there is that big a difference, and I > suspect that either the MSP430 code is using libraries carelessly, or > else it's doing fancier stuff than the B16 code. > Forth usually generates a lot higher code density than C on any platform, because of its modularity. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-09 18:24 -0700 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <7xhar6sm8v.fsf@ruckus.brouhaha.com> |
| In reply to | #15563 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Hmm, what kind of volume are you talking about? These tiny devices are > produced in amazing quantities compared with PCs (which typically > include dozens of the low-level devices already). The vast, vast > majority of CPUs are in embedded devices of some sort. Sure, there are a lot of those devices but the number of people writing code for them is relatively small, it seems to me, at least going by Craigslist ads and the like. If the device has just 1k of code, it's probably not going to keep many programmers busy. I agree that a lot of the programming is done by the hardware engineers. In that case they're splitting programming with other duties, so that's even fewer full-time-equivalent programmers. Finally, since the programs and processors are small, it's an area that calls for very good low-level optimization and debugging skills, but is less demanding in topics that mostly affect bigger systems. So, that may also explain why software specialists tend to look at these things differently.
[toc] | [prev] | [next] | [standalone]
| From | Anonymous <nobody@remailer.paranoici.org> |
|---|---|
| Date | 2012-09-09 13:42 +0000 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <41f1e301bc735078e9b121c9467a81f0@remailer.paranoici.org> |
| In reply to | #15520 |
Try a full build of gcc on your phone and let me know how long it takes ;-)
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-09-08 10:34 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <01699395948435@frunobulax.edu> |
| In reply to | #15519 |
Bernd Paysan <bernd.paysan@gmx.de> writes Re: Forth as a polarising language [..] > With the Forth OOP extensions, we also see the Blub paradox. We have > more than 20 different OOP extensions to Forth, and most of them are the > greatest thing than sliced bread for their author, and nothing but weird > for everybody else. Does this illustrate the Blub paradox accurately? Anyway, it is an interesting example. > And the fact is that most of them are rather > rudimentary, even though the authors don't want to acknowledge. As you are the author of, IIRC, 2 or 3 of these 20 OOP extensions, your last remark is the perfect Blub illustration :-) I have been interested in FOOP ever since Dick Pountain wrote his BYTE articles (30 years ago?). However, in all that time I have *never* seen an interesting Forth program that uses (needed to use) OOP. All we get is the same old trivial examples. My own experiments were all failures: in their final version the FOOP proved to make for unreadable (i.e. too much looking up to do) and unmaintainable code. All that withstood time is structure words and a numeric array package. At least your heap/heap1 code is easy to understand and interesting, but Mini-OOF results in a ridiculous 7..50 times slowdown. In my opinion the problem is not that FOOP creators think their particular version is the greatest thing since sliced bread, but that they are not able to convince others that this is indeed the case. At least not by example. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-09-08 07:06 -0400 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <504b26cb$0$286$14726298@news.sunsite.dk> |
| In reply to | #15521 |
On 9/8/12 4:34 AM, Marcel Hendrix wrote:> Bernd Paysan <bernd.paysan@gmx.de> writes Re: Forth as a polarising language > [..] >> With the Forth OOP extensions, we also see the Blub paradox. We have >> more than 20 different OOP extensions to Forth, and most of them are the >> greatest thing than sliced bread for their author, and nothing but weird >> for everybody else. > > Does this illustrate the Blub paradox accurately? >> And the fact is that most of them are rather >> rudimentary, even though the authors don't want to acknowledge. The statements are made that "most of them are ... nothing but weird ... and rather rudimentary". Most", not all. Hmmm. Wonder which ones are are considered not weird and not rudimentary. > I have been interested in FOOP ever since Dick Pountain wrote his > BYTE articles (30 years ago?). However, in all that time I have > *never* seen an interesting Forth program that uses (needed to use) > OOP. All we get is the same old trivial examples. Perhaps the problem is just looking at trivial examples. I don't have the Pountain Byte article but do have his article from JFAR,V3,#3. A few quotes from that might be helpful: *** begin quotes from Pountain Benefits of Object Orientation The benefit of object orientation is felt particularly in the production of large programs ... . The independence of modules allows each to be tested individually. When they are combined into a program, there is a guarantee that the modules cannot interact in unexpected ways. This is not so with languages that permit global access to data, ... . An additional benefit is improved maintainability. Module independence isolates the rest of the program from detail changes made to a module, provided that its interface is unchanged. ... The internal structure of an object is not visible, and sending an appropriate message is the only way in which an object can be affected. The set of messages an object understands is therefore its interface. *** end quotes from Pountain Take note of the last paragraph above. "Sending an appropriate message is the only way in which an object can be affected". This axiom of object programming is routinely broken in most of the OOFs I've seen (including later versions of my own). I don't like this. When a program gets very complex, and managing complexity is one important advantage of OOP, knowing that the internals of an object can *only* be manipulated by messaging is a powerful safety feature, perhaps as powerful as type checking. > My own experiments > were all failures: in their final version the FOOP proved to make > for unreadable (i.e. too much looking up to do) and unmaintainable > code. Unreadable and unmaintainable? That doesn't make sense to me. As just one small example, do you prefer to have many words like printString, printList, printArray, printRectangle, printBtree, printHeap, printComplex#, printFile, printText and so on vs the single word print? As to unreadable, I have to agree that some OOFs I've seen are difficult to follow, for me at least. A well designed OOF should be very easy to read and browse, IMO. > At least your heap/heap1 code is easy to understand and interesting, > but Mini-OOF results in a ridiculous 7..50 times slowdown. If you are needing speed, and I know that you frequently focus on that, then using objects is generally a mistake. That is not where object programming advantages exist. *** from Pountain A crucial difference is that [ when using OOP we do ] not need to know the type of an object to which a message is to be sent until the program is run. This is called late binding; a message is not bound to its method until runtime. This is less efficient than early binding [ or a simple Forth function ], in which most of the work is performed at compile time, but it allows for great flexibility. The same program might work on many types of object, which have different but related behaviours. *** Object programming is not rocket science as some seem to think it must be. The fundamentals of OOP have been around for a very long time. It is true that in recent years some variations of the paradigm have appeared including prototype based and meta object protocol. No doubt if we wait even more variations of object programming will appear. But at the end of the day we still have objects and messages. > In my opinion the problem is not that FOOP creators think their > particular version is the greatest thing since sliced bread, but that > they are not able to convince others that this is indeed the > case. At least not by example. Your opinion seems to run counter to some very heavily used programming techniques in languages like Python, Ruby, Lisp, Haskell, Lua, VisualBasic, Objective-C, Java, Smalltalk, SwiftForth (the list is too long to show completely here). I wonder why that is? Some say that Forth is so unique that it either already is "object oriented" or it doesn't need and can't benefit from object techniques. I don't subscribe to either notion. If objects don't work for you then I would strongly suggest you not use them. -Doug
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-09-08 16:14 +0200 |
| Subject | Re: Forth as a polarising language |
| Message-ID | <94891995948435@frunobulax.edu> |
| In reply to | #15522 |
Doug Hoffman <glidedog@gmail.com> wrote Re: OOP packages > On 5/15/12 2:37 PM, Marcel Hendrix wrote: >> Doug Hoffman<glidedog@gmail.com> writes Re: OOP packages [..] > try replacing the one DEFER word with a value, then change the two other > definitions affected (changes in UPPER CASE): > 0 VALUE allotocate > : makeobj ( class -- o) pre-obj allotocate EXECUTE post-obj ; > : make ( xt -- o) TO allotocate ' >body state @ > if postpone literal postpone makeobj else makeobj then ; > This then compiled and ran fine for me on my version of iForth, no > extraneous stack items. Actually, only one change is necessary: iForth's compiled IS is written as [IS], like this: : make ( xt -- o) [is] allotocate ' >body state @ if postpone literal postpone makeobj else makeobj then ; The problem with the extra stack items was my test: it was based on insufficient understanding of your code. I should not have pasted the output of your posting verbatim. \ Original (wrong) test dict> var value x x .s init: \ ok cr x p: 5 \ ok \ New test dict> var value x x .s init: \ ok cr x p: \ 5 ok Sorry about that. Conclusion: This OOP package works on all major Forths with only a single cosmetic (is DEFER standard already?) change. -marcel
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web