Dynamic type systems are not inherently more open • Hacker News Board

Re: Dynamic type systems are not inherently more open

#51

Post by yakshaving_jgt » Sun, Jan 19, 2020, 2:08 PM UTC

nickik wrote: post #30

youerbt wrote: post #7

This "be liberal in what you accept" idea, applied to modern programming, always struck me as strange. Yes, taking an unknown structure in your program is the easy part. Programming against an unknown structure is where the problem lies. I'd love to hear more examples of programming against such input that are beneficial over "parse don't validate" idea.

In Clojure you generally accept any kind of map, do some operation and return 'copy' of that map, or pass it on. A simple example is a ring web stack, where request flow threw different functions that transform the http request. Each function just assumes the keys its needed are there, or to do input validation, you just validate that the incoming map has the keys that you require but does not care what else is in th…

There is no reason why the same would not be possible in a statically-typed language.

Re: Dynamic type systems are not inherently more open

#52

Post by chongli » Sun, Jan 19, 2020, 2:11 PM UTC

amelius wrote: post #43

UglyToad wrote: post #29

I think there's a perhaps irreconcilable disconnect between 2 camps here, but I also think that's ok and different people are allowed to like different things. My experience, having gone from dynamic typing to static typing and now pining for more expressive type features in my chosen language is that static typing changes where you have to spend the cognitive complexity budget. To my mind if I return to a piece of d…

Yes. Perhaps this is an indication that we actually need automated type annotation. E.g. you initially write/prototype your program in a dynamically typed form, then you click a "magic" button, and a tool converts your program into statically typed style.

This already exists in Haskell. Firstly, Haskell has type inference so you can write entire programs without any type annotations. Second of all, since type annotations actually help to document your code, it’s recommended as good Haskell style to annotate all top-level definitions.

To aid you in the latter task, you can press a key in your editor to fetch an automatically-inferred type for the name under the cursor and insert it into your code, then refine it as necessary if you find it to be too general (inference always gives the most general type possible).

Re: Dynamic type systems are not inherently more open

#53

Post by yakshaving_jgt » Sun, Jan 19, 2020, 2:13 PM UTC

zozbot234 wrote: post #11

phoe-krk wrote: post #3

Disclosure: dynamic typer here. The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the time at which the data is operated upon, since calling a numeric addition function on not-numbers, e.g. strings, is a type violation, no matter which programming language you are writing in. The question is where you want your parsing-or-validating to occur, since…

The author actually argues against Haskell as an example of their philosophy, because Haskell has poor support for open static types. They generally have to be faked in unintuitive ways by relying on the typeclasses feature, and something like OCaml's support for structural, extensible records and variants seems to be entirely off limits out-of-the-box.

I don’t think that’s correct. The author’s point is that structural typing is possible in statically-typed languages, but isn’t a thing in Haskell.

To learn more, Google for “Haskell row polymorphism”.

The author correctly points out that structural vs nominal is a separate argument from static vs dynamic.

Re: Dynamic type systems are not inherently more open

#54

Post by danmaz74 » Sun, Jan 19, 2020, 2:14 PM UTC

ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

To reinforce your point: static typing doesn't just force you to fix some bugs earlier, but it also forces you to spend more time doing design upfront, often when you still don't have clear specs. That can be a big drag when you need to do a lot of experimentation/iteration.

Re: Dynamic type systems are not inherently more open

#55

Post by zozbot234 » Sun, Jan 19, 2020, 2:16 PM UTC

yakshaving_jgt wrote: post #53

zozbot234 wrote: post #11

Earlier quoted context omitted.

The author actually argues against Haskell as an example of their philosophy, because Haskell has poor support for open static types. They generally have to be faked in unintuitive ways by relying on the typeclasses feature, and something like OCaml's support for structural, extensible records and variants seems to be entirely off limits out-of-the-box.

I don’t think that’s correct. The author’s point is that structural typing is possible in statically-typed languages, but isn’t a thing in Haskell. To learn more, Google for “Haskell row polymorphism”. The author correctly points out that structural vs nominal is a separate argument from static vs dynamic.

The whole point of row polymorphism (for both records and variants) is that it allow for implementing open types in a static typing context. And OCaml supports this out of the box whereas Haskell does not.

Re: Dynamic type systems are not inherently more open

#56

Post by yakshaving_jgt » Sun, Jan 19, 2020, 2:17 PM UTC

fendy3002 wrote: post #41

alerighi wrote: post #33

Recently I worked on a project where initially we though about writing it in Rust, because why not, it seemed initially a good idea. It turned out to be a completely wrong idea. The project was a simple web API, nothing fancy, GraphQL and a SQL database. After a lot of frustrations we decided it to rewrite everything in TypeScript and did that in a week. TypeScript gives you the benefit of statically typed languages…

To add to this, dynamic typing is proper tool to use for API, because the input payload is just formatted text, without / with very few type definition. My experience said that it's hard to play with JSON on static typing, without adding a strict data validation / conversion at the start. Serialization comes with a set of strict rules that need to follow and state beforehand too. The contrary, on dynamic typing langu…

This is absolutely false. Not a single word you have written in this comment is true. This is a pervasive myth that you are perpetuating. If you had read the article, you would know that what you have said is demonstrably false.

There is nothing stopping you from operating on arbitrary JSON in Haskell.

Literally nothing.

Re: Dynamic type systems are not inherently more open

#57

Post by rwmj » Sun, Jan 19, 2020, 2:18 PM UTC

amelius wrote: post #48

zitterbewegung wrote: post #44

Earlier quoted context omitted.

Using Type inference[1] on a language could be able to figure out types in most situations. [1] https://en.wikipedia.org/wiki/Type_inference

Yes, some programming languages take this approach but I don't think that prototyping is as easy in such languages as it is in a dynamically typed language (e.g. Haskell vs Python).

When writing OCaml, if I'm unsure of the type I set the type to some impossible value, compile it, and the compiler tells me what the type really is.

Re: Dynamic type systems are not inherently more open

#58

Post by youerbt » Sun, Jan 19, 2020, 2:20 PM UTC

nickik wrote: post #30

youerbt wrote: post #7

This "be liberal in what you accept" idea, applied to modern programming, always struck me as strange. Yes, taking an unknown structure in your program is the easy part. Programming against an unknown structure is where the problem lies. I'd love to hear more examples of programming against such input that are beneficial over "parse don't validate" idea.

In Clojure you generally accept any kind of map, do some operation and return 'copy' of that map, or pass it on. A simple example is a ring web stack, where request flow threw different functions that transform the http request. Each function just assumes the keys its needed are there, or to do input validation, you just validate that the incoming map has the keys that you require but does not care what else is in th…

But I believe this is also with the spirit of the article. Your functions still assume something about input and are polymorphic over everything else in it.

AFAIK this can also be done in a type safe manner in languages which support extensible records/row polymorphism.

Re: Dynamic type systems are not inherently more open

#59

Post by StandardFuture » Sun, Jan 19, 2020, 2:22 PM UTC

phoe-krk wrote: post #3

Disclosure: dynamic typer here. The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the time at which the data is operated upon, since calling a numeric addition function on not-numbers, e.g. strings, is a type violation, no matter which programming language you are writing in. The question is where you want your parsing-or-validating to occur, since…

I actually really enjoy your views on dynamic typing.

But, if we agree on this definition then is it not an admittance that "dynamic type systems" don't actually exist and instead we are simply talking about evaluation/validation being programatically specified by the programmer instead of embedded evaluation/validation by the compiler and/or runtime? And since it is being specified by the programmer, then we run into the possibility of that validation being incorrectly implemented or possibly forgotten entirely.

Any type system that had better verification of self-programmed type validation code from the programmer would solve this issue, no?

Re: Dynamic type systems are not inherently more open

#60

Post by yakshaving_jgt » Sun, Jan 19, 2020, 2:24 PM UTC

zozbot234 wrote: post #55

yakshaving_jgt wrote: post #53

Earlier quoted context omitted.

I don’t think that’s correct. The author’s point is that structural typing is possible in statically-typed languages, but isn’t a thing in Haskell. To learn more, Google for “Haskell row polymorphism”. The author correctly points out that structural vs nominal is a separate argument from static vs dynamic.

The whole point of row polymorphism (for both records and variants) is that it allow for implementing open types in a static typing context. And OCaml supports this out of the box whereas Haskell does not.

Yes, that’s true. I’m not disputing that. Perhaps I misinterpreted your previous comment. I think the point I want to make is that in the argument between static vs dynamic, the structural vs nominal argument is not really relevant.