<story><title>Building a new functional programming language</title><url>https://www.onebigfluke.com/2023/03/a-new-functional-programming-language.html</url></story><parent_chain><item><author>PaulDavisThe1st</author><text>I&amp;#x27;ve been programming for 35 years or more, and I&amp;#x27;ve yet to come across situations where the hard problem was &lt;i&gt;the language&lt;/i&gt;.&lt;p&gt;Sure, there are situations where I&amp;#x27;ve been grateful for the ability to use Python (because everything is so easy), or Perl (because sometimes its the right tool for the job) or Lisp (because its slippery fluidity just feels right) rather than the C&amp;#x2F;C++ that I&amp;#x27;ve generally used during that time.&lt;p&gt;But the hard problems I&amp;#x27;ve faced writing code would (almost?) never be made easier by using functional programming, or Rust, or Go or Swift or Brainfuck. The problems are hard because the problems are hard, and typically for me over the last 23+ years, it has been the combination of generically tough programming problems with performance requirements that ultimately make the choice of language mostly irrelevant.&lt;p&gt;Sure, someone could offer me a thread-safe sparse integer-to-integer mapping container in another language, but then I have to wonder about what design assumptions were made and how performant it is, and if the language was clearly created to prevent me from ever doing such things myself, then I&amp;#x27;m going to be deeply suspicious from the outset that it could possibly have my (coding) interests at heart.&lt;p&gt;I understand that I&amp;#x27;m not the typical programmer these days, and I don&amp;#x27;t work on entirely typical problems, but I can&amp;#x27;t help but feel that sometimes the focus on &amp;quot;languages to help programmers&amp;quot; comes from programmers who just don&amp;#x27;t enjoy their work enough and&amp;#x2F;or don&amp;#x27;t have enough to do.</text></item></parent_chain><comment><author>Chris_Newton</author><text>&lt;i&gt;I&amp;#x27;ve been programming for 35 years or more, and I&amp;#x27;ve yet to come across situations where the hard problem was&lt;/i&gt; the language.&lt;p&gt;The hardest problem is usually something else, but IME some languages make it much easier to solve a given hard problem than others. Some languages are qualitatively safer. Some languages are much more expressive, in the sense that I can implement my solution with far less code&amp;#x2F;time&amp;#x2F;cost without compromising anywhere else.&lt;p&gt;There is a difference between whether I can solve a problem and how efficiently and pleasantly I can solve a problem. I find choice of language rarely affects the former but often profoundly affects the latter.</text></comment>
<story><title>Building a new functional programming language</title><url>https://www.onebigfluke.com/2023/03/a-new-functional-programming-language.html</url></story><parent_chain><item><author>PaulDavisThe1st</author><text>I&amp;#x27;ve been programming for 35 years or more, and I&amp;#x27;ve yet to come across situations where the hard problem was &lt;i&gt;the language&lt;/i&gt;.&lt;p&gt;Sure, there are situations where I&amp;#x27;ve been grateful for the ability to use Python (because everything is so easy), or Perl (because sometimes its the right tool for the job) or Lisp (because its slippery fluidity just feels right) rather than the C&amp;#x2F;C++ that I&amp;#x27;ve generally used during that time.&lt;p&gt;But the hard problems I&amp;#x27;ve faced writing code would (almost?) never be made easier by using functional programming, or Rust, or Go or Swift or Brainfuck. The problems are hard because the problems are hard, and typically for me over the last 23+ years, it has been the combination of generically tough programming problems with performance requirements that ultimately make the choice of language mostly irrelevant.&lt;p&gt;Sure, someone could offer me a thread-safe sparse integer-to-integer mapping container in another language, but then I have to wonder about what design assumptions were made and how performant it is, and if the language was clearly created to prevent me from ever doing such things myself, then I&amp;#x27;m going to be deeply suspicious from the outset that it could possibly have my (coding) interests at heart.&lt;p&gt;I understand that I&amp;#x27;m not the typical programmer these days, and I don&amp;#x27;t work on entirely typical problems, but I can&amp;#x27;t help but feel that sometimes the focus on &amp;quot;languages to help programmers&amp;quot; comes from programmers who just don&amp;#x27;t enjoy their work enough and&amp;#x2F;or don&amp;#x27;t have enough to do.</text></item></parent_chain><comment><author>bslatkin</author><text>I love to swing a hammer as much as the next programmer. But if you offer me a nail gun, even with slightly lower precision, I will happily use it the majority of the time and revert to my hand tools when it&amp;#x27;s most appropriate. This is about developing force multipliers and producing leverage, not avoiding the craft.</text></comment>