On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu < jlforr...@berkeley.edu> wrote:
> > Short definitions detract from one of Go’s primary goals - readability. I > started using Go in the first place because I wanted a strongly typed > language with explicit type declarations. > > Your claim of readability is not held by everyone. Some people prefer there be no type information in a program because the type information "detracts from what the program is doing". Hence, it becomes rather hard to please everybody. Short variable declarations are a poor man's type inference. In fully type-inferred languages, you can omit types everywhere, and the compiler will deduce an appropriate type for each declaration. It will typically pick the most general type for an expression. The type information is still there, but it is generated on-demand by the compiler, and programs which fail the type check are rejected. Haskell and OCaml are good examples of programming languages following this style. Yet in both languages, you often see type declarations sprinkled throughout the code base to guide the reader. You sort-of assume a certain amount of experience, and add types as you see fit to capture that experience. Often, you end up with your interfaces being type-annotated, but your internal code avoiding annotation. The grand advantage of type inference is that the types can vary easily. If you change a fundamental type, the compiler will check that your change is sound. And you don't have to go around the code base and change every occurrence. That's a really nice boon. We are slowly moving into a world where the compiler and the programmer are working on the code at the same time. You ask the compiler to fill out gaps in the programs you are writing. The result is that your editor can live-annotate the appropriate types of declarations and expressions because it can be lifted from the compiler. When I write OCaml, for instance, my editor annotates functions with types for me by adding a line above the function declaration in a smaller font. These lines only occur virtually in the buffer, and aren't present in the program file. For some languages, such as Agda, the interaction is even stronger: you can ask the compiler to fill in parts of the program based on the types they have. That is, types and terms coalesce and there is no stratification between them. Writing a term makes the compiler deduce the type. Writing a type makes the compiler deduce and fill in the term. Coming strong into this are large language models from machine learning. You can fill in lots of gaps in programs via LLMs. Programming often contains a lot of janitorial tasks around a computational kernel and LLMs can accelerate the janitor. In the future, I hope someone takes an LLM and starts exploiting type information. I have a hunch it's going to be far more effective for languages which have static type systems (inferred or not) because there's a much richer set of information you can exploit. -- J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com.
