Just to nit-pick everyone: Short variable declarations are not there to omit type information. You can do that with a regular variable declaration: https://go.dev/play/p/6XePFCh-6G2 Short variable declarations exist to 1. be shorter and 2. allow you to avoid re-declaration errors when assigning multiple variables: https://go.dev/play/p/bgbU9mTunhL So, IMO short variable declarations definitely increase readability, just by that latter effect. Type-inference is a bonus.
On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfFtaM2KMPxRYdaFS79O0vf91RPzQBHwHa2CLJWB6r5DJQ%40mail.gmail.com.
