Re:Go 1.3 is released
by phlyingpenguin on Thursday June 19, 2014 @08:19AM
(#7915668)
I'm very curious why you say operator overloading is a requirement. It's certainly nice to look at code with operator overloading when you're trying to understand a problem (or maybe it's a curse when you're trying to understand what a block of code actually does!), but it's the plainest case of syntactic sugar I can think of in language design. What are you getting from operator overloading that you can't get from chaining methods?
[ Parent
| on HN ]
If you work with vectors and matrices and do a lot of computations, it is very convenient to be able to express, thanks to operator overloading, the formula you have on paper into code with nearly the same syntax. This is one area where, for example, FORTRAN still shines. You can can really TRANslate your FORmula into code easily.
In the case of FORTRAN it is because the vector and matrices are recognized types, in other language, they are not built-in types but the convenience is added thanks to operator overloading.
Yes, exactly. The same could be said for computer graphics, where we traffic in vectors and matricies all day. I want a language in which those are base types, will all of the proper operators already defined, so I don't need operator overloading. Yes, I could write in Fortran, but something a little more modern would be nice.
Re:Go 1.3 is released
by shepardrtc on Thursday June 19, 2014 @10:12AM
(#7916144)
Fortran is coming up to speed pretty quickly. The 2003 and 2008 updates to it are pretty nice. In fact, I'm in the process of porting the nanomsg sockets library over to it. You can even use GTK3 and Glade to make GUIs for it now, too. I do a lot of matrix calculations, so Fortran is absolutely invaluable.
A simple preprocessor for transforming custom infix operators to method calls might do the trick here. Go comes with good libraries to make this, you wouldn't have to invent a new Go parser. There are other preprocessors that you can look at for inspiration.
That would produce a custom language not understood by other Go users and destroy much of the benefit of the compiler reporting errors straightforwardly.