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

211–220 of 363 posts

Re: Cold Showers

#211

Post by why-el »

MarquesMa wrote: post #189

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

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.

Re: Cold Showers

#212

Post by yen223 »

josephcsible wrote: post #195
moffkalast wrote: post #147

Earlier quoted context omitted.

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

> Whenever the object definition changes in another piece of the software stack the statically typed parts will crash You appear to completely misunderstand what static typing means. Runtime crashes due to type mismatches are exactly what static typing prevents .

You can't typecheck across system boundaries - that's the OP's point.

(Well you could, but then you'll be introducing a whole set of problems if the other system has a static type system that behaves differently from your application's static type system)

Re: Cold Showers

#213

Post by joeldo »

bjourne wrote: post #202
joeldo wrote: post #123

Earlier quoted context omitted.

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 .

What is an item in the second declaration? That it has type "Item" doesn't help you unless you have contextual information. And if you have contextual information you can probably figure out what an item is in the first declaration too.

I would argue that it isn't a zero-sum game. Extra context (that is enforced) is better than none at all.

Re: Cold Showers

#214

Post by ncmncm »

falcolas wrote: post #165
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’s basically self-evident that static analysis reduces bugs. And yet, per TFA, it’s not; at a minimum it’s clearly not “self evident”. Why do we developers value our personal experience above studies, while dunking on average citizens for doing the same? Guess we’re just as human as the rest of humanity; subject to the same urge to trust our own beliefs over contrary evidence.

Because the studies are constructed by equally fallible humans, and almost always badly.

Cold shower attempted, but the plumbing was busted?

Such studies invariably wholly miss the point: when you have a language with powerful type support, error checking is the least valuable work you get out of them. Types do serious heavy lifting expressing semantics.

Re: Cold Showers

#215

Post by ncmncm »

danieltanfh95 wrote: post #205
ebingdom wrote: post #200

Earlier quoted context omitted.

As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose. I associate verbosity with object-oriented programming, whether statically typed or not.

As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain

Not even wrong.

Without compile-time types, you are not equipped to express serious compile-time work.

Re: Cold Showers

#216

Post by ncmncm »

tharkun__ wrote: post #107
thom wrote: post #77

Earlier quoted context omitted.

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.

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

Yes. Shorter means less to compare against for consistency.

Re: Cold Showers

#217

Post by kdtsh »

bjourne wrote: post #202
joeldo wrote: post #123

Earlier quoted context omitted.

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 .

What is an item in the second declaration? That it has type "Item" doesn't help you unless you have contextual information. And if you have contextual information you can probably figure out what an item is in the first declaration too.

An item is an IItem, as it says in the definition. You can always ‘figure out what an item is’ in a dynamic typing system, that’s not the problem. There’s an incredible amount of mental overhead in any non-trivial project which employs dynamic typing. Engineers who can work around this have my respect, but I find static typing to be the easiest solution to this problem by far.

Re: Cold Showers

#218

Post by redredrobot »

jamal-kumar wrote: post #201
VWWHFSfQ wrote: post #110

Earlier quoted context omitted.

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

I don't use AWS for a damn thing because of exorbitant costs. I just don't get why people think that it's necessary other than that they're the types to get drawn into marketing hype. There's just so many better things for your company to be spending the money on.

The argument is - engineers are expensive so why pay for the expertise to setup and run machines? There's just so many better things for your company to be spending the money on.

Re: Cold Showers

#219

Post by the_only_law »

YetAnotherNick wrote: post #116
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.

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.

> let x = 5

x still has static type, the compiler just infers it based on the assignment, the type information is still there. Agree that implicit/unsafe casting is still and issue in some languages though.

Re: Cold Showers

#220

Post by ncmncm »

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

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.

Post reply on HN