Diminishing returns of static typing • Hacker News Board

Re: Diminishing returns of static typing

#211

Post by fulafel » Mon, Oct 02, 2017, 6:27 PM UTC

catnaroek wrote: post #119

amirouche wrote: post #70

Earlier quoted context omitted.

Python has jump to definition too.

Does it work in the presence and (ab)use of dynamic features? (e.g., when you have lots of decorated functions) Or is it just a best effort thing? (i.e., only works when your code would actually be expressible in a static way)

This is a continuum... in many statically typed languages there are regularly used paths that lead outside the realm of the language-defined type system as well. Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.

Re: Diminishing returns of static typing

#212

Post by jaggederest » Mon, Oct 02, 2017, 6:29 PM UTC

ubernostrum wrote: post #179

KMag wrote: post #114

Earlier quoted context omitted.

But if the compiler doesn't enforce that types are statically determinable, there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where…

there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically. I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing simil…

When $problem happens to $language_I_prefer, it's an unavoidable difficulty that is easy to work around.

When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.

Re: Diminishing returns of static typing

#213

Post by KMag » Mon, Oct 02, 2017, 6:29 PM UTC

ubernostrum wrote: post #198

always_good wrote: post #117

Earlier quoted context omitted.

You're kinda damning it with faint praise when you say that you can use dynamically typed languages on small projects that fit in your head (and are also probably written by a single developer). You can pretty much use any language in that scenario. But the chickens come to roost around day 30+ or so.

Personally I'd only use a language like C or C++ or Java for a tiny puny baby child's toy program. They're fundamentally unfit for real-world codebases.

I'm probably being trolled, but I'll bite.

How big are the "real-world codebases" you're talking about, and how many programmers are working on the code? Once you hit 5-10 million lines of code and/or thousands of developers, static typing really helps manage complexity.

Re: Diminishing returns of static typing

#214

Post by hellofunk » Mon, Oct 02, 2017, 6:30 PM UTC

avg_programmer wrote: post #191

What are the costs of statically typed languages? The author stated "thinking about the correct types" and "increases compile times" among some other, weaker (imo) costs. What is wrong with "thinking about the correct types"? You are thinking about the same things in a dynamic language, right? For example, say you need to know about things that are "thennable". Weather you are in a statically typed language or not, y…

One very simple and significant cost is developer time. It simply takes less time to write code in a dynamically-typed language. You don't have a compiler to please, you don't write extra code to massage types, annotate types, etc, and most dynamically typed languages are pretty elegant (i.e. Clojure), where you can pack a lot of punch in just a few characters.

So the trade off is: static typing gives you more compile-time certainty, but at a cost of spending more time developing your code. Dynamic typing gets you to a working product or prototype typically much much faster, but with added run-time debugging.

Each has its benefits and costs.

In my experience, there is no doubt that dynamically typed languages are faster-to-production than statically-typed. This doesn't mean that I don't admire static typing, though, because most developers appreciate some degree of purity in their work.

Re: Diminishing returns of static typing

#215

Post by cm2187 » Mon, Oct 02, 2017, 6:30 PM UTC

enraged_camel wrote: post #143

macspoofing wrote: post #60

Earlier quoted context omitted.

I'm so happy to see the pendulum swing the other way, because when JavaScript was becoming popular, and Ruby and Python had a popularity renaissance (around mid to late 2000s), I had a lot of online arguments about the value of static typing. People were complaining about static typing for the dumbest reasons (it's too 'wordy'). It started as a backlash against old-school enterprise Java development (which was fair,…

>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

If you have to write a test for every line of code you write, the "chatty" argument against static typing goes away.

Re: Diminishing returns of static typing

#216

Post by sidlls » Mon, Oct 02, 2017, 6:30 PM UTC

icebraining wrote: post #151

Eire_Banshee wrote: post #41

Earlier quoted context omitted.

This. Not just, "who the hell uses this", but "where the hell is this defined" as well.

PyCharm gets it right 99% of the time. That 1% is hardly worth switching the a different language.

What about the time accounted for in each of those buckets? If "that 1%" accounts for more than 1% of debugging, error chasing, and related time it starts to look more important, yes?

Re: Diminishing returns of static typing

#217

Post by jb1991 » Mon, Oct 02, 2017, 6:32 PM UTC

willtim wrote: post #101

Our industry has not yet even scratched the surface of what types can offer: Types for enforcing architectures and controlling effects, types for checking correct use/free of scarce resources, types for verifying protocol implementations etc etc. Currently, half the industry is using schema-less json and dynamic languages; so really it is far too early to generally talk about any diminishing returns.

In fact, the decades-old CSP model, upon with Go and Clojure's core.async are based, outlined compile-time assurance that there are no race conditions in your multi-threading. You are correct that these two modern implementations of CSP do not go there.

Re: Diminishing returns of static typing

#218

Post by jb1991 » Mon, Oct 02, 2017, 6:32 PM UTC

hwayne wrote: post #121

willtim wrote: post #101

Our industry has not yet even scratched the surface of what types can offer: Types for enforcing architectures and controlling effects, types for checking correct use/free of scarce resources, types for verifying protocol implementations etc etc. Currently, half the industry is using schema-less json and dynamic languages; so really it is far too early to generally talk about any diminishing returns.

There's a lot of great things our industry doesn't use: contracts, proper fuzz testing, cleanroom, formal specification, constraint solvers, _checklists_. We might (not necessarily, but _might_) be in a place where types are diminishing returns with respect to other low-hanging fruit.

When you speak of contracts, are you referring to run-time contracts i.e. Racket?

Re: Diminishing returns of static typing

#219

Post by jaggederest » Mon, Oct 02, 2017, 6:34 PM UTC

TheDong wrote: post #170

actsasbuffoon wrote: post #65

Earlier quoted context omitted.

You can, but you may start to run into some limitations. Many languages have some version of type inference, which allows them to figure out the type of a thing, even though the programmer didn’t specify it. C# has a very weak version of this with the auto keyword. Languages like Crystal take it much further by tracing the flow of data through the entire program. It generally works quite well, though there are a few…

Type inference goes hand-in-hand with static typing. Those are not opposite things. > C# .... Crystal Both are fully statically typed languages with type inference. Those are unrelated to the argument the parent comment is making.

They still both allow generic arguments, in reduction, this means that they still have uncertainty.

I can and have built a totally untyped language within a fully statically typed language - nostrademons' Scheme-in-haskell exercise is a lot of fun.

You just have to define a Universal type and then back out of all that nasty compile-time nonsense. Everything is Univ and Univ is everything.

Re: Diminishing returns of static typing

#220

Post by hellofunk » Mon, Oct 02, 2017, 6:34 PM UTC

snambi wrote: post #93

Any program that is non-trivial meaning 100K+ lines of code, involves many developers over 2+ years of time, should be written in a statically typed language.

That really means nothing. 100K+ lines of code is an arbitrary number. For that many lines of C++, a similar Clojure solution to the same problem would be a small fraction of that. And many widely-used Clojure libraries are in production all over the industry for many years.