Live data from Hacker News

Cold Showers

github.com

121–130 of 363 posts

Re: Cold Showers

#121
post #89

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…

Got it, you can be wrong faster!

Re: Cold Showers

#122

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

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 experience at least. YMMV.

Re: Cold Showers

#123

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

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.

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.

Re: Cold Showers

#124

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

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.

What about return types? Do you generally deal with voids in your line of work? Having code that could return different types depending on branching is pretty self-evidently worth preventing.

Re: Cold Showers

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

Even trivial things like a typo in the method name in a method call are not detected at compile time by languages like JavaScript or Ruby (since their "method calls" are in fact just lookups in a runtime hash table...).

If you have not seen them, the reason is probably that the code was tested well enough before you looked for the bugs.

Re: Cold Showers

#126

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

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 spent time writing tests for conditions in dynamically typed code that wouldn’t pass a type checker.

Re: Cold Showers

#127

Earlier quoted context omitted.

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

this is why I love spec (though I am starting to explore replacing it with malli)

We’ve been moving steadily to malli over the last 6 months. I have to say, programmatically composing malli schemas as values (rather than macros) is really powerful. I like being able to define a base set of fields on a map, and then merge in other schemas and different sets of fields that are required in different cases. Nice for modeling apis with reused structures but with varying field requirements.

Re: Cold Showers

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

Re: Cold Showers

#129

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

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.

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.

Re: Cold Showers

#130

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

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.

Depends on the specifics, but i'm betting if `IITem` is close by i know how to interact with it. I have no clue what the hell fields or methods may or may not be on `item`. Nor will i, ever. At best i have to enforce method/fields myself, at worst i subscribe entirely to duck typing and let the gods sort it out.
Post reply on HN