Hacker News Reader

There is no limit on the number of problems easier to solve using dynamically typed languages. For an individual hacker, dynamically typed languages make a lot of sense. I don't forget what types my functions accept as I am writing a program. All static typing can accomplish is slow me down when I'm trying to bang out something. This is why Python (for instance) is loved by data scientists, researchers, and startups. And they're right to love it! Purely anecdotal, but I can accomplish more faster (from a clean slate) with a dynamic language like Python than I can with Haskell, Go, or Rust. The difference is small, but non-negligible.

But static typing has a few key benefits:

* No searching through comments for type constraints.

* Better autocompletion.

* Better compilation.

* Better serialization/deserialization.

I do think static typing pays for itself in the long term. Sometimes, we shouldn't care about that. Engineering means managing tradeoffs: short-term velocity vs long-term performance and maintainability?

>There is no limit on the number of problems easier to solve using dynamically typed languages.

So, some examples? Also examples where "easier" is not just "you don't need to write types". That goes without saying...

how about using something like clojure.spec where you need it most to help make that long term payment?

It's an interesting take. e.g. provide specs/types across module boundaries only. Gradual typing is certainly becoming popular. Meanwhile, statically typed languages are adopting type inference. Some people only write the types for the exports in their modules. The two worlds are coming closer. More statically typed languages are adding dynamic type information (like Go). More dynamically typed languages are supporting static type markup (like Python).

The auto-completion is purely Python's dynamic-dispatch problem though. Lisp has symbol-based auto-completion which doesn't suffer from the same issue (search is a different story!).

This sounds terribly controversial, but I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate those).

I do wonder whether a better approach is to prove your code in some other language (say Z3, Agda, Coq) - then implement it in something else, making sure you can prove isomorphism. This has quite a few benefits; you're not tied to a constructive proof on the type-level ala Haskell, Rust, Go etc... and you can automate a large part of trivial proofs.

> I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate those).

When you are in a codebase where you don't know which modules have been soundly typed, and which ones are still in the 'gradual' phase.

The fascinating thing about Python is the ability to write functions where the parameter can intake multiple data types.

I haven’t quite seen another language handle it this elegantly as Python does.

Then, inside the function, you can check the parameter’s data type, and handle it appropriately. And error out immediately if the wrong type is passed in.

This allows you to operate on the data at a more logical level (what it implies), as opposed to just at the technical level (what data type it is).

For example, you can pass in a single string, or a list of strings. And your function can check the type and handle it appropriately.

In C++ and Java, because of the rigidity of the function declaration, in order to do something like this, then you would need to create multiple functions to handle each of the different types that you want to allow. Then you’d need to create a wrapper function to dispatch it to its appropriate sub function. That becomes a complete mess after a while.

C# has an is operator as well. I found it useful with generics.

Coming back to even your own ~+1KLOC project after 3 months of working on other things, compiler enforced types can help you jump right in

> There is no limit on the number of problems easier to solve using dynamically typed languages

40+ years of programming experience here + a language geek. I have for years programmed in both dynamic and static languages to find out what works best for me. My conclusion is that problems are easier to solve with statically typed languages. So clearly different languages works for different personalities.

One more that people easily forget. An IDE or LSP can detect much more errors as you type, saving quite a lot of context switch of mind.

Clojure gives you tools like spec https://clojure.org/guides/spec or Mali https://github.com/metosin/malli for schemas on data. Beats static typing IMHO.

I reject the claim that it is reasonable to capitalize all the string fields of arbitrary objects.

But it can still be done, like you mention, by using reflection. Now, you claim that it is unsafe. This is untrue, it depends how the reflection works. Even if it were unsafe, it would be no worse than in Python, where you get a TypeError or in JavaScript where you get undefined, which probably leads to a crash later.

For an example of reflection which is safer than just a string-dictionary like JavaScript or Python, see GHC.Generics. It works by compile-time generating a type safe structure which is not just a dictionary. The function you want would have a signature involving this constraint, "Generic x => x -> x", which means it works for any "object" implementing the Generic interface.

Now you may say "but I asked for a function that handles all objects", but I don't see the point. In statically typed languages you get an additional option of using generics when you want. It doesn't make sense to me to require all types to implement reflection when you don't actually need it everywhere.

>1. You could use "reflection" or some dynamic feature to do this, but lose type-safety

By using reflection you only lose type-safety for this particular function. With a dynamic language, you lose it everywhere.

And it's still an one-liner or close in a language without much ceremony (e.g. not Java 1.5).

Example implementation (pseudo-code):

  fun capitalize (o: object) -> [f.toUpper() for f in 
  reflection.fields(o) if reflection.type(f) == "string"]

That's not a very compelling example - in most statically typed languages the object field names are not actually stored in member, so it makes no sense to want to do runtime operations on them, because they don't exist by the time the code is compiled.

That's why you find it hard to do in a compiled statically typed language - because it's not something that really makes any sense.

> Let's say you want to write a function that can capitalize all the string fields in the object passed in. In a dynamic language, you could map over the values and apply capitalization trivially. It would be a one-liner.

That's fair, but can you explain the context here? I.e. why are we trying to capitalize all the field names of a record object? This may be an 'XY' problem--you may be trying to accomplish some final goal and 'capitalize all the field names of a map' seems like an obvious intermediate step to you, while to a statically typed language programmer they may take a very different approach.

It's pretty easy to do in Typescript and loses no type safety (without needing to assert or cast anything)

    type T = { [k: string]: number };
    
    const t: T = {
      one: 1,
      two: 2,
      three: 3,
    };
    
    const makeUpperCaseKeys = (v: T): T => {
      const keys = Object.keys(v);
      return keys.reduce((p, c) => {
        const key = c.charAt(0).toUpperCase() + c.slice(1);
        return { ...p, [key]: v[c] };
      }, {});
    };
    
    console.log(makeUpperCaseKeys(t));
    // {
    //   One: 1,
    //   Two: 2,
    //   Three: 3
    // }

That's great! Are you making the argument that I won't be able to find an example where doing some transform in a type-safe way is awkward in TypeScript, or just that this one example can be done in TypeScript?

By the way, my example was meant to be more like User -> User where there are some string values and some other types of value. You want to do the transformation in a generic way, but still have the type-safe object come out the other end with all the expected keys.

You can try this with typescript 4.1 :

interface User { name: string; age: number; }

type CapitalizeProperties<T> = { [Property in keyof T as Capitalize<string & Property>]: T[Property]; };

type CUser = CapitalizeProperties<User>;

var c : CUser = { Age: 17, Name: "john" }

You can check that the autocompletion works on the c variable.

https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=15&pc=2#...

> In reality, you probably wouldn't even try to write such a function in a typed language because of how awkward it is.

In reality, you probably wouldn't because of how contrived and completely removed from any conceivably realistic practical goal this example is. In what situation would I actually need to solve this problem for every type in my program?

As a proponent of static typing (at least for larger programs): thank you, that was a very enlightening example for when dynamic typing can be superior to static typing.