4 ms·
I didn't try to say that Haskell is the best language for everything. I also wouldn't want to do everything in Haskell. But as you are pointing out, you learned
by QuantumRoar 11y ago
I didn't try to say that Haskell is the best language for everything. I also wouldn't want to do everything in Haskell. But as you are pointing out, you learned a lot from Haskell and you are using its lessons in production.
The best a language can do is to fill a niche and to be very good at that particular thing. You should always use the language that is most suited for your problem, whatever that is. But there are many languages that let you get away with being a terrible programmer. Haskell just isn't like that and I want to point out that you can learn a great deal from being forced to think in more abstract ways, just like you did.
In programming, we often encounter the temptation to just mutate everything and to use side-effects since it's quite convenient to do so in the short-term. In the long-term, these things will come back and bite us. I argue that it is important that a programmer should have experienced what it is like to simply not have the option to do so. After learning Haskell, I tried to avoid side-effects in other languages as much as possible and to use them consciously. That was something I didn't even consider before learning Haskell. And, obviously, the less side-effects you have, the easier it is to maintain or exchange parts of your program.
I currently use Haskell to calculate probably a hundred analytical derivatives for a large sparse array that is used in a simulator written in Fortran. And it's very good at that. For quickly writing some evaluations of output of this simulator I use Python, because Python is better suited.
Pick a language based on the problem. Don't just use one language because you know it. In my experience, Haskell is very well suited for a lot of mathematical stuff.
------
Off topic:
By the way, Einstein's field equations will work for gravity in the classical regime, not in all cases. But still, if you simply want to calculate how far you'll throw a ball, you really should take another model based on Newtonian gravity or simply take a constant gravitational force. Planetary movements are also fine with Newtonian gravity (except when you really need it accurately. E.g. for the precession of the perihelion of mercury). However, GPS calculations are terribly inaccurate without general relativity (time flows differently if you are close to a big gravitational potential well). So, pick your model based on what you want to do, just like you pick your programming language based on what you want to do.
- krick 11y ago> I also wouldn't want to do everything in Haskell. Examples, please? And why?
- dllthomas 11y agoLack of dependent types? :-P
- QuantumRoar 11y agoIf you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that). While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran. Python has a lot of very useful modules. If I can solve my problem with basically a few import statements and don't care about performance or anything, I find Python to be better suited. Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.
- dllthomas 11y agoHaskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.
- QuantumRoar 11y agoOh. I didn't know that. Thanks for pointing that out.
- dllthomas 11y agoHaskell strikes many as "bad for mutation" because introductory tutorials don't really cover it. This is because 1) mutation is not terribly idiomatic, 2) relying on mutation often (not always) a bad design decision, 3) Haskell handles the immutable case really well, and 4) mutation involves some more complexity than is involved in other languages. All of these are good reasons to avoid talking about mutation in a beginner Haskell tutorial, but when you need to address a problem where mutation is the best fit you'll find that it actually works pretty well. Haskell doesn't make mutation difficult, it makes it explicit, which has upsides and downsides.