4 ms·

Is this specific to what Go offers, or is it just a CSP implementation? I can't tell from a glance at the page, but let's give credit where credit is due if it'

Is this specific to what Go offers, or is it just a CSP implementation? I can't tell from a glance at the page, but let's give credit where credit is due if it's coming from Hoare's ideas.

rumcajz 11y ago
it's CSP as extended by golang, i.e. with channels rather than named processes.
- eternalban 11y ago
  Is this how the term OO got degenerated? In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion. Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
  - skj 11y ago
    Go-the-language does not have a preemptive scheduler, just guarantees about how various means of synchronization interact. In fact, Go-the-implementation is only partially preemptive, I believe: in addition to calls into the runtime, calling any function can now be a scheduling event. But if you have a tight loop with no function calls (just arithmetic, perhaps), that goroutine will not yield control. A true preemptive scheduler would be able to take control from that goroutine.
    - eternalban 11y ago
      Not so. http://golang.org/doc/go1.2#preemption http://golang.org/doc/go1.2#preemption [edit: hmm. Possibly I've mis-parsed that.]
      - skj 11y ago
        I'm pretty sure you parsed that wrong :)
        eternalban 11y ago
        Yes, you're right. But original . re CSP stands :)
        skj 11y ago
        Sure. I don't really know much about CSP.
  - jerf 11y ago
    "Is this how the term OO got degenerated?" I have a theory that there exists no software engineering term that is unambiguously understood by all language communities to be the same thing. If there is one, it won't be for long. Another recent fun one: "Continuation". Used to mean something very specific in the programming language theory community, it is now nearly indistinguishable from "thread" in many communities.
    - eternalban 11y ago
      I agree and it is not good, at all. There is a serious impedance mismatch between industry and academia. The former wants them young and barefoot and the latter hasn't figured out how to convey the (at this point in time) substantial body of work in the field to those that elect for a 4 year (!) CS degree. Compare to state of affairs in medicine, as an example.
  - gravypod 11y ago
    The story is quite interesting if you have not read it. One of my favorite reads. http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
- pherq 11y ago
  Uh... CSP communication occurs by synchronising events between (possibly unnamed) processes. Each process offers events, and some events are only permitted to occur when every process in a synchronisation group offers them. Channels (which are a concept going back to CSP) are essentially families of events (so the set of events in.x for any x would also be referred to as the channel in). The main difference between CSP and the languages that are sort of based on it (and this is a difference that predates Go by a long time -- it's visible in occam, for example) is that CSP events aren't directional or procedural like channels, they're just things that sort of happen (so they don't have to be written from one place and read in another -- they can occur with only one process running, or can be used to synchronise between more than two processes, or one process can restrict another by not offering events). Communicating through named processes would be closer to the actor model than to CSP.
pherq 11y ago
It descends from the external choice operator in CSP, which offers a choice of events to the environment and lets any one of them happen (=~ accepting input on one of a number of channels, but CSP's semantics are a bit different from a typical PL).

Is this specific to what Go offers, or is it just a CSP implementation? I can't tell from a glance at the page, but let's give credit where credit is due if it's coming from Hoare's ideas.

rumcajz 11y ago

it's CSP as extended by golang, i.e. with channels rather than named processes.

eternalban 11y ago
Is this how the term OO got degenerated? In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion. Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
- skj 11y ago
  Go-the-language does not have a preemptive scheduler, just guarantees about how various means of synchronization interact. In fact, Go-the-implementation is only partially preemptive, I believe: in addition to calls into the runtime, calling any function can now be a scheduling event. But if you have a tight loop with no function calls (just arithmetic, perhaps), that goroutine will not yield control. A true preemptive scheduler would be able to take control from that goroutine.
  - eternalban 11y ago
    Not so. http://golang.org/doc/go1.2#preemption http://golang.org/doc/go1.2#preemption [edit: hmm. Possibly I've mis-parsed that.]
    - skj 11y ago
      I'm pretty sure you parsed that wrong :)
      - eternalban 11y ago
        Yes, you're right. But original . re CSP stands :)
        skj 11y ago
        Sure. I don't really know much about CSP.
- jerf 11y ago
  "Is this how the term OO got degenerated?" I have a theory that there exists no software engineering term that is unambiguously understood by all language communities to be the same thing. If there is one, it won't be for long. Another recent fun one: "Continuation". Used to mean something very specific in the programming language theory community, it is now nearly indistinguishable from "thread" in many communities.
  - eternalban 11y ago
    I agree and it is not good, at all. There is a serious impedance mismatch between industry and academia. The former wants them young and barefoot and the latter hasn't figured out how to convey the (at this point in time) substantial body of work in the field to those that elect for a 4 year (!) CS degree. Compare to state of affairs in medicine, as an example.
- gravypod 11y ago
  The story is quite interesting if you have not read it. One of my favorite reads. http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
pherq 11y ago
Uh... CSP communication occurs by synchronising events between (possibly unnamed) processes. Each process offers events, and some events are only permitted to occur when every process in a synchronisation group offers them. Channels (which are a concept going back to CSP) are essentially families of events (so the set of events in.x for any x would also be referred to as the channel in). The main difference between CSP and the languages that are sort of based on it (and this is a difference that predates Go by a long time -- it's visible in occam, for example) is that CSP events aren't directional or procedural like channels, they're just things that sort of happen (so they don't have to be written from one place and read in another -- they can occur with only one process running, or can be used to synchronise between more than two processes, or one process can restrict another by not offering events). Communicating through named processes would be closer to the actor model than to CSP.

pherq 11y ago

It descends from the external choice operator in CSP, which offers a choice of events to the environment and lets any one of them happen (=~ accepting input on one of a number of channels, but CSP's semantics are a bit different from a typical PL).