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

111–120 of 632 posts

Re: Diminishing returns of static typing

#111

Post by fulafel »

Eire_Banshee wrote: post #56
flavio81 wrote: post #49

Earlier quoted context omitted.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.

There have been references to Clojure, Elixir, Smalltalk, Common Lisp in the comments here, what makes you think just Javascript & Python?

Re: Diminishing returns of static typing

#112

Post by hwayne »

k__ wrote: post #8

I had the same experience, but I also have to say that the static type systems of some FP-languages feel really light-weight. So year, static typing doesn't buy you much, but in some languages it's at least cheap.

> So year, static typing doesn't buy you much, but in some languages it's at least cheap.

I think this is key. The benefit of static typing isn't that they provide safety, it's that they provide _low-cost_ safety. For a large class of problems, types are cheaper than tests are. For other classes, tests are cheaper than types. The main downside of nonstatic languages is that you have to use tests for everything, even that class where types are a better choice.

Re: Diminishing returns of static typing

#113

Post by gwbas1c »

cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

Isn't static typing a requirement when writing an algorithm and data structures for "every bit and clock cycle counts" situations? How can a 0-compute overhead for dynamic typing exist in a dynamic typed environment?

I always thought dynamic typing is a feature for situations where the code needs an extreme amount of flexibility to adapt to a wide variety of data; even at the expense of performance.

Re: Diminishing returns of static typing

#114

Post by KMag »

flavio81 wrote: post #49
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.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

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 the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at.

Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions.

The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.

Re: Diminishing returns of static typing

#115

Post by willtim »

mpartel wrote: post #74
runT1ME wrote: post #68

Earlier quoted context omitted.

> An awful lot of energy was wasted memorizing various tricks and conventions to make do with loops, slices and maps where in other languages you'd just call a generic method. I feel the same way going from languages with HKTs back to Java/C#... Not sure why you think they're not as useful, it sounds like you're making the same argument as OP but just moving the bar one notch over...

I am. I think the OP is fundamentally right about the sweet spot being pretty far from either extreme, I just disagree slightly about where exactly :) Subjectively, I use ordinary generics all the time, but see the need for HKTs only occasionally. It's entirely possible I'm not experienced enough to see most of their possible use cases, but then I'd wager most programmers aren't.

In retrospect, HKTs are arguably Haskells greatest innovation, enabling extremely general abstractions and huge amounts of code reuse.

Re: Diminishing returns of static typing

#116

Post by DanRosenwasser »

19873287234 wrote: post #57
cwyers wrote: post #52

Earlier quoted context omitted.

> vscode seems to figure out the types in javascript without any static typing. Doesn't it do this by treating Javascript as a statically-typed language (Typescript) and using type inference?

No it works without using typescript. I just figures it out through... I have never thought about it. I mean, var p = new Cat();. I am sure it can find the cat definition easy and read the properties and so on. It probably can't prove things 100% but it can guess very well at what things are.

Our team (TypeScript) powers this experience.

Re: Diminishing returns of static typing

#117

Post by always_good »

amirouche wrote: post #79
christopheml wrote: post #29

Earlier quoted context omitted.

My main progamming language at the time is Java, and the amount of assistance my IDE provides is astonishing (to the surprise of no one, it's IntelliJ). The confidence strong automatic refactors provide is of great help when managing large codebases.

I agree that static typing helps reading comprehension and that IDEs like pycharm help getting into big code bases, that said, at the end of the day, when you know the code both the IDE and static typing are getting in the way. Actually, I never saw anybody as quick as people using simple editors like emacs and vim. GUI is getting in the way of the programmers intent. Static typing is a hindrance in front of refactor…

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.

Re: Diminishing returns of static typing

#118

Post by geofft »

Eridrus wrote: post #35
cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

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.

What are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)?

I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.)

One thing that does seem to be true is that the requirement to name types means that a textual grep is way more reliable than it is in C. If I want to find all places where a Python class is used in a large codebase, I might as well give up.

Re: Diminishing returns of static typing

#119

Post by catnaroek »

amirouche wrote: post #70
Eire_Banshee wrote: post #56

Earlier quoted context omitted.

Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.

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)

Re: Diminishing returns of static typing

#120

Post by 3pt14159 »

scarmig wrote: post #71
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…

Although I'm skeptical about the 1 to 3 ratio, let's run with it. Given a million line codebase written in Perl vs a three million line codebase written in Go, which do you think most engineers would prefer?

Honestly the Ruby or Python one, but I've never seen them because you don't need a million lines in Ruby or Python to get something productive built.
Post reply on HN