On Sun, Apr 23, 2023 at 4:01 PM Robert Engels <reng...@ix.netcom.com> wrote:
> Personally that syntax has always bothered me with readability. It > requires lots of previous knowledge in some cases. A syntax like > > x, var y int = blah > > Is more explicit that x is reused and y is declared. > That specific suggestion would not work. It would mean it is ambiguous whether `var x, err = fmt.Println()` is mean to be a declaration of only x, or both - and note that this specific order is the more relevant, as `err` is the specific variable that tends to be re-used by `:=`. There probably could be alternatives though. But that seems a moot point now. > > Go is all about being explicit until it isn’t. > > > > On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > 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 > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFtaM2KMPxRYdaFS79O0vf91RPzQBHwHa2CLJWB6r5DJQ%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/CAEkBMfH3Gtom-3aDijy%2BvmXzTO9GXWRXULpqy-fQ5b98UXR%3D3Q%40mail.gmail.com.
