I’ve also been unemployed longer than I wanted to twice and had to swallow my pride and work on someone’s legacy to pay the bills. Switching the rockstar mentality with more humility and a sense that I’ve been very lucky was important.

Sounds like you could find a Scala job or a Rust job in your capital. They’re less rare than Haskell jobs.

As for advice: get obsessed, get good at something, don’t wait for people to pay you to excel at the tools you eventually want to master. I toyed around with Haskell for 10 years in my spare time before using it in production.

Where did you find those jobs?

Speaking from experience, the much reviled FAANGs have ample depth and reward correct solutions.

The recommendation to look for Haskell shops is exactly a heuristic for the thing you recommend:

> "work at a place that has problems that are deep enough to warrant deep dives."

There are many ways to find such places. Filtering by tech stack is one possible way of many to search for signal.

Yes and I'm arguing there's exactly zero causal relationship.

> There are many ways to find such places. Filtering by tech stack is one possible way of many to search for signal.

You're just wrong. Deep problems come with scale and also cost money to solve. Small-medium shops have neither no matter the "tech stack".

Some questions for you:

Would you say every programming language is fungible? If so, then why are there so many? How many should there be?

And how long did they have funding for to continue doing this work? Is there some part of "it's expensive to do deep work" that you disagree with?

> Would you say every programming language is fungible? If so, then why are there so many? How many should there be?

This is a complete non-sequitur.

Which languages do you reach for most often (whatever the reason for doing so)?

You're conveniently not addressing the more salient, central point: deep work costs lots of money.

Edit: but no one is solving PDEs using Haskell lol.

Thus languages are neither fungible nor does it seem from the languages you just mentioned (which most would say the same) that there is "zero causal relationship" between a language and solving problems in the domain of interest. In this particular hypothetical, someone would notice a desire to solve deep problems with lots of funding that use numerical computing and could thus look for the languages you mentioned as an initial filter. Such a person would probably not be looking at a javascript role, for instance, given these aims.

Thank you.

So what you need to do is start looking for big problems. Not big problems that are only seen by developers, but big problems that are seen by the general public. People will pay for solutions. You will be motivated by solutions, something that you need to research the hell out of. Something you need to make connections that no one else has made before to solve. That's it

You can’t imagine how abundant are boring projects and products made of scala :)

This is not about language or current hype.

Hard to say with confidence because of very scarce signals, but probably you want to find a job with 2 features: 1. Very early stage of a software 2. Very ambitious software itself (like a new db on a competitive market, new game engine)

Most of the “boring” jobs are not about developing the software per se, but rather about _using_ (wiring up, cobbling up, tuning, integrating) pieces of existing software to shove data around.

That what makes it boring in a nutshell - lack of the aha moment of creating something new.

Why? You're a 21st century plumber without union protection. Sort out your company's plumbing, then do wtf you want on your own time.

Still, I feel like I should at least try.

https://www.benkuhn.net/hard/

Have you looked into shops that use Haskell? I know some trading firms use lispy languages and some game studios (Naughty Dog?) also use them. But I could be wrong.

Naughty Dog had somewhat famously written Crash Bandicoot and Jak and Daxter using Lisp although they don't appear to use it these days

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Damn I'd love to use it in Emacs. I never had to use Emacs and stopped dreaming about it or vim, but would love to learn it, and the best way to learn it is to be forced to use it for a few weeks.

It would also be interesting to read the code for debugger, linker and compiler.

I'm actually just starting my own company using Haskell so I can think deeply about what I want while making the product how I want.

If you do want to eventually get a role using Haskell (which are rare), it is a good strategy to pick some commercial thing and implement it in Haskell. For instance, do a CRUD app using a postgresql app like Esqueleto/Persistent, Opaleye, etc. Or make a web app with Yesod (or even Scotty or Servant).

As for benefits, I get the following:

- strong, static typing via the Hindley-Milner type system

That means any changes to my logic and type signatures have to be addressed immediately everywhere.

- type-safe, composable everything

I want as many issues as possible to be caught at compile time. Ideally, I would have no runtime errors. It is possible to get close to this ideal with Haskell.

- terse, expressive language

Less code to read per concept expressed plus a strong type system means that maintenance and refactoring is a breeze. In fact, I can fearlessly refactor. That means once I get everything up and running, the codebase is stable even when I change things. Thus, I can actually focus more on the product and customer needs.

Combining all of the above with other stable and maintainable technology choices makes the entire app architecture easy to maintain over time as well.

You always have to consider the technology so you can properly architect your application and its dependencies.

1. Dod labs and defense contractors are great places to dive into topics pending you are inexpensive. You will likely be paired with other people who can sit and thinking deeply with you. As you progress though, you will be pushed into management, forced to being in money, and pulled many ways preventing your deep thinking. This is when most good scientists leave.

2. Be confident in your job search about what you are looking for. Don't be afraid to say you want 85% deep technical work and 15% reporting to stakeholders. This will be polarizing to a lot of employers but those who want you will quickly scoop you up when u get connected to them.

3. The market is terrible for r and d right now across almost all sectors. Most r and d labs are looking 3-6 months out which means they want people qoth a specific background to build prototypes amd fail quickly. This will be existing scientists in the company but rarely any new hires. i interviewed at Amazon and found this to be the case as an example (I turned down the role).

4. Wait until the market improves but keep looking while doing item 2.

Good luck.

One approach: Pick something that was at the time 'state of the art' and envision what would constitute 'state of the art' today. 1800's good for steam punk approach. Describe what existed at the time of 'original state of the art' and how that changed to current state of the art aka standards, techniques (black smith to all digital chip/embedded laser scan). Learn quite a bit about how things came to be & underlying abstractions/standards that 'simpify'/'unify' things.

Keep open mind about Alexander Fleming approach to 'bugs' in an experiment. (did that old ME design bug faithfully get replicationed in the software, intentionally or unintentionally?)

###

   ** 1800's telegraph engineer solution to needing multiple telgraph wires vs. current version of usb

   1800's fax : https://www.damninteresting.com/curio/the-fax-machines-of-the-1800s/

   ** K&R C vs. Published C standards (iso or otherwise) always fun way to find intersting things to explore (applied to hardware or not hardware applied). 

   ** RFC's bit less 'wordy'.

   ** awk progam(s) to use/interpret BNF in real time to provide "modern" constructs for awk programming. (or impliment way to read/interpret lambda expressions in awk to extend awk)

   ** ( as a learning tool/approach a scaled/toy awk scripted version of dbos )

   dbos :  https://www.google.com/search?client=firefox-b-1-d&q=dbos

   ** Nipkow mechanical tv 1920's vs. python/pi implimentation! (or Philo Farnsworth's take)

   mechanical tv : https://www.youtube.com/watch?v=R-wbfP1pmVw

   Farnsworth : https://en.wikipedia.org/wiki/Philo_Farnsworth

   ** foucault's measurements vs. LIGO vs. Fizeau Apparatus
   
   https://en.wikipedia.org/wiki/Foucault%27s_measurements_of_the_speed_of_light

   measuring speed of light : https://www.youtube.com/watch?v=R-wbfP1pmVw

   LIGO : https://en.wikipedia.org/wiki/LIGO

   Fizeau Apparatus : https://www.youtube.com/watch?v=YMO9uUsjXaI

   ** MUMPS vs. current 'concurrent' databases (postgres).

   MUMPS : https://en.wikipedia.org/wiki/MUMPS                                       

How to loop in a loopless language might be useful for going from "spinning disks" to 'trees' : https://www.youtube.com/watch?v=qzsxO79zxS8