<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>sparkie</author><text>&amp;gt; I&amp;#x27;d like to read people treating languages and platforms as tools and not as cargo cults. You don&amp;#x27;t read carpenters writing they&amp;#x27;ll ditch hammers for screwdrivers because the old cupboard they are fixing uses nails. You read carpenters debating the pros and cons of using hammers versus screwdrivers. And you read better carpenters that debate how cupboards are designed, because it is ultimately more important than whether they are glued, nailed or screwed.&lt;p&gt;The problem with this carpenter analogy is that it simply doesn&amp;#x27;t scale - a carpenter is not going to build a skyscraper. To build skyscrapers we need &lt;i&gt;engineering&lt;/i&gt; - the practical application of science - something which is completely missing from our field. We call ourselves &lt;i&gt;software engineers&lt;/i&gt;, but we&amp;#x27;re really &lt;i&gt;software masons&lt;/i&gt; - we can do good work in small quantities, but we&amp;#x27;re terrible and building big structures - which is where many of our software problems lie.&lt;p&gt;You can&amp;#x27;t build a house on some land, and later turn it into a skyscraper either - because the foundations are perhaps the most vital part of the structure - they need to be designed with some knowledge of the size, shape and mass of the structure they intend to support. The approach taken in software development is the tacking on of new systems - building structures equivalent to say, the Kowloon walled city (unsightly and unstable).&lt;p&gt;To do engineering and science, we need math - and we have no sound way of modeling imperative languages&amp;#x2F;programs in ways that makes them useful as mathematical concepts. FP &lt;i&gt;is&lt;/i&gt; math - so building up concepts in these languages is providing a richer set of math objects and abstractions which we can later use to build our large structures. Using FP doesn&amp;#x27;t mean we need to abandon imperative coding - it just means we should clearly mark the effects of such imperative chunks of code, so we can treat them mathematically.&lt;p&gt;Carpenters are still relevant in the construction of skyscrapers - but their responsibilities are only a small part of it - they&amp;#x27;re given clearly defined boundaries of when and where they should be working. This is really how we should be doing software - we need engineers and architects to build structures, using science and math, then assigning isolated environments for the &amp;quot;masons&amp;quot; (e.g, junior programmers) to work in - in such a way that a mistake by a junior programmer cannot bring the entire skyscraper crashing down. (Turns out this was understood in the 70s, because Unix pipes and processes are still the best approach we have to this day).&lt;p&gt;Of course, this doesn&amp;#x27;t mean it should be &amp;quot;my Coq is better than your Twelf&amp;quot; - we need to separate the math from the textual representations and even the execution models.</text><parent_chain><item><author>sklivvz1971</author><text>Programming is hard. A few years back, in the 90&amp;#x27;s when most of the code in my field was still mostly structured, and bad at that, a lot of people were saying that OOP would sort it out. I was skeptical, not because I&amp;#x27;m resistant to change, but because it was obvious to me that doing OOP right was (and is) very hard. Not that structured programming was easy.&lt;p&gt;Fast forward to today: programming is still hard, and actually it probably got a lot harder. OOP did not sort it out. Most of the code in my field is object-oriented, and bad at that. A lot of people are saying that FP will sort it out. I am skeptical, not because I&amp;#x27;m resistant to change, but because it is obvious to me that doing FP right is (and will be) very hard. Not that object oriented programming is easy.&lt;p&gt;Am I alone in thinking that fast forward a few years, once there is enough rotten FP code written, we will be reading people ditching FP because it&amp;#x27;s the root of all evil?&lt;p&gt;The facts are that programming is hard. Working with legacy code is hard. Learning a paradigm well enough so the code you write in it is not total crap is very hard, and requires years of practical experience if you are proficient at another paradigm, let alone if you simply skimmed a paradigm and moved away because it was too hard...&lt;p&gt;It&amp;#x27;s great that people want to move on from single-platform, single-paradigm monocultures, with one caveat: breadth without depth is shallowness.&lt;p&gt;I&amp;#x27;d like to read people treating languages and platforms as tools and not as cargo cults. You don&amp;#x27;t read carpenters writing they&amp;#x27;ll ditch hammers for screwdrivers because the old cupboard they are fixing uses nails. You read carpenters debating the pros and cons of using hammers versus screwdrivers. And you read better carpenters that debate how cupboards are designed, because it is ultimately more important than whether they are glued, nailed or screwed.</text></item></parent_chain></comment><story><title>Sick of Ruby, dynamic typing, side effects, and object-oriented programming</title><url>https://blog.abevoelker.com/sick-of-ruby-dynamic-typing-side-effects-object-oriented-programming/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>eru</author><text>Some changes are real progress:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  - automatic memory management by default
  - testing by default
  - distributed version control by default
&lt;/code&gt;&lt;/pre&gt;
All of these make you more productive in a typical project.  (And should be turned off when not, that&amp;#x27;s why I say, by default.)  I suggest that the following are also unalloyed good, and will make their way into more and more languages over time:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  - functions as first class values
  - immutability by default &amp;#x2F; copy-on-write semantics by default
  - side-effects only possible when declared (eg IO Monad)
  - powerful static typing by default
&lt;/code&gt;&lt;/pre&gt;
(We already see in eg git and some file systems that even when the implementation is imperative, immutability makes concepts simpler.  Immutability by default virtually requires automatic memory management.)</text><parent_chain><item><author>sklivvz1971</author><text>Programming is hard. A few years back, in the 90&amp;#x27;s when most of the code in my field was still mostly structured, and bad at that, a lot of people were saying that OOP would sort it out. I was skeptical, not because I&amp;#x27;m resistant to change, but because it was obvious to me that doing OOP right was (and is) very hard. Not that structured programming was easy.&lt;p&gt;Fast forward to today: programming is still hard, and actually it probably got a lot harder. OOP did not sort it out. Most of the code in my field is object-oriented, and bad at that. A lot of people are saying that FP will sort it out. I am skeptical, not because I&amp;#x27;m resistant to change, but because it is obvious to me that doing FP right is (and will be) very hard. Not that object oriented programming is easy.&lt;p&gt;Am I alone in thinking that fast forward a few years, once there is enough rotten FP code written, we will be reading people ditching FP because it&amp;#x27;s the root of all evil?&lt;p&gt;The facts are that programming is hard. Working with legacy code is hard. Learning a paradigm well enough so the code you write in it is not total crap is very hard, and requires years of practical experience if you are proficient at another paradigm, let alone if you simply skimmed a paradigm and moved away because it was too hard...&lt;p&gt;It&amp;#x27;s great that people want to move on from single-platform, single-paradigm monocultures, with one caveat: breadth without depth is shallowness.&lt;p&gt;I&amp;#x27;d like to read people treating languages and platforms as tools and not as cargo cults. You don&amp;#x27;t read carpenters writing they&amp;#x27;ll ditch hammers for screwdrivers because the old cupboard they are fixing uses nails. You read carpenters debating the pros and cons of using hammers versus screwdrivers. And you read better carpenters that debate how cupboards are designed, because it is ultimately more important than whether they are glued, nailed or screwed.</text></item></parent_chain></comment><story><title>Sick of Ruby, dynamic typing, side effects, and object-oriented programming</title><url>https://blog.abevoelker.com/sick-of-ruby-dynamic-typing-side-effects-object-oriented-programming/</url></story>