Hacker News Reader

Comment by lisper | Hacker News Reader

> They [dynamic types] have potential to be more than "no static types", but that hasn't happened.

It happened thirty years ago:

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...

But the thing that really drives me nuts about this never-ending debate is that static and dynamic are not a dichotomy. You don't have to choose one or the other. You can have both.

The real choices are:

1. Do you want the language to require the coder to provide type information (e.g. Java), or permit the coder to provide type information (e.g. Common Lisp) or forbid the coder from providing type information (e.g. early versions of Python, Javascript).

2. How much work do you want the compiler to do with regards to finding potential problems at compile-time, and what do you want it to do when it finds one? Options include: do nothing (e.g. Javascript), warn if it finds a problem (e.g. C), or forbid you to run the program if it finds one (Java, Haskell).

Personally these choices have always seemed like no-brainers to me: allow but don't require type information, and warn when the compiler finds a problem but allow the program to run anyway. What possible advantage is there to be gained from any other choice?

View on HN

> What possible advantage is there to be gained from any other choice?

You're thinking like a single individual. Almost all programming that happens in the real world is in teams, and most of that probably within companies.

Teams and especially companies often benefit from strict standards that keep everyone on the same page and make it harder to screw things up.

> Teams and especially companies often benefit from strict standards that keep everyone on the same page and make it harder to screw things up.

Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch". That still allows you to, for example, test parts of an uncompleted program, which can vastly improve productivity. Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude.

The issue with enforcement by policy is it puts the onus of checking things on whoever is enforcing the policy.

Which is usually either no-one, or an already busy/overloaded team lead or (even worse) manager.

Every software engineering organization I’ve been at either wanted, or put in place, automated policy enforcement because otherwise it either never happened (and hence there were constant problems), or everyone hated doing it because it felt like a waste of their time (with it’s own constant source of problems).

it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Ideally before it can be part of any product, or be depended on by other work that would need to be refactored.

Which automated tools can do cheaply. If it is in the compiler, even better!

Doing it manually delays the feedback cycle, AND burns people decision energy, which is almost always the thing everyone is in the shortest supply of anyway.

> it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible.

Sure. But it does not follow that it is beneficial for your language to forbid you from testing some code you wrote over here until you fix a completely unrelated problem over there, indeed until you fix every single problem that the compiler can find.

> Doing it manually delays the feedback cycle

I'm not talking about "doing it manually", I'm talking about the compiler issuing warnings instead of errors.

If you can check in those problems, and make them problems for everyone else - it absolutely is an issue!

If the policy is ‘you can generate “warnings” all your want locally, but you can’t check them in’ then sure.

The issue of course is folks want to check things in as soon as they ‘work’ in their basic use case, even if it means bypassing a bypassable alert.

So it means enforcing it at check-in time, in a non bypassable way (usually), which just means folks have a lot of ‘hidden’ cleanup to do before submitting, while they have their code ‘working’, which is always a drag.

Such policies should be defined by the company, not enforced by the language.

Even in static languages world, a lot of projects allow dev/nightly builds to be unstable. Which is literally what you're talking about: checking in problems for everyone else.

But checking in policy is a VCS/CI domain, not a language domain.

And what is to prevent someone from checking in code that doesn't compile?

> whoever is enforcing the policy.

CI/CD, based on CTO edict? Have them (or their startup equivalent) make the edict at the start of the company's lifecycle for best results.

Don't make it a human procedure, make it a "you're physically unable to deploy until tool X doesn't throw a warning". Anything else will, as you say, fail.

> Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy

Yes, policy debates are amazing, so fun, so productive. And nothing funnier than having to discover completely new and incompatible policy when changing company, or trying to change policy.

That's one of the few good things I have to say about Go, they considered policy debates and went "fuck that". I think they went too far and wrong in lots of ways, but on that front I can't fault the heart, even if I hate the language.

> Yes, policy debates are amazing, so fun, so productive.

Who says there's going to be a debate? The commit hooks and/or CI pipeline should prevent you from merging code that doesn't pass typecheck. It's still enforced by tooling, just at a different place in the process.

Which lets folks get deeper into trouble before running into a wall.

Well, you're going to want those checks regardless because, if we really want to be pessimistic, developers can commit code without running the compiler locally anyway.

The question is really, before you commit/push your code, and you just want to run the code, do you really need to be prevented from running the code just because it didn't pass typecheck? I'm inclined to say no.

It’s not being pessimistic, it happens all the time, which is why CI/CD is a thing. It’s also why if it’s a compiled language, I’d personally want to know if it’s definitely not going to be working if I go to check it in right away.

If I wanted something that could kinda work, I’d just use a scripting language?

I don't see any reason that policy debates should be any more problematic than language debates.

Language debates are over once a substantial amount of the code has been written. Policy debates continue eternally.

This is silly. There are tools that enforce the types of policy we're talking here very well.

In a TypeScript codebase you would not let CI pass if the TypeScript build fails. Locally you can still run the output. There's not much room for debate and I've never seen a TypeScript project that both has CI and allowed failing builds to be merged. I've also never heard of someone proposing that PRs failing to build should be allowed to be merged.

Not every team has eternal policy debates. Eternal debates indicate a deeper problem with the engineering culture. I'd rather have that problem become visible so that I could address it, than keep it hidden under a pile of irreversible decisions.

I do. Policy is up for debate. If your codebase is in <x> the debate is over

> They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch".

I laughed out loud when I read this.

Funny thing is, this would work where I'm at now, Google, because Google actually has an enormous number of presubmit checks that require all KINDS of things out of your code, it's practically crazy how many checks it runs. Since there's already so much setup for these checks, yeah adding one more would be fine (and it already does this for type annotations for dynamically typed languages like Javascript).

But most places aren't Google, and it's way more realistic to prevent this kind of problem by just having a language that'll enforce it automatically, then you never have to think about it, or have a policy debate, or always make sure during code review to look for that thing, etc.

If I'm putting out some small open source library where I might get an occasional pull request, I'd much rather have the language automatically enforce correct typing than have to remember to look for it myself every time (and then possibly miss something if I screw up).

Well, sure, they don't have to be. As a team you can come to an agreement on policies, and if you have the time, you can set up linting or configure your tools to make sure that they are enforced in CI. We use Rust and TypeScript at work, and for the latter we've made some effort to make it as strict as possible, and even added some eslint rules to enforce things more. But it sure is nice when the language itself does that by default for you, so you don't have to advocate for lint rules or tsconfig options and spend time setting them up. Plus, if it's built into the language, it effectively means that even people outside your organization are following the same policies as you.

All that being said, your point is a valid one. It's a tradeoff and depending on what you're used to, you'll feel the pain from one approach or the other more strongly.

> Don't push anything that produces warnings to the master branch

I have never worked on a project that has actually followed such advice.

> Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude.

This sounds insane to me. Do you really think needing to specify types up front saves you that much time?

Multiple orders of magnitude means you're talking a 100x speedup at minimum.

Could be right. Make a change in one place to see how it behaves, code elsewhere that wouldn't be executed for your test input now doesn't compile - do you get to learn from that experiment now, or do you have to go and placate the compiler temporarily first.

For example, making unused function arguments a fatal error would be an easy place to increase iteration time.

Initially I disagreed with you, but I do see value in what you propose, but I would implement it the other way around — add an option to the compiler that turns type check errors into warnings only, say dev mode.

Then the following arguments are moot, as CICD will run it in the “sane default” setting.

Even a single individual has to team up with his past and future selves.

Those standards don't have to live between the individual and every single execution, though.

> and warn when the compiler finds a problem but allow the program to run anyway

Your compiler giving you a type check error is saying that the program is meaningless. What is the advantage of running a program that is known to be wrong?

The design of the type system will define what is meaningful/meaningless per type check rule (eg a missing branch which can be a warning vs an ambiguous type inference that means the program cannot be compiled). The question is really whether you want to design a type system that can be checked statically, which to me the no-brainer answer is "yes."

I don't want to have to run the program to know if it type checks. I don't want to have to run it to know what types are in the program, or the signature of functions. I want my tool to tell me when my code is provably wrong, and to prevent provably wrong code from being merged into a codebase without executing it.

> Your compiler giving you a type check error is saying that the program is meaningless.

The TypeScript compiler will absolutely give you errors for well-formed programs that are guaranteed* do the right thing with respect to what the author intended and that anyone else can see is correct but that the TypeScript compiler itself doesn't reason about correctly. In instances where this happens, it's very useful to be able to ignore them—just like you might ignore the protests of a misinformed team member who insists that such-and-such won't work, even though it provably will. (Although the alternative of just not using the TypeScript compiler can be a worthwhile decision as well.)

* not to be confused with undefined behavior in C where it might just happen to work with one known compiler/platform combo but break horribly for other valid targets

The cost for this is that programs with type errors must still be specified to have a well-defined semantics. That in turn means that you can't hang useful language features off static types.

For example, TypeScript explicitly declares as a design goal that they don't use the type system to generate different code:

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Meanwhile in Dart, you can write:

   double d = 1;

In Dart, doubles and integers are different types with different representations. The above line of code works because if we see an integer literal in a context where a floating-point number is expected, we implicitly treat it as a double literal. Note that there's no runtime conversion here. We can do this because Dart does have a sound type system and is happy to use it for language features.

That's also why Dart (and other statically typed languages) support extension methods while TypeScript does not:

https://github.com/microsoft/TypeScript/issues/9#issuecommen...

If the language gives users the ability to type their code, it's really nice to be able to give them as much value in return for their effort. That means building language features on top of them and using types to generate smaller, faster code.

But languages with unsound type systems or that treat programs with type errors as well formed can't really do that.

> Your compiler giving you a type check error is saying that the program is meaningless. What is the advantage of running a program that is known to be wrong?

Well one bit is you might not be looking at the meaningless part.

Sometimes when doing large refactorings or updates never getting to run, try, or look at anything is discouraging. It's a great feeling when it compiles and everything works (or near enough), but spending two days cycling between compiling and fixing compilation errors is not as enjoyable as e.g. seeing the unit test report's green bar tick up.

Maybe compilers should provide more enjoyable feedback, not just better error messages (though I fully support that movement).

I'm not sure I get what you mean by "you might not be looking at the meaningless part"?

What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean?

> I'm not sure I get what you mean by "you might not be looking at the meaningless part"?

For example, you might not be pushing buttons that trigger the meaningless part, but the other parts of the system might still be functional.

> What's the difference between seeing a bunch of test failures and fixing them one by one until the test suite is all green, and seeing a bunch of compiler errors and fixing them one by one until the compiler runs clean?

The difference is in one of the cases a highly qualified professional has freedom to decide _when_ to do the fixes.

If there is a pretty graph or not? (Not joking)

Speaking of which, that WOULD be a cool IDE feature. I always liked the feeling of my junit bar going all green after a big change.

Large refactoring and updates are exactly where strong type systems are the most useful. Make change, fail build, fix build, be happy. Unit tests are still there to turn green when you're done.

I can't think of many worse experiences than my past self trying to refactor Python 2 code. Compared to _any_ type system it's just not even close.

Have you considered reading what I actually wrote rather than just hook onto a pair of words and ignore everything else?

I agree. Sometimes I'm prototyping something or feeling my way down one possible implementation -- it's a lot more efficient to go deep in one area of the codebase and come back to fix up everywhere else later once I'm sure this is the right trajectory. In my day job, I use Flow.js which gives me this and I'm a little hesitant to give that up, given there's no many static type checkers that work this way.

I get the sentiment, but ime this speaks more to architecture and code organization than the merits of static typing. It's always possible to skip type checking by designing the software to be modular enough that unreachable code isn't included in the local build.

Like updating data structures should never result in days of work before you can run simple tests. Create a new build artifact that only pulls in the new data structures and the software modules you're working on (and their tests). If you need to pull in the universe to run any unit tests, they aren't unit tests.

> What possible advantage is there to be gained from any other choice?

Substantially better performance, which still matters in some domains.

If you occupy any space on the spectrum besides fully static typing, you must represent and check your types at runtime. This means that every object (even Int and Bool!) needs to have a header that tells the runtime what type it is, which can quite literally double your RAM requirements.

If a language is already including object headers anyway (like Java does), you're correct that there's not an enormous barrier to embracing gradual typing [0]. But there are a lot of places where we really do still care about RAM usage, and erasing types at runtime is an obvious place to free up a lot of RAM very quickly.

[0] Indeed, you can sort of do this in Java already by just typing everything as Object and coming back later to correct it with actual types, though please don't actually do this.

> If you occupy any space on the spectrum besides fully static typing, you must represent and check your types at runtime.

If the language requires you to give at so much type information that the compiler can infer all the types, I would say that language, from the compiler’s view, would have fully static typing, so it wouldn’t have to do any checks at runtime, but from the programmer’s viewpoint, it could look as if it didn’t have fully static typing.

The modern auto to deduce a type in C++ makes a small step towards that, but I think it could be taken further. The language could deduce types both in the direction “if you pass foo to a function taking an integer, it must be an integer” and “if you only pass integers to bar, bar must take integers”.

I expect it will be hard to specify a powerful algorithm for filling in the blanks that feels natural to programmers, though. If the compiler frequently complains about missing type information where the programmer doesn’t understand why it complains, the language won’t be popular.

> I expect it will be hard to specify a powerful algorithm for filling in the blanks that feels natural to programmers, though. If the compiler frequently complains about missing type information where the programmer doesn’t understand why it complains, the language won’t be popular.

This is the problem in a nutshell. Folks in the optional typing and gradual typing communities have been trying to pull this off for decades and so far no one has been able to come up with a language that:

1. Lets you ignore types completely and write dynamically typed code in some parts of the program.

2. Gives you the expected performance of completely typed code in parts of the program that are typed.

3. Is sufficiently pleasant to use that it gets adoption.

There are languages that give you either 1 or 2 along with 3. There may be some language out there that gives you 1 and 2 but if so, it doesn't give you 3 or I would have heard of it.

I suspect it's intractable.

What you're describing is already common in functional languages such as OCaml and Haskell. They tend to use the Hindley-Milner type system, which allows for exactly the kind of non-local inference you're talking about (where `auto` is only for local inference): https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...

However, better type inference does not mean that a language is no longer statically typed, it just moves a lot of the burden of assigning types from the programmer to the compiler. You still don't have as much flexibility at runtime, and you still can't run your code until the compiler can prove that it it correctly typed. The only thing you get is less syntax, not dynamic semantics.

That has been done by Haskell for example for decades. Look into Hindley-Milner type systems.

> 1. Do you want the language to require the coder to provide type information (e.g. Java), or permit the coder to provide type information (e.g. Common Lisp) or forbid the coder from providing type information (e.g. early versions of Python, Javascript).

Liberties are rarely created and destroyed. Instead, they tend to be trasferred from one place to another. So an equally valid way to phrase this question is from the compiler's perspective:

1. Do you want the compiler to be able to rely on the presence of type information (e.g. Java), or sometimes have access to type information (e.g. Common Lisp) or be forbidden from using type information (e.g. early versions of Python, Javascript).

In that equivalent formulation, the value proposition of static types is clearer: When the language specifies that everything has a computable static type, then the compiler can rely on types for useful language features (extension methods, overloading, static dispatch, etc.) and to generate smaller, faster code.

Dynamic types give the programmer some liberties (they can not worry about types) but takes some others away (they can't reach certain performance goals or use type-dependent features). Static types do the opposite. Pick your poison.

Adding to this, there's a set of language features which use the type system to generate code. So, things like traits in Rust or Typeclasses in Haskell use the type system to infer which instance is being used and insert a dictionary of trait method implementations as the first argument to your polymorphic function. You can't really do this kind of thing if the compiler can't do `Type -> code` and is only verifying the types are consistent.

A pseudocode example is something like:

    trait ToString for T {
      fn toString(self: T) -> String;
    }
    
    impl ToString for number {
      fn toString(self: number) -> String {
        // implementation here
      }
    }
    impl ToString for Point {
      fn toString(self: Point) -> String {
        return f"({self.x.toString()}, {self.y.toString()})";
      }
    }
    
    fn printString<T: ToString>(t: T) {
      print(t.toString());
    }

Then when it generates code, it uses the inferred type information to generate different code:

    let p = Point(1.0, 2.0);
    printString(p);
    // translated into
    printString(implToStringForPoint, p);
    let n = 2.0;
    printString(n);
    // translated into
    printString(implToStringForNumber, n);

And then type inference becomes implementation inference, which is really powerful

Beside performance impact, how is it different than what is possible with virtual method (dyn dispatch)?

Virtual dispatch makes it much harder for an optimizing compiler to inline method calls, so there is a significant performance hit even for callsites that do end up always calling the same method.

In AOT compiled languages at least, it is an often performed optimization in JIT compilers.

Also, I was explicitly asking besides performance.

Since you have the concrete type, you can do stuff like storing it inline (which may not be possible if you don't know its size).

One jump vs. multiple pointer dereferences.

OP also glossed over the important distinction between opt-in static types (TS, Python etc) and opt-in lack of them ("dynamic" in C#). When talking about what's permitted, these are functionally the same, but the difference has an immense effect on the actual idiomatic use.

I would argue that something like "dynamic" is preferable in a sense that it gives you an escape hatch with minimal syntactic overhead for those cases where dynamicity is really that beneficial, yet defaults to a safer option that's usually the best choice.

Isn’t dynamic’s primary purpose is multiple dispatch methods? In an OOP language (not caring about primitives and non-objects), you can go “dynamic” typed by using Object, and casts.

"dynamic" literally behaves as if the variable declared such had the actual type of the object at runtime every time that it's referenced, and under the hood it is all implemented using casts and reflection (and a lot of caching to make it fast enough - that's the DLR bit). So method calls are still single-receiver, it just makes them behave as if all methods were virtual.

I guess the part where it will also pick the correct overload at runtime depending on the actual type of the arguments is a bit like multiple dispatch, especially if the argument itself is "dynamic". I'd say that the difference is that the list of possible candidates is closed once the class is defined, so even if you declare a new type, you can't customize the behavior when passing it to an object of an existing class.

> What possible advantage is there to be gained from any other choice?

If you're the only one writing the entire stack of code that gets bundled into the delivered program, you're right, no real advantage from other choices.

But as that's rarely the case, there is a lot of advantage from having a forced type system. Otherwise your code might be great but you're pulling in libraries and code from many other teams who chose to omit type info and/or ignore all warnings so you still have the same problem.

> Otherwise your code might be great but you're pulling in libraries and code from many other teams who chose to omit type info and/or ignore all warnings so you still have the same problem.

This is actually a really great argument. Having well-typed dependencies is a real benefit. But I would say you don't need to force typing on people to achieve that. In my experience with gradually typed languages (TypeScript and Erlang) you tend to see decent adoption of typing in prominent libraries. There are natural incentives (i.e. crashing software) that drive people away from depending upon libraries that don't have strong type guarantees.

Haskell can actually do the "warn if it finds a problem" option: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...

I've been meaning to write up something comparing dynamic typing + SLIME to -fdefer-type-errors and ghcid...

The existence of this option is what actually finally convinced me to give haskell a real try, but I have to say, I haven't actually ever used it. I alwyas just use undefined to defer any type error, actually seeing each spot there is an error and comprehending how to delay the problem for later basically seems to help me comprehend the problem I need to solve.

In Haskell, type information is used to generate code. And not just in fancy metaprogramming libraries like Servant - any use of chained type class resolution is generating code for you based on static type information. How does that power fit into your framework?

> What possible advantage is there to be gained from any other choice?

I was with you until your last sentence. The world of programming is a lot bigger than your tiny corner of it.

I could be working in a safety-critical situation, where preventing errors is more important than developer velocity.

Or, I could just have that one annoying co-worker who checks in stuff that "works for him", but always crashes when others try to use it.

Or...

You can still enforce all of those constraints in your commit hooks or build pipeline, without enforcing them on an individual developer's machine.

This is the best opinion about this topic I’ve ever read and I thought that after 20 years of programming in as many languages I knew them all.

Thanks!

It's not just about type information; in fact, having type information doesn't mean anything in its own right. The point is in static analysis, which can be mandatory (most statically typed languages), or optional (e.g. Python).

I am not aware of any static languages that check the types at runtime (if such languages exist, please mention them in the comments); however. they require a static analysis to happen at compile time, and refuse to compile if the analysis breaks at any point. Python, on the other hand, allows to be compiled and executed without ensuring the type safety first; however it can still be statically analyzed, even without explicit type annotations, using an optional tool such as mypy (which can infer types quite correctly in many cases).

Most languages do some checks at runtime. This is the strong / weak typing dichotomy (which is different from the static/ dynamic one).

For example, Java will throw an exception at runtime if an object is cast (using .asInstanceOf) to an incompatible class. Python throws if you add an integer to a string. Both of those languages are strongly typed.

On the other hand, C has no runtime checks whatsoever. If you add a number to an array the program will happily move the array pointer and maybe overflow, but even that won't cause a runtime failure every time.

This is precisely my point. In the examples above, the checks are implemented in specific cases, and not universally; so the whole point of static typing is the analysis, and not runtime safety.

Eclipse IDE (Java) can run your project, even if it doesn't all compile.

I expect this must be fairly common among IDEs with incremental compilers. You can run valid sections & gradually progress the complete correctness. No need for a dynamic language.

With static typed language, reliability and refactoring are easy.

I'm scripting some small scripts in Python this week but every time I come back to it, I am reminded how not actually very good it is.

Why do you want to run programs that are wrong?

There are two reasons you may want to run a program that fails typechecking:

1. The program is in fact correct, but the typechecker can't prove the program is correct and so reports it as a failure (for contrast other typecheckers only report errors if it can prove that there is an error)

2. The type checker is correct in that the program is flawed in some way, but you are the middle of development and it would be more productive if you could observe the behavior of the program before fixing the types. Since your CI pipeline will fail on type errors it's not like you're going to be able to merge your changes before fixing them.

Let me add a 3rd.

3. The program is incorrect but correct for all expected end user inputs.

In that case, add a type that constrains the values to the expected user inputs. Now not only are you passing the type checking, you're strongly enforced this invariant at the point where it makes the most sense, you've future-proofed this code against possible future misuse where the expected inputs might change, and you've made the code essentially self-documenting.

I'm not sure many languages support the introduction of types such as:

* An integer that is sum of two primes.

* A string that is created between the hours of 2 pm - 4 pm on a Tuesday.

* A dictionary who's fields comprise a valid tax return.

What do you mean by future proving? If the new version of the code doesn't ship by 2 pm today, the company goes bankrupt and there is no future for the code.

> I'm not sure many languages support the introduction of types such as:

Any language with types can enforce any proposition you can reliably check, which you run as part of the type's constructor. There are multiple ways to do this, for instance in pseudo-ML:

> * An integer that is sum of two primes.

    type SumOfPrimes
    fn sumOfPrimes : Prime -> Prime -> SumOfPrimes
    type Prime
    fn primeOfInt : Int -> Maybe Prime

> * A string that is created between the hours of 2 pm - 4 pm on a Tuesday.

    type Tuesday2To4String
    fn whichString : Clock -> String -> Either String Tuesday2To4String

> * A dictionary who's fields comprise a valid tax return.

    type ValidTaxReturn
    fn checkTaxReturn : Dictionary String String -> Maybe ValidTaxReturn

> What do you mean by future proving? If the new version of the code doesn't ship by 2 pm today, the company goes bankrupt and there is no future for the code.

Shipping broken code will not save the company from bankruptcy. It's also a myth that dynamically typed languages will get your code out faster.

I'm not sure how you intend to check the creation date of a string in memory since there is no information available to do that or that a tax return is valid given the thousands of rules involved.

Nevertheless let's move on.

It's not a myth, if you are using dynamic typing you will get three times the number of features out the door as someone who uses static typing.

It's just a fact.

1 dynamic typed programmer = 3 static typed programmers in productivity and output.

That is why people use dynamic typing.

From a commerical perspective, static typing does not make sense in most cases. You need something more than a typical business CRUD app to justify it. Usually you only need static typing for performance reasons. Like for a video game or image processing.

In practice, the shipped code doesn't have noticably more bugs. That just something which people who have never used dynamic typing properly like to believe.

If you ever read an article by Eve online where they say Python is their secret weapon or watched what Discord did by implementing everything in Python first. You will understand.

People use dynamic typing less and less, though. JavaScript and Python are the two most prominent dynamically typed languages in the industry, and what do we have there? Most JS developers love TypeScript, and Python bolted on type annotations in the core language (and libraries are generally following suit).

With that in mind, your other claims like the 1:3 ratio really need very solid sources to be taken seriously.

I had a job for 2 years where I had the write the same program in both a dynamically typed language and a statically typed language around every week.

On Monday morning, I wrote the dynamic typed version of the program. Then until Thursday afternoon wrote the statically typed version of the program. Then the rest of the week was writing tests that compare the output of both versions of the program.

After 2 years of doing it, I think I would know. If that sounds weird to you, it's called Prototyping, shocking that someone might prototype something in a scripting language designed for prototyping, I know.

The two classic examples are Eve Online with their "Python is our secret weapon". They used Python to out develop their competition. The other example is Discord who used Python to get to market quickly. Then they used Rust to reduce their operating costs by increasing the code's performance.

Python adding type annotations is an unfortunate problem associated with too many people coming in from statically typed languages. The problem with success and all that.

Statically typed Python codebases tend to be awful because the developers don't realise that they need to break the codebase down into smaller programs.

JavaScript is not a very good language due to the way it was designed and built and pretty much anything is an improvement to it.

> I'm not sure how you intend to check the creation date of a string in memory since there is no information available to do that

See the signature of the constructor function I provided.

> or that a tax return is valid given the thousands of rules involved.

Tax software does it every year. Clearly the government has an effective procedure to decide the validity of a tax return, even if that procedure is executed by a human.

> It's not a myth, if you are using dynamic typing you will get three times the number of features out the door as someone who uses static typing. It's just a fact.

That's just laughably false. There is zero empirical evidence supporting this claim.

> In practice, the shipped code doesn't have noticably more bugs. That just something which people who have never used dynamic typing properly like to believe.

No True Scotsman fallacy.

A signature of a function is very different from it's implementation.

"That's just laughably false. There is zero empirical evidence supporting this claim."

There is a reason all the startups are using Python. Just ask Eve Online or Discord. Dynamic typing is great for getting products to market fast.

Neither of them have problems with too many bugs. What you are saying doesn't even make sense, since you would just increase your QA budget if it increased the rate of bugs. So how in earth could the end user see more bugs?

Dynamic typing has an issue but that issue is code performance. Eve Online gets slow downs during massive battles and Discord rewrote parts of their interface in Rust to save on server costs.

> There is a reason all the startups are using Python.

Show the evidence that "all the startups" are using Python.

Why don't you go argue with an empirical study on the topic instead of me?

https://games.greggman.com/game/dynamic-typing-static-typing...

Because all the studies say that dynamic typing reduces development time without increasing the number of bugs.

> Because all the studies say that dynamic typing reduces development time without increasing the number of bugs.

This is literally false, which you can clearly see if you'd bothered to actually check the references cited in that article that links to this review:

https://danluu.com/empirical-pl/

Numerous studies demonstrate that static typing had little effect on development time, if the typed language was expressive, but did have noticeable effects on the quality of results and the maintainability of the system. The more advanced and expressive the type, as with Haskell and Scala, the better the outcome, but all studies done so far have flaws.

As for the specific data discussed in that article, here's what that review had to say:

    The speaker used data from Github to determine that approximately 2.7% of Python bugs are type errors. Python's TypeError, AttributeError, and NameError were classified as type errors. The speaker rounded 2.7% down to 2% and claimed that 2% of errors were type related. The speaker mentioned that on a commercial codebase he worked with, 1% of errors were type related, but that could be rounded down from anything less than 2%. The speaker mentioned looking at the equivalent errors in Ruby, Clojure, and other dynamic languages, but didn't present any data on those other languages.
    This data might be good but it's impossible to tell because there isn't enough information about the methodology. Something this has going for is that the number is in the right ballpark, compared to the made up number we got when compared the bug rate from Code Complete to the number of bugs found by Farrer. Possibly interesting, but thin.

In other words, this "evidence" you cited is a clearly biased anecdote, nothing more. I also recommend reading the HN comments also linked, where former Python programmers describe why scaling dynamic typing to large codebases is problematic.

In the end, my originally stated position on this stands: you have literally no empirical evidence to justify the claims you've made in this thread.

That is the correct end state, but there can be practical considerations for why you might want to run (and possibly even release) the software in this partially correct state, and fix the edge cases later.

I don't disagree, but most statically typed languages don't enforce a level of correctness where this would be an issue. We're not programming with theorem provers with an elaborate specification.

I somewhat agree with your point #2 which is why Haskell provides a deferred type checking mode for prototyping purposes[1]. I think this should be more common among typed languages, but this is not a very typical scenario either.

[1] https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...

You presume that the program is able to determine that it is wrong.

One of the most annoying things moving from Ruby / Python into a language with static types that are checked at compile time is dealing with JSON from an external API.

I know, I know. The API could send me back a lone unicode snowman in the body of the response even if the Content-Type is set to JSON. I know that is theoretically possible.

But practically, the endpoint is going to send me back a moustache bracket blob. The "id" element is going to be an integer. The "first name" element is going to be a string.

Sometimes a disable-able warning is all we want.

Maybe look at languages created in the last 30 years or so?

Because e.g. in Rust what you're talking about is:

    #[derive(Deserialize)]
    struct Whatever {
        id: usize,
        first_name: String
    }

    // ...

    let thing: Whatever = get(some_url)?.json()?;

You encode your assumptions as a structure, then you do your call, ask for the conversion, get notified that that can fail (and you can get an error if you but ask), and then you get your value knowing your assumptions have been confirmed.

It's definitely less "throw at the wall" than just

    thing = get(some_url).json()

but it's a lot easier to manipulate, inspect, and debug when it invariably goes to shit because some of your assumptions were wrong (turns out `first_name` can be both missing and null, for different reasons).

For a 5 lines throwaway script the latter is fine, but if it's going to run more than a pair of time or need more than few dozen minutes (to write or run) I've always been happier with the former, the cycle of "edit, make a typo, breaks at runtime, fix that, an other typo, breaks again, run for an hour, blow up because of a typo in the reporting so you get jack shit so you get to run it again".

I haven't had problems with that in strongly-typed languages I've used (most notably, C#). If the response payload isn't JSON, or if it has a missing required field or something is the wrong type, then JsonSerializer.Deserialize(...) will throw an exception. I don't have to add more code just to make the type check pass or anything. (And if I did, _usually_ it's around nullability and the "!" operator would do the trick, or "?? throw new ImpossibleException(...)")

And within the bounds of pragmatism, it's nice that it actually checks this stuff and throws exceptions. In Ruby if the ID field is the wrong type, the exception won't happen at time of JSON.parse(...) but instead much later when you go to use the parsed result. Probably leading to more confusion, and definitely making it harder to find that it was specifically an issue with the JSON and not with your code.

"One of the most annoying things moving from Ruby / Python into a language with static types that are checked at compile time is dealing with JSON from an external API."

That doesn't make much sense - either the API has a well-defined schema, and you define your static types to match (which there are usually tools to do for you automatically, based on an OpenXML/Swagger schema, if there isn't already an SDK provided in your language of choice), or you use a type designed for holding more arbitrary data structures (e.g. a simple string->object Dictionary, or some sort of dedicated JsonObject or JsonArray type).

There are issues around JSON and static typing, e.g. should you treat JSON with extra fields as an error, date/time handling, how to represent missing values etc. (and whether missing is semantically different to null or even undefined), but I would hardly see it as "one of the most annoying things".

Edit: the other issue I forgot is JSON with field names that aren't valid identifiers, e.g. starting with numerals or containing spaces or periods etc. But again, not insurmountable. I'd actually be in favour of more restrictive variation of JSON that was better geared towards mapping onto static types in common languages.

Oh, sweet summer child. If only those ‘shoulds’ would reliably be ‘will’s, the world would be a much better place.

TypeScript can type based on object literals, so while you can't type JSON on the fly, you can type a JSON file automatically.

With code gen you can usually just print out your JSON directly from the source and import that as a type into your source code.

This is why apis are moving towards specifications that trigger multiple generators.

JSON typing is possible without generation, but more cumbersome.

interface TypedJSON {

  string?: string;

  number?: number;

  array?: TypedJSON[];

  boolean?: boolean;

  object?: {[key: string]: TypedJSON}

}

{foo: {string: "my string"}, bar: {number: 4}}

Probably makes sense to make the "string" key "s" for minimal payload size impact, or this could also be done by converting standard JSON to this typed representation at runtime.

You should check what the external API returns anyway. If only because the format of any external API might break in subtler way than just returning a single Unicode snowman, and you'll want to ensure that all such failures are correctly detected as soon as practically feasible.

Because the property of being wrong is not binary. It might be partly wrong but correct enough for your current situation.

How do you know when it's crossed into being just a little too wrong?

You can have a catch all exception handler that emails any exceptions that occur to you.

It's not pretty but it can be done. :P

I think a catch-all top level exception is totally fine and not ugly at all!

That’s why my Python APIs never fatally crash, they just log an exception and move onto the next request.

Because you haven't finished the whole thing but you want to test part of it before you continue.

There's always an escape hatch for this. Even in Java (and Haskell), you can just throw an unchecked exception from your unimplemented function.

Likewise in Rust you can todo!() in incomplete functions. But it’s still much harder to run incomplete code than it is in javascript, because you still need to satisfy the type checker and borrow checker even for incomplete programs.

Why would you want to talk to people who are wrong?

Sometimes I don't care which political party the barista voted for, I just want to get my coffee.

People and programs are never perfect. Type checked program is not guaranteed to be correct, it just has stronger constraints.

Per #1, why can't it be per module or per routine? Framework-oriented API's we often want "tighter" while domain-centric glue-code can be looser.

Per #2, why not a language that facilitates "lint" style inspectors to give a list of warnings, as in "do you really wanna do that?" This reduces the burden of the compiler. Meta-markers can switch certain warnings off so we don't clutter the results for intentional spot looseness.

I think that if you permit, but don't require, type information, then there is little practical difference between failing typechecking at compile time and merely issuing warnings.

Rust has strong static typing but it also has very powerful type inference, I think it fails to fit in your dichotomy.

They cite haskell which, if anything, has even stronger static typing and more powerful type inference (because the rust devs decided to favour explicit clarity and removed global type inference).

And as GHC actually has a compilation mode where it only warns about compilation errors: https://gitlab.haskell.org/ghc/ghc/-/wikis/defer-errors-to-r...

So they're 0/2, on the subject they're espousing upon, through a language they mentioned.

Rust’s type inference still requires you to manually specify the input and output types of every function. I think it’s clearly in the camp of “all types must be specified by the programmer / you get compiler errors”.

The GP asked what’s the point of languages like this. The two massive advantages in my mind are that compiled programs are usually correct, and compiled programs run really fast. I often have the experience in rust of writing hundreds of lines of new code, and my program works perfectly the first time I run it. That’s a delight.

The decision to require explicit global type annotation in Rust has nothing to do with "compiled programs are usually correct, and compiled programs run really fast", you can do that with global type inference.

It has to do with documentation, intent, and clarity. Also clarity of error messages, compilation errors with generic functions under GTI are as bad as C++ template errors.

> It has to do with documentation, intent, and clarity.

I wish it were common [0] for source code to show a combination of programmer-specified and compiler-deduced details.

Seems like we could get the best of both worlds.

[0] I know some IDEs show e.g. type information as mouse-over text. I'm talking about something that integrates more cleanly into the actual source-code text. So, e.g., it would show up when diff'ing the source code.

See <http://cr.yp.to/qhasm/literature.html>

> compiled programs are usually correct

This is absolutely false. Compiled programs might be correct with respect to type safety, but that is very different from being correct. There are all kinds of ways that programs can fail besides type errors.

In fact, this widespread false belief is IMHO one of the strongest arguments against using enforced-compile-time-strong-typing because it lulls you into a false sense of security. I have a long list of war stories where this led to problems that ranged from annoying to very nearly catastrophic.

Of course there’s lots of ways a compiled program could still be incorrect. But in my experience (having spent years with both languages) the practical per-line error rate of rust code I write is many times lower than my per-line error rate in javascript. (And typescript is somewhere in the middle for me).

Yes, you still need tests. But testing is never perfect. Bugs still slip through. I like not needing to be as paranoid in rust as I am in other languages.

Agreed, and Julia is in an odd spot as well. The type inference combined with JIT and dispatch act make for strong dynamic optional typing vs rusts strong static inferred typing.

Reply on news.ycombinator.com