13

I thought there were patterns to how functions were named, but after looking carefully it seems I can always find exceptions. For instance

  • FindThreshold = Action + Object
  • SetAlphaChannel = Action + Object
  • ReplaceImageValue = Action + Object

but... ImageResize = Object + Action, and why not ImageBinarize instead of Binarize?

J. M.'s missing motivation
  • 124,525
  • 11
  • 401
  • 574
M.R.
  • 31,425
  • 8
  • 90
  • 281
  • There are some I find inconsistent. There's Binarize vs the non-existent ImageBinarize. There's the inconsistent pairs FromCharacterCode/ToCharacterCode vs FromRomanNumeral/RomanNumeral. Several "conversion" functions are ToThing, and several are just Thing: ToString, ToUpperCase vs LetterNumber and SparseArray. (In my mind, SparseArray is a conversion function, since the InputForm of a SparseArray object is of a very different format to the form in which one would usually input it.) – Patrick Stevens Aug 07 '15 at 15:10
  • And why FindPeaks but PeakDetect? Perhaps consistency is the hobgoblin of small minds... – bill s Aug 07 '15 at 15:10
  • @bills, it does make a kind of sense. FindThing finds a thing (perhaps numerically) and returns the thing and its location. ThingDetect returns the original object but where the thing is highlighted. – Patrick Stevens Aug 07 '15 at 15:14
  • 1
    @bills … although it might be A New Kind of Sense. – Patrick Stevens Aug 07 '15 at 15:20
  • 1
    I think this is a great question and would vote to re-open it. Understanding the logic and principles that have gone into System names can IMO be of great assistance in being able to correctly guess a new/recalled function but also in designing your code. Perhaps it could be narrowed down to a request for some small set of principles used in such naming? – Ronald Monson Aug 13 '15 at 00:12
  • Here is Stephen Wolfram's blog on the naming of functions. – Sjoerd C. de Vries Aug 13 '15 at 05:36
  • I agree with Ronald, It is a nice question, but the close reason is valid. It would of course be much better if a former or active WRI employee would stop by and share something from experience, but we shouldn't actively rely on that (hence the close reason again). @Sjoerd, perhaps your link with some excerpts from it would suffice as an answer too. – LLlAMnYP Aug 13 '15 at 14:54

1 Answers1

18

You'll find plenty of exceptions if you keep looking — e.g. MapThread (action-action), FileExtension (object-object), NIntegrate, NSolve (Hungarian-like), etc.

I've always felt it's better to be more pragmatic about things like naming conventions as it allows for flexibility in the language design. I dare say it even improves readability at times, because it allows the designer to pause and reflect on how a symbol might be used and how it appears when read in code (as opposed to sticking to a naming dogma). In the case of image processing functions, I suppose the thought process was something like this:

  • Compose, Convolve, Histogram, Apply, Dimensions are generically named functions that are also meaningful in the image processing context. But rather than overload these existing (possibly heavily optimized) functions to work on _Image, it makes sense to create separate symbols. So... HistogramOfImage? ConvolveWithImage? ApplyOnImage? A bit too verbose, even for Mathematica, and doesn't evoke the same simplicity as the parent functions.

  • You then start using a prefix to common functions that immediately convey to the user what it does (because you're already familiar with the verb/noun) and what it acts on (the prefix) e.g. ImageHistogram, ImageDimensions, ImageConvolve, etc. This also helps disambiguate context specific uses of the noun/verb from generic ones.

  • Once you do this, you've now already established sort of a soft convention that seems to fit well, so you then extend the idea to other symbols (but not necessarily based on pre-existing ones) such as ImageCrop, ImageTrim, ImageResize, ImageData, etc. The noun/verb conveys the meaning succinctly and can be used with other data types just as easily (e.g. StringTrim).
  • Then finally you come to specialized functions which really have no use cases other than in image processing — SetAlphaChannel, RemoveAlphaChannel, Opening, Closing, etc. And now you've broken your own convention. And that's OK.

Could they have added an Image- prefix to all of these specialized functions for consistency? Yes. Should they have? Probably not, since it adds no additional information. Is it more readable as a result of not sticking to the rules? I would argue yes. If one must insist on consistency, then insisting on local consistency (within a specific package/functionality/group of functions) is better than insisting on global consistency.

rm -rf
  • 88,781
  • 21
  • 293
  • 472