I'd settle for being able to contain whatever level of intelligence it is that writes papers like this.
Just don't tell them how far they are from reality and they'll keep writing the papers. Intelligence contained.
Readit Newsst1x7 commented on Superintelligence cannot be contained: Lessons from Computability Theory arxiv.org/abs/1607.00913... · Posted by u/giuliomagnifico
This is just science fiction. To mention "recent developments" in the introduction is somewhat misleading considering how far the current state of technology is from their hypothetical superintelligence.
We don't have superintelligence, we don't have the remote idea of how to get started on creating it, in all likelihood we don't even have the correct hardware for it or any idea what the correct hardware would look like. We also don't know whether it's achievable at all.
Deleted Comment
st1x7 commented on How to Become a Data Engineer in 2021 khashtamov.com/en/how-to-... · Posted by u/adilkhash
This is an anecdote - plenty of firms are using Scala in their data engineering stacks and it's a great tool for the job.
While maybe not strictly necessary per se, it's a great way to get a foot in the door, and provides a great way to foster advanced type systems and functional programming (I personally find it to be a really fun language to write in to boot).
> plenty of firms are using Scala in their data engineering stacks
Isn't that just a result of everyone being into Spark a few years ago?
Optimizing for worker fungibility, in a vacuum, seems like a -EV "playing not to lose" strategy. It's understandable that this line of thinking is common though.
I also believe that to be the case as an employee. Ie, being a generalist is probably -EV for your career but it feels safer so it's kind of a contrarian position to say "be a specialist".
> Optimizing for worker fungibility, in a vacuum, seems like a -EV "playing not to lose" strategy.
That's why you don't optimise for it in a vacuum. You weigh the potential benefits of switching to Haskell versus the additional cost of maintaining/growing a Haskell team.
I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff, I would assume mostly due to larger competition among employers for the former (and in parts better community access for small shops in niche languages and self-selection of who learns the niche languages)
> I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff
Of course, there is just more of them in the first place. The other effects that you describe might also be true but keep in mind what the base rates are.
The market works somewhat differently for small companies there. Yes, there are fewer people with relatively niche skills, on the other hand you have an easier time to attract the few you need. Not every company wants to become large.
> on the other hand you have an easier time to attract the few you need
How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?
Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.
I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.
Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.
I feel like this isn't discussed enough. I can't comment on the technical merits of Haskell but growing an organization and replacing engineers is so much more difficult when you're using tools that aren't mainstream.