Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic type systems are not inherently more open

lexi-lambda.github.io

Post reply on HN
Print view View original

191–200 of 286 posts

Re: Dynamic type systems are not inherently more open

#191

Post by msangi »

skybrian wrote: post #172

Protobufs don't follow this model. For example, a User message type will often be defined in one place and code generated from it in multiple languages. Every server and client uses essentially the same type, modified as suitable for that language. As a result, clients are usually working with types that they don't control and that have many more fields than they actually use. Maybe clients should declare their own t…

With protobufs you get bytes that you have to parse with defined rules on what to do with unexpected and missing fields.

How’s it different from the proposed model where you start by parsing the data you receive and, once it’s parsed and know it’s good, you process it?

Re: Dynamic type systems are not inherently more open

#192

Post by msangi »

mcnamaratw wrote: post #37

Definitely dynamic typing is not about modeling the world. And it's much broader than that. Static typing, strict or loose, also isn't about modeling the world. OO design isn't about modeling the world. These things are successful because they're effective methods for organizing code . They're about as useful for modeling the world as the Dewey Decimal System is. And that's fine! 'Modeling the world' is a grandiose p…

How do you write code without having a model of the world?

Re: Dynamic type systems are not inherently more open

#193

Post by IggleSniggle »

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.

TypeScript can come close to this, especially with the latest release with Assertion support. You make assertions about your code, and the downstream types are inferred based on your assertions. Thus, the runtime behavior of your code gives you progressively enhanced type-checking. If you do these assertions at the borders, your "correctness" is dependent on the strength of your runtime assertions.

Re: Dynamic type systems are not inherently more open

#194

Post by yakshaving_jgt »

beders wrote: post #134
NicoJuicy wrote: post #40

Earlier quoted context omitted.

I actually rely on static typing to make architectural code changes. Why I would want to go to dynamic typing is beyond me. My performance/efficiency would greatly decrease. . The next change I will implement will likely be to not allow null in a property, which can be done in c# 8

The idea is that you wouldn't need large refactorings in more dynamic languages in the first place since you are operating on a different abstraction level.

Nothing about static types nor dynamic types dictate what level of abstraction one must operate on.

Re: Dynamic type systems are not inherently more open

#195

Post by aliceryhl »

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…

It sounds like you think adding a conversion at the start is difficult and cumbersome, but it isn't if you use a good serialization library. E.g. with the Rust library serde, you just define the shape you expect your JSON data to have and plop a #[derive(Deserialize)] on it. Boom, fully failsafe JSON deserialization into the type.

Re: Dynamic type systems are not inherently more open

#196

Post by pwm »

hopia wrote: post #87
chongli wrote: post #52

Earlier quoted context omitted.

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…

On what editor setup you get this kind of functionality with Haskell? I mean the auto-insert of the inferred types.

Recent ghcide can do it now as well as https://github.com/mpickering/apply-refact for hlint

Re: Dynamic type systems are not inherently more open

#197

Post by IggleSniggle »

hhas01 wrote: post #150
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…

Yep. Being able to work fast and dirty is a huge boon when testing ideas and figuring out the initial design, and it is deeply annoying that so many typed languages refuse to permit this. The faster you can write code, the faster you can throw it away again; and arriving at good code almost invariably requires† writing lots of bad code first. If writing bad code is made expensive (another example of Premature Optimiz…

This is why TypeScript is so popular. JavaScript is very loose, but you can progressively enhance it using TypeScript with stricter and stricter types, many of which can be inferred, and since 3.7 can be derived by runtime assertions, and the strictness of which can be controlled with compiler flags.

Additionally, it is fairly typical in js to use functional programming styles, making type inference a breeze / provable / not introducing much boilerplate by adding types.

Re: Dynamic type systems are not inherently more open

#198

Post by jose_zap »

hopia wrote: post #103
chongli wrote: post #92

Earlier quoted context omitted.

I’ve been out of the game for a number of years but I used something called ghc-mod [1] with its associated vim plugin [2] to get this functionality. Moving forward, it seems that all of the effort has moved over to Haskell IDE Engine [3]. It looks like this exact feature hasn’t been brought over yet but it is planned. In the mean time you could still use ghc-mod though. [1] https://github.com/DanielG/ghc-mod [2] htt…

Thanks for the tip! Haskell IDE engine is exactly what I've been using til now and would've been very pleased to find out it had such a convenient feature. Ghcide is on my list to try next as it's gotten a lot of attention lately.

Yes, it already has a code command to automatically add top level type annotations. The caveat I that it can only work if you add -Wall to your compilations flags.

Re: Dynamic type systems are not inherently more open

#199

Post by jose_zap »

hopia wrote: post #104
danidiaz wrote: post #98

Earlier quoted context omitted.

It seems that "ghcide" can do this: https://twitter.com/chris__martin/status/1218331415869190144 https://github.com/digital-asset/ghcide

Template Haskell not working on ghcide has sadly been holding me back with it. I've heard great things about it otherwise

You can use HIE. It supports template Haskell

Re: Dynamic type systems are not inherently more open

#200

Post by pwm »

azhenley wrote: post #163
leshow wrote: post #160

Earlier quoted context omitted.

I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to…

I quoted the title of my blog post. Do you have any evidence for your claim that it increases readability or usability? A few human-subjects studies from different labs have recently been ran on this and the findings mostly agree with my opinions. Papers forthcoming.

I don’t agree with readibility (there are pros and cons, ie. terser code vs. implicit types) but, at least in Haskell, it improves usability by inferring the most generic type to your expression.
Post reply on HN