Programming languages and the developer
(note, for this article I will be assuming you know some basic terms about programming languages)
So for this article, I'd like to talk about the usage of programming languages. Computer science is more about principles of OOP design
and learning you the basics of functional programming, and not so much about teaching you languages or the internals of one. I personally agree
with this. Programming languages (usually) tend to stick to the same ideas. Over time functional programming has become more mainstream,
further minimizing the difference between functional programming languages and purely object oriented imperative ones.
Now the cons of functional programming is that it usually works with pattern matching (F# and Ocaml also have ways to do OOP, but the type system for it is basically disjunct from the type system for union types), this means that adding a data field will require you to make sure that every pattern match on the data type you're extending needs to be filled in. This can be desirable, e.g. you're implementing some kind of heuristic and this added data needs to always taken in account. However it also goes against the idea of extending a program somewhat, you cannot easily add a field without fixing every occurence to have the right amount of fields.
Functional programming
I very much enjoyed writing Haskell, and as it is considered pretty much THE language for functional programming I can say that I learned some things from writing in it has also given me some insight in what the strengths and cons of functional programming are. The strengths of haskell are in its type system, which is statically strongly typed. A program written in Haskell is quite likely to not have runtime errors, although of course errors in logic can still happen. The IO monad is in my opinion also a very handy feature of the language. If you do not know what the IO monad is I will try to explain it in a simple manner. IO is sort of a type declaration (there is more to it, but this article is not about monads) which all functions that get input from stdin, accessing the file system have (basically 'impure code' as it has side effects). One thing that is also quite prevalent is the absence of null in functional languages. Instead expressing that something could containt a value, or is empty is usually expressed by optionals. Optionals are a very simple disjunct type. It is either None, or it is a Some(value). The very big benefit of this is that, again, this is expressed in the static type system. Most languages have also added optionals in their codebase, although in older languages those implementations are flawed in that an optional itself is still allowed to be null as it is an object itself.Now the cons of functional programming is that it usually works with pattern matching (F# and Ocaml also have ways to do OOP, but the type system for it is basically disjunct from the type system for union types), this means that adding a data field will require you to make sure that every pattern match on the data type you're extending needs to be filled in. This can be desirable, e.g. you're implementing some kind of heuristic and this added data needs to always taken in account. However it also goes against the idea of extending a program somewhat, you cannot easily add a field without fixing every occurence to have the right amount of fields.