Talk:Letter frequency: Difference between revisions

m
Line 114:
: Mine is perfectly serviceable for the small text I wanted a count of, and cost me no effort or time to write.
 
: For me (and for anyone familiar with the tradition of composing pure functions, and with that well-established ML tradition of function names, subsequently adopted by various other languages) my version is familiar and easy to read, with a good ratio of signal-to-noise. We can glance at it and see immediately how it defines the problem. Referring to the detail of how each familiar abstraction is implemented, can give the curious some useful insight into the paricularparticular quirks and data structures of AppleScript.
 
: Your version is clearly more legible to you, but do remember that to others it may also look like a cloud of squid ink, spreading densely and noisily past the Rosetta code 80 character limit, and folding a bit wildly, while tracing through a series of state mutations which, in formal terms, is very much more complex, and very much less safe and predictable, and much harder to model, than any composition of pure functions.
 
: The distinction between these two approaches is usually formulated in terms like ''Procedural'' (or ''Imperative'') vs ''Functional'' (or ''Declarative''), and something like that might be a little more helpful to readers than the slightly more private 'Straightforward' vs 'WeirdUnfamiliar' which seems, quite understandably, to express your own experience :-)
: The right tool for a job depends on the moment and the context - sometimes we need much more efficient use of our own time – swift writing, easy refactoring, less debugging. Something quick and reliable for a smallsmallish data sample.
 
: And sometimes we can afford to spend more of our own time, and want to build something that we can use with larger sets of data, optimized for run-time rather than write-time.
: The right tool for a job depends on the moment and the context - sometimes we need much more efficient use of our own time – swift writing, easy refactoring, less debugging. Something quick for a small data sample.
 
: And sometimes we can afford to spend more of our own time, and want to build something that we can use with larger sets of data, optimized for run-time rather than write-time.
 
:Yours works very well for the latter context (possibly at the cost of how much time it take to write and debug) though I personally might reach for another language when performance or scale are what I need. (In a macOS scripting context, the same composition of pure functions runs very fast in JavaScript for Automation, for example. I hardly need to tell you that AppleScript records are not famous for their speed or powers of introspection). By the time we have to reach for ObjC Foundation classes to get some usable performance at any scale, AppleScript has really rather lost the bloom of its charm and claims to accessibility, and may be an implausible or inappropriate instrument to reach for anyway.
 
:To avoid the risk of a faintly comic impression, might it make sense for us to find a slightly more illuminating, and more widely understood alternative to "straightforward" ? My approach obviously seems more "straightforward" to me – that's a symmetrical relationship :-) Perhaps ''Imperative'' ? ''Procedural'' ? Something else which has some precedent and familiarity on Rosetta Code, and will immediately be intelligible ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 10:17, 13 April 2020 (UTC)
9,655

edits