"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)

"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."


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, 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 
For more options, visit

Reply via email to