Live data from Hacker News

The advantages of static typing, simply stated

pchiusano.github.io

111–120 of 127 posts

Re: The advantages of static typing, simply stated

#111

It's frustrating that this static vs dynamic 'battle' still goes on. The longer everyone thinks this is actually a problem, the longer we have to wait for innovations to happen. Look at the web in 2016, the technology is a complete disarray. Look at the game industry in 2016, where C++ is thrown around as the the cause and solution to all life's problems. A language created 33 years ago now with no intention of being…

> Look at the web in 2016, the technology is a complete disarray

So that's pretty much been that way since the Java plugin for Netscape Navigator. That started the plugin battle which morphed into the mess we're in today.

> Look at the game industry in 2016, where C++ is thrown around as the the cause and solution to all life's problems.

Software written in C/C++ often have LUA/Python/Perl plugins to add scriptability.

> The advantage of static typing is obvious to me; the more my computer understands of my code, the less work I have to do.

Nope. Computers don't understand code, they just processes it and point out where your errors are, there's very little understanding. Type checking is really just rattling off a checklist to validate the type being passed around is the type that's expected.

Re: The advantages of static typing, simply stated

#112
post #89

Earlier quoted context omitted.

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.

As complexity increases, the probability approaches zero that any code works exactly as desired on first execution. I'd still take that bet. Of course, I'd have to be able to use the REPL about as often as a someone uses a compiler.

Re: The advantages of static typing, simply stated

#113
post #29

Earlier quoted context omitted.

With static typing the computer doesn't "understand" your code. It just automatically checks the correctness proof you've presented to it. And the correctness is limited only to certain properties of the program, that a given type system supports.

We can argue about the definition of 'understand' all day, but it's a simple fact that the computer has more of an understanding of the structure of your program with a type system, and thus can help out more.

I still wouldn't use 'understanding' in that context. It makes as if a static typing compiler sounds "magical".

I could say "python is better at understanding what the programmer wants to do". But I think you'd disagree with me.

The compiler is doing lexical analysis of the program being fed into it. That's it.

Re: The advantages of static typing, simply stated

#114
post #110
post #86

Earlier quoted context omitted.

You make a good point, so I'll answer in parts. First, when most people talk about static typing, they're talking about the near-useless version -- just types like Int and String. I think we agree there, so I won't mention it further. Second, a dynamically typed language like Python has more typing information than some folks first assume. Python's AttributeError is quite similar to a TypeError. In fact, with old-sty…

> First, when most people talk about static typing, they're talking about the near-useless version -- just types like Int and String. I think we agree there, so I won't mention it further. I don't agree. Who is "most people"? Certainly not PL designers and not most of what I've seen here in HN. More importantly, it's also not what the article under discussion is saying, either. > Static typing errs on the side of saf…

> you can have your cake and eat it, too.

Like a dynamic language with optional type hints? As I said, both techniques can mimic each other, with the corresponding tradeoffs. As you use more generics in a statically typed language, you're sacrificing safety. As you use more type hints in a dynamically typed language, you're increasing syntax clutter and decreasing flexibility.

Re: The advantages of static typing, simply stated

#115
post #88

Earlier quoted context omitted.

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

That is a nifty syntax.

Re: The advantages of static typing, simply stated

#116

Earlier quoted context omitted.

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.

The are limits to what a formal proof system can do (eg. The halting problem).

I also have never met someone who claimed to never need tests because of a powerful type system.

Re: The advantages of static typing, simply stated

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

No, not just testing. Most languages have a variety of control flow tools, standard abstractions, and idioms that enable the creation of instantly-familiar interfaces.

Re: The advantages of static typing, simply stated

#118
post #104

Earlier quoted context omitted.

> A language created 33 years ago now with no intention of being used as it is today. You know that they update the language regularly, and have a games sig? https://groups.google.com/a/isocpp.org/forum/#!forum/sg14

Yeah, but C++ has so much baggage with it. It could really use profiles. Strict mode or something, where the code should only use N "good practice" features.

Those are called style guides. Or use the "official" C++ core guidelines. Teams choose/write one and use it as a basis during code review.

Re: The advantages of static typing, simply stated

#119
post #104

Earlier quoted context omitted.

> A language created 33 years ago now with no intention of being used as it is today. You know that they update the language regularly, and have a games sig? https://groups.google.com/a/isocpp.org/forum/#!forum/sg14

Yeah, but C++ has so much baggage with it. It could really use profiles. Strict mode or something, where the code should only use N "good practice" features.

[deleted]

Re: The advantages of static typing, simply stated

#120

Interestingly, most of these advantages are not specific to static typing, but derive from having a language that talks about types – even a dynamic one. For example, most of these advantages apply to Julia as well, a dynamic language that has type declarations, which: - Lets you create typed collections so that if you insert the wrong kind of value, you get an error immediately, albeit only when code runs, not befor…

These are exactly some of the advantages Perl6 has over Perl5. In Perl6 you do have types but they're optional. So you can be as precise or as imprecise (typed) as you like.

In D for instance you do have an auto type, yet it's still a type. An auto function that returns real or BigInt will trigger a compiler error. You need to convert the real to BigInt before any compilation can occur.

Post reply on HN