Lucio, "It took Dijkstra quite some effort to accept the concept of "interrupts" (quotation anyone?), but eventually he went with it."
E.W. Dijkstra Archive: My recollections of operating system design (EWD1303) https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html "The third arrangement, known as "the interrupt", circumvents all these dilemmas. While the computer calculates at full speed, a piece of dedicated hardware monitors the outside world for completion signals from communication devices. When a completion is detected, the program under execution is interrupted after the current instruction and in such a fashion that it can be resumed at a later moment as if nothing had happened, thus instantaneously freeing the central processor for a suddenly more urgent task. After the interrupt the processor would execute a standard program establishing the source of the interruption and taking appropriate action." Peter On Saturday, August 5, 2017 at 12:26:58 AM UTC-4, Lucio wrote: > > (Some unjustifiable opinionated ramblings from a faraway place, read at > your peril.) > > It took Dijkstra quite some effort to accept the concept of "interrupts" > (quotation anyone?), but eventually he went with it. > > Resistance to operator overloading is as admirable as it is futile. > Ultimately, the range of base types in a programming language is an > arbitrary decision and the operators applied to them is equally an > artifact, not divine inspiration. Go slipped badly when it added "+" as the > string concatenation operator and I don't remember much resistance to that. > > In fact, I have adopted the expression x += 1 in lieu of x++ in all my > coding specifically because I don't think the increment operator is > necessary at all; a circular shift operator has more merit, but no one asks > for that. Nor has anyone, including Rob Pike, suggested that we head the > APL route and add any available special symbols as operators. I can see > why, of course! > > I would expect programming languages one or two generations from now to > resemble nature more closely and allow programs to evolve rather than be > "written" or coded. For that, the basic building blocks have to change > dramatically. But our guidance may well come from the DNA double helix and > its very small range of components. > > I find generics inelegant, they lack any aesthetic appeal and that was > enough for templates to turn me off C++ 2.0, I hope that Go will not adopt > similar ugliness. That said, if one could treat types as mutable properties > of the language objects (variables that can be transformed between > "compatible" types - a lot like interfaces allow presently, but much more > visibly, perhaps, I haven't thought that hard about it), then "generic > functions" would span such "types" intrinsically and still protect the > program from mistakes at compile time. Hmm, if the type assertion was > intrinsic rather than explicit, perhaps? We're trying to avoid that, so we > need a concept as fresh as "type interface", but more amenable to > enumeration, an explicit "type set" perhaps? I seem to remember something > like that from "kencc"? > > Ultimately, to return to the topic of operator overloading, with C++ they > came before templates and templates were the inevitable progression. > Interfaces are a different starting point and there is no immediately > obvious progression from there, but maybe the Go "leading minds" haven't > been looking. Maybe all we lack is the type of theory that went into > describing SQL as a mathematical concept, applied to interfaces, just > maybe... > > A final thought: the Go.1 promise is a wonderful idea, since it encouraged > a whole cultural group to look for every conceivable improvement that could > be made to a very stable core. But of course it had to apply blinkers. > Eventually, someone will peek over the edge of such blinkers and figure > what we've all been missing. It is not a critical component, but once it or > they are identified, it will be hard to imagine how they could have been > missed for so long. > > Lucio. > > On Saturday, 5 August 2017 03:52:28 UTC+2, as....@gmail.com wrote: >> >> I'm hesitant to accept generics due to the fear of *overloaded operators >> *being the next big deal*. *C# even has *properties (user-defined >> methods dispatched upon an assignment operation)*. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
