Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

91–100 of 632 posts

Re: Diminishing returns of static typing

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

>I just figures it out through... I have never thought about it.

Are there not definitions written by someone or a tool that vscode looks at?

That is what I saw using some npm packages with typescript: http://definitelytyped.org/

Re: Diminishing returns of static typing

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

>Tooling is another major argument. vscode seems to figure out the types in javascript without any static typing. >But it is great for refactoring Searching for strings isn't that much worse. Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch. >finding all references to a function or a property or…

The vast majority of development time is spent finding and fixing bugs. Small startups got huge often because they hit the sweet spot of features before anyone else, not because their code was high quality. Once they get large installed bases (and large valuations) they get religion about the value of more strict typing.

The unknowable question is, would they have hit that sweet spot anyways by engineering their product more rigorously, and had less pain later? Or would it have impeded them in the exploratory phase of writing and rewriting their code until they hit that spot?

Re: Diminishing returns of static typing

#95
post #32

Earlier quoted context omitted.

Yes! Many engineers use tools they like for reasons unrelated to the job they're doing or the product they're building.

It might still, at least arguably, be "the right tool for the job." If you have a huge team of expert C# developers C# might be "the right tool for the job" even if it would be a little easier to do in a different language, given the same pool of experts in that language.

Agree. My point is that, if I personally dislike C# (I don't), and I'm on a team of C# experts and C# is the best choice for shipping the product given those experts and all the other use cases, then C# is the best tool for the job and I'll peruse C# documentation. I try my best to focus objectively on the product, not my ego or subjective preferences...and I often fail :(.

Re: Diminishing returns of static typing

#96

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 logical conclusion and implemented first-class contract support. It seems work on contracts stopped with Eiffel (although I've heard that clojure spec is _kinda_ getting there).

Re: Diminishing returns of static typing

#97
post #84

I really enjoyed how the analysis shows that different developers can have different equally valid opinions on this topic. It's where you place your values and preferences of programming, modified by what you are programming. The failure state of a cat photo sharing web app likely isn't as dramatic or important as that of a financial system or driverless car code. Great article.

Static typing reduces the time you spend on debugging. Automatically reducing errors in code is not just for reducing errors in the resulting program. It also greatly reduces the time you spend on hunting bugs, especially if you have a poorly designed type systems where errors are reported far from their origin. Null, interface{}, NaN etc. propagates errors and thus gives you a stacktrace that is worthless when it finally fails. It's a waste of time.

Re: Diminishing returns of static typing

#98
The two languages I develop in are Javascript and Swift. Couldn't be more different in type safety.

I love everything about Swift except the compile times and occasionally inscrutable compile error messages.

I love the interactivity of Javascript, but despise the lack of types, it's like I'm sketching out the idea for a program instead of directly defining what it is. And the lack of types burns me occasionally.

Re: Diminishing returns of static typing

#100

Earlier quoted context omitted.

Python has jump to definition too.

You mean there’s an ide with that feature? It’s never as good as with any statically type language.

Sublime Text has this feature on hover, but I am fairly certain it is based on text search of the modules in the python path.
Post reply on HN