Talk:FizzBuzz: Difference between revisions

→‎AppleScript (Functional): See 2015 May 22 discussion of this.
(→‎AppleScript (Functional): See 2015 May 22 discussion of this.)
 
(3 intermediate revisions by 3 users not shown)
Line 31:
 
Why the sudden break up of the page by language type? --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 13:02, 22 September 2015 (UTC)
:It is easier to compare programs "from the same family" that way.
:Especially when they are spread out, like all the different BASIC-variants. --[[User:Hajo|Hajo]] ([[User talk:Hajo|talk]]) 21:11, 22 September 2015 (UTC)
 
== Missing from Solutions by Programming Task Category ==
Line 48 ⟶ 50:
:: I also disagree --- ''only keeping the one(s) showing the language in best light should be kept''   --- is very subjective, who is able to say that other versions are kinda OK, but MY version is the bestus and shows off the language better than the others   (possibly implying that the quality of other versions aren't up to scratch).   But putting the joking aside, each version (most likely) demonstrates how to do a very simple task in different ways, I prefer simplicity (for understanding) and easy expandability (such as possibly adding a   '''Jazz'''   option for multiples of 7   and/or others --- for instance).   Just because the requirements are so simplistic, it doesn't mean that we have to prune the examples down to a couple (or whatever number).   Besides, it's not like they are consuming a vast amount of space.   I think each example shows how to solve the task using different approaches (or algorithms).   Once we start pruning computer programming examples, where does it stop? --- And who does the pruning?   Who gets to decide that one version isn't that much different than another?   Certainly, a few comments in the code (or prologue) would help immensely for some of the "trickier" and/or obtuse algorithms (or heaven help us all, obfuscated code) --- but then I'm not a huge fan of code golf (albeit, sometimes it's hard to distinguish between   ''shortness of code''   and;   ''concise code'') --- although it seems that there are a lot of examples that seem to preach that idea (as demonstrated by the number of programming examples in the various Rosetta Code tasks).   Of course, it's possible that my observations are somewhat jaded a bit. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:33, 20 November 2014 (UTC)
 
:::To Hajo and <strike>Gerald</strike> Gerard: Ouch and ouch respectively. I think we all should collectively bare in mind the need to show the language off clearly and without too much bloat. If you are putting up another variant then the reason for adding it should either be obvious or discussed and made plain. Is the imposition of extra constraints a good reason? In this case don't think so. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 05:56, 20 November 2014 (UTC)
 
===Here are the five versions as they were:===
Line 172 ⟶ 174:
 
It's... well, see for yourself... --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 01:29, 16 April 2015 (UTC)
 
== AppleScript (Functional) ==
Square brackets have never officially been part of AppleScript and could cease to work without notice. --[[User:Nig|Nig]] ([[User talk:Nig|talk]]) 08:37, 26 June 2020 (UTC)
: There was some discussion of this between HAS and Michael Tsai on mjtsai.com (in comments 2015 may 22)
: I personally share MT's view on the balance between readability and performance. AppleScript would not be a sensible choice anyway for performance-sensitive applications.
: Re 'cease to work' – probably unlikely. It's worked consistently throughout the history of the language, the whole of which is now in its sunset. Active development of AppleScript ceased several versions of macOS ago. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:49, 26 June 2020 (UTC)
9,655

edits