[jll29]

In 2005, I needed to hire a Haskell dev with deep NLP expertise to replace a member of my startup team.

After a posting on the Haskell mailing list, zero responses came back.

We realized the world had about 3 people that matched all the requirements: one was the dev that needed to be replaced, the other one was a tenured professor of a U.S. university (Hi, Hal!), and there was one more, whom I don't remember but it may just as well have been Simon Peyton-Jones himself (only slightly exaggerating here).

Note the Haskel NLP mailing list - https://archives.haskell.org/projects-pipermail/nlp/ - did not exist then, it was formed only in 2009.

In the end, I forced a complete re-write in Java of our initial "rapidly prototyped" Haskell codebase at the time, and I often wonder what I would do nowadays, nearly 20 years later (Python is slow, has the commercial disadvantage of letting customers read off your secret sauce if code runs on their machines, but has a good dev pool to hire from, and definitely is both high-level enough as well as suitable regarding library support; ironically, Java is still a contender, despite the boilerplate Kotlin isn't getting the traction that Rust is getting against C, C++ has changed dramatically every 5 years in the 20 years since, and still ads complexity, which is all very scary, and Julia has a small talent pool, and isn't ready for prime time yet, certainly not regarding NLP libraries).

I know, since this is HN, people will say "LISP!", but I'm not sure; I always loved the aestetics of Scheme, but not the ergonomics - and my conjecture is there might be something about keywords that makes them superior cognitively for humans compared to just piles of nested parentheses.

EDIT: fixed a typo.

[downrightmike]

When you have one expert in something, you'll need to back them up or replace them in the future. You're job is to find three or four people that are decent at thing, and then put them all on expert tasks, as a team, so they grow into experts. This also frees up your expert to do that level or higher work.

[singpolyma3]

I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.

[aleph_minus_one]

> we always hire from our product community because tech is easier to teach than product.

Whether this is true depends a lot on the product and the tech that is used.

[throwaway2037]

What product?

[forgetfulness]

Pretty different if it's semiconductor engineers instead of the business school guys that would be covered by that sentence 99% of time.

[skydhash]

> and my conjecture is there might be something about keywords that makes them superior cognitively for humans compared to just piles of nested parentheses.

It's the nature of the language and the VM that it runs in. The code is data and data is code. You can construct a list and then decide to evaluate it. Or the current code you're writing is actually data for another piece of code. It's a paradigm that really opens the computation mindset.

The VM looks like the common REPL you see in Python, but it's more powerful. It's more like a OS installation than a language interpreter. You can inspect anything, patch anything. When paired with an editor, that means you can only apply part of the code and then rerun part of the code. You can also try stuff and then formalize stuff down in code, no need to rerun the whole program.

For me, the parenthesis are the same as Python's whitespaces and colons. Or C-like language and their brackets and semicolons. Just syntax. After a while, you just don't notice them other than check that the expression is correct.

[nequo]

> You can inspect anything, patch anything. When paired with an editor, that means you can only apply part of the code and then rerun part of the code. You can also try stuff and then formalize stuff down in code, no need to rerun the whole program.

I’ve heard this a lot about Lisp. But doesn't this lead to greater cognitive complexity because every time you patch your running code, you have to keep in mind the state of the running program and mentally check whether your patch affects any part of that state?

A lot of people do data analysis this way in R/Python who aren’t programmers either by training or for a living, and it is not a practice that generally leads to bug-free outcomes. This has also mirrored my experience with Emacs which is a Lisp machine, maybe getting closer to Common Lisp’s programming environment.

Is this process of runtime modification fundamentally different in CL? What am I misunderstanding?

[skydhash]

When you redefine a function in CL, every function that use this function is notified of the change and pickup the new version. And because it's functional and you're not supposed to modify the state outside your function, everything will keep churning.

The issue with emacs is the sheer number of variables. And the fact they're global. That leads you to do stuff you shouldn't do. But the principles are essentially the same. And in CL, you can snapshot the current state of your program to a file. Then restart later, instead of reloading the environment from the code.

A quick demo: https://youtu.be/jBBS4FeY7XM