Cold Showers

&gt; Benchmarking cutting-edge graph-processing algorithms running on 128-core clusters against a single-threaded 2014 Macbook Pro. The laptop consistently wins, sometimes by an order of magnitude.<p>LOL, this hits close to home. My company had a modeling specific VM set up to run our predictive modeling pipelines. Typical pipeline is about 50,000 to 5 million rows of training data. At best, using an expensive VM, we managed to get 2x training speed from lightgbm on the VM vs my personal work laptop. We tried GPU boxes, hyper threaded machines, you name it. At the end of the day, we decided to let our data scientists just run models locally.

&gt; Static Typing reduces bugs.<p>At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It&#x27;s a tool for thinking and communicating.

&gt; Hype: &quot;Static Typing reduces bugs.&quot;<p>It’s only hype because it’s imprecisely stated. Static type systems make entire classes of bugs impossible at runtime. The stronger (read less permissive) the type system, the more classes of bugs cannot occur.

&gt; Hype: &quot;Identifiers should be self-documenting! Use full names, not abbreviations.&quot;<p>&gt; Shower: Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging.<p>That&#x27;s a very weird take on the statement. The downside of using abbreviations is probably dominated by the difficulty of fixing the bug. The problem I have with abbreviations is that they just become another thing that you have to spend your mental resources on. “What is this variable exactly? Oh, I see.” is just wasted effort.

&gt; Static Typing reduces bugs.<p>This matches my experience. People say otherwise might need to put more effort on writing better tests.<p>That said static typing usually catch minor problems like typo faster. But for dynamic typing it&#x27;s going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it&#x27;s a tradeoff.<p>My favorite approach is the mixed approach like TypeScript:<p>1. Faster feedback loops: Usually statically typed languages compiles slower thus slower feedback loops. But languages like TypeScript can skip type check and emit only to the runtime, making test watcher very fast - as soon as I hitting Cmd-S I can see the result.<p>2. Optional typing: Sometimes a function signature is going to be 10x larger than the body, which is really a hassle. Sometimes I just skip them, or skip typing module private functions as long as it&#x27;s properly tested.

Hype: Cold showers are good for you (good stress)<p>Shower: keybored, your shower is not cold enough to induce stress and you are too lazy to modify the showering experience in any way<p>Caveats: Other people may be anti-lazy enough to modify the showering experience<p>Notes: Check yourself

For me the biggest advantage of static typing is that it allows to safely refactor code. Without it even with extensive unit test coverage refactoring often is just not an option.

Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23935943" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23935943</a>

IMO a lot of truths in programming are not amenable to &quot;scientific studies&quot;.<p>Static typing is objectively better than dynamic typing for the vast majority of cases, but you can&#x27;t capture this in a scientific experiment or study.<p>The only thing you can do is find people who are similarly experienced, break them up into groups (n=1 is also ok) and ask them to complete a specific project, and see how much time it takes. But even then there are so many caveats. The experiment must be set up such that the presense of extensive library support for a particular task is not a confounding factor. There&#x27;s also the open question of how do you measure these people&#x27;s skills before the experiment begins?

&gt;Hype: &quot;Static Typing reduces bugs.&quot;<p>Oof, that one is a huge can of worms.

Where I work, static analysis has found quite a few bugs. It&#x27;s primarily through CodeQL and I think it&#x27;s greatest strength is how flexible it is. Our code base is weird (it&#x27;s C++ and has its own memory allocators and schedulers).

&gt; Hype: &quot;Identifiers should be self-documenting! Use full names, not abbreviations.&quot;<p>Most names aren&#x27;t particularly good - especially when someone tries to make them sound like a full sentence. My experience is that at around four words they start getting less accurate. At seven I would probably read more from an interpretive dance about the function in question.

&gt; Hype: &quot;We need big data systems to handle big data.&quot;<p>I do not get this one. It&#x27;s incorrect by definition: &quot;Big data refers to data sets that are too large or complex to be dealt with by traditional data-processing application software. &quot;<p>If you do not need a big data system, then it&#x27;s not big data.

&gt; Hype: &quot;Static Typing reduces bugs.&quot;<p>&gt; Shower: A review of all the available literature (up to 2014), showing that the solid research is inconclusive, while the conclusive research had methodological issues.<p>Which research is supposedly solid?<p>Skimming through the article it seems to me that proper controlled study would be prohibitively expensive and that no controlled study comes close to real world conditions of multiple people developing and maintaining a larger codebase. Conditions, where supposedly (according to anecdotal evidence) static typing would make a notable difference.

Was hoping to see, and would like to see, one of these on Functional Programming.<p>It’s been an immensely enjoyable experience getting into it, but with a non trivial startup cost.<p>My team has generally adopted it (at least to some degree, and in a language which half supports these patterns), but I’m sure this coding style erodes in favor of something that feels more imperative when we move on.

&gt; Compared to other languages, Go&#x27;s concurrency system of goroutines and channels is easier to understand, easier to use ...<p>True and not a hype: Compared to other languages, Go has a runtime and built-in concurrency primitives that makes it easier to write concurrent code.<p>&gt; and is less prone to bugs and memory leaks.<p>Who is actually claiming this? I&#x27;ve got a collection of good Go resources and nowhere something like this is stated. In contrast, some actually make it very clear to be very careful when sharing memory or actually better no sharing memory at all.<p>Concurrency is conceptually hard in Java, C#, Javascript, Python, C, C++ ... there&#x27;s no reason to bully Go.<p>Rust makes the claim of &quot;fearless concurrency&quot; and the compiler indeed saves us from race conditions, but those are not the only concurrency related bugs, e.g. deadlocks are very well possible in Rust. Therefore Rust would be a proper candidate on this &quot;Cold Showers&quot; list.

&gt; Hype: &quot;We should develop software using Agile.&quot;<p><a href="https:&#x2F;&#x2F;www.agitma.nl&#x2F;wp&#x2F;wp-content&#x2F;uploads&#x2F;2016&#x2F;07&#x2F;Dilbert_Training_Agile_Programming.png" rel="nofollow">https:&#x2F;&#x2F;www.agitma.nl&#x2F;wp&#x2F;wp-content&#x2F;uploads&#x2F;2016&#x2F;07&#x2F;Dilbert_...</a>

Luke warm showers to me - these points need good sources to back them up to be really cold.

Overall a questionable list of unproven claims. E.g.:<p>&gt; Hype: &quot;Static Typing reduces bugs.&quot;<p>Just because the author has not found proper research proving it doesn&#x27;t mean it&#x27;s false.<p>A great type system with sum types prevents tons of bugs. I wonder how anyone can question this.<p>&gt; Hype: &quot;Identifiers should be self-documenting! Use full names, not abbreviations.&quot;<p>Same as above. To fix bugs you need to read and understand the code. Not having to map abbreviations to your mental model reduces overhead. I&#x27;ve seen code bases where u was used as an abbreviation for user and users in different methods. That was not a fun code base.

&gt; &quot;Static Typing reduces bugs.&quot;<p>I would argue that static typing reduces bug complexity&#x2F;creep. Mainly from working in environments without proper testing during the js days, TS was rough at first, but did help.

I wish someone would do one of these for life in general.

I am particularly surprised by the agile statements. I wonder if this flies in the face of the &quot;state of DevOps&quot; reports some people wave around.

Where&#x27;s the cold shower for this article?

Title should be “Cold Showers for Straw-man Arguments”.

Any cold showers for unit tests?

Hype: Your friend says, &quot;Good morning!&quot;<p>Shower: Unfortunately, there is no conclusive peer-reviewed evidence that it is, in fact, a good morning. A randomized trial found that many mornings are bad.<p>Caveats: Only applies to mornings. No rigorous paper exists for evenings, so this remains an unknown.

I&#x27;ll admit I didn&#x27;t read these articles. However, all of these reek of:<p>Claim! Thing good!<p>Wait! Thing has downsides!<p>It&#x27;s not thorough comparison, it&#x27;s just showing that everything in life has tradeoffs, which is obvious.

Formal methods has a lot of practical application but the tools and techniques are very inaccessible to the average SME. We need better tools. For example, here is a demo of how to use an SMT solver to write better system requirements: <a href="http:&#x2F;&#x2F;slra1.baselines.cloud&#x2F;" rel="nofollow">http:&#x2F;&#x2F;slra1.baselines.cloud&#x2F;</a>