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

481–490 of 632 posts

Re: Diminishing returns of static typing

#481

Post by DubiousPusher »

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.

That may be entirely true and everything you can achieve with Roslyn and T4 templates may be achievable through some more elegant construct in another language.

But I've never had the luxury of choosing a tech stack for it's purity of design. So the feature is wonderful in my day to day regardless.

I'd love to build 3D experiences in a language like lisp or scheme. It'd be great fun to learn but I don't currently have the luxury of the time it would take to ramp.

And I certainly don't have the political capital to convince my entire dev team to change.

Re: Diminishing returns of static typing

#482

Post by wernercd »

sampo wrote: post #455
alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

> you can't make good experiments with those time frames Multi-decadal longitudinal studies are not too uncommon in medicine, epidemiology and psychology. Why there is no will to conduct, or fund, this kind of research in computer science, I am not sure. https://en.wikipedia.org/wiki/Longitudinal_study

Maybe because of "lifespans"?

People live for ~80 years... doing a 2-4 decade study isn't out of the realm of possibility.

Computers on the other hand... While there are a few mainframes that live to be 10 years old - the vast majority of the internet, program languages, apps, etc... Hell, even the iPhone just hit 10 years old.

How can you have a 20 year study when the majority of "code" is less than 10 years old?

Re: Diminishing returns of static typing

#483

Post by jonnytran »

danharaj wrote: post #28
agentultra wrote: post #10

I think what's often missing from these arguments is that statically checking (or inferring) homogenous lists is probably one of the most superficial uses of the type system in Haskell (and indeed not the interesting feature most power-users of Haskell are interested in as far as I can tell). What is interesting is using the type system to specify invariants about data structures and functions at the type level befor…

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…

I do the exact same thing on large codebases of Ruby, but instead of the compiler type-checking errors, it's the test suite errors.

It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing; it could be well-typed but completely wrong. On the other hand, tests prove that the code does the correct thing in certain cases. ...Of course, it's up to the developers to actually write a good test suite.

The faster we can all accept that there are pros and cons to both, the faster we can come up with a solution that takes advantage of the best of both worlds. That's the whole point of this OP.

I, personally, have always wondered about ways to dial in to the sweet-spot over time as a project matures. At the start of a project, shipping new features faster is often more important. But if the project survives, maintenance (by new developers) and backward compatibility become more and more of a priority.

Re: Diminishing returns of static typing

#484

Post by yawaramin »

catpolice wrote: post #106

Static typing prevents bugs in code to the degree that the programmer can correctly encode the desired behavior of the program into the type system. Relatively little behavior can be encoded in inexpressive type systems, so there's a lot of room for bugs that have nothing to do with types. A lot more behavior (e.g. the sorts of invariants mentioned in agentultra's top level comment) can be encoded in a more expressiv…

> ... and just that level of type information would add a lot of overhead to my code.

Can you give an example of this overhead?

Re: Diminishing returns of static typing

#485

Post by kobeya »

tree_of_item wrote: post #466
kobeya wrote: post #460

Earlier quoted context omitted.

You mean like this: http://hackage.haskell.org/package/hotswap Or this: http://hackage.haskell.org/package/dyre

15 commits 4 years ago, 121 commits 8 months ago If these things are so good why does no one use them? EVERYONE using Erlang is using the same hotswapping facility. This sort of dynamism is just fighting against the language in an environment like Haskell.

Why would you need to? GHCi supports dynamic code reloading which most people do during development. During runtime there’s not so much of a use case though for most people.

Re: Diminishing returns of static typing

#486

Post by catnaroek »

jonnytran wrote: post #483
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…

I do the exact same thing on large codebases of Ruby, but instead of the compiler type-checking errors, it's the test suite errors. It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing; it could be well-typed but completely wrong. On the other hand, tests prove that the code does the correct thing in certain cases. ...Of course,…

> It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing;

So prove it yourself. Proving things about programs that rely on dynamism is invariably much harder than proving things about programs that don't.

Re: Diminishing returns of static typing

#487

Post by catnaroek »

hwayne wrote: post #96
agentultra wrote: post #10

I think what's often missing from these arguments is that statically checking (or inferring) homogenous lists is probably one of the most superficial uses of the type system in Haskell (and indeed not the interesting feature most power-users of Haskell are interested in as far as I can tell). What is interesting is using the type system to specify invariants about data structures and functions at the type level befor…

> The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks. I really wish more languages took this to the logica…

Contracts are useless. They merely describe what you want your code to be, not what your code actually is. Just grab a pen and a piece of paper, and start proving things about your programs.

Re: Diminishing returns of static typing

#488

Post by deepGem »

zmmmmm wrote: post #419
alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. It is a natural assumption when y…

And half the reason we keep throwing code away is because it was created without consciousness of maintainability.

Well, this has nothing to do with static vs dynamic typing. You can write unmaintainable code in static languages very easily. In startups, developers often overlook maintainability, I completely agree but that's because everyone knows that the code you are writing today might not be needed 2 years down the line, you are mostly iterating to find PMF.

Re: Diminishing returns of static typing

#489

Post by catnaroek »

s17n wrote: post #409
zbobet2012 wrote: post #281

Earlier quoted context omitted.

It depends on your type system. In new languages like Idris or F* you can encode in the type the correctness of an algorithm and it will not compile if the compiler can not prove that correctness. For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). Or I could prove that my function squares all elements in a list. Etc. Now a big part of the p…

There's no such thing as "proving correctness". You can have bugs in the type definitions. You can have bugs in the english (or whatever your native language is) description of what you think the algorithm should be doing. You can prove a program does what the types say it should do but that is not what "correctness" means. >Now a big part of the problem is expressing with sufficient accuracy what the properties of t…

> You can have bugs in the english (or whatever your native language is) description of what you think the algorithm should be doing.

According to the principle of separation of concerns, this isn't the programmer's problem.

> You can prove a program does what the types say it should do but that is not what "correctness" means.

Of course, the ultimate arbiter of what “correctness” means is the program specification.

Re: Diminishing returns of static typing

#490

Post by fulafel »

kobeya wrote: post #462
eloff wrote: post #414

Earlier quoted context omitted.

Incredulous that people would downvote this.

I’m in the static camp myself, but there are dynamic language JIT runtimes that meet or exceed the performance of many static languages.

Including the Java runtime - the JVM is basically dynamic.
Post reply on HN