[naasking]

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

[ReflectedImage]

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.

[int_19h]

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.

[ReflectedImage]

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.

[naasking]

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

[ReflectedImage]

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.

[naasking]

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

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

[ReflectedImage]

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.

[naasking]

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