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

Diminishing returns of static typing

blog.merovius.de

Post reply on HN
Print view View original

391–400 of 632 posts

Re: Diminishing returns of static typing

#391

Post by cobbzilla »

cle wrote: post #37
drblast wrote: post #31

Earlier quoted context omitted.

Definitely. Static typing lets you turn the compiler into a hard-working friend that helps you refactor large projects without going insane. There are no diminishing returns. Defining types is easy and enhances code readability.

Believing that any technology has no cost is poor engineering IMO. There are costs to that rigidity, and they're rather self-evident.

No one is saying there is no cost. The cost of using static types is (1) you have to think about type info when writing the code and (2) you have to fix compile-time type errors while you are developing. The poster is claiming that, over time, as code bases tend to grow large, this small investment yields increasing (not diminishing) returns; a claim I would agree with.

Re: Diminishing returns of static typing

#392

Post by underwater »

DubiousPusher wrote: post #73
danharaj wrote: post #28

Earlier quoted context omitted.

List typing isn't as superficial as it seems. The following has happened to me multiple times, perhaps in the last month : I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again…

Yup, love that about statically typed languages. This happens all the time for me in C#. I have several libraries I like that do a lot of code generation. When the project is young, directly handling the generated classes works well but as the project grows, I inevitably want to wrap the handling of the generated classes. It's awesome to be like, welp... it's time to handle this one type differently. Change the retur…

I’d argue that code generation is an anti—pattern that is only necessary because of static typing. A dynamic language would let you change the implementation of all generated objects simultaneously.

Re: Diminishing returns of static typing

#393

Post by dragonwriter »

underwater wrote: post #392
DubiousPusher wrote: post #73

Earlier quoted context omitted.

Yup, love that about statically typed languages. This happens all the time for me in C#. I have several libraries I like that do a lot of code generation. When the project is young, directly handling the generated classes works well but as the project grows, I inevitably want to wrap the handling of the generated classes. It's awesome to be like, welp... it's time to handle this one type differently. Change the retur…

I’d argue that code generation is an anti—pattern that is only necessary because of static typing. A dynamic language would let you change the implementation of all generated objects simultaneously.

In principle, this should be possible with static typing with a robust enough type system, too.

Re: Diminishing returns of static typing

#394

Post by voidmain »

lisper wrote: post #388

100% statically-type-checked code != 100% bug-free code. That would require solving the halting problem. So you have to test everything anyway if you need high reliability.

This argument is incorrect. The "halting problem" is the problem of determining if an arbitrary program halts. It is not impossible to prove, and verify mechanically, that a particular program halts.

The state of the art is not up to proving every desirable property of every program that we would like to build. But that has nothing much to do with computability. And some extremely impressive things have been done, like the seL4 separation kernel, which has static proofs of, among other things, confidentiality, integrity, and timeliness, and a proof that its binary code is a correct translation of its source.

Re: Diminishing returns of static typing

#395

Post by sigstoat »

boramalper wrote: post #390
flavio81 wrote: post #301

Earlier quoted context omitted.

>What exactly does it mean to have "good dynamic typing facilities"? Picking Common Lisp as an example: (NOTE: Some of the features are also present in good statically typed languages as well, so what I advocate is to use good, well-featured languages, not really static vs dynamic.) (NOTE 2: I'm sorry for being such a fanboy, but that thing is addictive like a hard drug...) 0. Code is a first class citizen, and it ca…

> 3. The error handling system is exemplary: Not only designed to "catch" errors, but also to apply a potential correction and try running the function again. This is known as "condition and restarts", and sadly is not present in many programming languages. I found this extremely weird and (or hence ) interesting at the same time. Where can I read more about this?

googling for "common lisp condition system" turns stuff up. i looked at one point, and i don't remember finding an academic treatment of them.

they're (hand wave hand wave) basically a matter of stuffing the current continuation inside of the exception, whenever you throw an exception, and then making use of that to provide more options whenever the exception is caught.

Re: Diminishing returns of static typing

#396

Post by catnaroek »

flavio81 wrote: post #387
catnaroek wrote: post #373

Earlier quoted context omitted.

What does “somewhat sound” mean?

I think he refers to some of the usual criticisms of Common Lisp: 1. The language specification is very big. This is true, it is a very big specification. On the other hand, this is mostly caused because the language spec also includes the spec for its own "standard library", unlike what happens in C or Java, for example, where the Std. lib is specified elsewhere. CL's "standard library" is very big, because there ar…

0. There is nothing wrong with big standard libraries, so long as they are not redundant and the core language is small.

1. This is a serious criticism, but it has nothing to do with soundness.

2. There is absolutely nothing wrong with a language being designed by a committee, so long as the committee's members are all competent.

3. Back to 0.

Re: Diminishing returns of static typing

#397

Post by raquo »

dwaltrip wrote: post #136
ruskimalooski wrote: post #22

Earlier quoted context omitted.

But even the asymptotes are an assumption derived from pure thought experiment.

More realistically, it's an educated guess based off the author's personal experience as well as their understanding of the experiences of other developers operating under different constraints. The author makes it clear that the analysis is not perfectly rigorous. There is a very wide landscape between perfectly rigorous and completely useless. Do you think the article fails to hint at any of the fundamental dynamic…

I'm not who you're replying to, but for me the charts didn't make sense either.

For one example, I don't think it's a given that the green line (velocity vs % type-checked) should have a negative slope. Maybe in some cases, for some projects or some people, but certainly not universally. At least part of it would have been positive on almost all projects that I've worked on, and I'm not doing rocket science.

Then, the combined chart just looks at the amount of bug-free output, completely ignoring the amount of bug-ridden output. That latter part doesn't just get discarded, it needs fixing, and bugs that were only discovered in production are expensive to discover, debug and fix.

This is in addition to pretty much every other top level comment in this thread, a lot of which bring up important points that are unaccounted for even conceptually in the charts.

Re: Diminishing returns of static typing

#398

Post by magice »

https://dl.acm.org/citation.cfm?id=2635922

Just ONE study, so don't take too much heed. That said, apparently:

* Strongly type, statically compiled, functional, and managed memory is least buggy

* perl is REVERSELY correlated with bugs. Interestingly, Python is positively correlated with bug. There goes the theory about how Python code looks like running pseudo-code... Snake (python's, to be more precise) oil?

* Interestingly, unmanaged memory languages (C/C++) has high association with bugs across the board, rather than just memory bugs.

* Erlang and Go are more prone to concurrency bugs than Javascript ¯\_(ツ)_/¯. Lesson: if you ain't gonna do something well, just ban it.

All in all, interesting paper.

Re: Diminishing returns of static typing

#399

Post by flavio81 »

catnaroek wrote: post #396
flavio81 wrote: post #387

Earlier quoted context omitted.

I think he refers to some of the usual criticisms of Common Lisp: 1. The language specification is very big. This is true, it is a very big specification. On the other hand, this is mostly caused because the language spec also includes the spec for its own "standard library", unlike what happens in C or Java, for example, where the Std. lib is specified elsewhere. CL's "standard library" is very big, because there ar…

0. There is nothing wrong with big standard libraries, so long as they are not redundant and the core language is small. 1. This is a serious criticism, but it has nothing to do with soundness. 2. There is absolutely nothing wrong with a language being designed by a committee, so long as the committee's members are all competent. 3. Back to 0.

>2. There is absolutely nothing wrong with a language being designed by a committee

It sort of has a bad stigma, because two well-known, unloved languages were designed by committee: COBOL and PL/I.

Re: Diminishing returns of static typing

#400

Post by Merovius »

mattnewton wrote: post #371
Merovius wrote: post #361

Earlier quoted context omitted.

The fact that maps/slices/channels already exist generically is what puts Go into the sweet spot. You have generic containers for the vast majority of use-cases, so the value-added consideration of being able to cover more use-cases with generic containers becomes a lot smaller. In a hypothetical world where the designers never added the specific containers they did, you'd get a whole lot more value out of generics f…

You have containers for all the use cases the designers thought of, but then you have it worse than Python for all the other use cases, and you are stuck doing code generation or type erasure. It is impractical to expect go’s designers to have foreseen the best trade off for every codebase. Architecture astronauting can be prevented with best practices and code review, not with language limitations. It’s a fools erra…

> It is impractical to expect go’s designers to have foreseen the best trade off for every codebase.

Which is not the argument made by anyone. Indeed, I explicitly acknowledge that there is a certain fraction of use-cases not covered by the builtins. So there isn't really any disagreement about this.

The question is how large this fraction is, how much it would benefit and how inconvenient/costly the existing workarounds are. Like all engineering questions, these are impossible to talk about when dealing in absolutes. And once you actually talk about these questions quantitatively, I achieved the goal I had with the post - to change the debate into a quantitative one explicitly acknowledging the tradeoffs involved.

> Architecture astronauting can be prevented with best practices and code review, not with language limitations.

I work at a company which has probably one of the highest standards in regards to code review in the industry. As such, I disagree with you that it is effective in addressing this.

> It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.

If that's the case, where do the complaints come from about the lack of generics? It seems that Go really has generics then, in your opinion?

Of course, that's a strawman and a misrepresentation of your argument. But what makes this a strawman, the difference between the existing workarounds and actual generics, is just as effective an argument for your side as it is one for my side. Because codegen is made so inconvenient, people bias heavily towards using the builtins, away from custom data structures, if they can at all get away with it. Thus greatly reducing the overall complexity of the codebase.

So it would seem to me, that this argument is logically flawed. Either codegen is a poor replacement, thus leading to people using less generic code, thus there is an effective reduction in complexity. Or codegen has the same effect on complexity, which would mean it is used just as much, meaning it can't be that bad a workaround.

Post reply on HN