[HN Gopher] Cold Showers
___________________________________________________________________
Cold Showers
Author : blopeur
Score : 258 points
Date : 2022-06-18 19:34 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hourago wrote:
| > 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 wrote:
| You may have answered your own question.
| bilekas wrote:
| The answer is in the data..
| jbjbjbjb wrote:
| 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.
| slaymaker1907 wrote:
| 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).
| hyperhopper wrote:
| 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]
| martinhath wrote:
| 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 wrote:
| Not reading things is an excellent way to establish for
| yourself the tautological obviousness of everything.
| shisisms wrote:
| I wish someone would do one of these for life in general.
| CapmCrackaWaka wrote:
| > 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.
| VWWHFSfQ wrote:
| Haha! Back in ~2014 or so my company was spending nearly
| $30,000/month on an EC2 "compute-optimized" cluster to
| transcode live video streams to multiple renditions. One of our
| engineers said hey, why don't we try to colo some real
| hardware? We did a test with a single bare-metal 8-core Xeon
| server and it completely destroyed the performance of the EC2
| "compute-optimized" cluster!
|
| After that we colo'd 4 big Xeon servers for about $1,600/month
| total. Looking back on it now it's just so insane...$30,000? no
| way.
| thom wrote:
| There appear to be slightly weird commercial reasons behind
| this, because gaming GPUs have great CUDA performance but
| NVIDIA won't let you put them in a datacentre. So buying your
| data scientists gaming laptops (RGB and all) generally works
| out faster for any reasonable price point. That said, a
| dedicated server with a decent Xeon and MKL set up correctly
| generally outperforms CPU-bound stuff.
| CapmCrackaWaka wrote:
| I think it really depends on your data size. All the
| benchmarks I can find are on massive datasets, with tens of
| millions of rows or thousands of columns. I'm sure there are
| significant performance gains in these situations. Our data
| just wasn't big enough.
| makeset wrote:
| With larger data it really depends on the algorithm. If you
| must iterate over more than a few GB at a time, GPU memory
| capacity and bus speeds become prohibitive, while a dead-
| simple implementation on a single CPU with 100+ cores and
| TBs of RAM goes brrr.
| christophilus wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| IIRC Quick Sync encoded with poorer quality than
| software; is that not still the case?
| ddorian43 wrote:
| AFAIK that should still be the case.
| xwdv wrote:
| Any cold showers for unit tests?
| riazrizvi wrote:
| Luke warm showers to me - these points need good sources to back
| them up to be really cold.
| moralestapia wrote:
| >Hype: "Static Typing reduces bugs."
|
| Oof, that one is a huge can of worms.
| ryanmarsh wrote:
| 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.
| almost_usual wrote:
| I used to debate this but after learning Rust it's undeniable.
| ilikehurdles wrote:
| I thought I wanted static typing until I started writing
| clojure.
| icambron wrote:
| I occasionally missed types even in Clojure. "What keys are
| supposed to be in this map again? Hmm, turns out some
| callers are providing foo and some are providing bar..."
|
| That said, I certainly agree it comes up less than it does
| in, say, JavaScript
| ilikehurdles wrote:
| I agree. In another comment I mentioned how I think
| Elixir's pattern matching and annotations (type specs)
| would take clojure to that next level and strike a
| perfect balance between between ergonomics and
| correctness.
| icambron wrote:
| Clojure has a few options here. Typed Clojure is a set of
| macros for enforcing typing, conceptually similar to
| Typescript (and like Typescript, I found it hard to
| incrementally retrofit in a large existing project), and
| core.spec, which is a way of declaring DSTs validations,
| which I found useful without cramping the Clojureness too
| much. But it's been a few years
| robertfw wrote:
| this is why I love spec (though I am starting to explore
| replacing it with malli)
| froderick wrote:
| Same here. Clojure offers a bunch of different invariants
| than 'this field is a string'. Things like 'nobody is
| modifying this complex data structure out from underneath
| you' or 'this complex value is trivially printable,
| readable, inspectable, comparable, diffable, etc'. And if
| you want to know for sure that field will be a string, you
| can spec it and enforce it where it matters. And ignore it
| where it doesn't.
| vnorilo wrote:
| Yes. Dynamic types, mutability and complex OOP types are
| the toxic mix.
|
| It is very hard to make large programs simple, but lisps
| are some of the best PLs for that, especially if you stick
| with immutable data.
| christophilus wrote:
| 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 wrote:
| 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.
| almost_usual wrote:
| 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.
| Spivak wrote:
| Working in a huge Ruby codebase, I know not the same, but
| still super super dynamic my approach is
|
| 1. If I don't understand what code does just delete/noop
| it and see what tests fail.
|
| 2. Write my assumptions into new tests to be very loud
| people if someone wants to break them. Easier said then
| done with frameworks/callback patterns that want to call
| my code from god knows where but really powerful when
| you're pulling a value.
|
| 3. In the case of callback spooky object at a distance
| stuff be strict about what you accept and fail loud.
| agildehaus wrote:
| 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 wrote:
| > 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 wrote:
| Got it, you can be wrong faster!
| strager wrote:
| > 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.
| joeldo wrote:
| 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.
| leononame wrote:
| 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 wrote:
| > By empirical measure, static typing reduces bugs
|
| As the article says, this does not appear to be actually true
| when you go and check.
| laurencerowe wrote:
| 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_retr
| a...
|
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| BlargMcLarg wrote:
| Almost all of the null pointer errors I've seen came from
| not fully thinking things through. I can see the same
| mistakes happening with non-nullable types because
| someone got lazy and passed a default value or something.
| You get the benefit of the compiler shouting at you for
| not initializing a variable, but that won't necessarily
| protect you from not thinking every situation through /
| lazily passing default values / making poor assumptions.
|
| I'm with GP, I'd really like evidence of this before
| people continue shouting things which aren't proven.
| tasuki wrote:
| I don't think a scientific study is needed. There exist
| different classes of bugs. The stronger static typing,
| the more classes of bugs become _impossible to make_. You
| will not see a NullPointerException in Haskell.
|
| The only way in which strong static and dynamic typing
| could produce the same number of bugs would be if strong
| static typing resulted in introducing other bugs, ones
| which wouldn't be introduced in a dynamically typed
| language. Proving that would probably require a
| scientific study ;)
| [deleted]
| [deleted]
| fizzynut wrote:
| 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 wrote:
| > 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 wrote:
| 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/...
|
| I'm not sure what evidence your fact is based on, feel
| free to present some evidence for it.
| quickthrower2 wrote:
| 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 wrote:
| > 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.
| tluyben2 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.)
| tluyben2 wrote:
| > Ok but lack of imagination is not science.
|
| Sure, but that's what I said in the first place. It all
| seems there is no evidence, not even empirical for either
| way. I was looking for any, if there was. MS or whatnot
| must have something no?
| chrisseaton wrote:
| > I was looking for any, if there was.
|
| I would say in summary that no, we don't have any
| evidence. Evidence that people have tried to present has
| been found to be flawed in peer review.
| tluyben2 wrote:
| > We are adding optional static typing to it,
|
| Why, if not for reducing bugs?
| chrisseaton wrote:
| > Why, if not for reducing bugs?
|
| Maintainability, tooling, and some people would argue for
| reducing bugs - but I'd challenge them in the same way I
| challenge you - can they prove it? And I would guess that
| they cannot.
|
| If the person I was replying to was saying that they
| could not imagine a large system without types, and well
| they don't have to since I gave them a real example.
| Perseids wrote:
| Something else I find rather likely is that different
| people are working most effectively with different
| methodologies (a believe that is grounded in the repeated
| experience of being shocked at how other people program
| and still be effective). So it is entirely plausible
| there is a self-selection bias that people that work best
| with strong types don't work on projects with weak types
| and vice verse. I guess its really hard to control for
| that effect when you want to look at big projects, since
| people need to be willing to work on that for a long
| time.
| tluyben2 wrote:
| I agree it seems hard to prove; disappointed not more
| tried. Especially large companies that have skin in the
| game (MS with ts and c#/f#, Google with go and dart,
| oracle with Java, Mozilla with rust). Guess it'll be a
| religious argument for some time to come and I will steer
| clear.
| slaymaker1907 wrote:
| 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 wrote:
| 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!"
| rajin444 wrote:
| 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.
| cloogshicer wrote:
| > 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.
| dmitriid wrote:
| As long as the types, variables and function names have proper
| names. And not `A -> A -> B -> [B, D]` (looking at you,
| Haskell).
| klysm wrote:
| Refactoring with confidence that you didn't forget somewhere.
| repsilat wrote:
| Yeah, a common mode when I'm making changes is "add a field
| to the type, run the type-checker, fix all the failures."
|
| In a sense "type coverage" is analogous to test coverage.
| onion2k wrote:
| _that it aids my understanding and helps in navigating the
| program_
|
| Static typing reduces bugs _because_ it aids your
| understanding.
| cloogshicer wrote:
| Not necessarily. This increased ease of understanding could
| also simply result in faster development speed - so same
| number of bugs, but more features in less time.
|
| Not sure though.
| lolinder wrote:
| So fewer bugs per feature. Assuming that the total number
| of features required is the same either way, by the end
| you're still left with fewer bugs.
| silisili wrote:
| Well, it also fails to compile. Which to me is better than
| blowing up at runtime, or worse, not blowing up but giving
| weird results.
| jacobsenscott wrote:
| I've never found static typing to aid in my understanding of a
| program. For example: def
| add_item_to_cart(item)
|
| vs void add_item_to_cart(IItem item)
|
| They are equally easy to understand. The first is easier to
| read.
| joeldo wrote:
| What is an item in the first declaration? Is it an id? Is it
| an object (if so, what type of object? Id and qty or some
| other data)?
|
| I guess you now need to read through the implementation or
| docs. The first is much easier to read _incorrectly_.
| OJFord wrote:
| Allegedly? Have you ever written code in a dynamically typed
| language? I'm forever fixing TypeErrors and AttributeErrors and
| the like.
|
| I suppose it's not even necessary to argue about experience
| fixing them or not, just the fact that those are runtime errors
| rather than compile-time (and so we presume not shipped) shows
| it reduces bugs doesn't it?
| moffkalast wrote:
| I'd say it reduces bugs... in size, making them harder to
| find.
| haswell wrote:
| Reduces bugs in size, or only leaves smaller bugs behind?
|
| These are two very different outcomes.
|
| If the remaining bugs are unrelated to the class of bugs
| that were eliminated entirely, then the difficulty in
| finding them has little bearing on the outcome, since we're
| now talking about an entirely different class of bugs.
| mlyle wrote:
| And that's covered right there by the caveats.
| glouwbug wrote:
| Until the types don't match the execution model... see: python
| type hints
| HL33tibCe7 wrote:
| That isn't static typing
|
| That's a dynamic typed language with comments
| OJFord wrote:
| 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.
| slaymaker1907 wrote:
| 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).
| CraigJPerry wrote:
| Static typing has an undisputed benefit, performance. If i need
| to add dynamic thing a and thing b, I'll always have the
| overhead of figuring out what add means first in this context,
| an overhead i dont have when asked to add some ints.
|
| All the other claims from readability to understandability to
| refactoring to less bugs, all come with an "it depends" caveat.
| Sometimes the claims are true, sometimes they're not. It's also
| not possible to say "but in most cases claim X holds".
|
| The thing I've never understood yet in this debate is in my
| experience, the people who have argued about correctness have
| universally been below par at getting to the bottom of
| requirements. Which leads to "great, you correctly built the
| wrong thing. And you took forever to do it." Which isn't doing
| our profession any good in the eyes of other professions who
| depend on us.
| sumy23 wrote:
| It's basically self-evident that static analysis reduces bugs.
| It's trivial to construct an example of where type information
| would catch a bug. Unless there is some reason that including
| type information increases bugs, the existence of a single
| example where type information catches a bug would prove that
| overall type information reduces total bug count.
| jacobsenscott wrote:
| It is not evident to me. Having used both statically typed
| and dynamically typed languages my experience is that I can't
| remember ever seeing a bug in our fairly large rails app that
| a type system would catch. Nobody's passing strings where
| hashes are expected, or Widget instances where User instances
| are expected. The thing to pass to the function is nearly
| always self evident. If you did it would immediately be
| caught when a test runs anyway.
|
| However, refactoring code in C# is _much_ easier than
| refactoring ruby because you can lean on the type system
| there. However writing new code in C# is often _much_ harder
| to do in C# because of the constraints of the type system. So
| really, it ends up being a wash for me.
| unethical_ban wrote:
| >Nobody's passing strings where hashes are expected
|
| See, When I'm throwing together apps to clean up
| configurations, I am Pythonifying XML often. And when
| handling different return values, reshaping it into the
| useful components I need and trying to analyze data (and
| dealing with different return formats depending on number
| of results, aka a dict if there is one value, or a
| list(dict) if there are more) I have to constantly remember
| if I am going to be getting a list(dict(dict(dict(str))))
| or just a dict(dict(string)), and so on. But that's me
| cobbling together scripts and not understanding the API by
| heart well enough.
| imiric wrote:
| > If you did it would immediately be caught when a test
| runs anyway.
|
| That's the point though. With dynamic typing you would only
| (hopefully) catch this with manually written tests. With
| static typing you get that feedback for free at build time.
| YetAnotherNick wrote:
| Static typing doesn't mean type information being available.
| Most statically typed language allow some version of `let x =
| 5`. Similarly static types doesn't mean unsafe casting are
| not performed.
|
| Also in the opposite direction, many dynamically typed
| language allows specifying types if you want to including
| python.
| drujensen wrote:
| This reminds me of the studies done related to traffic lights
| and stop signs.
|
| Removing traffic lights and stop signs actually reduces
| accidents because drivers are more careful when driving
| through intersections which reduces speeds and drivers become
| more alert.
|
| Developers will adapt to their toolset. If you have a
| statically typed language, you trust it will deal with type
| related issues and you become more lax with testing things
| related to types. When you develop in non-typed languages
| like Ruby, you tend to write more tests and not trust your
| compiler (because you don't have one). This is why you will
| find most Ruby developers are really good at writing tests
| and embracing TDD.
| [deleted]
| thom wrote:
| One could argue that dynamically typed code is often shorter,
| and therefore both easier to reason about, and possessed of
| fewer bugs on a bugs-per-line basis. Not really keen to push
| that line of reasoning myself, just helping picture one
| possible argument.
| therealdrag0 wrote:
| Shorter how? The typing can often be implicit in many
| languages like Scala which makes it pretty short compared
| to something like Java. While there is a bit of explicit
| typing, I think it's well into diminishing returns to force
| even shorter code.
| tharkun__ wrote:
| I would even argue that shorter can do the opposite. You
| can squeeze an awful lot of information into a tight space
| in dynamically typed languages that allow functional
| programming and especially with terse syntax for often used
| constructs.
|
| This can make it much harder to _actually_ reason about the
| code, while making it seem easier to reason about. Most
| people would agree w / your reasoning on a short piece of
| logic, which then at runtime spectacularly fails because
| the inputs don't adhere to the types you expected. In a
| statically typed language you would not even have gotten it
| to compile and while it might not feel like a bug is being
| prevented and actually feel tedious, every time your IDE
| (or compiler) tells you that the type on something is
| wrong, you've prevented a potential bug.
| mdtusz wrote:
| This is true in a local context, but entirely breaks down
| when a codebase becomes larger than a single person can fit
| into their brain-RAM. Not arguing or saying you're wrong -
| just presenting the very quickly reached boundary where the
| argument breaks down.
| BlargMcLarg wrote:
| It's not just local context. Reading a dense book is
| still more difficult than reading a less dense book,
| given a fairly similar amount of information and style in
| conveying that information. Larger codebases suffer the
| same problem you mention in a different way, and
| cargocults in most static languages tend to advocate very
| verbose writing styles.
|
| Where this falls apart, the more verbose writing style
| hasn't been proven to convey more information or in a
| better way. That's an assumption still tossed around.
| kangda123 wrote:
| It is just a fair bit harder to figure out the types as
| program grows.
| _the_inflator wrote:
| I agree. At least for JavaScript I would always use TypeScript
| now. The main reason is understanding of code as well as
| tooling, which means communication in the end.
|
| I remember working 2012 on a SaaS app, and I wasn't the only
| guy anymore doing frontend stuff with JS. I knew my objects,
| but my colleagues did not. How to you document object APIs?
| TypeScript really shines in large projects with lots of devs.
| bilekas wrote:
| > "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 wrote:
| 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 wrote:
| 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.
| aranchelk wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| fpoling wrote:
| 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 wrote:
| 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
| keybored wrote:
| 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 wrote:
| 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?
| tbihl wrote:
| The way to start cold is to stick your head/face directly in
| to start the shower. That gives you the strongest mammalian
| dive response. Not sure if that offsets any of the cold
| shower benefit though.
|
| https://en.m.wikipedia.org/wiki/Diving_reflex
|
| Edit: This is also the time of year to do this, while the tap
| water is probably warmer and your house is warmer. I wouldn't
| try to acclimate in winter.
| moffkalast wrote:
| So in short, jump into a pool instead?
| Toine wrote:
| Anecdotal, but for some reason, when I tell myself "It's just
| cold water", my fight or flight response instantly goes away.
| soperj wrote:
| 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 wrote:
| 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.
| moffkalast wrote:
| > Hype: "We should develop software using Agile."
|
| https://www.agitma.nl/wp/wp-content/uploads/2016/07/Dilbert_...
| theIV wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=23935943
| fallingmeat wrote:
| 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/
| dfee wrote:
| 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.
| ryanmarsh wrote:
| Title should be "Cold Showers for Straw-man Arguments".
___________________________________________________________________
(page generated 2022-06-18 23:00 UTC)