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

291–300 of 632 posts

Re: Diminishing returns of static typing

#291

Post by crdoconnor »

macspoofing wrote: post #255
hellofunk wrote: post #190

Earlier quoted context omitted.

> Thank God people are coming to their senses. There are no senses to come to. Static and dynamic typing each have their own benefits, and there are genuine tradeoffs to choosing one over the other. That we are even having this debate in 2017 shows that the world of typing is not a "solved problem" and there are still good reasons to use one over the other for various reasons.

>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 using it.... there's so little it's almost embarrassing. One obscure window manager, one obscure VCS, facebook's spam filter and some tool for converting markup.

Given a sprinkling of asserts, a decent linter and a high level of test coverage I don't see much of a benefit to adding static typing.

Re: Diminishing returns of static typing

#292

Post by avip »

gopalv wrote: post #201
Eridrus wrote: post #35

Earlier quoted context omitted.

I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.

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

Could you clarify - did you go over all classes in your codebase and added __slots__ attribute? Or you have some tooling to do that for you? I don't have any clear counterargument but that sounds wildly unpythonic thing to do.

Re: Diminishing returns of static typing

#293

Post by pkd »

andrewla wrote: post #244
flavio81 wrote: post #148

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…

It's Camp D that I'm least familiar with here; outside of academic projects in lisp/scheme I've never used them for anything serious. What exactly does it mean to have "good dynamic typing facilities"?

If you Google, you can find tons of good stuff written in Lisps. Julia is an up-and coming language - but it is highly regarded by the data science community.

> What exactly does it mean to have "good dynamic typing facilities"?

The ability to change the structure of your program at runtime will be at the top of the list for me. You can't do that with Ruby/Python.

Re: Diminishing returns of static typing

#294

Post by crdoconnor »

rbobrowicz wrote: post #203
enraged_camel wrote: post #143

Earlier quoted context omitted.

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

Personal anecdote: I worked on a small Python project some years ago and we had a type error in production despite having tests. We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return…

>or the author of the library for bad design

That's the one. That's a damned stupid decision.

Re: Diminishing returns of static typing

#295

Post by coding123 »

kjaer wrote: post #288
coding123 wrote: post #276

I'm converting a codebase of Javascript of about 200+ js files to Typescript today. I am about 5% complete... already found two places where the argument list was wrong and was being sent into a void. I also see the code that was making up for the fact that the third argument was being ignored (basically patching downstream because they thought the feature was broken). Now this codebase was written with a high degree…

If you're just rewriting these Promises because the syntax is too verbose, you might be interested in checking out async/await as another alternative; I just rewrote some Promises to that recently, and it's really, really nice. Of course, if you prefer RX Observables, go right ahead :)

Thanks for the note, I am looking into it right now. One area that may grind my head with async await however is that there is a lot of Promise.all work in this codebase. Would you still use async/await constructs when you need to do a lot of fork/join/merge stuff? (sorry for the derail HN)

Re: Diminishing returns of static typing

#296

Post by pkd »

nnq wrote: post #283
fulafel wrote: post #205

Earlier quoted context omitted.

What makes you put Python and JS in the same basket here? Python is widely raised as a language that has a good dynamic typing system with strong types and good type error handling - arguably better than Lisps (nil punning). JS is infamous for the opposite. Macros are quite orthogonal to this.

> Macros are quite orthogonal to this. You ain't gonna to find any sane way to combine macros with a powerful type system in a way the doesn't make a 140+ IQ a requirement for any programmer touching the code using these features in a real world project... Problem with programming language design is that the ideal/Nirvana solutions lie at the edge, or beyond, the limits of human intellect. If you want something that…

There is a programming language property called Restrictability - it means that you only need to know a subset of the features the language provides to become productive. The best languages have high restrictability without compromising on the high level features like powerful macros.

The point of having macros is that they allow you to solve problems that cannot be solved elegantly in any other way. But 95% of programmers don't need to solve such problems and can do very well without using macros.

Re: Diminishing returns of static typing

#297

Post by kazinator »

gopalv wrote: post #201
Eridrus wrote: post #35

Earlier quoted context omitted.

I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.

> 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 expr-1:1
Both warnings are static. If we put that into a function body and put that function into a file, and then load the file, we get the warnings.

The diagnostics after the warnings are then from evaluation.

Those are nothing; TXR Lisp will get better diagnostics over time. I'm just starting the background work for a compiler.

There is dynamic and then there is crap dynamic.

Don't confuse the two.

There is crap static too. Shall we use C as the strawman examples of static? Hey look, two argument function called with three arguments; and there's a buffer overrun ...

Re: Diminishing returns of static typing

#298

Post by macspoofing »

lordCarbonFiber wrote: post #259
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).

Cheap and plentiful dev talent. Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev. There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.

>Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev.

I expect any programmer to be able to transfer their skillet to a new programming language - especially when we're talking about mainstream languages with a GC.

>There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.

What kind of agility multiplier? Maybe it makes a difference during a hackathon where you have 24 hours to put something together or maybe if you're putting together shell scripts ... but taking something to MVP takes weeks or months - mainstream dynamic languages simply don't have any edge in development speed in those instances.

Re: Diminishing returns of static typing

#299

Post by crdoconnor »

andrewaylett wrote: post #155
enraged_camel wrote: post #143

Earlier quoted context omitted.

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

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.

Re: Diminishing returns of static typing

#300

Post by djur »

tiuPapa wrote: post #252

So the article does praise Go, but how is Rust? Does it strike that sweetish spot? Is it a language a startup should use?

Rust's type system is much closer to Haskell than Go, and even advocates of the language will admit that it can sometimes be very difficult to convince the compiler that your program is valid. Compile speed isn't great either, although it's been improving. I would say that Rust is pretty much on the other end of the scale from the author's supposed "sweet spot".
Post reply on HN