3 ms·

Languages are means to end, where the end you reach is significantly affected by the means you used to get there. - Using Haskell means you can model your doma

Languages are means to end, where the end you reach is significantly affected by the means you used to get there. - Using Haskell means you can model your domain more precisely and have higher correctness guarantees. - Using Rust means you get memory safety while maintaining the speed of C++, where the vast majority of vulnerabilities are memory safety issues. - Using SQL means you can apply an optimizer on top of what is essentially relational algebra over tables. In all of these cases, a less effective tool could be used, yes. But "it's just a tool" doesn't capture the fact that tools do solve domain-specific issues, and OP is not wrong to seek an employer who acknowledges the value of Haskell has to add.

ironman1478 5y ago
I get all that, but it still feels backwards a bit? I work in HW but I write a lot of software tools and prototype control firmware (though I come from an enterprise background). I generally have to write python, C++ or C (all context dependent). If somebody came to me saying "I want to work in C" or "Python" I'd say "so"? They should be saying they are interested in solving optimization problems, image quality search problems, etc. I understand Haskell is great for certain use cases but that applies to every language barring joke ones. Why would an employer hire somebody if they are simply interested in the tool through which the problem is solved not the domain itself? What signal does that provide and what evidence do I have that the person will become component in the domain? The way the original post is framed feels backwards to me. I should also add, I was one of these people that just wanted to write C++ template metaprogramming all day and I had a hard time find jobs due to this exact line of thinking. Once I relaxed this constraint, I was able to find a new job AND use the programming tools I want, assuming its appropriate for the context.
- smasher164 5y ago
  > They should be saying they are interested in solving optimization problems, image quality search problems, etc. They are. OP has been spending 30 years not being paid to use the tools he wants. > but that applies to every language barring joke ones Some languages are far more effective for a domain than others. To stretch it further than Haskell, there's a reason why Verilog is used in hardware over something like C. It would be enormously frustrating to work against my tool to get something done. Programmers who focus on "getting stuff done" in these situations are succeeding despite their tools, which is commendable, but we should still push to using better tools. > interested in the tool through which the problem is solved not the domain itself Many factors play into why someone works at a company, whether it's cost-effective to use a certain tool, whether a tool is trendy, whether the candidate is passionate about the domain, or whether the candidate is passionate about the tooling. A lot of people aren't passionate about the domain of adtech, for example, unlike self-driving cars, but they work in these areas because they like the practice of engineering.
  - ironman1478 5y ago
    > OP has been spending 30 years not being paid to use the tools he wants. You know you're right about that and I hadn't really thought about what you mentioned in your post overall. But it makes a lot of sense

ironman1478 5y ago

I get all that, but it still feels backwards a bit? I work in HW but I write a lot of software tools and prototype control firmware (though I come from an enterprise background). I generally have to write python, C++ or C (all context dependent). If somebody came to me saying "I want to work in C" or "Python" I'd say "so"? They should be saying they are interested in solving optimization problems, image quality search problems, etc. I understand Haskell is great for certain use cases but that applies to every language barring joke ones. Why would an employer hire somebody if they are simply interested in the tool through which the problem is solved not the domain itself? What signal does that provide and what evidence do I have that the person will become component in the domain? The way the original post is framed feels backwards to me. I should also add, I was one of these people that just wanted to write C++ template metaprogramming all day and I had a hard time find jobs due to this exact line of thinking. Once I relaxed this constraint, I was able to find a new job AND use the programming tools I want, assuming its appropriate for the context.

smasher164 5y ago
> They should be saying they are interested in solving optimization problems, image quality search problems, etc. They are. OP has been spending 30 years not being paid to use the tools he wants. > but that applies to every language barring joke ones Some languages are far more effective for a domain than others. To stretch it further than Haskell, there's a reason why Verilog is used in hardware over something like C. It would be enormously frustrating to work against my tool to get something done. Programmers who focus on "getting stuff done" in these situations are succeeding despite their tools, which is commendable, but we should still push to using better tools. > interested in the tool through which the problem is solved not the domain itself Many factors play into why someone works at a company, whether it's cost-effective to use a certain tool, whether a tool is trendy, whether the candidate is passionate about the domain, or whether the candidate is passionate about the tooling. A lot of people aren't passionate about the domain of adtech, for example, unlike self-driving cars, but they work in these areas because they like the practice of engineering.
- ironman1478 5y ago
  > OP has been spending 30 years not being paid to use the tools he wants. You know you're right about that and I hadn't really thought about what you mentioned in your post overall. But it makes a lot of sense