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

Re: Dynamic type systems are not inherently more open

#231

Post by nickbauman » Sun, Jan 19, 2020, 9:30 PM UTC

frankpf wrote: post #208

nickbauman wrote: post #201

Earlier quoted context omitted.

I think it's a question of efficacy and productivity. People routinely make mistakes using type systems. While static typing tends to be really good at solving problems it itself introduces (change a type and, wow! My IDE knows where that type is everywhere and can change it for me! Nevermind that only the producer and final receiver should care, it's everywhere now...) There hasn't been a lot of study on this topic*…

> There hasn't been a lot of study on this topic* but what little there is shows that 3% of errors found can be mitigated with type systems, where they do not exist, fixing these classes of errors takes less time than it took to use the type system. It seems to me like you're cherry picking evidence. Copy-pasting from a previous comment I made in another thread ( https://news.ycombinator.com/item?id=19530274 ): There…

Well what I should have said is there has been a lot of studies on the efficacy of type systems, but much has been shown to be flawed. I haven't looked at your citations mostly because of the use of typescript which I have personal experience with and I know it's not helping. I'm not going to debate this with you, though; too little good papers on the topic so too much heat and too little light. I've spent most of my career using static typed languages in hindsight I've found most of the static typing not helpful for successful projects.

Re: Dynamic type systems are not inherently more open

#232

Post by zmmmmm » Sun, Jan 19, 2020, 9:34 PM UTC

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…

> To my mind if I return to a piece of dynamically typed code written any time other than in the same session I have to load a whole mental model of the entire code, what types all the variables are

This is one reason my favorite model is the "egg model" - hard outer shell (static typed signature) of a function with a soft gooey center - dynamic code internally. It lets you use the convenience of dynamic typing but confines the scope of the mental budget to understanding just a few lines of dynamically typed code. Languages like groovy are pretty good for this type of code.

Re: Dynamic type systems are not inherently more open

#233

Post by sweeneyrod » Sun, Jan 19, 2020, 9:40 PM UTC

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.

If type inference damaged readability, we would expect companies/projects that use languages such as OCaml and Haskell where type inference is possible but not mandatory to have policies against it in their style guides. In my experience with OCaml, the widely agreed on style is to only annotate types of functions that are part of some public interface (although since this annotation is necessary to define the public interface of a library, it's not even necessarily true that type inference impairing readability is the primary reason for this).

Also, if lack of type annotations were a common problem, you would expect Java programmers who switch to Python to frequently want to annotate all their types. But as far as I know this is not the case: even now that mypy is becoming popular, people only annotate the types that it can't infer.

Re: Dynamic type systems are not inherently more open

#234

Post by galangalalgol » Sun, Jan 19, 2020, 9:51 PM UTC

caseymarquis wrote: post #210

galangalalgol wrote: post #78

Earlier quoted context omitted.

I haven't read that textbook. Do you have a good reference. I may have been intentionally been using an anti pattern. I often have a POD class that gets passed down a processing chain.

YMMV. There's probably at least one good use case for virtually every design. What you're doing could be totally reasonable. The original description sounded like 13 functions being manually chained together, each inside the last. Where to go from there is very situational. Using a POC is pretty much a given. For transformation in the simplest form, I'd typically have a series of extension methods (or some equivalent…

I'm keeping that line. More wrong places... That is koan worthy. What is DI dynamic initialization? I can't imagine passing a const bit of POD through 13 layers without it bein used, but not every layer uses all of it probably.

Re: Dynamic type systems are not inherently more open

#235

Post by millstone » Sun, Jan 19, 2020, 9:58 PM UTC

choeger wrote: post #221

millstone wrote: post #217

I wrote the pickle.load comment [1]. I want to defend it here. King (the author) places "dynamically typed" and "statically typed" in opposition. But keep in mind that many languages have both: Java, ObjC, TypeScript, C#, etc. I like to say that a a language "has" static and/or dynamic types, but "is" dynamic if it supports runtime features like reflection - of course this is a sliding scale. King observes that stati…

I can easily write you pickle in Haskell. In fact you can easily embed Python's single type in Haskell and thus do everything you can do in python. The difference to Java has nothing to do with reflection, really, but rather with a uniform object representation (in Java you know the shape of all values by default).

I don’t believe one can write pickle.load in Haskell. Please show me how!

A Java pickle.load would need to lean heavily on its dynamic features including reflection. For example, looking up a class by name.

Re: Dynamic type systems are not inherently more open

#236

Post by skybrian » Sun, Jan 19, 2020, 10:02 PM UTC

msangi wrote: post #191

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?

It probably would work, provided that each client takes the original proto file and removes all the fields they don't use, so they are treated as unknown fields?

I don't know if there's a supported way to do this, though. To leverage it for refactoring, there would also need to be a way to do a query to find out out which clients use which fields.

Re: Dynamic type systems are not inherently more open

#237

Post by azhenley » Sun, Jan 19, 2020, 10:19 PM UTC

sweeneyrod wrote: post #233

azhenley wrote: post #163

Earlier quoted context omitted.

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.

If type inference damaged readability, we would expect companies/projects that use languages such as OCaml and Haskell where type inference is possible but not mandatory to have policies against it in their style guides. In my experience with OCaml, the widely agreed on style is to only annotate types of functions that are part of some public interface (although since this annotation is necessary to define the public…

Companies do have policies against using type inference (e.g., the use of var in C#).

But how would companies/people know if it damaged readability? There has been little research on this (a few studies are currently in peer review!) and our intuition about such things is often inaccurate. There are so many other confounding factors that it is hard to isolate just type inference/annotations.

Re: Dynamic type systems are not inherently more open

#238

Post by neilparikh » Sun, Jan 19, 2020, 10:26 PM UTC

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…

Statically typed languages can, and do permitted “fast and dirty” code.

For example, in Haskell: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: Dynamic type systems are not inherently more open

#239

Post by Silhouette » Sun, Jan 19, 2020, 10:46 PM UTC

pron wrote: post #223

Silhouette wrote: post #183

Earlier quoted context omitted.

My guess is that types would be better for enforcing code organization and for tooling ... while contracts are better for correctness I see what you're getting at, but there is one other crucial difference: the types we're talking about here are usually checked at compile time, whereas the contracts we're talking about here are usually checked at run time. Although the latter may be more expressive if other things ar…

> whereas the contracts we're talking about here are usually checked at run time No, they can be checked in many different ways, hence their power. They can be checked "statically", i.e. at compile-time, or dynamically. One approach is sound but requires more effort, while the other is cheap yet unsound -- and there is a spectrum in between the two extremes. > If you're writing a program that is going to control a sa…

No, they can be checked in many different ways, hence their power.

Sure, but the more dynamic ones that drift away from what a (good) static type system offers are exactly the ones that aren't amenable to automated proofs and so tend to be checked at run time.

Such programs often use formal methods that precisely use such contracts. Rich type systems (like Idris's) are virtually never used in practice in those cases.

As someone who has worked on relatively high-reliability systems, I can say with 100% confidence: it depends. This too is an area with a whole spectrum of possibilities, and some of those involve a degree of formal proof of algorithm properties but not a mechanically verified translation of those algorithms into implementation code. In such cases, a powerful static type system certainly can be a useful safeguard against introducing defects during the translation.

Re: Dynamic type systems are not inherently more open

#240

Post by yawaramin » Sun, Jan 19, 2020, 11:32 PM UTC

Barrin92 wrote: post #227

yawaramin wrote: post #224

Earlier quoted context omitted.

> ignoring or reasoning about unknowns diminishes the advantages of static typing. Ignoring the unknowns that are unnecessary to solve the problem at hand, is literally the essence of software abstraction. Why would you want to do more work than is necessary to solve a given problem? > you can define an "unknown" type if you want and make your static language as permissive as possible And 'unknown' type doesn't make…

>What you always gain from static typing–exposing the assumptions and invariants of your code as first-class parts of the code, making it easy for readers to understand at a glance what they are This is essentially what I was getting it. To me the static typing seems to be almost more about naming things that it is about verifying the correctness of your program in the face of unknown or interesting behaviour. And th…

> To me the static typing seems to be almost more about naming things that it is about verifying the correctness of your program in the face of unknown or interesting behaviour.

That's exactly backwards. The point is not naming things, the point is encoding behaviours and invariants in the type system so the compiler can help you check them.

> With typing, it is very easily possible for someone to create bad abstractions that you have no control over

It's possible for programs to be written badly in any typing discipline, static or dynamic. Neither saves you from the bad decisions of others. I've personally seen PHP code that no one could understand and everyone was afraid of touching because it heavily used reflection. I've heard of this for Ruby and Objective-C code too.