Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-08 19:17 +0000 |
| Message-ID | <xn0kpqvce30zrvt002@nntp.aioe.org> |
| In reply to | #58801 |
HAA wrote: > Perhaps a better comparison would be locals which are searched > before the dictionary. Ah, OK. > Waiting until you have a need before implementing something isn't just > a great way to determine its worth, it's an effective use of time and > resources. That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always implement things when you actually need them, never when you just foresee that you may need them." http://deviq.com/yagni/ https://martinfowler.com/bliki/Yagni.html https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -- Rudy Velthuis http://www.rvelthuis.de "A notation is important for what it leaves out." -- Joseph Stoy
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 14:25 +0000 |
| Message-ID | <2017May9.162525@mips.complang.tuwien.ac.at> |
| In reply to | #58861 |
"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>> Waiting until you have a need before implementing something isn't just
>> a great way to determine its worth, it's an effective use of time and
>> resources.
>
>That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always
>implement things when you actually need them, never when you just
>foresee that you may need them."
A variant of this principle as advocated by some posters in this
newsgroup is
"Never implement things, even if they are simple to implement. When
these things are needed, instead of spending the minutes it takes to
implement them (or adapt an existing implementation), better spend
many hours arguing why they are not needed.
If you absolutely cannot avoid implementing something, a
special-purpose solution that fails on corner cases is to be preferred
to a general-purpose solution even if the implementation complexity is
the same. This vindicates your argument that the general-purpose
thing is not needed, and anyway, we all know that general-purpose
solutions are bad.
Building two, or five special-purpose things is better than having one
general-purpose thing, because each special-purpose thing is simpler;
and if it's not, it's at least more special-purpose."
However, Forth itself is the anti-thesis of this approach. Instead of
writing each program special-purpose in machine language, Chuck Moore
built a huge hook: the dictionary and FIND.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-09 21:22 -1000 |
| Message-ID | <6tednStqKok3Io_EnZ2dnUU7-N3NnZ2d@supernews.com> |
| In reply to | #58895 |
On 5/9/17 4:25 AM, Anton Ertl wrote: > "Rudy Velthuis" <newsgroups@rvelthuis.de> writes: >>> Waiting until you have a need before implementing something isn't just >>> a great way to determine its worth, it's an effective use of time and >>> resources. >> >> That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always >> implement things when you actually need them, never when you just >> foresee that you may need them." > > A variant of this principle as advocated by some posters in this > newsgroup is > > "Never implement things, even if they are simple to implement. When > these things are needed, instead of spending the minutes it takes to > implement them (or adapt an existing implementation), better spend > many hours arguing why they are not needed. I haven't actually seen that here. What I have seen is a resistance to implement something "because LanguageX has it and we need to compete and besides somebody might want it someday." It's always a good thing to implement (or adopt an existing implementation of) something you *need* because when you need it you know exactly how in *this app* you need it to work. > If you absolutely cannot avoid implementing something, a > special-purpose solution that fails on corner cases is to be preferred > to a general-purpose solution even if the implementation complexity is > the same. This vindicates your argument that the general-purpose > thing is not needed, and anyway, we all know that general-purpose > solutions are bad. Implementation complexity is rarely the same for the solution for *this* situation as for a general-purpose solution. In the case where there is no cost for generality, by all means, generalize. But sitting around stewing about possible corner cases that you know *this* application can't have is not a good use of time. > Building two, or five special-purpose things is better than having one > general-purpose thing, because each special-purpose thing is simpler; > and if it's not, it's at least more special-purpose." That's a good maxim only if it *is* simpler. > However, Forth itself is the anti-thesis of this approach. Instead of > writing each program special-purpose in machine language, Chuck Moore > built a huge hook: the dictionary and FIND. Works pretty well, too :-) Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-13 13:33 +1000 |
| Message-ID | <of5uq2$klb$1@gioia.aioe.org> |
| In reply to | #58929 |
Elizabeth D. Rather wrote: > On 5/9/17 4:25 AM, Anton Ertl wrote: > > "Rudy Velthuis" <newsgroups@rvelthuis.de> writes: > >>> Waiting until you have a need before implementing something isn't just > >>> a great way to determine its worth, it's an effective use of time and > >>> resources. > >> > >> That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always > >> implement things when you actually need them, never when you just > >> foresee that you may need them." > > > > A variant of this principle as advocated by some posters in this > > newsgroup is > > > > "Never implement things, even if they are simple to implement. When > > these things are needed, instead of spending the minutes it takes to > > implement them (or adapt an existing implementation), better spend > > many hours arguing why they are not needed. > > I haven't actually seen that here. What I have seen is a resistance to > implement something "because LanguageX has it and we need to compete and > besides somebody might want it someday." It's always a good thing to > implement (or adopt an existing implementation of) something you *need* > because when you need it you know exactly how in *this app* you need it > to work. Which is the antithesis of what 'standard libraries' offer. General purpose libraries by definition must cater to a variety of situations leading to unnecessary code and inefficiency. If general purpose libraries isn't what 'standard forth' is about - then what is? That should be obvious. Ideology. Vested interests having declared 'forth needs x' then proceed to impose their particular form of it. For example, telling implementers they can choose between having a standard, or having a combined stack f/p, was blackmail pure and simple having no technical basis. Some would say Forth has suffered from the ability of implementers to reject standards. I think it's the only thing that has kept Forth alive and honest.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-12 21:32 -1000 |
| Message-ID | <yPGdnRKY5J87K4vEnZ2dnUU7-aPNnZ2d@supernews.com> |
| In reply to | #59145 |
On 5/12/17 5:33 PM, HAA wrote: > Elizabeth D. Rather wrote: >> On 5/9/17 4:25 AM, Anton Ertl wrote: >>> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes: >>>>> Waiting until you have a need before implementing something isn't just >>>>> a great way to determine its worth, it's an effective use of time and >>>>> resources. >>>> >>>> That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always >>>> implement things when you actually need them, never when you just >>>> foresee that you may need them." >>> >>> A variant of this principle as advocated by some posters in this >>> newsgroup is >>> >>> "Never implement things, even if they are simple to implement. When >>> these things are needed, instead of spending the minutes it takes to >>> implement them (or adapt an existing implementation), better spend >>> many hours arguing why they are not needed. >> >> I haven't actually seen that here. What I have seen is a resistance to >> implement something "because LanguageX has it and we need to compete and >> besides somebody might want it someday." It's always a good thing to >> implement (or adopt an existing implementation of) something you *need* >> because when you need it you know exactly how in *this app* you need it >> to work. > > Which is the antithesis of what 'standard libraries' offer. General purpose > libraries by definition must cater to a variety of situations leading to > unnecessary code and inefficiency. > > If general purpose libraries isn't what 'standard forth' is about - then what is? > That should be obvious. Ideology. Vested interests having declared 'forth > needs x' then proceed to impose their particular form of it. For example, > telling implementers they can choose between having a standard, or having > a combined stack f/p, was blackmail pure and simple having no technical > basis. Some would say Forth has suffered from the ability of implementers > to reject standards. I think it's the only thing that has kept Forth alive and > honest. There's a lot of value in code portability beyond "standard libraries" full of inefficient code to take care of all possible cases, etc. Here are some examples: * We often see people come on c.l.f and say, "anybody got code for doing *something*?" Then somebody posts a bunch of code and there's some extra word in there that the OP doesn't recognize. Once that's explained (and maybe an implementation suggested), the code's useful. This scenario happens fairly regularly. The fact that there's a standard that we can point to makes it much easier to share the rest of the code as well as to suggest a fix for the missing bit. * A company has a project (or mods to a past project) to be done in Forth and needs programmers. If programmers can be found with a background in Standard Forth, they're much more valuable than a person who has only used a personal, idiosyncratic version. This happens far more often than you realize. * A project is being planned, and a programmer is advocating Forth. The manager never heard of it. If it can be shown that there is an approved standard and programmers around who are familiar with it, the odds go way up that Forth can be used. These are routine, frequently-occurring instances. Without Standard Forth the technology would assuredly be as actually dead as some of you seem to think it is. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2017-05-13 07:12 -0700 |
| Message-ID | <8fb9f8de-6682-4877-aeb3-e6b9d42536a8@googlegroups.com> |
| In reply to | #59157 |
On Saturday, 13 May 2017 09:33:01 UTC+2, Elizabeth D. Rather wrote: > On 5/12/17 5:33 PM, HAA wrote: > > Elizabeth D. Rather wrote: > >> On 5/9/17 4:25 AM, Anton Ertl wrote: > >>> "Rudy Velthuis" <newsgrxelthuis.de> writes: > >>>>> Waiting until you have a need before implementing something isn't just > >>>>> a great way to determine its worth, it's an effective use of time and > >>>>> resources. > >>>> > >>>> That's called YAGNI (You Ain't -- or Aren't -- Gonna Need It): "Always > >>>> implement things when you actually need them, never when you just > >>>> foresee that you may need them." > >>> > >>> A variant of this principle as advocated by some posters in this > >>> newsgroup is > >>> > >>> "Never implement things, even if they are simple to implement. When > >>> these things are needed, instead of spending the minutes it takes to > >>> implement them (or adapt an existing implementation), better spend > >>> many hours arguing why they are not needed. > >> > >> I haven't actually seen that here. What I have seen is a resistance to > >> implement something "because LanguageX has it and we need to compete and > >> besides somebody might want it someday." It's always a good thing to > >> implement (or adopt an existing implementation of) something you *need* > >> because when you need it you know exactly how in *this app* you need it > >> to work. > > > > Which is the antithesis of what 'standard libraries' offer. General purpose > > libraries by definition must cater to a variety of situations leading to > > unnecessary code and inefficiency. > > > > If general purpose libraries isn't what 'standard forth' is about - then what is? > > That should be obvious. Ideology. Vested interests having declared 'forth > > needs x' then proceed to impose their particular form of it. For example, > > telling implementers they can choose between having a standard, or having > > a combined stack f/p, was blackmail pure and simple having no technical > > basis. Some would say Forth has suffered from the ability of implementers > > to reject standards. I think it's the only thing that has kept Forth alive and > > honest. > > There's a lot of value in code portability beyond "standard libraries" > full of inefficient code to take care of all possible cases, etc. Here > are some examples: > > * We often see people come on c.l.f and say, "anybody got code for doing > *something*?" Then somebody posts a bunch of code and there's some extra > word in there that the OP doesn't recognize. Once that's explained (and > maybe an implementation suggested), the code's useful. This scenario > happens fairly regularly. The fact that there's a standard that we can > point to makes it much easier to share the rest of the code as well as > to suggest a fix for the missing bit. > > * A company has a project (or mods to a past project) to be done in > Forth and needs programmers. If programmers can be found with a > background in Standard Forth, they're much more valuable than a person > who has only used a personal, idiosyncratic version. This happens far > more often than you realize. > > * A project is being planned, and a programmer is advocating Forth. The > manager never heard of it. If it can be shown that there is an approved > standard and programmers around who are familiar with it, the odds go > way up that Forth can be used. > > These are routine, frequently-occurring instances. Without Standard > Forth the technology would assuredly be as actually dead as some of you > seem to think it is. > > Cheers, > Elizabeth > > -- > Elizabeth D. Rather > FORTH, Inc. > 6080 Center Drive, Suite 600 > Los Angeles, CA 90045 > USA Hi Elizabeth, I totally agree. Especially as I recently asked "anybody got code for doing MD4?". That was a few weeks ago, and the answer then was "no", but now the answer is "yes". And its even ANS compliant! Cheers, Howerd
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-13 14:30 +0000 |
| Message-ID | <xn0kpxole4ihgih00g@nntp.aioe.org> |
| In reply to | #59145 |
HAA wrote: > > I haven't actually seen that here. What I have seen is a resistance > > to implement something "because LanguageX has it and we need to > > compete and besides somebody might want it someday." It's always a > > good thing to implement (or adopt an existing implementation of) > > something you need because when you need it you know exactly how in > > *this app* you need it to work. > > Which is the antithesis of what 'standard libraries' offer. General > purpose libraries by definition must cater to a variety of situations > leading to unnecessary code and inefficiency. Not necessarily. General libraries do not have to be inefficient at all. But they may be "bloated". Runtime libraries should at least provide what most people might need. Fighting bloat is done by letting something (like a linker or some such) eliminate what is not used. So it all depends on whom you are writing for. Is it for yourself? Don't implement what you don't need. Is it for (possibly many) others? Implement what most people might need. And it is not always easy to find out what that is, or how it should be presented/implemented. -- Rudy Velthuis http://www.rvelthuis.de "A child of five could understand this. Fetch me a child of five." -- Groucho Marx
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-04 11:37 -0400 |
| Message-ID | <oefhlh$tbg$2@dont-email.me> |
| In reply to | #58497 |
On 5/2/2017 10:27 AM, Alex wrote: > On 5/2/2017 09:49, Andrew Haley wrote: > > I've started a new thread for clarity. I'm answering one at a time as my > time permits. > >> The proposal allows recognizers to precede dictionary searches, so >> that even if a word would have been found it might not be executed >> because a recognizer got in there first. This will not help >> debugging; it is not a good thing. > > > But Forth has never insisted on protecting the programmer from not good > things; qv the "ain't Forth weird!" example of 1 CONSTANT 0 . And a > system with recognizers should, since backward compatibility is > essential, be able to act in entirely the same way as a classical > interpreter. The only difference will be the inability to add > recognizers, simple, literal or otherwise, in a standard way. Backward compatibility with applications is important, backward compatibility with previous versions of the standard is not. Otherwise changes would never be made. How often does any app you are aware of redefine literal values as words? Isn't that the criterion for compatibility, how likely it is to impact existing code? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 17:51 +0100 |
| Message-ID | <oeflvk$fs7$1@dont-email.me> |
| In reply to | #58669 |
On 5/4/2017 16:37, rickman wrote: > Backward compatibility with applications is important, backward > compatibility with previous versions of the standard is not. Otherwise > changes would never be made. The two should be synonymous; if they're not, then the application cannot be a "Standard Program" (see the standard for the definition). Recognizers will not change anything if you wish nothing to be changed; standard compliant Forth system will still be standard, and standard programs will continue to run unchanged. Changes or additions to the standard that break stuff will not be welcomed by anybody. NOT is the poster child for that category of change. Sometimes it's possible because the breakage goes away; for instance, machine architectures that don't support 2s complement are as rare as hen's teeth. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-05 07:31 +0000 |
| Message-ID | <2017May5.093139@mips.complang.tuwien.ac.at> |
| In reply to | #58673 |
Alex <alex@rivadpm.com> writes:
>Changes or additions to the standard that break stuff will not be
>welcomed by anybody. NOT is the poster child for that category of
>change. Sometimes it's possible because the breakage goes away; for
>instance, machine architectures that don't support 2s complement are as
>rare as hen's teeth.
Adding the guarantee of 2s-complement arithmetic does not break a
standard program (and since AFAIK there never was a Forth system for a
non-2s-complement machine, no non-standard program, either), so this
is not a good example.
Blocks might be a better example, but it will take quite a while yet:
They don't make that much sense on today's flash-based storage and on
terabyte hard disks, and what we currently do is to provide an
emulation layer on top of file systems; do small systems (their
justification) still use them? So they may fall completely out of use
over time, and if so, blocks can be destandardized at one point in the
future. But, OTOH, keeping them as optional wordset does not hurt, so
I don't think anybody is in a hurry to get rid of them.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-05 20:35 +0200 |
| Message-ID | <868tmbf8xn.fsf@molnjunk.nocrew.org> |
| In reply to | #58691 |
Anton Ertl writes: > AFAIK there never was a Forth system for a non-2s-complement machine Beginnings of a Forth for the ones-complement PDP-1: https://github.com/larsbrinkhoff/lbForth/blob/master/targets/pdp1/itc.mac > Blocks might be a better example ... > do small systems (their justification) still use them? I'm tempted to use block storage for microcontroller targets. There is no other option in the standard if you want to avoid writing a file system.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-05 12:27 -0700 |
| Message-ID | <132165b4-3984-4256-a237-fa30bb1b5193@googlegroups.com> |
| In reply to | #58710 |
Am Freitag, 5. Mai 2017 20:35:49 UTC+2 schrieb Lars Brinkhoff: > Anton Ertl writes: > > AFAIK there never was a Forth system for a non-2s-complement machine > > Beginnings of a Forth for the ones-complement PDP-1: > > https://github.com/larsbrinkhoff/lbForth/blob/master/targets/pdp1/itc.mac > > > Blocks might be a better example ... > > do small systems (their justification) still use them? > > I'm tempted to use block storage for microcontroller targets. There is > no other option in the standard if you want to avoid writing a file system. There are other more compact and very efficient ways, f.ex. execution token lists as binary objects resident in ROM / NV-RAM.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-05 15:03 -0500 |
| Message-ID | <oeilkt$6k8$1@dont-email.me> |
| In reply to | #58710 |
On 5/5/2017 1:35 PM, Lars Brinkhoff wrote: > Anton Ertl writes: >> AFAIK there never was a Forth system for a non-2s-complement machine > > Beginnings of a Forth for the ones-complement PDP-1: > > https://github.com/larsbrinkhoff/lbForth/blob/master/targets/pdp1/itc.mac > >> Blocks might be a better example ... >> do small systems (their justification) still use them? > > I'm tempted to use block storage for microcontroller targets. There is > no other option in the standard if you want to avoid writing a file system. > eForth is also available for the PDP1, C.H. Ting has it available along with a FPGA implementation of the PDP1 -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-06 16:26 +0000 |
| Message-ID | <2017May6.182659@mips.complang.tuwien.ac.at> |
| In reply to | #58710 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Anton Ertl writes:
>> Blocks might be a better example ...
>> do small systems (their justification) still use them?
>
>I'm tempted to use block storage for microcontroller targets. There is
>no other option in the standard if you want to avoid writing a file system.
I am not an expert on microcontrollers, but my impression is that
these days they have flash memory that behaves like RAM when reading,
but can be written only with a certain granularity (which may,
however, be larger than the 1024 characters of a standard block).
Maybe microcontroller users can fill in how they use this.
Maybe we should have some standard way to deal with flash in
microcontrollers. Or maybe, by the time we have that standardized,
flash is replaced by phase-change memory, which supposedly can be
accessed like RAM (but is persistent).
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-06 18:17 +0100 |
| Message-ID | <oel08o$lhg$1@dont-email.me> |
| In reply to | #58739 |
On 5/6/2017 17:26, Anton Ertl wrote: > Lars Brinkhoff <lars.spam@nocrew.org> writes: >> Anton Ertl writes: >>> Blocks might be a better example ... >>> do small systems (their justification) still use them? >> >> I'm tempted to use block storage for microcontroller targets. There is >> no other option in the standard if you want to avoid writing a file system. > > I am not an expert on microcontrollers, but my impression is that > these days they have flash memory that behaves like RAM when reading > but can be written only with a certain granularity (which may, > however, be larger than the 1024 characters of a standard block). > Maybe microcontroller users can fill in how they use this. While that's true for expensive & increasingly rare NOR flash, NAND flash isn't amenable to byte addressing, and is better (oddly) at serial reads and writes. Its use as random access memory is only because it's so much faster than disk (at least for reads; writes can be almost as slow) and so much cheaper than DRAM. Reads and writes are in pages, normally several K of bits in size. For example, first byte read might be 25us, with subsequent cells at 25ns per byte (i.e. random byte reads are 1000 times slower than sequential). Buffering in RAM is used to make the random performance acceptable. Writes proceed in much the same way, but generally with increased latency. Updates however take place in complete blocks of pages; 256KB is not uncommon as a block size, and the block needs erased first, which is a horribly time expensive operation and can only be done a limited number of times. Milliseconds for the erase are not uncommon. This demands that we use file or block management systems that do not update blocks, but always write new (generally, log structured filesystems meet this criteria). It also means that a fresh device is likely to perform very well until the device has had every page written to; then, overwriting and having to erase blocks can reduce the performance, sometimes so considerably that the device is much slower than disk. > > Maybe we should have some standard way to deal with flash in > microcontrollers. Or maybe, by the time we have that standardized, > flash is replaced by phase-change memory, which supposedly can be > accessed like RAM (but is persistent). This might be of interest; NVM Programming Model https://www.snia.org/sites/default/files/technical_work/final/NVMProgrammingModel_v1.1.pdf I doubt Forth's simple block wordlist is adequate for the lowest level flash management tasks to be honest. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-05-06 12:26 -0700 |
| Message-ID | <f101a8a8-23c2-4329-91bc-cf18b55c01df@googlegroups.com> |
| In reply to | #58741 |
On Saturday, May 6, 2017 at 10:17:18 AM UTC-7, Alex wrote: > > This demands that we use file or block management systems that do not > update blocks, but always write new (generally, log structured > filesystems meet this criteria). It also means that a fresh device is > likely to perform very well until the device has had every page written > to; then, overwriting and having to erase blocks can reduce the > performance, sometimes so considerably that the device is much slower > than disk. I think performance is a matter of having more RAM blocks. FLUSH would then be able to write to flash in bigger chunks. FLUSH should be able to handle wear leveling so, for example, block 1000 is at an address specified in a table rather than a physical address. How to make that table non-volatile within hardware constraints is a matter of implementation, but that should be FLUSH's business, not the application programmer's. Other than wear leveling, the same concerns date back to floppy disk days. If you have to go out to floppy disk, it's gonna cost you. > > This might be of interest; NVM Programming Model > https://www.snia.org/sites/default/files/technical_work/final/NVMProgrammingModel_v1.1.pdf Imagine writing something that's compliant to those 85 pages and then verifying compliance. You could, but there has to be a compelling reason.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-06 21:39 +0100 |
| Message-ID | <oelc4f$t5i$1@dont-email.me> |
| In reply to | #58744 |
On 5/6/2017 20:26, Brad Eckert wrote: > On Saturday, May 6, 2017 at 10:17:18 AM UTC-7, Alex wrote: >> >> This demands that we use file or block management systems that do >> not update blocks, but always write new (generally, log structured >> filesystems meet this criteria). It also means that a fresh device >> is likely to perform very well until the device has had every page >> written to; then, overwriting and having to erase blocks can reduce >> the performance, sometimes so considerably that the device is much >> slower than disk. > > I think performance is a matter of having more RAM blocks. Well, that's one solution, but it's not anywhere near perfect, and you might be surprised when you add cache and the performance gets worse. Unless you have the rare case where the processor (how fast can i generate IO) and device (how fast can I sink it) are equally matched, most of the time it's the processor that wins. It's common to drive I/O to devices at such a high rate that it's all too possible to overwhelm the device and its cache. Parallelism helps; that is, multiple devices acting as one. That reduces the latency while writing, since we can write to any available (that is, not busy doing something else) device and record where we wrote. This "write anywhere" doesn't help on reads, since we need to read from the device where we wrote, so the latency is that of the device; and it had better not be busy doing a bunch of writes from your cache. Here's the summary; 1. For writes, it's pretty unusual to read the same block within the expected block lifetime in cache. The only benefit is to smooth the flushing of the cache to the persistent device; but that requires it's battery or supercap backed cache, since the cache needs to be consistent. 2. Don't cache writes if the write I/Os are coming in faster than the device can manage and the cache is full. Don't let flushing the cache interfere with incoming writes. 3. Don't cache random reads. Pollution for no benefit. 4. Cache sequential reads by reading ahead. Don't cache the blocks read before you've worked out that the reads are sequential; pollution for no benefit (the blocks have already been passed back to the requester). 5. Don't read ahead if the requester is reading blocks faster than the device can fill the cache. 6. There's more... It's not that simple, tbf. For decent cache management you need some smart algorithms, or help from the I/O requester. > FLUSH > would then be able to write to flash in bigger chunks. FLUSH should > be able to handle wear leveling so, for example, block 1000 is at an > address specified in a table rather than a physical address. How to > make that table non-volatile within hardware constraints is a matter > of implementation, but that should be FLUSH's business, not the > application programmer's. > > Other than wear leveling, the same concerns date back to floppy disk > days. If you have to go out to floppy disk, it's gonna cost you. > >> >> This might be of interest; NVM Programming Model >> https://www.snia.org/sites/default/files/technical_work/final/NVMProgrammingModel_v1.1.pdf > >> > Imagine writing something that's compliant to those 85 pages and then > verifying compliance. You could, but there has to be a compelling > reason. > There's money to be made. We (one being the company I work for) are writing stuff that's compliant, to make these things work, and then to make money. Block and byte addressable persistent memory is a real challenge, for many reasons; it's fast, but not that fast, so load/store operations need to be carefully considered if up to 100ns+ latency isn't going to kill you; the big red switch to solving problems doesn't do much, since memory isn't cleared; it provides a unique security issue when persistent pages are doled out to processes that should be security isolated; and so on. Fantastic opportunity btw. It's a great time to be in this business; the PM revolution and potential for serious change is as big as anything in my lifetime, certainly since the introduction of the hard disk over 40 years ago. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-07 03:58 -0500 |
| Message-ID | <BdKdne7S8sckfJPEnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #58739 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Lars Brinkhoff <lars.spam@nocrew.org> writes: >>Anton Ertl writes: >>> Blocks might be a better example ... >>> do small systems (their justification) still use them? >> >>I'm tempted to use block storage for microcontroller targets. There is >>no other option in the standard if you want to avoid writing a file system. > > I am not an expert on microcontrollers, but my impression is that > these days they have flash memory that behaves like RAM when reading, > but can be written only with a certain granularity (which may, > however, be larger than the 1024 characters of a standard block). > Maybe microcontroller users can fill in how they use this. > > Maybe we should have some standard way to deal with flash in > microcontrollers. Or maybe, by the time we have that standardized, > flash is replaced by phase-change memory, which supposedly can be > accessed like RAM (but is persistent). What's wrong with BLOCK, though? It sounds perfect for flash. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 10:39 +0100 |
| Message-ID | <oempq7$970$1@dont-email.me> |
| In reply to | #58760 |
On 5/7/2017 09:58, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Lars Brinkhoff <lars.spam@nocrew.org> writes: >>> Anton Ertl writes: >>>> Blocks might be a better example ... >>>> do small systems (their justification) still use them? >>> >>> I'm tempted to use block storage for microcontroller targets. There is >>> no other option in the standard if you want to avoid writing a file system. >> >> I am not an expert on microcontrollers, but my impression is that >> these days they have flash memory that behaves like RAM when reading, >> but can be written only with a certain granularity (which may, >> however, be larger than the 1024 characters of a standard block). >> Maybe microcontroller users can fill in how they use this. >> >> Maybe we should have some standard way to deal with flash in >> microcontrollers. Or maybe, by the time we have that standardized, >> flash is replaced by phase-change memory, which supposedly can be >> accessed like RAM (but is persistent). > > What's wrong with BLOCK, though? It sounds perfect for flash. It's too simplistic as a low level interface, and would require a lot of support either on-chip or in the I/O stack. NAND flash isn't really a random access block or byte addressable medium. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-07 23:39 +0000 |
| Message-ID | <oeob70$3p2$5@dont-email.me> |
| In reply to | #58761 |
Am Sun, 07 May 2017 10:39:24 +0100 schrieb Alex: > On 5/7/2017 09:58, Andrew Haley wrote: >> What's wrong with BLOCK, though? It sounds perfect for flash. > > It's too simplistic as a low level interface, and would require a lot of > support either on-chip or in the I/O stack. NAND flash isn't really a > random access block or byte addressable medium. BLOCK was originally for disks, and it copied the contents of the referenced block into RAM. So it matches NAND flash access style perfectly (maybe with the exception of how big the NAND flash granularity is - but I think most NAND flashes still are 512 bytes, while large hard disks nowadays have 4k sectors). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web