The advantages of static typing, simply stated • Hacker News Board

Re: The advantages of static typing, simply stated

#91

Post by Koshkin » Fri, Sep 16, 2016, 4:15 PM UTC

lallysingh wrote: post #57

xapata wrote: post #45

> Is it safe to call f(x)? The author asserts that static typing allows the compiler to answer this question, but this only allows the compiler to spot type errors in advance. There are many other kinds of errors that are completely invisible to the compiler. In a dynamically typed language, if I don't spot the error from reading the code, I must wait until runtime/testing to discover the error. This is also true for…

> Personally, type errors haven't been the kind of errors that haunt my dreams. The point of strongly-typed systems is that you can represent your constraints as types. This takes extra thinking and work, but gives you almost almost unlimited expressive power (ref: agda). Simple example: meters and feet as different numerical types. When you multiply them, you get a silly unit (foot-meters) that doesn't fit with what…

An even simpler example would be the fact that it makes no sense to add values expressed in different units (without an appropriate type conversion).

Re: The advantages of static typing, simply stated

#92

Post by noelwelsh » Fri, Sep 16, 2016, 4:30 PM UTC

barrkel wrote: post #77

noelwelsh wrote: post #32

Earlier quoted context omitted.

The arrogance (and inaccuracies) in your first paragraph are unnecessary

The chap's lack of experience makes him unqualified to expound in the way that he does. I'm sorry I read the article. I wanted to warn other people away.

The author has been programming professionally for about a decade.

Re: The advantages of static typing, simply stated

#93

Post by staticassertion » Fri, Sep 16, 2016, 5:09 PM UTC

xapata wrote: post #90

staticassertion wrote: post #71

Earlier quoted context omitted.

"Type errors" go way further than "Damn, I passed a string in where I expected an integer". Types are a way of expressing aspects of your code. You can avoid race conditions, you can ensure a program's state is always expected, you can avoid race conditions, you can avoid design errors by encoding the contracts of your design into your types. I think if you're used to a language like Java or C++ you may not see what…

Static typing is one technique for designing safe, easy to use interfaces. Depending on the language, there may be other tools that are just as effective.

Like what? I assume you're referring to testing. Tests are a way to ensure that for some set of inputs you will get some set of desired outputs. And this is assuming you wrote correct tests.

Types are far more rigorous - you can ensure, with types, that your code behaves in a certain way given any input. Yes, this extends to "design" bugs ie: not just crashes - you can write a type that ensures that an API can only be used correctly, for example. You can encode logic like "Don't allow unauthenticated users to access this content" into your type system - and you no longer need tests.

Of course, type systems don't prevent you from writing tests. They actually make it easier, you can generate test cases based on types, as an example.

Re: The advantages of static typing, simply stated

#94

Post by dllthomas » Fri, Sep 16, 2016, 5:22 PM UTC

tigershark wrote: post #47

kbanman wrote: post #43

I've recently joined a team writing primarily in Clojure, whose proponents often tout repl-driven programming as a unique benefit to the language. In a statically typed language (the stronger the better), aided by a good IDE, I don't need to be constantly executing my code against data during development; My editor is constantly validating my code, and when it stops complaining, my code will work. And months later wh…

with F# you have a REPL, it is not only prerogative of dynamic typed languages.

Haskell, too. And these days you can even, if you really want, run things before they type check.

Re: The advantages of static typing, simply stated

#95

Post by jdmichal » Fri, Sep 16, 2016, 5:27 PM UTC

jondubois wrote: post #22

I started programming with PHP and JavaScript (both dynamically typed) then I started writing games with ActionScript 2 (dynamically typed) then I switched to ActionScript 3 (statically typed), then I got into Java (statically typed) and later C/C++ (statically typed) - So I spent a lot of time with both. For the past few years I've been coding almost exclusively in dynamically typed languages - I did some Python (dy…

Forgive me, because I only have what you have said to work with. It sounds like this was a lot of smaller projects with smaller teams? If so, static typing increases value as project size and head count increases.

The more pieces of the project that you didn't write or otherwise have low knowledge of their inner workings, the more dangerous modifying code becomes. It's very useful to have something telling you that everything looks OK. That something can be testing, but why rely on writing good tests when we have formal proof systems available?

Re: The advantages of static typing, simply stated

#96

Post by jdmichal » Fri, Sep 16, 2016, 5:35 PM UTC

StefanKarpinski wrote: post #85

jblow wrote: post #74

Earlier quoted context omitted.

Being able to get these errors without running the code is almost all the benefit. It enables a whole class of highly effective program manipulations that are just unavailable to a non-statically-checked language.

The claimed benefit is getting the error earlier and "at the location the erroneous value is inserted." That's exactly what happens in a dynamic language with typed collections – but, as I admitted, not at compile time. Is it better to get an error at compile time? Sure, but most of the benefit comes from the error being raised at the erroneous insertion and not later when the value is used by some completely unrelat…

Those other "highly effective program manipulations" include refactoring and modifications which involve changing parameter and return types. While I understand what you're saying, to myself it's pretty clear that there's a wide gap between these two scenarios:

* Changing the collection's type and not knowing until runtime -- when your program crashes -- that it's being used wrong.

* Changing the collection's type and the program refusing to compile until all usage is corrected.

Because of this, I don't agree with the most modifier you're attempting to apply. The difference to me is confidence. In the former, how confident am I that I didn't miss a use-case on some branch? Considering that the program will crash or otherwise fail to operate, that seems like something I want to be pretty confident about.

It's very useful to have something telling you that everything looks OK. That something can be testing, but why rely on writing good tests when we have formal proof systems available?

Re: The advantages of static typing, simply stated

#97

Post by hepta » Fri, Sep 16, 2016, 5:39 PM UTC

TheAceOfHearts wrote: post #81

One of my problems with static types in a lot of languages is that they're usually very limited in what they allow you to express. For example: a function that takes an integer between 1 and 100. That's a straightforward constraint! Elixir is an example of a language that lets you express some of those kinds of constraints, by using guard clauses. Along with its powerful pattern matching, you end up with very nice co…

Even though that may be factually correct, it doesn't seem to be related to static typing. Haskell has guards but they are slightly different.

Re: The advantages of static typing, simply stated

#98

Post by jdmichal » Fri, Sep 16, 2016, 5:44 PM UTC

xapata wrote: post #88

lallysingh wrote: post #57

Earlier quoted context omitted.

> Personally, type errors haven't been the kind of errors that haunt my dreams. The point of strongly-typed systems is that you can represent your constraints as types. This takes extra thinking and work, but gives you almost almost unlimited expressive power (ref: agda). Simple example: meters and feet as different numerical types. When you multiply them, you get a silly unit (foot-meters) that doesn't fit with what…

I haven't met anyone other than Haskellians that would create separate types for meters and feet. I also wonder when you would make that distinction in the lifecycle of your application. I suspect not until you first encounter the bug of accidentally mixing units. If so, we'd be solving the problem at the same time, just using different techniques.

F# allows sub-typing of numerics with a unit of measure.

https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...

Re: The advantages of static typing, simply stated

#99

Post by jdmichal » Fri, Sep 16, 2016, 5:49 PM UTC

staticassertion wrote: post #93

xapata wrote: post #90

Earlier quoted context omitted.

Static typing is one technique for designing safe, easy to use interfaces. Depending on the language, there may be other tools that are just as effective.

Like what? I assume you're referring to testing. Tests are a way to ensure that for some set of inputs you will get some set of desired outputs. And this is assuming you wrote correct tests. Types are far more rigorous - you can ensure, with types, that your code behaves in a certain way given any input. Yes, this extends to "design" bugs ie: not just crashes - you can write a type that ensures that an API can only b…

A type checker is a formal proof system. A test determines correctness for a given input. A formal proof system determines correctness for all inputs.

Re: The advantages of static typing, simply stated

#100

Post by jdmichal » Fri, Sep 16, 2016, 5:52 PM UTC

xapata wrote: post #89

Koshkin wrote: post #80

Earlier quoted context omitted.

> conditioned on the complexity Indeed, difference in complexity is the key here.

I'm confused. Are you agreeing with me?

It's a back-handed agreement. Static typing increases value with project complexity and head count. So yes, if you only ever do small tasks with low or singular head count, then dynamic typing probably works OK for you.