<story><title>The combined power of F# and C#</title><url>https://steven-giesel.com/blogPost/2f70d926-ec92-4dfe-b278-18f78078253d</url></story><parent_chain><item><author>michaelteter</author><text>Functional core, imperative shell.  This seems to be a good approach, especially when you push pretty hard to stuff as much as possible into the functional core.&lt;p&gt;Writing tests is much easier and requires much less code, and bugs are much easier to track down (since you have less surface area of &amp;quot;what might have modified this object I now hold?&amp;quot;).&lt;p&gt;Since a functional approach also goes well with single-responsibility-principle and composability, you can end up with multiple times more actual functions.  They&amp;#x27;re all (ideally) very conceptually simple, but the larger number of more specialized functions means you have to work a lot harder on choosing meaningful names.  And to write meaningful names of specific functions, you can end up with some quite long names.  This is actually quite ok as it makes things much more readable, but some people have some strong negative reactions to seeing 4-6 word function names.  But at least in this case (Java being the most famous counter scenario) each function probably has more real value as it&amp;#x27;s not just OO layer artefacts.</text></item></parent_chain><comment><author>gugagore</author><text>One thing that I have seen in the Julia ecosystem, where multiple dispatch is pervasive, is that function names can get away with only being verbs. Without dispatch, you often see an approximation by baking in (Hungarian notation) the name of a type into the function.&lt;p&gt;This is most clearly seen with conversation functions between types defined in different libraries. A collection class might have a method like &amp;quot;from_Array&amp;quot;.</text></comment>
<story><title>The combined power of F# and C#</title><url>https://steven-giesel.com/blogPost/2f70d926-ec92-4dfe-b278-18f78078253d</url></story><parent_chain><item><author>michaelteter</author><text>Functional core, imperative shell.  This seems to be a good approach, especially when you push pretty hard to stuff as much as possible into the functional core.&lt;p&gt;Writing tests is much easier and requires much less code, and bugs are much easier to track down (since you have less surface area of &amp;quot;what might have modified this object I now hold?&amp;quot;).&lt;p&gt;Since a functional approach also goes well with single-responsibility-principle and composability, you can end up with multiple times more actual functions.  They&amp;#x27;re all (ideally) very conceptually simple, but the larger number of more specialized functions means you have to work a lot harder on choosing meaningful names.  And to write meaningful names of specific functions, you can end up with some quite long names.  This is actually quite ok as it makes things much more readable, but some people have some strong negative reactions to seeing 4-6 word function names.  But at least in this case (Java being the most famous counter scenario) each function probably has more real value as it&amp;#x27;s not just OO layer artefacts.</text></item></parent_chain><comment><author>bob1029</author><text>&amp;gt; Functional core, imperative shell.&lt;p&gt;You can find this pattern in a lot of places if you are a little bit flexible with your definition of &amp;quot;functional&amp;quot;.&lt;p&gt;For example, why would we not consider some combination like SQL and PHP to be hinting at this exact same kind of archetype? You&amp;#x27;ve got a crusty outer shell of yucky hackarounds (PHP) that talks to this (ideally) well-normalized &amp;amp; clean data store (SQL). Assuming you &amp;quot;stuff as much as possible&amp;quot; into core part of the solution, you could swap the outer shell for anything you desire without much headache.</text></comment>