Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cold Showers

github.com

Post reply on HN
Print view View original

171–180 of 363 posts

Re: Cold Showers

#171

Post by wtetzner »

strager wrote: post #89
agildehaus wrote: post #16

Earlier quoted context omitted.

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.

> 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 a…

I doubt you can run your Python or JavaScript test suit faster than the OCaml compiler could both typecheck and compile your code.

Re: Cold Showers

#172

Post by siwatanejo »

kevinmchugh wrote: post #131
drujensen wrote: post #101

Earlier quoted context omitted.

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 wit…

I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.

> A type system can keep you from having to write those tests.

Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.

Re: Cold Showers

#173

Post by wtetzner »

chrisseaton wrote: post #59
tluyben2 wrote: post #55

Earlier quoted context omitted.

> We are adding optional static typing to it, Why, if not for reducing bugs?

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

> can they prove it? And I would guess that they cannot.

Of course not, to do that you’d need a way to detect all bugs in a program.

If we had an effective way to that, we’d be using to remove all of the bugs from our programs instead of looking for ways to avoid bugs.

Re: Cold Showers

#174

Post by nojs »

sethammons wrote: post #158
number6 wrote: post #8

Earlier quoted context omitted.

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?

For these people that claim taking cold showers, I want water temp. Out of the tap, in summer, my water is 53 degrees (f), upper 40s in winter. I'm not sure I could get through a whole shower sans hypothermia. Edit: looked it up. 30min-2hr for hypothermia at that range. Typically I take a 15-20 minute shower, so only flirting with hypothermia. I love a hot, hot shower. Best advancement in technology in the last thous…

Ha, I have been taking cold showers for a few months, and recording water temp for interest. Currently it’s about 11C/52F. No hypothermia yet :)

Re: Cold Showers

#175

Post by wtetzner »

chrisseaton wrote: post #54
slaymaker1907 wrote: post #46

Earlier quoted context omitted.

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

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.

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.

Re: Cold Showers

#176

Post by lostmsu »

makeset wrote: post #94
CapmCrackaWaka wrote: post #86

Earlier quoted context omitted.

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.

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.

CPU RAM is generally much slower.

8 channels of DDR4-3200 only provide 200GB/s bandwidth. RTX 3090 has 936GB/s. So even 4 socket Xeon won't catch up.

Re: Cold Showers

#177

Post by semiquaver »

jacobsenscott wrote: post #115
sumy23 wrote: post #62

Earlier quoted context omitted.

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.

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 cau…

If you search your exception tracker for NoMethodError in production, do any results come up?

Re: Cold Showers

#178

Post by ReactiveJelly »

SmooL wrote: post #161
WalterBright wrote: post #149

Earlier quoted context omitted.

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?

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 (oth…

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.

Re: Cold Showers

#179

Post by semiquaver »

falcolas wrote: post #168
randtrain34 wrote: post #129

Earlier quoted context omitted.

But suppose you were unfamiliar with the code, the 2nd tells you what fields/methods are available for "item", and furthermore most IDEs will use that info to populate autocomplete suggestions and such.

Language engines exist for Python and Ruby (and Lisp, etc.)as well, and they handle autocomplete and refactoring quite handily.

No they don’t.

Re: Cold Showers

#180

Post by ReactiveJelly »

moffkalast wrote: post #147
aranchelk wrote: post #126

Earlier quoted context omitted.

Are you sure all statically typed languages are slower to develop in than comparable dynamic ones? I used to be thoroughly convinced this was true, but 3 things are now making me doubt it: 1) Statically typed languages with inference don’t require time spent writing signatures. 2) I know I’ve spent time chasing down bugs in dynamically typed software that would have been caught by a type checker. 3) I also know I’ve…

> bugs that would have been caught by a type checker Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically). Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of…

> exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed

Anecdotally, this is not true for C++ using JSON or msgpack, since those are self-describing formats where extra fields are safe to ignore.

And it's not even true for Rust using serde, which writes the serializing / de-serializing code for you. serde_json will also ignore unknown fields when parsing, and you can preserve the original object as a `serde_json::Value` in case you want to pass unknown fields downstream as opaques.

Protocol buffers and Flat Buffers also have solutions to this, and all 4 of these formats are pretty popular in both static and dynamic languages.

Even if you write a custom TLV format, this is not that hard to deal with.

Was this common in the static code you worked with? You weren't just casting objects to `char *` and doing a `memcpy`, I hope?

Post reply on HN