Hacker News Reader

Comment by wiz21c | Hacker News Reader

>>> functions usually are very composeable

This plus the fact that the "function" is also the most basic way to describe operation on data means that you can build any kind of operations, data structure, program construct as you please like lego.

This is at the same time, imho, the weakness of the paradigm when used in industry : it gives so much freedom that two programmers will solve the same problem in different ways, making it harder to share code. Not everyone has the desire/patience to understand the many flavors of solutions proposed by the colleagues.

View on HN

I don't know if this relates or whether I'm misunderstanding, but one approach to impose a bit more structure on the functional approach that I rather like is 'behaviours' in Elixir (and Erlang?):

https://elixir-lang.org/getting-started/typespecs-and-behavi...

What do you think the solution is? Not being snarky here; I'm genuinely interested in the problem you've described, because this unbounded freedom bothers me too.

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.

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/

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.

Reply on news.ycombinator.com