<commit_before># Additional Notes

During the webcast, someone asked “For what sorts of projects is functional programming better suited that imperative programming?” I didn’t have a good answer at the moment, and noted that it’s something of a theological issue. I recommended that the person do a search for *functional vs. imperative programming* and see what people on both sides of the issue thought.

After some reflection, there is a better answer. Whether you are programming in functional or imperative style, it makes sense to separate the pure functions from those with side effects. Functions that are pure and don’t change global state are great for programs that use concurrency--you don’t have to worry about another process changing some value that you depend upon, because values are immutable. In imperative languages, you have to do some extra work to make sure that you keep things pure; in many functional languages that’s the default. For example, [Erlang](http://www.erlang.org/) is designed with those principles in mind to enable massive concurrency with literally tens of thousands of lightweight processes as the norm.

While I was writing [Études for ClojureScript](http://catcode.com/etudes-for-clojurescript/) I spent a lot of time figuring out the answer to one of the exercises, and I thought it would come out to hundreds of lines of code; it turned out to be only 40-some-odd lines. The functional style puts a greater emphasis on figuring out the problem before you start coding; it seems to result with more concise code as a result. Your mileage may vary.
<commit_msg>Fix typo.<commit_after># Additional Notes

During the webcast, someone asked “For what sorts of projects is functional programming better suited than imperative programming?” I didn’t have a good answer at the moment, and noted that it’s something of a theological issue. I recommended that the person do a search for *functional vs. imperative programming* and see what people on both sides of the issue thought.

After some reflection, there is a better answer. Whether you are programming in functional or imperative style, it makes sense to separate the pure functions from those with side effects. Functions that are pure and don’t change global state are great for programs that use concurrency--you don’t have to worry about another process changing some value that you depend upon, because values are immutable. In imperative languages, you have to do some extra work to make sure that you keep things pure; in many functional languages that’s the default. For example, [Erlang](http://www.erlang.org/) is designed with those principles in mind to enable massive concurrency with literally tens of thousands of lightweight processes as the norm.

While I was writing [Études for ClojureScript](http://catcode.com/etudes-for-clojurescript/) I spent a lot of time figuring out the answer to one of the exercises, and I thought it would come out to hundreds of lines of code; it turned out to be only 40-some-odd lines. The functional style puts a greater emphasis on figuring out the problem before you start coding; it seems to result with more concise code as a result. Your mileage may vary.

{'fraction_non_alphanumeric': 0.03898939488459139, 'fraction_numerical': 0.0012476606363069245, 'mean_word_length': 4.676106194690266, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6468165', 'n_tokens_mistral': 733, 'n_tokens_neox': 702, 'n_words': 503}