Comment by aDyslecticCrow
19 hours ago
Use the right tool for the job. Thats engineering.
Instead you insist we should solve a nieche problem with a ill suited tool, while inventing a costume solution when a standard solution exist.
19 hours ago
Use the right tool for the job. Thats engineering.
Instead you insist we should solve a nieche problem with a ill suited tool, while inventing a costume solution when a standard solution exist.
This kind of tradeoff discussion is good to explicitly call out in an interview. I often say things like "if this were my own project I'd use X, but on a team I would probably try to find a library in a language the team already uses".
Bringing the team up on Prolog and integrating it into your CI/CD system and finding some way to connect it with other services is often going to be a poor choice, even if in isolation it's the very best tool for the job. And that's the best case solution - more likely the tests will be limited and not automated, the code review will be rubber stamp because only the author knows the language, and the code and deploy process will be a black box that everyone is afraid to touch once the author moves on.
Obviously in an interview none of the code should make it into production, but being openly pragmatic is still a good idea. And if you use an obscure language, you'd better have better than usual communication skills to concisely explain how the code works for someone who hasn't used that language before. I've seen it done well but it's difficult.