Re:The Wolfram Language: Fast Introduction for Programmers
by fdej on Monday December 21, 2015 @04:26PM
(#10773639)
This is less of a problem when you consider that peripheral functions tend to have verbose, descriptive names. Is GeoProjection really fundamentally worse than Geo.Projection? The upper case convention by itself greatly reduces the chance of collisions with user-defined functions and variables.
[ Parent
| on HN ]
Re:The Wolfram Language: Fast Introduction for Programmers
by murbard2 on Monday December 21, 2015 @04:48PM
(#10773759)
Yes it is.
Either all of your geography related function start with "Geo" followed by a capital. In that case you're basically using a namespace while reaping none of the benefits. You can't use the namespace to avoid repeating yourself in some local context, you can't rename it, you can programmatically inspect its content, etc.
Either they do not, in that case you have an inconsistent mess.
Re:The Wolfram Language: Fast Introduction for Programmers
by ori_b on Monday December 21, 2015 @05:16PM
(#10773947)
Ok. So they basically use a namespace. Now, your objection is that the implementation of the builtin functions repeats Geo too much?
As a user, why should I care?
Re:The Wolfram Language: Fast Introduction for Programmers
by murbard2 on Monday December 21, 2015 @05:51PM
(#10774151)
No, that's the weakest advantage, I've cited others. For instance, being able to rename the namespace is very important if you're using third party libraries which may have conflicting names.
Re:The Wolfram Language: Fast Introduction for Programmers
by brandonbloom on Monday December 21, 2015 @06:15PM
(#10774290)
Half the reason for Wolfram Language's large standard library is that you should almost never need a third party library of any kind. If there was a third party library that was particularly useful to typical Mathematica use cases, Wolfram would just put it in to the standard library...