Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: fizzbuzz problem in forth Date: Fri, 20 May 2016 21:55:42 -0700 Organization: A noiseless patient Spider Lines: 70 Message-ID: <87futcc8mp.fsf@jester.gateway.pace.com> References: <2210aa04-1df4-4328-bf8c-66fbf845609c@googlegroups.com> <871t566dwf.fsf@jester.gateway.pace.com> <2016May13.145248@mips.complang.tuwien.ac.at> <8760udodtl.fsf@jester.gateway.pace.com> <2016May17.154948@mips.complang.tuwien.ac.at> <87k2ismu0z.fsf@jester.gateway.pace.com> <2016May18.143614@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="52eac348160ce62b68e4635eee7cc854"; logging-data="14648"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184TZEw+96eQJSNIisqnySA" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:4TD8WtiwlLMvY58KrqshEwJxt/w= sha1:iTrzAIqnWPlee5emIUZvofCSTWM= Xref: csiph.com comp.lang.forth:47392 anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>The trouble is that the specified string might be the empty string. > Not in the original task and not in the extended versions suggested by > nor those > discussed in other postings I found, either. The original task was just 3->Fizz, 5->Buzz. The extended versions suggested additional numbers like 7, and additional strings like Bazz. I don't remember it mentioning the empty string specifically, but the empty string is a perfectly good string just like 0 is a perfectly good number. Neither should make programs misbehave. > So, ok, your solution, my "more Forth-like solution" and the Haskell > Maybe variant are prepared for the case when the extended task says: > "In some cases, print nothing." Well here there's again a code smell, or maybe a specification smell, where the word "nothing" is overloaded. It's cleaner to say that the empty string is not nothing. It's a string, whose length happens to be zero. That is something rather than nothing. > But is it worth complicating the solution with Maybe and (up-to-now) > redundant flags in order to be prepared for this? The extra flags in the Forth examples do complicate the code, but I think one point of the blog post is that Maybe doesn't complicate things as much, because of how Maybe's monoid instance lifts the string concatenation operation into the Maybe String type. That is, the post is a bit of Haskell advocacy, saying Haskell's built-in abstractions make this stuff work automatically. The Maybe type also makes the difference between "the empty string" and "nothing" explicit, which helps clear thinking. > Anyway, one of Chuck Moore's principles is "Do what is needed, don't > generalize", and this discussion is a good example for that. OTOH, one of the principles from "The Elements of Programming Style" from the same era was 33. Make sure your code does "nothing" gracefully. ( https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style ) If my system has a word INCREASE-FOO: VARIABLE foo : INCREASE-FOO ( n -- ) ... ; \ make foo larger by n and it somehow doesn't work when n=0, that's broken code even if none of the examples in the specification had n=0. Making it work properly for n=0 is not overgeneralization by any means. > Whatever solution you write, the interviewer (or, in real life, the > customer) can give you a change request for which it does not work > well. And you can "smell" that, so every solution will have a smell > if you are thinking in terms of what-ifs. There's a big enough body of experience in programming by now that we have identified lots of valuable practices, re-usable abstractions, etc. Handling do-nothing cases properly is so basic good practice that even the the Programming Style book from the 1970's documented it explicitly. "Maybe" values might have originated in ML in the 1980s, but are finally catching on in the wider world. > Back to the >STRING-EXECUTE implementation. I thought about a simpler > way (as far as implementation is concerned). Fig-Forth has a user > variable OUT ... IMHO this is still way ugly compared with remembering whether any of the tests succeeded, or alternatively, remembering whether the string printer has been called (possibly with the empty string as argument).