My immediate thought is specifying the requirements for the input and output desired. This is something I thought a small bit about when learning Haskell. It's easy enough to search on Hoogle[0] by type signature to at least narrow it down, but then you have to look through all sorts of functions to see if the semantics are correct. Then, one may think, perhaps having search functionality to pass a collection of inputs and outputs and run any relevant functions that have a valid type for the inputs and outputs. However, that could take longer to compute than just writing the function in the first place. It also gets complicated because perhaps what you need is a composition of functions (map reduce, filter map, etc.), so now how do you know when to stop composing functions to get the desired output? I'm not smart enough to know if there's a general solution to this (other than simpler cases of cycles).

I would also really like more insights into this. I'm working on a toy project dealing with bytecode and being able to interpret the semantics of a series of instructions reliably would be very handy. I believe if the above has any practicality then it would help my problem.

[0]: https://www.haskell.org/hoogle/

Not who you replied to, but I, personally, think it boils down to trust. Using someone else's code, _especially_ if it's functional, should be the same as using the proverbial black box. You shouldn't need to understand their code in order to use it with your own. The same should be true of your own code, really. You shouldn't need to remember implementation details of a function you wrote in order to use it in elsewhere in your code.

I know there's then the issue of security, freedom, openness. . .whatever. But if you're working on a project with someone else, and you don't trust them, the project's probably doomed to fail to begin with.

Discipline. A lot of people dislike bondage and discipline languages like Ada. But one of the reasons for those languages was that it enforced discipline. This made it very compelling from a systems engineering perspective.

Languages that permit more freedom for programmers require the programmers, themselves, to practice discipline. This requires attention to detail, up to date documentation, and effective communication. Those things require full-time staff, beyond just the programmers, to facilitate. And, really, you need to have systems architects/engineers to be making decisions or guiding decisions with a heavy hand.

I dunno :-( I think there's a permanent tension between creativity and norms... But my guess is that not everyone is wants to cope with that. Not everyone wants to discover yet a new solution, yet a new style each time he reads some code. Personally, I love that but given the success of, say, Java, I'd say there are people who prefers more guidelines. And this has nothing to do with IQ or coding skills or anything, it's just personality I think.