On Tue, 3 Mar 2015, Steven G. Johnson wrote:
On Monday, March 2, 2015 at 7:57:10 PM UTC-5, MA Laforge wrote:
The real question is how much programming overhead is required to use
these types (assuming the compiler does the grunt work reducing the
*performance* overhead)
No, the real question is whether the benefit of using special types for
radians vs. degrees would outweigh the costs of retraining every single
user from every single previous mainstream programming language. To me,
there is no contest ? doing angles differently from every other programming
language would impose enormous costs in teaching, documentation, and
support (imagine the never-ending flood of mailing-list questions) that
would completely overwhelm the benefit of eliminating a "d" suffix on a few
functions and automating a few angle conversions.
+1
One of the reasons the language from the MathWorks company is so
popular is that it lifts the burden of worring about types, memory
allocation, and a host of other issues from the backs of people who
only want to do math. Requring users to specify a type in order to
take a sin or cos (or sind or cosd) will make Julia very unpopular.
From what I understand, Julia uses types sparingly, and for two
reasons:
* When needed for high performance.
* As a way to do something like object-oriented programming.
As I understand it, types are not systematically required as a basic
part of writing a program to so ordinary users can become effective
at solving their math problem quickly. This is opposed to, say, C++,
which requires strict typing from the get-go, and is accordingly
difficult for non-programmers to use for doing math.
Since types should be used sparingly, I don't think it a good idea to
replace convenience functions like sind and cosd with a type-driven
invocation mechanism -- ordinary users will be confused.
Stuart
