5 ms·
It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non
by rprospero 13y ago
It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in:
div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a))
than it is in
(-b+sqrt(b^2-3ac))/(2*a)
On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably curse any programmer who used it and thank the gods that it was left out of Go.
Conversely, since I write a lot of numerical code, I don't care about generics or typing, which is crucial to many other programmers. Generics don't matter since everything I work with is either a Double or a collection of Doubles. Similarly, static typing doesn't help, since most functions just have the type (Double -> Double) and the type checker can't tell a sine from a logarthim. Of course, the reverse is also true. Since everything is either a double or a collection of doubles, the fancy tricks that dynamic languages offer don't give me a damn thing, so I'm extremely ambivalent about the typing debate.
Of course, on other projects, I've written code that benefited from static typing and I've written valid code that would choke any type checker. I've written code that heavily needed generics. When I did that, I used the languages that had the features I needed.
Go just won't work for the programs I write and it sounds like it doesn't work for yours, either. That's why we won't use Go. I've heard it works wonderfully for a certain class of server software and I'm glad those guys have a useful language for their domain. If I ever have to write another server, I might even teach myself Go. But don't feel guilty that you're using an old hammer instead of the shiny new saw.
- termain 13y agoAmbivalent or apathetic regarding the typing debate? Typing can become useful in numerical code when you move past operating on scalars. Column and row vectors needn't be confused, a two-vector and a complex number have different types, etc. Also, physical quantities can have different types and a type system can be useful there. I totally agree that for numerical code, operator overloading is of great utility.
- scott_s 13y agoIf you haven't seen Julia, you may want to give it a look: http://julialang.org/ http://julialang.org/ Introduction to the manual: http://docs.julialang.org/en/release-0.1-0/manual/introduction/ http://docs.julialang.org/en/release-0.1-0/manual/introducti...
- zwieback 13y agoAgree with what you're saying but I think you probably wanted 4ac
- ufo 13y agoI think thats his point. Its easier to spot the bug on the second version :)
- lightcatcher 13y agoIf you don't mind me asking, what sort of work do you do where you mostly write numerical code? Academia?
- rprospero 13y agoYou hit the nail on the head with academia. Physics, to be precise. About 80% of my code is data analysis stuff where I'm just reducing events from data files. The other 20% is monte carlo simulations.
- kyzyl 13y agoFor the record, there are lots of other places where you do numerical work. Any kind of genomics work, for one, will involve tons of data processing and numerics, and it's it's not strictly an academic pursuit. At my previous job most of my day-to-day work was on algorithms for speech recognition and topic modeling, which is pretty well doubles flying left and right. That wasn't academia either.
- lightcatcher 13y agoThanks. I've actually done some machine learning work both in industry and academia, so I'm both aware (and excited about) doing numerical stuff in industry. I've yet to actually meet someone in industry who does numerical work that isn't some form of data analysis. Maybe someday...
- howeman 13y agoIt's not quite that bad in Go, (-b + math.Sqrt(bb - 4ac)) / (2 a) though if you're using a ton of matrices it could be. I for one have found Go great for computing. The really quick compile times with static checking plus the composability are great. It definitely depends though; while the native concurrency is great there aren't a lot of easy solutions for non-shared memory computations. (I saw an MPI package at one point, but I haven't tried to use it)
- howeman 13y agoSorry, new to posting on HN. How do I get asterisk literals?
- scott_s 13y agoMake sure there are spaces on both sides. Asterisk: * (plain asterisk surround by spaces). Italics: foo ('foo' surrounded by asterisks).
- prodigal_erik 13y agohttps://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc says two leading spaces formats code verbatim: (-b + math.Sqrt(b*b - 4*a*c)) / (2*a)
- sampo 13y agoLeave a whitespace after the asterisk: 1 * 2 * 3 = 6 https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
- rprospero 13y agoIt's more than just matrices, though. For instance, I have a little library that propagates uncertainty for me. Without operator overloading, I'm back to descending into the rpn hole from my example. Another poster pointed out unit analysis. I've done this before with custom types that keep track of the units on measurements. Since you mentioned parallelization, that's another fun toy I've played with. By overloading the operators for an object that defines a snippet of OpenCL code, it's possible to push these snippets through pre-existing functions and have it return a final OpenCL function. You then call that returned function on your arrays of data to run everything through your GPU with just three lines of code changes from the sequential. Operator overloading is more than just adding matrices. It's a powerful technique that comes in handy almost any time that you're working heavily with numerical data. Of course, it's also dangerous as hell in the wrong hands. The code for the OpenCL example was actually some pretty terrible code that did extremely non-intuitive things during value comparisons.
- JulianMorrison 13y agoYou and FORTRAN were made for each other.
- kibibu 13y ago> and the type checker can't tell a sine from a logarthim Oddly enough, in Go it can. type sine_val float64 type log_val float64 These are now incompatible types, and you couldn't pass a sine_val to a function expecting a log_val, for example. (Not that I am advocating this sort of approach, but it is possible to let the typechecker work this stuff out if you are dedicated)