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

311–320 of 632 posts

Re: Diminishing returns of static typing

#311

Post by igouy »

gnaritas wrote: post #306
igouy wrote: post #67

Earlier quoted context omitted.

>> finding all references to a function Yes, you can find all references to a method in Smalltalk -- but those references are not separated-out from all the references to other methods that happen to have the same method name but are defined on a different class. With type information for the receiver and method arguments, we can find just the references we're looking for.

Which is why Smalltalk's refactoring browser has a manual intervention step to allow you to see what it proposes to do, and remove any steps you don't agree with, as well as the ability to scope your refactorings to a package or class to limit the scope to more relevant data. Either way, it's sufficient to get 99% of the benefits of automated refactorings without the 100% guarantee static typing provides; good enough…

> Automated refactoring was invented in Smalltalk, claiming it's a benefit only static typing provides is to not know history.

History: In Bill Opdyke's thesis work, the tooling was written for C++ and written in CLOS.

http://www.laputan.org/pub/papers/opdyke-thesis.pdf

Re: Diminishing returns of static typing

#312

Post by flavio81 »

kazinator wrote: post #297
gopalv wrote: post #201

Earlier quoted context omitted.

> In dynamically typed languages you kind of just grep and hope the name is not too common. For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work. And very quickly, the whole team became fans of __slots__ in Python. I still write 90% of my useful code in python, but that one week of deb…

TXR Lisp, a dialect I created: $ txr This is the TXR Lisp interactive listener of TXR 185. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (set a.b 3) ** warning: (expr-1:1) qref: symbol b isn't the name of a struct slot ** warning: (expr-1:1) unbound variable a ** (expr-1:1) unbound variable a ** during evaluation of form (slotset a 'b 3) ** ... an expansion of (set a.b 3) ** which is located at…

>There is dynamic and then there is crap dynamic. (...) There is crap static too.

Excellent. My point exactly. I have no fear of using a static or dynamic language, as long as it is a good implementation of a statically (or dynamically) typed language.

Re: Diminishing returns of static typing

#313

Post by igouy »

KingMob wrote: post #157
igouy wrote: post #67

Earlier quoted context omitted.

>> finding all references to a function Yes, you can find all references to a method in Smalltalk -- but those references are not separated-out from all the references to other methods that happen to have the same method name but are defined on a different class. With type information for the receiver and method arguments, we can find just the references we're looking for.

I can't speak to Smalltalk, but any namespaced Lisp system can figure out what references what. The key is that the searches happen through the REPL, not grep/ag. So if I tell CIDER to find all instances of a Clojure symbol, it can use the namespace to avoid false positives.

Are you saying that reduces the number of false positives or are you saying that eliminates false positives?

Re: Diminishing returns of static typing

#314

Post by wstrange »

crdoconnor wrote: post #299
andrewaylett wrote: post #155

Earlier quoted context omitted.

Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.

>there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case. By adding sanity checking asserts in a dynamically typed language you can achieve more or less the same result.

If you are going to add a bunch of asserts, why not just use types?

Re: Diminishing returns of static typing

#315

Post by Merovius »

Arcsech wrote: post #78
ridiculous_fish wrote: post #42

Earlier quoted context omitted.

If you believe there are no diminishing returns, I'm interested to hear your reply to the author's question about why we don't all use Agda or Idris.

Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet. They're still missing many commonly-needed libraries, compile times are slow, the tooling isn't great, etc etc. Getting a language to the point where it's workable for serious projects is a lot of work. Rust is getting there with the backing of Mozilla, Haskell has made some decent strides too (but still has a way to…

> Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet.

It's also self-evidently wrong. Agda was first released in 1999, ten years before Go. If you use a wallclock interpretation of "maturity", Agda is twice as old as Go and Idris is roughly as old as Go. Both are used significantly less (by several orders of magnitude), though. Despite them having a far stronger type-system.

If you, on the other hand, you are using a "developers' time" interpretation of maturity, on the other hand, you are making a circular argument, i.e. "Agda is seeing less use, because it has been used less", as resources invested in a language ecosystem tend to be strongly correlated with it's usage.

Re: Diminishing returns of static typing

#316

Post by zzzcpan »

smaddox wrote: post #72
zzzcpan wrote: post #36

"I don't think it's particularly controversial, that static typing in general has advantages" That's not really true, just a belief. I give you an example to start understanding these things: the exact same program written in a very high level and very expressive language, like Perl, instead of Go, is going to have at least 3 times less code and since defect rates per line of code are comparable, you would end up wit…

"...and since defect rates per line of code are comparable..." That's not really true, just a belief. A naive belief, if you ask me.

That claim is supported by more than one study.

Re: Diminishing returns of static typing

#317

Post by tome »

ubernostrum wrote: post #197
whyever wrote: post #165

Earlier quoted context omitted.

No, you don't have to write tests for invariants enforced by the type system.

I think the bigger idea is that people who've never actually written serious code in a dynamically-typed language assume that people who do always write a bunch of extra unit tests to assert correct types, assert behavior on incorrect types, etc. etc., and that programs crashing due to type errors is a super frequent occurrence. None of those things are true.

And yet there are dynamic language proponents in this very subthread suggesting that's exactly what everyone should do.

Re: Diminishing returns of static typing

#318

Post by golergka »

crdoconnor wrote: post #291
macspoofing wrote: post #255

Earlier quoted context omitted.

>Static and dynamic typing each have their own benefits, I struggle to think of any benefits of dynamic typing on a reasonably sized code-base (e.g. 50k+ LOC).

>I struggle to think of any benefits of dynamic typing on a reasonably sized code-base Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in. I'm frankly surprised nobody brings it up more often but the prototypical example of "static typing done right" - Haskell - is talked about nearly constantly but when I look for actual software I might use that's written usi…

"Quick to develop in" doesn't sound as a very good thing to me - because it usually means "slow and hard to maintain for the next guy".

Re: Diminishing returns of static typing

#319

Post by tome »

Silhouette wrote: post #193
sacado2 wrote: post #87

Earlier quoted context omitted.

Defining types is easy and enhances code readability until you go too far. Some type declarations in Haskell or highly templated C++ are hard to read.

While this is a valid point, it's also worth remembering that if you have a data structure of sufficient complexity that writing out its type is cumbersome, then your data is still in that structure whether you choose to be explicit about it or not. Any code reading or modifying some element within that data still needs to correctly find that element, and if writing out the types is a burden then probably finding the…

Absolutely. Sometimes the type is too complex not to be explicit about it.

Re: Diminishing returns of static typing

#320

Post by lomnakkus »

kazinator wrote: post #297
gopalv wrote: post #201

Earlier quoted context omitted.

> In dynamically typed languages you kind of just grep and hope the name is not too common. For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work. And very quickly, the whole team became fans of __slots__ in Python. I still write 90% of my useful code in python, but that one week of deb…

TXR Lisp, a dialect I created: $ txr This is the TXR Lisp interactive listener of TXR 185. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (set a.b 3) ** warning: (expr-1:1) qref: symbol b isn't the name of a struct slot ** warning: (expr-1:1) unbound variable a ** (expr-1:1) unbound variable a ** during evaluation of form (slotset a 'b 3) ** ... an expansion of (set a.b 3) ** which is located at…

It seems to me that you've just invented a static type checker. (Combined with a run-time type checker.) Am I mistaken?

I mean, we can argue the semantics of what, exactly "static type checker" means, but...

Post reply on HN