89 ms·

Cold Showers

629 points by blopeur 4y ago

moralestapia 4y ago
>Hype: "Static Typing reduces bugs." Oof, that one is a huge can of worms.
- leononame 4y ago
  This one definitely hits close to home. By empirical measure, static typing reduces bugs, but maybe it's just me. I definitely like the comfort of trusting my types. My only experience with dynamic typing is really node, which improves a bit with typescript. But I'm still extremely wary of it because it doesn't give you runtime guarantees. It irks me a lot that you can just do JSON.parse, declare any type on it and call it a day. I firmly believe that static typing increases code readability and catches low-hanging fruit, but I'm going to have to sieve through that research it seems.
  - chrisseaton 4y ago
    > By empirical measure, static typing reduces bugs As the article says, this does not appear to be actually true when you go and check.
    - tluyben2 4y ago
      Well, how is this measured? My experience working over 3 decades with large teams also says this is so (static typing does prevent bugs) but that is not science. How do they measure this 'when you go and check'? I am really curious as I don't even understand how people make large systems without static typing and all massively complex systems that I personally have worked with that run for decades transacting billions$ etc without flaws are all statically typed.
      - chrisseaton 4y ago
        We don't seem to be able to measure it, despite people trying several wacky approaches. Either that means it's hard to measure, or it means the effect is not actually there. Either way, this means that we cannot say that static typing reduces bugs. > all massively complex systems that I personally have worked with that run for decades transacting billions$ etc without flaws are all statically typed Did you try building the same systems without static typing as well and see what the difference was? Or are you just saying that you built systems with static typing and they were successful? That tells you nothing about static typing except that it doesn't prevent successful programs, which is a very weak thing to be able to claim! Lots of people, like you, think static typing is very important for developing software, but when someone challenges this and says 'can you actually show that?' they have never been able to. At some point you need to reconsider if it's actually the case.
        tluyben2 4y ago
        I do reconsider it all the time; we only have short lives and I cannot build a lot large systems in my life. So that is why I asked if how it is measured. I see that my teams are more effective with static typing, but that also is my management as I, as I said, cannot really imagine writing large systems in not statically typed systems. I write a lot of scheme and k and bash and wrote a lot of tcl and Perl but never could get to scale like I can with statically compiled languages. I lean more to dependently typed languages than dynamic as I simply saw only misery, but, again, this is not saying anything, it is just my experience. I am a bit afraid though, because there is no clear measurement, it is just anyone’s experience. Edit; which actually would be fine; if it works for you and your team, company and business goals…
        chrisseaton 4y ago
        > I see that my teams are more effective with static typing If you think you really can see evidence for it then I'd encourage you to write up a paper and submit it for peer review. I guess when you sat down to write it you'd suddenly realise that you don't actually have any hard evidence. > cannot really imagine writing large systems in not statically typed systems Ok but lack of imagination is not science. Some people cannot imagine a spherical Earth, but that doesn't make it untrue. For example I work on a system in a dynamically typed language (Ruby) that successfully handles tens of billions a year, so we know that it is possible. (We are adding optional static typing to it, but it was written without it.)
      - slaymaker1907 4y ago
        A lot of the studies have been problematic because they look at toy problems (like leetcode problems). Static typing really starts to show its value in large projects. One huge project I'm aware of that uses a lot of python is the Sims 4 which uses it for a lot of the game engine and mods.
        bjourne 4y ago
        Your argument is analogous to the one used by homeopaths and those believing in telekinesis. "There is an effect but it disappears in a laboratory setting, but it's still there!"
        seoaeu 4y ago
        All effects disappear if you don’t use strong enough measurement techniques
    - laurencerowe 4y ago
      The article mentions the literature review is from 2014. Many older statically typed languages (Java/C/etc.) don’t enforce null safety. Tony Hoare called it his ‘billion dollar mistake’. https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... Thankfully more modern type systems (Swift/Kotlin/F#/Rust/TypeScript/etc.) now do, hugely reducing the likelihood of runtime errors. As a mostly dynamic language developer I never saw the benefit of Java-like static typing but more modern type systems seem much more useful.
      - chrisseaton 4y ago
        > hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.
        slaymaker1907 4y ago
        Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
        chrisseaton 4y ago
        There's no evidence of the absence of the easter bunny, but we are happy that he probably doesn't exist since there's an absence of evidence. Write up your experience with null safety as a paper and submit it, because this would be a world-first if you can demonstrate it.
        wtetzner 4y ago
        I’m not really sure what you’re arguing. You seem to be saying that since we can’t prove that one approach is better than the other, we should just assume they’re all equal. We do have proofs that certain classes of bugs are impossible given a certain type system.
        4y ago
    - fizzynut 4y ago
      I am curious for why people say this as in my experience when writing a function in a dynamic language that takes a variable as a parameter: The function will generally only work on a subset of types for given variable. If I don't check the type of the variable in the function, the function will not behave as you might expect, e.g. silently fail or crash. If I do check for every possible type for a given variable: I may not have a good way of handling certain types being passed in, I may be forced to either log something out, create a run time crash or even have the function silently fail. All 3 are bad run time behaviours. If I am checking for every type in the functions, then using static typing would cause the failure at compile time so the bugs could never exist, but also being significantly less verbose than the dynamic language equivalent.
      - chrisseaton 4y ago
        > I am curious for why people say this I'm saying it because it's a fact. I'm not giving you an opinion - it's a falsifiable fact that you can verify for yourself - we have as an industry not been able to give any good evidence for static typing reducing bugs that has stood up to peer review. You're presenting arguments for why you think there should be evidence... but when people look there isn't actually any evidence. Maybe your arguments are not sound for some reason that we don't understand, or maybe we are unable to measure the effect.
        fizzynut 4y ago
        Well, this paper found that a conservative underestimate of 15% of bugs would be saved through static typing: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/gao2017javascript.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I'm not sure what evidence your fact is based on, feel free to present some evidence for it.
        chrisseaton 4y ago
        > I'm not sure what evidence your fact is based on, feel free to present some evidence for it. The linked meta-study in the article we're commenting on. https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ "under the specific set of circumstances described in the studies, any effect, if it exists at all, is small" And this question has generated the most rebuttals and retractions I've ever seen for flawed studies in computer science - it's notorious. Remember this? https://dl.acm.org/doi/10.1145/3340571 https://dl.acm.org/doi/10.1145/3340571 > Well, this paper found that a conservative underestimate of 15% of bugs would be saved through static typing Yeah does look that one shows a larger effect and has not been rebutted or retracted. One positive measurement against many negative measurements.
    - quickthrower2 4y ago
      Interesting. I wonder what about software development that we do that you can prove scientifically then. Does planning a project mean faster delivery? Does thinking about architecture up front reduce refactors and technical debt. Does estimating lead to faster software development? There is a lot we have to decide without evidence in how we develop software. Maybe we just pick the things that feel right and make us happy.
      - moffkalast 4y ago
        > Does planning a project mean faster delivery? Does that plan include the client changing their mind 10 times before delivering? Or finding out that some approach doesn't work and that pivoting is needed halfway through? Likely depends on how smart the planning is. > Does estimating lead to faster software development? Unlikely, because engineers are then busy ass-pulling useless time figures over and over instead of actually working on the project. All of these points have high random factors attached to them regardless, so you'd need a pretty big sample to say what generally works best.
        quickthrower2 4y ago
        Yes I agree with you. My point is that almost everything we do in management if software teams and architecture decisions is a guess. We have to carry on regardless and make decisions. The nuance is what you do, why you do it and is there cultism or cargo cultism to the decisions.
    - deleted 4y ago
      [deleted]
  - rajin444 4y ago
    Thorough understanding of the problem and thorough testing prevent bugs. Static typing allows you to more succinctly express your thorough understanding of a problem, but it does not fix the root problem. Quality of life benefits are where static typing (and in some cases performance) really shines.
  - davnicwil 4y ago
    > It irks me a lot that you can just do JSON.parse, declare any type on it and call it a day You should look at zod [0], which validates data with inferred types based on the validation having passed, so you do have the guarantee of the type being correct at runtime. [0] https://zod.dev https://zod.dev
- almost_usual 4y ago
  I used to debate this but after learning Rust it’s undeniable.
  - ilikehurdles 4y ago
    I thought I wanted static typing until I started writing clojure.
    - christophilus 4y ago
      Clojure is the only dynamic language I’ve ever loved. It is in its own ballpark, really, though maybe Erlang or Elixir would win me over if I spent enough time with them.
      - ilikehurdles 4y ago
        I’ve actually been spending the last year with elixir professionally. I’m embracing some of it… I would love to see its pattern matching and annotations come over to clojure, and would make my clojure code even more “correct.” I don’t super fully “get” all of its message passing plumbing, and I don’t like the quality of its library ecosystem. But clojure’s REPL, babashka, and clojure.spec are sorely missed.
        christophilus 4y ago
        For me, after Clojure, I just get annoyed by every other language's special syntax.
    - almost_usual 4y ago
      I’m not smart enough to program quickly and correctly in Clojure. I think it follows the same ethos Rich Hickey has about unit testing being “guard rail driven development”. I watched him talk about this a decade ago at Strange Loop. To understand your whole program all the time at scale is probably something Rich Hickey is capable of but I definitely am not.
- agildehaus 4y ago
  Static typing makes refactoring easier. Your compiler can instantly tell you what you've broken. Bugs are reduced by monitoring, testing, and reducing how much code there is so there's less surface area (which also makes monitoring and testing easier). You reduce code by refactoring.
  - strager 4y ago
    > Your compiler can instantly tell you what you've broken. For some definition of "instant". I can often run my Python or JavaScript test suite faster than Haskell/GHC or Rust/rustc can type-check a module. And it can take a while to understand Haskell, Rust, or C++ error reports. (Of course, Python and JavaScript startup time and execution speed can hurt refactoring too. And AttributeError-s and random undefined-s aren't always easy to debug.)
    - elteto 4y ago
      Got it, you can be wrong faster!
    - wtetzner 4y ago
      I doubt you can run your Python or JavaScript test suit faster than the OCaml compiler could both typecheck and compile your code.
    - ReactiveJelly 4y ago
      How many hours do you, the human, have to spend maintaining the type-checking of that test suite?
  - strager 4y ago
    > Bugs are reduced by monitoring, testing, and reducing how much code there is so there's less surface area (which also makes monitoring and testing easier). > > You reduce code by refactoring. This is a great point. I wonder if there's a study on bugs-per-line-of-code, how this changes across project sizes, and whether refactoring changes bugs-per-line-of-code.
- ryanmarsh 4y ago
  You can pry typescript from my cold dead hands. All these “inconclusive” studies but has anyone ever tried a trial where 20 nearly identical teams tried implementing the same spec using a typed or untyped language? It’s inconclusive because a post hoc review of projects is going to be spurious at best.
- joeldo 4y ago
  Yeah, having worked with both typed and untyped languages (and on teams that have transitioned between these) it is hard to reconcile. There are so many variables involved that I see this being difficult to prove empirically, but anecdotally it doesn't ring true.
- wtetzner 4y ago
  Really, like everything, there’s nuance. E.g. not all type systems are equal, not all programmers are equally effective at taking advantage of the type system, etc.
- ttty 4y ago
  Refactor any js code to typescript. You’ll see how many bugs are discovered and how many wtfs!
keybored 4y ago
Hype: Cold showers are good for you (good stress) Shower: keybored, your shower is not cold enough to induce stress and you are too lazy to modify the showering experience in any way Caveats: Other people may be anti-lazy enough to modify the showering experience Notes: Check yourself
- number6 4y ago
  Most Times I can't bring myself to get into a cold shower. If I start warm I can cool down from there. Is there a way to start cold and go even colder?
  - Toine 4y ago
    Anecdotal, but for some reason, when I tell myself "It's just cold water", my fight or flight response instantly goes away.
    - wiether 4y ago
      "fight or flight" is how you nicknamed your balls? Because when I take a cold shower they do instantly go away!
  - soperj 4y ago
    It's pretty easy to start cold if you've just done a huge amount of cardio, otherwise there's nothing wrong with just turning off the hot water completely during a shower if you want a brief cold period.
  - keybored 4y ago
    I don’t think there’s anything wrong with starting warm and cooling down. The only thing that matters is that you can go cold enough for a decent amount of time.
    - readbeard 4y ago
      For me, there is some value in facing the cold water head-on in the morning ("Wow, this is going to be cold, but here goes!" Great way to start the day. I have to admit though, the cold water is not super cold here this time of year.
theIV 4y ago
Previous discussion: https://news.ycombinator.com/item?id=23935943 https://news.ycombinator.com/item?id=23935943
hourago 4y ago
> Hype: "We need big data systems to handle big data." I do not get this one. It's incorrect by definition: "Big data refers to data sets that are too large or complex to be dealt with by traditional data-processing application software. " If you do not need a big data system, then it's not big data.
- djmips 4y ago
  You may have answered your own question.
  - bilekas 4y ago
    The answer is in the data..
- jbjbjbjb 4y ago
  That definition assumes the code is reasonably performant or that they didn’t just begin on the cloud for whatever (often not well thought out) reason.
hyperhopper 4y ago
I'll admit I didn't read these articles. However, all of these reek of: Claim! Thing good! Wait! Thing has downsides! It's not thorough comparison, it's just showing that everything in life has tradeoffs, which is obvious.
- deleted 4y ago
  [deleted]
- martinhath 4y ago
  That's not what this is, and if you'd bothered to look for more than a second, you'd seen that too. All the claims listed are very concrete claims that are possible to falsify, unlike "Thing good!", and the research (which, admittedly isn't directly linked, so it might be hard to find what research they're referring to) shows that this is either not true, or that the research is inconclusive. It is important not to take these statements for granted if they cannot be shown to be true; that's simply cargo-culting.
- pvg 4y ago
  Not reading things is an excellent way to establish for yourself the tautological obviousness of everything.
CapmCrackaWaka 4y ago
> 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. 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.
- christophilus 4y ago
  I found the same thing when doing video transcoding. The VPSs were all woefully underpowered. Netcup bare metal (root servers) ended up getting pretty close and were by far the best bang for the buck of anything I found.
  - bilekas 4y ago
    Curious what the setup of VPS' was and why you would expect better than real hardware, video transcoding is quite a beast from what I remember and I just can't imagine there's a VPS solution that expects to keep up
    - otterley 4y ago
      The Intel Xeon processors that cloud providers typically use don't have the Intel Quick Sync core that provides hardware A/V encoding/decoding on typical desktop/laptop CPU SKUs. So the software has to fall back to CPU-based codecs, which are much slower. AWS EC2 has a VT1 instance family that enables high-speed A/V encoding via a Xilinx media accelerator card.
      - dataflow 4y ago
        IIRC Quick Sync encoded with poorer quality than software; is that not still the case?
bilekas 4y ago
> "Static Typing reduces bugs." I would argue that static typing reduces bug complexity/creep. Mainly from working in environments without proper testing during the js days, TS was rough at first, but did help.
- christophilus 4y ago
  I don’t know about static types reducing complexity. I’d argue the opposite. Static types allow you to do things that you wouldn’t want to attempt with dynamic types due to the difficulty of reasoning. At least for me, I try to keep my dynamic systems simple because I don’t have a compiler watching my back.
  - bilekas 4y ago
    Complexity in relation to tracking down the bug of course* Interesting though, I would say that dynamic typing allows you to shoot yourself in the foot a bit more, especially over teams who might need to interact with source later. I agree with you to keep the dynamic ones (that are inevitable) simple though.
cloogshicer 4y ago
> Static Typing reduces bugs. 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's a tool for thinking and communicating.
- mlyle 4y ago
  And that's covered right there by the caveats.
- glouwbug 4y ago
  Until the types don't match the execution model... see: python type hints
  - slaymaker1907 4y ago
    I find that is a far less common problem than the documentation being wrong. Even if someone doesn't add documentation for some library, static types provide a lot more insight into how it works than dynamic languages (Racket style contracts are even better since they can check way more than static types while still working in a first class way with docs).
  - HL33tibCe7 4y ago
    That isn’t static typing That’s a dynamic typed language with comments
    - OJFord 4y ago
      They can be consumed by static analysis tooling, which assuming properly configured etc. makes it sort of 'dynamically typed language with the guarantees of a statically typed one', at least so far as the hints are complete.
    - semiquaver 4y ago
      Most statically typed languages compile down to object code which runs in one of the most dynamic runtime environments imaginable. What are the types in the source code but “comments”?
slaymaker1907 4y ago
Where I work, static analysis has found quite a few bugs. It's primarily through CodeQL and I think it's greatest strength is how flexible it is. Our code base is weird (it's C++ and has its own memory allocators and schedulers).
riazrizvi 4y ago
Luke warm showers to me - these points need good sources to back them up to be really cold.
fallingmeat 4y ago
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: http://slra1.baselines.cloud/ http://slra1.baselines.cloud/
ryanmarsh 4y ago
Title should be “Cold Showers for Straw-man Arguments”.
aranchelk 4y ago
> Hype: "Static Typing reduces bugs." 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.
- moffkalast 4y ago
  On the other hand it increases development time and makes modifications and new features much harder to implement. If you took it to the extreme, you could also mathematically prove your code is correct for every input variable. Everything's a trade-off, the question is which approach is best for your application. Your average website doesn't warrant as much rigor as a Mars rover.
  - forrestthewoods 4y ago
    Hard disagree. Dynamic typing only increases development speed for the first few thousands lines of a solo programmer project. After that it is, in my personal experience, a significant drag on development speed. Furthermore, dynamic typing makes modifications and new features significantly harder to write. Turning compile-time bugs into runtime bugs is a catastrophic decrease in development speed. That’s my personal experience at least. YMMV.
    - moffkalast 4y ago
      taps temple That's why you keep code encapsulated as much as possible in separate files/classes up to like a thousand lines. Any more will be unreadable anyway. > dynamic typing makes modifications and new features significantly harder to write Depends on what you're doing I suppose. Adding a parameter to an object? With dynamic typing you just add it to the object in literally any location, no issues. With static typing you might just need to refactor half your codebase if you have lots of interfaces. Have fun resolving merge conflicts with your team. Not only that, but (in Java as an example) serialization codes for objects will change unless you planned for that previously (you didn't), making old objects impossible to load. A completely new bug that's created solely by static types. And it's not the only one.
_0w8t 4y ago
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.
- woojoo666 4y ago
  So many people in the thread saying this. But in my experience refactoring large code bases in both Java and Javascript, it's roughly the same. Ultimately the real answer will have to come from a peer reviewed study, because as the post suggests, these sorts of things are not as intuitive as people think
  - greymalik 4y ago
    Does your JavaScript require higher test coverage to achieve the same level of safety?
    - woojoo666 4y ago
      Hard to measure, the javascript I worked with was mostly front-end, which is harder to write automated tests for. Not impossible, but the higher friction naturally leads to less tests, especially given how frequent the front-end changes. "Level of safety" would also need better quantification. Something that a peer-reviewed study would be better suited for
  - _0w8t 4y ago
    I have done multiple times both refactoring of untyping JS and JS fully typed with Flow. With the latter after the Flow compiler stopped complaining one can expect things to work. With the former despite extensive tests sometimes it took weeks to fix bugs caused by the refactoring. Granted this is personal experience and I may be simply not careful enough to do untyped refactoring, but few people I talked about that shared the experience.
  - ncmncm 4y ago
    Java does not have anything like strong typing. Likewise C. Results comparing to Java or C are intrinsically useless and actively misleading. Studies insisting static typing has no effect always assume the runtime-typed program is less buggy than it really is.
dfee 4y ago
Was hoping to see, and would like to see, one of these on Functional Programming. It’s been an immensely enjoyable experience getting into it, but with a non trivial startup cost. 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.
xwdv 4y ago
Any cold showers for unit tests?
moffkalast 4y ago
> Hype: "We should develop software using Agile." https://www.agitma.nl/wp/wp-content/uploads/2016/07/Dilbert_Training_Agile_Programming.png https://www.agitma.nl/wp/wp-content/uploads/2016/07/Dilbert_...
shisisms 4y ago
I wish someone would do one of these for life in general.
laserlight 4y ago
> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." > 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. That'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.
- blueprint 4y ago
  How new devs modify the code depends on its names too. So does how we further consume code modules. Architecture and system complexity are virtually emergent from names. So I agree. Kind of a nonsense one.
- WalterBright 4y ago
  People nearly always gravitate towards abbreviations in natural language. The more a word is used, the more likely it gets shortened. LA for Los Angeles, Frisco for San Francisco, Vicki for Victoria, Jay for Jason, Dub for George W Bush, Doozy for Duesenberg, and on and on. Why should programming be different?
  - SmooL 4y ago
    Because abbreviations are nice when there's a shared context that is perpetually "in memory" - I don't have to think to know what LA stands for. However, that is not the case when debugging. It is almost certainly the case for the person who wrote the code originally, but it is certainly not the case for the next person to come read it afterwards. IMO code is meant to be read, so I try to never use abbreviations (other than e.g. _i_ as a for loop index, which, given it's pervasive use, falls under the category of "shared context").
    - ReactiveJelly 4y ago
      I read somewhere, "The length of a variable name should be proportional to the size of its scope". Usually I don't have long loop bodies, so if the loop body fits in 24 lines, `i` is perfect for the index. If I'm locking a mutex, doing something, and quickly unlocking it, `l` for the lock guard is fine. But if it won't fit on screen, it needs a longer name. And if there's something like a top-level `App` struct, I just call it `a` because its scope is really just `main`, even though its _lifetime_ may be the entire process.
Tade0 4y ago
> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." Most names aren'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.
- charlieflowers 4y ago
  And a java observerFactoryVisitorInstanceBuilder is like a total nerd with no rythym trying to dance to hip hop
hsn915 4y ago
IMO a lot of truths in programming are not amenable to "scientific studies". Static typing is objectively better than dynamic typing for the vast majority of cases, but you can't capture this in a scientific experiment or study. 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's also the open question of how do you measure these people's skills before the experiment begins?
- ReactiveJelly 4y ago
  I present "The emotional argument for static typing". Static typing is good because dynamic typing measurably makes me sad. Therefore I want the company to use static typing.
  - H8crilA 4y ago
    This is actually the case, lol. Whether it is the extra cognitive load of not always knowing the types, or whether it actually makes things go faster - IDK, but I definitely want the types.
  - hsn915 4y ago
    This but unironically. Your feelings are often a good heuristic. If something makes you feel depressed, it's because your mind has gathered enough information from past experience to know the situation is hopeless. It's your mind discouraging you from wasting your energy on a pointless activity.
mhh__ 4y ago
Where's the cold shower for this article?
MarquesMa 4y ago
> Static Typing reduces bugs. This matches my experience. People say otherwise might need to put more effort on writing better tests. That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff. My favorite approach is the mixed approach like TypeScript: 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. 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's properly tested.
- why-el 4y ago
  I like types, but I like types even more when they are at the edge of two systems and both systems understand them. For instance, in the past we ran Rails APIs and a lot of mobile apps consumed them, and there was a lot of math involved. We put Google's protocol buffers between them. The data's type info is thus shared. I liked this pattern a lot, and it did reduce A LOT of bugs (for instance ints vs floats). Another thing: people working with dynamic typing often forget that often times they are interacting with a system with extreme opinions on types, namely their relational database, which is often times literally the heart of the business. If your language of choice has typing, you can sync that type info (smart ORMs, codegen), and thus reduce friction. With that said, I develop in Ruby and my understanding of where there might be "type friction and potential for bugs" has improved a lot over the years, so I don't mind the lack of types until we get optional typing sorted out.
- ehnto 4y ago
  Why not have static typing and an IDE catch the issue before you run the test?
blindmute 4y ago
Hype: Your friend says, "Good morning!" 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. Caveats: Only applies to mornings. No rigorous paper exists for evenings, so this remains an unknown.
- Konohamaru 4y ago
  Refutation: Any morning you're on this side of the grass is a good morning.
  - bewareandaware 4y ago
    Refutation: I'm not in the same timezone as you are
- wkrsz 4y ago
  Caveat: It's unspecified whether the friend wishes reader a good morning, or means that it is a good morning whether reader wants it or not; or that they feel good this morning; or that it is a morning to be good on?
WuxiFingerHold 4y ago
> Compared to other languages, Go's concurrency system of goroutines and channels is easier to understand, easier to use ... 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. > and is less prone to bugs and memory leaks. Who is actually claiming this? I'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. Concurrency is conceptually hard in Java, C#, Javascript, Python, C, C++ ... there's no reason to bully Go. Rust makes the claim of "fearless concurrency" 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 "Cold Showers" list.
- deleted 4y ago
  [deleted]
WuxiFingerHold 4y ago
Overall a questionable list of unproven claims. E.g.: > Hype: "Static Typing reduces bugs." Just because the author has not found proper research proving it doesn't mean it's false. A great type system with sum types prevents tons of bugs. I wonder how anyone can question this. > Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." 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'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.
- randomtwiddler 4y ago
  > I wonder how anyone can question this. Some developers and teams don't need the crutches. Type systems are also an encumbrance that comes with a non zero amount of issues. They slow development velocity down for a theoretical trade-off boon. I've seen a type system take down a production system where a simple coercion would have functioned just fine. Literally the only thing wrong was the type defined and the code refused to run.
zigzag312 4y ago
> Hype: "Static Typing reduces bugs." > 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. Which research is supposedly solid? 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.
roeles 4y ago
I am particularly surprised by the agile statements. I wonder if this flies in the face of the "state of DevOps" reports some people wave around.
- arendtio 4y ago
  I just watched the whole video and only agree with about 20% of the arguments. It feels a bit like Bertrand Meyer is missing the point of Agile. Yes, a bit of upfront understanding of the problem domain certainly is a good idea, but IMHO he is missing the point, that user stories are an instrument to support communication. He treats them like an incomplete requirements document, but instead they should just contain the bullet points so that the people who talked about the issue still remember what they talked about. In a typical requirements document the communication form is written, whereas in case of user stories the communication form is verbal and the document is just there to help people to remember.

Cold Showers

629 points by blopeur 4y ago

moralestapia 4y ago

>Hype: "Static Typing reduces bugs." Oof, that one is a huge can of worms.

leononame 4y ago
This one definitely hits close to home. By empirical measure, static typing reduces bugs, but maybe it's just me. I definitely like the comfort of trusting my types. My only experience with dynamic typing is really node, which improves a bit with typescript. But I'm still extremely wary of it because it doesn't give you runtime guarantees. It irks me a lot that you can just do JSON.parse, declare any type on it and call it a day. I firmly believe that static typing increases code readability and catches low-hanging fruit, but I'm going to have to sieve through that research it seems.
- chrisseaton 4y ago
  > By empirical measure, static typing reduces bugs As the article says, this does not appear to be actually true when you go and check.
  - tluyben2 4y ago
    Well, how is this measured? My experience working over 3 decades with large teams also says this is so (static typing does prevent bugs) but that is not science. How do they measure this 'when you go and check'? I am really curious as I don't even understand how people make large systems without static typing and all massively complex systems that I personally have worked with that run for decades transacting billions$ etc without flaws are all statically typed.
    - chrisseaton 4y ago
      We don't seem to be able to measure it, despite people trying several wacky approaches. Either that means it's hard to measure, or it means the effect is not actually there. Either way, this means that we cannot say that static typing reduces bugs. > all massively complex systems that I personally have worked with that run for decades transacting billions$ etc without flaws are all statically typed Did you try building the same systems without static typing as well and see what the difference was? Or are you just saying that you built systems with static typing and they were successful? That tells you nothing about static typing except that it doesn't prevent successful programs, which is a very weak thing to be able to claim! Lots of people, like you, think static typing is very important for developing software, but when someone challenges this and says 'can you actually show that?' they have never been able to. At some point you need to reconsider if it's actually the case.
      - tluyben2 4y ago
        I do reconsider it all the time; we only have short lives and I cannot build a lot large systems in my life. So that is why I asked if how it is measured. I see that my teams are more effective with static typing, but that also is my management as I, as I said, cannot really imagine writing large systems in not statically typed systems. I write a lot of scheme and k and bash and wrote a lot of tcl and Perl but never could get to scale like I can with statically compiled languages. I lean more to dependently typed languages than dynamic as I simply saw only misery, but, again, this is not saying anything, it is just my experience. I am a bit afraid though, because there is no clear measurement, it is just anyone’s experience. Edit; which actually would be fine; if it works for you and your team, company and business goals…
        chrisseaton 4y ago
        > I see that my teams are more effective with static typing If you think you really can see evidence for it then I'd encourage you to write up a paper and submit it for peer review. I guess when you sat down to write it you'd suddenly realise that you don't actually have any hard evidence. > cannot really imagine writing large systems in not statically typed systems Ok but lack of imagination is not science. Some people cannot imagine a spherical Earth, but that doesn't make it untrue. For example I work on a system in a dynamically typed language (Ruby) that successfully handles tens of billions a year, so we know that it is possible. (We are adding optional static typing to it, but it was written without it.)
    - slaymaker1907 4y ago
      A lot of the studies have been problematic because they look at toy problems (like leetcode problems). Static typing really starts to show its value in large projects. One huge project I'm aware of that uses a lot of python is the Sims 4 which uses it for a lot of the game engine and mods.
      - bjourne 4y ago
        Your argument is analogous to the one used by homeopaths and those believing in telekinesis. "There is an effect but it disappears in a laboratory setting, but it's still there!"
        seoaeu 4y ago
        All effects disappear if you don’t use strong enough measurement techniques
  - laurencerowe 4y ago
    The article mentions the literature review is from 2014. Many older statically typed languages (Java/C/etc.) don’t enforce null safety. Tony Hoare called it his ‘billion dollar mistake’. https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... Thankfully more modern type systems (Swift/Kotlin/F#/Rust/TypeScript/etc.) now do, hugely reducing the likelihood of runtime errors. As a mostly dynamic language developer I never saw the benefit of Java-like static typing but more modern type systems seem much more useful.
    - chrisseaton 4y ago
      > hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.
      - slaymaker1907 4y ago
        Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
        chrisseaton 4y ago
        There's no evidence of the absence of the easter bunny, but we are happy that he probably doesn't exist since there's an absence of evidence. Write up your experience with null safety as a paper and submit it, because this would be a world-first if you can demonstrate it.
        wtetzner 4y ago
        I’m not really sure what you’re arguing. You seem to be saying that since we can’t prove that one approach is better than the other, we should just assume they’re all equal. We do have proofs that certain classes of bugs are impossible given a certain type system.
        4y ago
  - fizzynut 4y ago
    I am curious for why people say this as in my experience when writing a function in a dynamic language that takes a variable as a parameter: The function will generally only work on a subset of types for given variable. If I don't check the type of the variable in the function, the function will not behave as you might expect, e.g. silently fail or crash. If I do check for every possible type for a given variable: I may not have a good way of handling certain types being passed in, I may be forced to either log something out, create a run time crash or even have the function silently fail. All 3 are bad run time behaviours. If I am checking for every type in the functions, then using static typing would cause the failure at compile time so the bugs could never exist, but also being significantly less verbose than the dynamic language equivalent.
    - chrisseaton 4y ago
      > I am curious for why people say this I'm saying it because it's a fact. I'm not giving you an opinion - it's a falsifiable fact that you can verify for yourself - we have as an industry not been able to give any good evidence for static typing reducing bugs that has stood up to peer review. You're presenting arguments for why you think there should be evidence... but when people look there isn't actually any evidence. Maybe your arguments are not sound for some reason that we don't understand, or maybe we are unable to measure the effect.
      - fizzynut 4y ago
        Well, this paper found that a conservative underestimate of 15% of bugs would be saved through static typing: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/gao2017javascript.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I'm not sure what evidence your fact is based on, feel free to present some evidence for it.
        chrisseaton 4y ago
        > I'm not sure what evidence your fact is based on, feel free to present some evidence for it. The linked meta-study in the article we're commenting on. https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ "under the specific set of circumstances described in the studies, any effect, if it exists at all, is small" And this question has generated the most rebuttals and retractions I've ever seen for flawed studies in computer science - it's notorious. Remember this? https://dl.acm.org/doi/10.1145/3340571 https://dl.acm.org/doi/10.1145/3340571 > Well, this paper found that a conservative underestimate of 15% of bugs would be saved through static typing Yeah does look that one shows a larger effect and has not been rebutted or retracted. One positive measurement against many negative measurements.
  - quickthrower2 4y ago
    Interesting. I wonder what about software development that we do that you can prove scientifically then. Does planning a project mean faster delivery? Does thinking about architecture up front reduce refactors and technical debt. Does estimating lead to faster software development? There is a lot we have to decide without evidence in how we develop software. Maybe we just pick the things that feel right and make us happy.
    - moffkalast 4y ago
      > Does planning a project mean faster delivery? Does that plan include the client changing their mind 10 times before delivering? Or finding out that some approach doesn't work and that pivoting is needed halfway through? Likely depends on how smart the planning is. > Does estimating lead to faster software development? Unlikely, because engineers are then busy ass-pulling useless time figures over and over instead of actually working on the project. All of these points have high random factors attached to them regardless, so you'd need a pretty big sample to say what generally works best.
      - quickthrower2 4y ago
        Yes I agree with you. My point is that almost everything we do in management if software teams and architecture decisions is a guess. We have to carry on regardless and make decisions. The nuance is what you do, why you do it and is there cultism or cargo cultism to the decisions.
  - deleted 4y ago
    [deleted]
- rajin444 4y ago
  Thorough understanding of the problem and thorough testing prevent bugs. Static typing allows you to more succinctly express your thorough understanding of a problem, but it does not fix the root problem. Quality of life benefits are where static typing (and in some cases performance) really shines.
- davnicwil 4y ago
  > It irks me a lot that you can just do JSON.parse, declare any type on it and call it a day You should look at zod [0], which validates data with inferred types based on the validation having passed, so you do have the guarantee of the type being correct at runtime. [0] https://zod.dev https://zod.dev
almost_usual 4y ago
I used to debate this but after learning Rust it’s undeniable.
- ilikehurdles 4y ago
  I thought I wanted static typing until I started writing clojure.
  - christophilus 4y ago
    Clojure is the only dynamic language I’ve ever loved. It is in its own ballpark, really, though maybe Erlang or Elixir would win me over if I spent enough time with them.
    - ilikehurdles 4y ago
      I’ve actually been spending the last year with elixir professionally. I’m embracing some of it… I would love to see its pattern matching and annotations come over to clojure, and would make my clojure code even more “correct.” I don’t super fully “get” all of its message passing plumbing, and I don’t like the quality of its library ecosystem. But clojure’s REPL, babashka, and clojure.spec are sorely missed.
      - christophilus 4y ago
        For me, after Clojure, I just get annoyed by every other language's special syntax.
  - almost_usual 4y ago
    I’m not smart enough to program quickly and correctly in Clojure. I think it follows the same ethos Rich Hickey has about unit testing being “guard rail driven development”. I watched him talk about this a decade ago at Strange Loop. To understand your whole program all the time at scale is probably something Rich Hickey is capable of but I definitely am not.
agildehaus 4y ago
Static typing makes refactoring easier. Your compiler can instantly tell you what you've broken. Bugs are reduced by monitoring, testing, and reducing how much code there is so there's less surface area (which also makes monitoring and testing easier). You reduce code by refactoring.
- strager 4y ago
  > Your compiler can instantly tell you what you've broken. For some definition of "instant". I can often run my Python or JavaScript test suite faster than Haskell/GHC or Rust/rustc can type-check a module. And it can take a while to understand Haskell, Rust, or C++ error reports. (Of course, Python and JavaScript startup time and execution speed can hurt refactoring too. And AttributeError-s and random undefined-s aren't always easy to debug.)
  - elteto 4y ago
    Got it, you can be wrong faster!
  - wtetzner 4y ago
    I doubt you can run your Python or JavaScript test suit faster than the OCaml compiler could both typecheck and compile your code.
  - ReactiveJelly 4y ago
    How many hours do you, the human, have to spend maintaining the type-checking of that test suite?
- strager 4y ago
  > Bugs are reduced by monitoring, testing, and reducing how much code there is so there's less surface area (which also makes monitoring and testing easier). > > You reduce code by refactoring. This is a great point. I wonder if there's a study on bugs-per-line-of-code, how this changes across project sizes, and whether refactoring changes bugs-per-line-of-code.
ryanmarsh 4y ago
You can pry typescript from my cold dead hands. All these “inconclusive” studies but has anyone ever tried a trial where 20 nearly identical teams tried implementing the same spec using a typed or untyped language? It’s inconclusive because a post hoc review of projects is going to be spurious at best.
joeldo 4y ago
Yeah, having worked with both typed and untyped languages (and on teams that have transitioned between these) it is hard to reconcile. There are so many variables involved that I see this being difficult to prove empirically, but anecdotally it doesn't ring true.
wtetzner 4y ago
Really, like everything, there’s nuance. E.g. not all type systems are equal, not all programmers are equally effective at taking advantage of the type system, etc.
ttty 4y ago
Refactor any js code to typescript. You’ll see how many bugs are discovered and how many wtfs!

keybored 4y ago

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

number6 4y ago
Most Times I can't bring myself to get into a cold shower. If I start warm I can cool down from there. Is there a way to start cold and go even colder?
- Toine 4y ago
  Anecdotal, but for some reason, when I tell myself "It's just cold water", my fight or flight response instantly goes away.
  - wiether 4y ago
    "fight or flight" is how you nicknamed your balls? Because when I take a cold shower they do instantly go away!
- soperj 4y ago
  It's pretty easy to start cold if you've just done a huge amount of cardio, otherwise there's nothing wrong with just turning off the hot water completely during a shower if you want a brief cold period.
- keybored 4y ago
  I don’t think there’s anything wrong with starting warm and cooling down. The only thing that matters is that you can go cold enough for a decent amount of time.
  - readbeard 4y ago
    For me, there is some value in facing the cold water head-on in the morning ("Wow, this is going to be cold, but here goes!" Great way to start the day. I have to admit though, the cold water is not super cold here this time of year.

theIV 4y ago

Previous discussion: https://news.ycombinator.com/item?id=23935943 https://news.ycombinator.com/item?id=23935943

hourago 4y ago

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

djmips 4y ago
You may have answered your own question.
- bilekas 4y ago
  The answer is in the data..
jbjbjbjb 4y ago
That definition assumes the code is reasonably performant or that they didn’t just begin on the cloud for whatever (often not well thought out) reason.

hyperhopper 4y ago

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

deleted 4y ago
[deleted]
martinhath 4y ago
That's not what this is, and if you'd bothered to look for more than a second, you'd seen that too. All the claims listed are very concrete claims that are possible to falsify, unlike "Thing good!", and the research (which, admittedly isn't directly linked, so it might be hard to find what research they're referring to) shows that this is either not true, or that the research is inconclusive. It is important not to take these statements for granted if they cannot be shown to be true; that's simply cargo-culting.
pvg 4y ago
Not reading things is an excellent way to establish for yourself the tautological obviousness of everything.

CapmCrackaWaka 4y ago

> 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. 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.

christophilus 4y ago
I found the same thing when doing video transcoding. The VPSs were all woefully underpowered. Netcup bare metal (root servers) ended up getting pretty close and were by far the best bang for the buck of anything I found.
- bilekas 4y ago
  Curious what the setup of VPS' was and why you would expect better than real hardware, video transcoding is quite a beast from what I remember and I just can't imagine there's a VPS solution that expects to keep up
  - otterley 4y ago
    The Intel Xeon processors that cloud providers typically use don't have the Intel Quick Sync core that provides hardware A/V encoding/decoding on typical desktop/laptop CPU SKUs. So the software has to fall back to CPU-based codecs, which are much slower. AWS EC2 has a VT1 instance family that enables high-speed A/V encoding via a Xilinx media accelerator card.
    - dataflow 4y ago
      IIRC Quick Sync encoded with poorer quality than software; is that not still the case?

bilekas 4y ago

> "Static Typing reduces bugs." I would argue that static typing reduces bug complexity/creep. Mainly from working in environments without proper testing during the js days, TS was rough at first, but did help.

christophilus 4y ago
I don’t know about static types reducing complexity. I’d argue the opposite. Static types allow you to do things that you wouldn’t want to attempt with dynamic types due to the difficulty of reasoning. At least for me, I try to keep my dynamic systems simple because I don’t have a compiler watching my back.
- bilekas 4y ago
  Complexity in relation to tracking down the bug of course* Interesting though, I would say that dynamic typing allows you to shoot yourself in the foot a bit more, especially over teams who might need to interact with source later. I agree with you to keep the dynamic ones (that are inevitable) simple though.

cloogshicer 4y ago

> Static Typing reduces bugs. 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's a tool for thinking and communicating.

mlyle 4y ago
And that's covered right there by the caveats.
glouwbug 4y ago
Until the types don't match the execution model... see: python type hints
- slaymaker1907 4y ago
  I find that is a far less common problem than the documentation being wrong. Even if someone doesn't add documentation for some library, static types provide a lot more insight into how it works than dynamic languages (Racket style contracts are even better since they can check way more than static types while still working in a first class way with docs).
- HL33tibCe7 4y ago
  That isn’t static typing That’s a dynamic typed language with comments
  - OJFord 4y ago
    They can be consumed by static analysis tooling, which assuming properly configured etc. makes it sort of 'dynamically typed language with the guarantees of a statically typed one', at least so far as the hints are complete.
  - semiquaver 4y ago
    Most statically typed languages compile down to object code which runs in one of the most dynamic runtime environments imaginable. What are the types in the source code but “comments”?

slaymaker1907 4y ago

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

riazrizvi 4y ago

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

fallingmeat 4y ago

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: http://slra1.baselines.cloud/ http://slra1.baselines.cloud/

ryanmarsh 4y ago

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

aranchelk 4y ago

> Hype: "Static Typing reduces bugs." 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.

moffkalast 4y ago
On the other hand it increases development time and makes modifications and new features much harder to implement. If you took it to the extreme, you could also mathematically prove your code is correct for every input variable. Everything's a trade-off, the question is which approach is best for your application. Your average website doesn't warrant as much rigor as a Mars rover.
- forrestthewoods 4y ago
  Hard disagree. Dynamic typing only increases development speed for the first few thousands lines of a solo programmer project. After that it is, in my personal experience, a significant drag on development speed. Furthermore, dynamic typing makes modifications and new features significantly harder to write. Turning compile-time bugs into runtime bugs is a catastrophic decrease in development speed. That’s my personal experience at least. YMMV.
  - moffkalast 4y ago
    taps temple That's why you keep code encapsulated as much as possible in separate files/classes up to like a thousand lines. Any more will be unreadable anyway. > dynamic typing makes modifications and new features significantly harder to write Depends on what you're doing I suppose. Adding a parameter to an object? With dynamic typing you just add it to the object in literally any location, no issues. With static typing you might just need to refactor half your codebase if you have lots of interfaces. Have fun resolving merge conflicts with your team. Not only that, but (in Java as an example) serialization codes for objects will change unless you planned for that previously (you didn't), making old objects impossible to load. A completely new bug that's created solely by static types. And it's not the only one.

_0w8t 4y ago

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.

woojoo666 4y ago
So many people in the thread saying this. But in my experience refactoring large code bases in both Java and Javascript, it's roughly the same. Ultimately the real answer will have to come from a peer reviewed study, because as the post suggests, these sorts of things are not as intuitive as people think
- greymalik 4y ago
  Does your JavaScript require higher test coverage to achieve the same level of safety?
  - woojoo666 4y ago
    Hard to measure, the javascript I worked with was mostly front-end, which is harder to write automated tests for. Not impossible, but the higher friction naturally leads to less tests, especially given how frequent the front-end changes. "Level of safety" would also need better quantification. Something that a peer-reviewed study would be better suited for
- _0w8t 4y ago
  I have done multiple times both refactoring of untyping JS and JS fully typed with Flow. With the latter after the Flow compiler stopped complaining one can expect things to work. With the former despite extensive tests sometimes it took weeks to fix bugs caused by the refactoring. Granted this is personal experience and I may be simply not careful enough to do untyped refactoring, but few people I talked about that shared the experience.
- ncmncm 4y ago
  Java does not have anything like strong typing. Likewise C. Results comparing to Java or C are intrinsically useless and actively misleading. Studies insisting static typing has no effect always assume the runtime-typed program is less buggy than it really is.

dfee 4y ago

Was hoping to see, and would like to see, one of these on Functional Programming. It’s been an immensely enjoyable experience getting into it, but with a non trivial startup cost. 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.

xwdv 4y ago

Any cold showers for unit tests?

moffkalast 4y ago

> Hype: "We should develop software using Agile." https://www.agitma.nl/wp/wp-content/uploads/2016/07/Dilbert_Training_Agile_Programming.png https://www.agitma.nl/wp/wp-content/uploads/2016/07/Dilbert_...

shisisms 4y ago

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

laserlight 4y ago

> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." > 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. That'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.

blueprint 4y ago
How new devs modify the code depends on its names too. So does how we further consume code modules. Architecture and system complexity are virtually emergent from names. So I agree. Kind of a nonsense one.
WalterBright 4y ago
People nearly always gravitate towards abbreviations in natural language. The more a word is used, the more likely it gets shortened. LA for Los Angeles, Frisco for San Francisco, Vicki for Victoria, Jay for Jason, Dub for George W Bush, Doozy for Duesenberg, and on and on. Why should programming be different?
- SmooL 4y ago
  Because abbreviations are nice when there's a shared context that is perpetually "in memory" - I don't have to think to know what LA stands for. However, that is not the case when debugging. It is almost certainly the case for the person who wrote the code originally, but it is certainly not the case for the next person to come read it afterwards. IMO code is meant to be read, so I try to never use abbreviations (other than e.g. _i_ as a for loop index, which, given it's pervasive use, falls under the category of "shared context").
  - ReactiveJelly 4y ago
    I read somewhere, "The length of a variable name should be proportional to the size of its scope". Usually I don't have long loop bodies, so if the loop body fits in 24 lines, `i` is perfect for the index. If I'm locking a mutex, doing something, and quickly unlocking it, `l` for the lock guard is fine. But if it won't fit on screen, it needs a longer name. And if there's something like a top-level `App` struct, I just call it `a` because its scope is really just `main`, even though its _lifetime_ may be the entire process.

Tade0 4y ago

> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." Most names aren'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.

charlieflowers 4y ago
And a java observerFactoryVisitorInstanceBuilder is like a total nerd with no rythym trying to dance to hip hop

hsn915 4y ago

IMO a lot of truths in programming are not amenable to "scientific studies". Static typing is objectively better than dynamic typing for the vast majority of cases, but you can't capture this in a scientific experiment or study. 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's also the open question of how do you measure these people's skills before the experiment begins?

ReactiveJelly 4y ago
I present "The emotional argument for static typing". Static typing is good because dynamic typing measurably makes me sad. Therefore I want the company to use static typing.
- H8crilA 4y ago
  This is actually the case, lol. Whether it is the extra cognitive load of not always knowing the types, or whether it actually makes things go faster - IDK, but I definitely want the types.
- hsn915 4y ago
  This but unironically. Your feelings are often a good heuristic. If something makes you feel depressed, it's because your mind has gathered enough information from past experience to know the situation is hopeless. It's your mind discouraging you from wasting your energy on a pointless activity.

mhh__ 4y ago

Where's the cold shower for this article?

MarquesMa 4y ago

> Static Typing reduces bugs. This matches my experience. People say otherwise might need to put more effort on writing better tests. That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff. My favorite approach is the mixed approach like TypeScript: 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. 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's properly tested.

why-el 4y ago
I like types, but I like types even more when they are at the edge of two systems and both systems understand them. For instance, in the past we ran Rails APIs and a lot of mobile apps consumed them, and there was a lot of math involved. We put Google's protocol buffers between them. The data's type info is thus shared. I liked this pattern a lot, and it did reduce A LOT of bugs (for instance ints vs floats). Another thing: people working with dynamic typing often forget that often times they are interacting with a system with extreme opinions on types, namely their relational database, which is often times literally the heart of the business. If your language of choice has typing, you can sync that type info (smart ORMs, codegen), and thus reduce friction. With that said, I develop in Ruby and my understanding of where there might be "type friction and potential for bugs" has improved a lot over the years, so I don't mind the lack of types until we get optional typing sorted out.
ehnto 4y ago
Why not have static typing and an IDE catch the issue before you run the test?

blindmute 4y ago

Hype: Your friend says, "Good morning!" 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. Caveats: Only applies to mornings. No rigorous paper exists for evenings, so this remains an unknown.

Konohamaru 4y ago
Refutation: Any morning you're on this side of the grass is a good morning.
- bewareandaware 4y ago
  Refutation: I'm not in the same timezone as you are
wkrsz 4y ago
Caveat: It's unspecified whether the friend wishes reader a good morning, or means that it is a good morning whether reader wants it or not; or that they feel good this morning; or that it is a morning to be good on?

WuxiFingerHold 4y ago

> Compared to other languages, Go's concurrency system of goroutines and channels is easier to understand, easier to use ... 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. > and is less prone to bugs and memory leaks. Who is actually claiming this? I'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. Concurrency is conceptually hard in Java, C#, Javascript, Python, C, C++ ... there's no reason to bully Go. Rust makes the claim of "fearless concurrency" 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 "Cold Showers" list.

deleted 4y ago
[deleted]

WuxiFingerHold 4y ago

Overall a questionable list of unproven claims. E.g.: > Hype: "Static Typing reduces bugs." Just because the author has not found proper research proving it doesn't mean it's false. A great type system with sum types prevents tons of bugs. I wonder how anyone can question this. > Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." 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'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.

randomtwiddler 4y ago
> I wonder how anyone can question this. Some developers and teams don't need the crutches. Type systems are also an encumbrance that comes with a non zero amount of issues. They slow development velocity down for a theoretical trade-off boon. I've seen a type system take down a production system where a simple coercion would have functioned just fine. Literally the only thing wrong was the type defined and the code refused to run.

zigzag312 4y ago

> Hype: "Static Typing reduces bugs." > 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. Which research is supposedly solid? 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.

roeles 4y ago

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

arendtio 4y ago
I just watched the whole video and only agree with about 20% of the arguments. It feels a bit like Bertrand Meyer is missing the point of Agile. Yes, a bit of upfront understanding of the problem domain certainly is a good idea, but IMHO he is missing the point, that user stories are an instrument to support communication. He treats them like an incomplete requirements document, but instead they should just contain the bullet points so that the people who talked about the issue still remember what they talked about. In a typical requirements document the communication form is written, whereas in case of user stories the communication form is verbal and the document is just there to help people to remember.