Yeah, expected return only makes sense in e.g. a diversified portfolio.
edit: You can downvote all you want, but it still doesn't make sense to consider the expected return on one item in isolation. If you disagree, provide a reason.
They also let you compose SQL fragments in ways that would be a lot more difficult or less clear otherwise. In the case of Diesel, they let you typecheck the composition of those fragments. ORM hate is based on misunderstanding of the benefits those who do use them get from them.
Disagree. There are too many STEM students already. It's just that plenty of web development shops are okay with hiring a physicist. It's a waste of money and time to encourage more STEM education unless the student is actually passionate about the subject in itself.
The downsides of the current trend are:
- pretentious web development job posts requiring master's degrees in CS "or related field" (as if physics prepares you for jQuery).
- debt-ridden, unfulfilled scientists relegated to the above
Yeah, I'll never tell someone not to learn something for the sheer enjoyment. But this article is downright pretentious. It gussies up a lot of simple day-to-day tasks with off-putting terms and would not be helpful to a beginner.
I'm always curious what people are using the more exotic type system functionality of e.g. Haskell or Idris for in practice. It was interesting to hear that even Simon didn't expect such things to be used in industry quite yet.
Still, I wish I could see more info on this. At what point does the additional cognitive burden of advanced type system features become a worthwhile tradeoff for program correctness? It seems to me that this depends wholly on the complexity of the program.
Further to that point, the most complex programs I can think of (perhaps you may be able to offer other opinions, which I welcome) are AAA game engines. What are the reasons why the big engines out there are not using higher-kinded types, dependent types and the like? Is this just because of pragmatic issues such as the languages the developers learned in school not supporting these features, or because here-to-date functional languages supporting these features lacked the appropriate throughput of C/C++, where one can layout data for cache-efficiency?
So using CSS, one can fingerprint a browser and communicate that information back to home base by programmatic inclusion of font A or font B. This inclusion triggers the download from the respective URL, thus giving that URL information about the user.
In oversimplified terms, Rust has objects but not classes. It skews more toward:
- from a C dev's perspective: data-driven design
- from a Haskell dev's perspective: typeclasses and ADTs
Thanks for helping to qualify when the proposed solution starts to become appropriate. I'd still really need a solid example of when this starts to be beneficial. Could anyone oblige?