To clarify, the semantics of a go statement from a language perspective changes based on earlier statements. That is simply weird - and hurts readability.
> On Apr 23, 2023, at 9:01 AM, 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. > > 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. >> >> -- >> 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. -- 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/E8FA3620-7513-48C2-8263-98D9082469F5%40ix.netcom.com.
