On Sun, Oct 26, 2008 at 3:46 AM, Spacen Jasset <[EMAIL PROTECTED]> wrote: >>> I am not entirely sure that 30 or (x amount) of new operators would be a >>> good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 = >>> m1 X m2 ? and how often will that happen? It's also going to make the >>> language more difficult to learn and understand. >> >> I have noticed that in pretty much all scientific code, the f(a, b) and >> a.f(b) notations fall off a readability cliff when the number of operators >> grows only to a handful. Lured by simple examples like yours, people don't >> see that as a problem until they actually have to read or write such code. >> Adding temporaries and such is not that great because it further takes the >> algorithm away from its mathematical form just for serving a notation that >> was the problem in the first place.
Yes, heavy math code is hard to read in the current situation. I almost always prefix any significant math with a comment giving the equations being implemented in a more compact notation. Having to write the same thing in two different ways like that is a waste of effort. It would be very cool if I could just write it once and have it look like it does in my notebook. > Yes, that is indeed a fair point and I agree. D is a "systems programming > language." [sic] though; and so what will people use it for in the main? D is a compile-to-the-metal language that is of interest to anyone who ranks performance high on their list of priorities. Mathemeticians and scientists are among the few remaining groups where maximum speed is still needed. Games are another area, and games are becoming more and more sophisticated mathematically under the hood. > I suggest that communities that require scientific code have options now, and > that they can and do choose languages for the purpose which have better > support for thier needs than D might achieve. The traditional math languages suck at doing anything besides math. Want to do a bit of math then display the results interactively in an OpenGL window? With Fortran?! Ha! On the other end there are the Matlab and NumPy-type solutions. They are convenient for tinkering around and displaying some results, but these are not good for performance. D has both. So I think D has potential to gain traction in the world of math-heavy computing. But anyway, I'm got convinced several posts back that the time is not yet ripe for Unicode in D. So I'm not gonna argue that D go Unicode now. I'm just saying that math code is hard to read, and that heavy math users are a good target audience for D because they need performance, but don't necessarily want to give up general-purposeness. --bb
