Loading ...
Sorry, an error occurred while loading the content.

What year will your language become popular?

Expand Messages
  • Logan, Patrick D
    ... I would strongly encourage today s language designers to consider moving away from the early 1970 s model of shared memory and variations of Hoare s
    Message 1 of 1 , Feb 24, 2003
    • 0 Attachment
      > What I mean to say is - it is valuable to make all functions
      > synchronized, then provide a keyword 'reentrant' or something along
      > those lines. Once you start creating threads, nothing is sane
      > unless you specifically add locking mechanisms.

      > I would imagine this would help incremental development since you
      > wouldn't have to concentrate so much on concurrency (and keep more
      > of your hair).

      I would strongly encourage today's language designers to consider
      moving away from the early 1970's model of shared memory and
      variations of Hoare's monitor mechanism. [1] Implementing and then
      using these things are like programming in handcuffs. Been there, got
      the T-shirt (and the scars).

      Hoare himself moved away from monitors by the end of the 1970s. Why
      Gosling, et al. chose them for a 1990's applet language is almost
      beyond reason. Why Microsoft followed suit in the late 1990's, even
      moreso. [2]

      Don't say it's for performance. Erlang uses Hoare's later 1970's CSP
      mechanism and runs huge distributed real-time switches as well as huge
      near-real-time distributed Internet services. [3][4]

      Architecturally, where do monitors leave you? Bound to shared memory,
      objects are tangled up among themselves and their prophylactics,
      making migration of any set of objects into an alternate arrangement a
      challenge at best.

      Imperative languages should be sequential and shared-nothing to aid
      simplicity. They should communicate with messages by value to other
      processes running in the same address space (sharing no global
      references), a different address space on the same node, or to another
      node on the network. Each of these processes, whatever its location,
      maintains its own state that cannot be affected by another process
      except via message passing.

      Interestingly this approach is true in spirit to the intent of
      Smalltalk and of concurrent Active Objects. [5][6] Now that it is more
      than feasible, languages are needed to support the model. Existing
      languages can be used as-is, even re-hosted over time on more modern
      virtual machines, to develop cooperating components in this style,
      providing an evolutionary path toward systems based on shared-nothing
      message passing.

      The dotNET CLR and the JVM are dead ends, if for no other reason than
      any given language and virtual machine is an eventual dead
      end. Building new languages in a finer grained evolutionary style will
      prolong their lives and increase their value around the network, across
      many kinds of devices and arrangements. What year will your language
      become popular?

      [1] http://www.cs.mtu.edu/~shene/NSF-3/e-Book/MONITOR/basics.html

      [2] http://www.cs.mtu.edu/~shene/NSF-3/e-Book/CH/basics.html

      [3] http://www.erlang.org/

      [4] http://ll2.ai.mit.edu/talks/armstrong.pdf

      [5]
      http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_
      smalltalk.html

      [6]
      http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=active+objects&bt
      nG=Google+Search
    Your message has been successfully submitted and would be delivered to recipients shortly.