3 ms·

There is your problem right there. These static type gurus live in an alternative universe in ivory towers far removed from where the rest of us simpleton progr

There is your problem right there. These static type gurus live in an alternative universe in ivory towers far removed from where the rest of us simpleton programmers live. Frankly I think it is an intellectual cargo cult. For all its sophistication these languages have not delivered that much. Look at language like Go, which these guys would laugh their butt off. Yet Go has produced usable software for a lot more people and made a lot more developers happy than Haskell ever could. Coming years after Haskell Julia seems to be doing a lot more for science than Haskell has ever managed to achieve.

noelwelsh 7y ago
Well allow me to climb down from my ivory tower and offer the following in way of explanation: Here is a reasonably good overview of safety (aka dynamic typing) vs types: https://papl.cs.brown.edu/2018/safety-soundness.html https://papl.cs.brown.edu/2018/safety-soundness.html Put another way, the standard programming language theory is that types are constraints that are uncovered (via type inference) and checked at compile-time. If type information is found at run-time these are known as tags. In Haskell, for example, you can declare a type like newtype SecretKey = Int This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however. You cannot use a SecretKey where an Int is expected and vice-versa. This could prevent you leaking secrets to other parts of your program, for example. This is one way you can reclaim performance in a statically typed language, vs dynamic types, without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors).
- socialdemocrat 7y ago
  In my opinion you are actually reading this the wrong way. When I explain concepts such as boxing to people I will refer to type tags. But in that context I use the phrase to refer to how something is implemented. How a type system is implemented is different from how it conceptually / semantically. For instance in Julia types are conceptually objects you can pass around. However they will not always correspond to a type tag. Conceptually all objects in Julia have a type. However at runtime they may not. The JIT compiler could have gotten entirely rid of them. When values are placed in a Julia array, individual elements will typically not have any type tags. However conceptually they still have a type. To me type tags are just an implementation detail which both dynamic and static languages may use. However when you speak at a conceptual level you don't use that word. You don't say, "lets put this type tag into that object," you say "lets put that type into that object, bind to that variable or whatever." The way I like to talk about static and dynamic languages is to say: In dynamic languages values have types, but not expressions / variables. In static languages expressions have types, not values. That is of course a simplification, but IMHO simple and sensible way of making the distinction.
- socialdemocrat 7y ago
  > This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however. I can do exactly the same in Julia struct SecretKey value::Int end After the JIT compiler is done, there is no difference between this and an `Int`. The type associated with the value only exists conceptually at runtime. A `SecretKey` value in Julia will in most methods look no different from an `Int` > without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors). That would be the same in a strongly typed dynamic language. Except the error will of course be caught at runtime. But it is not like you can use the types in an illegal way.

noelwelsh 7y ago

Well allow me to climb down from my ivory tower and offer the following in way of explanation: Here is a reasonably good overview of safety (aka dynamic typing) vs types: https://papl.cs.brown.edu/2018/safety-soundness.html https://papl.cs.brown.edu/2018/safety-soundness.html Put another way, the standard programming language theory is that types are constraints that are uncovered (via type inference) and checked at compile-time. If type information is found at run-time these are known as tags. In Haskell, for example, you can declare a type like newtype SecretKey = Int This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however. You cannot use a SecretKey where an Int is expected and vice-versa. This could prevent you leaking secrets to other parts of your program, for example. This is one way you can reclaim performance in a statically typed language, vs dynamic types, without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors).

socialdemocrat 7y ago
In my opinion you are actually reading this the wrong way. When I explain concepts such as boxing to people I will refer to type tags. But in that context I use the phrase to refer to how something is implemented. How a type system is implemented is different from how it conceptually / semantically. For instance in Julia types are conceptually objects you can pass around. However they will not always correspond to a type tag. Conceptually all objects in Julia have a type. However at runtime they may not. The JIT compiler could have gotten entirely rid of them. When values are placed in a Julia array, individual elements will typically not have any type tags. However conceptually they still have a type. To me type tags are just an implementation detail which both dynamic and static languages may use. However when you speak at a conceptual level you don't use that word. You don't say, "lets put this type tag into that object," you say "lets put that type into that object, bind to that variable or whatever." The way I like to talk about static and dynamic languages is to say: In dynamic languages values have types, but not expressions / variables. In static languages expressions have types, not values. That is of course a simplification, but IMHO simple and sensible way of making the distinction.
socialdemocrat 7y ago
> This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however. I can do exactly the same in Julia struct SecretKey value::Int end After the JIT compiler is done, there is no difference between this and an `Int`. The type associated with the value only exists conceptually at runtime. A `SecretKey` value in Julia will in most methods look no different from an `Int` > without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors). That would be the same in a strongly typed dynamic language. Except the error will of course be caught at runtime. But it is not like you can use the types in an illegal way.