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

141–150 of 363 posts

Re: Cold Showers

#141

Post by ip26 »

CapmCrackaWaka wrote: post #12

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

That seems like a problem of matching the workload to the hardware- graph computing isn’t embarrassingly parallel in the regular sense.

Re: Cold Showers

#142

Post by greymalik »

aranchelk wrote: post #126
moffkalast wrote: post #102

Earlier quoted context omitted.

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.

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…

> 1) Statically typed languages with inference

What are some strong examples of this? Haskell does an amazing job with it. Java technically supports some amount of inference, but it doesn’t reduce verbosity by all that much. Apart from those I haven’t run into it.

Re: Cold Showers

#143

Post by moffkalast »

forrestthewoods wrote: post #122
moffkalast wrote: post #102

Earlier quoted context omitted.

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.

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…

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.

Re: Cold Showers

#144

Post by Tade0 »

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

Re: Cold Showers

#145

Post by moritonal »

drujensen wrote: post #101
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.

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…

You're point is valid, but you really quickly move past just how slowly drivers have to be when there aren't traffic lights. As with everything they're a helpful tool for efficient traffic, just like static compilation.

Re: Cold Showers

#146

Post by greymalik »

woojoo666 wrote: post #109
_0w8t wrote: post #84

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.

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

Does your JavaScript require higher test coverage to achieve the same level of safety?

Re: Cold Showers

#147

Post by moffkalast »

aranchelk wrote: post #126
moffkalast wrote: post #102

Earlier quoted context omitted.

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.

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 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 (or say change from a float to a double which can be irrelevant). A nightmare in systems with lots of moving parts.

One might say that's working as intended, and it of course is, but it also forces you to fix and recompile all of that for no real net gain. Hence the longer dev time I mentioned.

I've spent years working with statically typed languages, and I honestly don't think I'll ever go back to them in any professional capacity.

Re: Cold Showers

#148

Post by b3n »

fizzynut wrote: post #69
chrisseaton wrote: post #11

Earlier quoted context omitted.

> By empirical measure, static typing reduces bugs As the article says, this does not appear to be actually true when you go and check.

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…

> The function will generally only work on a subset of types for given variable.

This is true for many functions defined in statically typed languages too. Just because your function says it works with an integer, doesn't mean it's necessarily going to work with _any_ integer (think `1/n`). Very often the type used isn't narrow enough.

Modern dynamic languages understand this, see for example Clojure's spec[1].

[1] https://clojure.org/about/spec

Re: Cold Showers

#149

Post by WalterBright »

laserlight wrote: post #128

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

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?

Re: Cold Showers

#150

Post by Gigachad »

klysm wrote: post #68
cloogshicer wrote: post #14

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

Refactoring with confidence that you didn’t forget somewhere.

This is the major one. I work on a 10 year old rails app and it has got to the point where we are terrified of making any change that has the potential to affect areas outside of the visible git diff. It's easy enough to manually verify regular changes by looking at the code. But something like a library update is impossible to verify and we constantly end up with production issues because of something changing in a library that wasn't mentioned in the upgrade guide and would be impossible to have considered beforehand. But that a type system would catch.
Post reply on HN