I don't have a lot of experience with functional programming and none with OCaml. I do have a little real world experience programming in Scala, and what I fou

I don't have a lot of experience with functional programming and none with OCaml. I do have a little real world experience programming in Scala, and what I found was that my Scala code was more readable than my Java code, because I could use Scala's much greater expressivity to make the code more clear. The code in the Lift web framework was quite difficult to read, way worse than Java code, however. This has been a while so I don't remember the specifics, but I remember thinking that the Lift developers belonged to the "Look ma, no hands!" school of functional programming. Instead of splitting some logic up into four statements with some local variables, you'd have a giant four line statement that was all one giant expression with a lot of nesting. I'm just writing JavaScript these days, and not in a particularly functional style. I do write some functional code weekly if not more frequently, in Bash. I start out with one command, and then incrementally build out a pipeline where I extract, and filter, and reformat to get some data into a format I can understand. The thing to note is that this code has to be built incrementally and tested at every step. The code written this way is not remotely readable or maintainable when I get done with it, but that's OK, because I'm usually going to throw it away after using it a few times. On the rare occasions that I need to immortalize this kind of code in a permanent script I have to put a fair amount of effort into refactoring it into something I can understand and modify in the future. It kind of seems to me (but keep in mind that I am no expert) that we have some problems that are not so much with functional programming languages as they are with functional programming culture. There is a tremendous emphasis on being concise, but being more concise does not, in general, make code more readable or understandable.