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

Predicting Variable Types in Dynamically Typed Programming Languages

arxiv.org

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#21

Post by IshKebab »

toast0 wrote: post #16
jcelerier wrote: post #10

Earlier quoted context omitted.

> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.

I've basically spent my career without static types (except for the little bits of C that happen here and there), but I keep hearing about how types would change my world ... But then evertime I've looked at a typed language lately, everything is type 'auto'. Well, maybe not Java, I don't think they have auto yet? As an honest question, if types are good, why would you put auto, instead of telling me the type? For co…

Automatic type deduction is not the same as dynamic typing. There are still types and you still get compile time errors if they don't match.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#22

Post by IshKebab »

satyanash wrote: post #3

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statical…

That hasn't been my experience with Rust at all. Autocomplete never works.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#23

Post by jayd16 »

toast0 wrote: post #16
jcelerier wrote: post #10

Earlier quoted context omitted.

> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.

I've basically spent my career without static types (except for the little bits of C that happen here and there), but I keep hearing about how types would change my world ... But then evertime I've looked at a typed language lately, everything is type 'auto'. Well, maybe not Java, I don't think they have auto yet? As an honest question, if types are good, why would you put auto, instead of telling me the type? For co…

As others have said, you keep all the static checking with these systems but you get the brevity of a shorter definition.

It also makes refactoring easier. If you use var then you don't need to change all your declarations if you change a class name.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#24

Post by vidarh »

ScottBurson wrote: post #12
phoe-krk wrote: post #2

How does this relate and compare to actual type inference? For example, Common Lisp implementation SBCL is able to infer types pretty nicely now and it doesn't need neural networks for "predicting" the types with some kind of chance.

Data flow analysis will certainly predict a fair number of types in typical programs in dynamically-typed languages, but there will also be lots of cases it can't handle. I don't know the details of the CMUCL/SBCL type inference algorithm, but I've worked on whole-program data flow analysis, and there are still lots of types it fails to recover, for various reasons. Often, for example, the entire program is not avail…

It can still be used for optimization in many cases depending on the language, e.g by generating specialised versions and shunting calls from known call sites to the specialised version when you can either guarantee the guesses are right or cheaply lift guards up the call stack.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#25

Post by seanmcdirmid »

ScottBurson wrote: post #12
phoe-krk wrote: post #2

How does this relate and compare to actual type inference? For example, Common Lisp implementation SBCL is able to infer types pretty nicely now and it doesn't need neural networks for "predicting" the types with some kind of chance.

Data flow analysis will certainly predict a fair number of types in typical programs in dynamically-typed languages, but there will also be lots of cases it can't handle. I don't know the details of the CMUCL/SBCL type inference algorithm, but I've worked on whole-program data flow analysis, and there are still lots of types it fails to recover, for various reasons. Often, for example, the entire program is not avail…

DFA isn’t usually used in type inferencing algorithms, at least ones that generate types for programmers rather than compiler optimizations. It isn’t that it is expensive, but in general syntax tree walking works well enough.

Whole program analysis is too expensive for type inference (or much of anything for that matter) even with its precision ramped all the way down via something like CFA0. Type inference with sub typing is a very similar problem to alias analysis, which hints at why doing it in any but very restrictive contexts is too expensive.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#26

Post by truculent »

whateveracct wrote: post #13
satyanash wrote: post #3

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statical…

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way. Hell, in Haskell inference can take you pretty far, and you can defer type errors til runtime in development and basically get an opt-in dynamically typed experience!

> you can defer type errors til runtime in development dumb question: is there any reason you'd actually want to do this?

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#27

Post by hellofunk »

saagarjha wrote: post #6
satyanash wrote: post #3

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statical…

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc) I think it’s importatnt to mention that in Swift this lookup has exponential behavior, and can time out if the expression is too complex.

I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#28

Post by naasking »

truculent wrote: post #26
whateveracct wrote: post #13

Earlier quoted context omitted.

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way. Hell, in Haskell inference can take you pretty far, and you can defer type errors til runtime in development and basically get an opt-in dynamically typed experience!

> you can defer type errors til runtime in development dumb question: is there any reason you'd actually want to do this?

It's useful for prototyping, where your solution is always in flux and incomplete, but you need to test that some module is working correctly (like a hardware interface).

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#29

Post by defertoreptar »

satyanash wrote: post #3

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statical…

> Dynamic languages as a result of their "dynamicness" tend to allow much better expression of control flow when compared to static languages.

That may be, but I'll be damned if Golang's verbose type casting hasn't saved me from some bugs over the years.

Also, I think there's an argument for type declarations being expressive in their own right. I like seeing what types a function receives and returns. It's a quick jumping off point when trying to understand what the function does.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#30

Post by continuational »

hellofunk wrote: post #27
saagarjha wrote: post #6

Earlier quoted context omitted.

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc) I think it’s importatnt to mention that in Swift this lookup has exponential behavior, and can time out if the expression is too complex.

I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.

JetBrains business is all about understanding programming languages - Java in particular. And Kotlin is very, very close to Java.
Post reply on HN