3 ms·

Your example actually illustrates why dynamically typed languages should be avoided in general, especially when manipulating data coming from outside. Your cod

Your example actually illustrates why dynamically typed languages should be avoided in general, especially when manipulating data coming from outside. Your code starts by making a few checks on the shape of the data you're receiving and failing earlier if some conditions are not met. Great. Once these checks are cleared, you now know that you can materialize an object with valid values in it, something the rest of your business code will be able to manipulate. So you instantiate that new object, return it and... all the knowledge about the shape of that data is lost. The only thing your callers will see is an Object and zero information about what operations or fields are available on this object. They'll have to guess. With a statically typed language, you don't have such a problem. You have asserted all these properties about the data that came in, you know exactly the class of the object you are creating, why forget all this precious information that will keep your code robust? In my experience, dynamically typed languages are at an evolutionary dead end and offer close to zero advantages over modern statically typed languages (e.g. Kotlin, Swift).

harpiaharpyja 9y ago
> Once these checks are cleared, you now know that you can materialize an object with valid values in it, something the rest of your business code will be able to manipulate. So you instantiate that new object, return it and... all the knowledge about the shape of that data is lost. I'm not really seeing how that necessarily falls out of the example given by GP. Could you go into that in more detail? Is there something preventing create_user(params) from emitting an object with a well defined interface?
- hota_mazi 9y ago
  That function does create an object with a well defined interface, but because you are using a dynamically typed language, that object has the type "Object" (or Any, or whatever the mono type of that language is). If you call that function, you have no idea what the type of that object is. Only the function knows it and that information is lost as soon as the function returns.
  - harpiaharpyja 9y ago
    I think I will have to disagree with that. The type of object is not enforced by the compiler, but that's a long way off from "you have no idea what the type of that object is."
    - hota_mazi 9y ago
      The fact that the compiler cannot enforce it is a big deal since it prevents automatic refactorings, often impairs performance and overall, hinders readability. And yes, you really have no idea what the type of that object is unless you look at the source of the function. Which is obviously suboptimal, especially if you don't have access to that source.

harpiaharpyja 9y ago

> Once these checks are cleared, you now know that you can materialize an object with valid values in it, something the rest of your business code will be able to manipulate. So you instantiate that new object, return it and... all the knowledge about the shape of that data is lost. I'm not really seeing how that necessarily falls out of the example given by GP. Could you go into that in more detail? Is there something preventing create_user(params) from emitting an object with a well defined interface?

hota_mazi 9y ago
That function does create an object with a well defined interface, but because you are using a dynamically typed language, that object has the type "Object" (or Any, or whatever the mono type of that language is). If you call that function, you have no idea what the type of that object is. Only the function knows it and that information is lost as soon as the function returns.
- harpiaharpyja 9y ago
  I think I will have to disagree with that. The type of object is not enforced by the compiler, but that's a long way off from "you have no idea what the type of that object is."
  - hota_mazi 9y ago
    The fact that the compiler cannot enforce it is a big deal since it prevents automatic refactorings, often impairs performance and overall, hinders readability. And yes, you really have no idea what the type of that object is unless you look at the source of the function. Which is obviously suboptimal, especially if you don't have access to that source.