in reply to Re^4: Attack on Perl or Perl's need better PR (again)
in thread Attack on Perl or Perl's need better PR (again)

Let's do a little rewording...
Concurrency is not a language issue for the same reason that it is not a checkbox that you can put on a feature list. Correctly implementing concurrent program is a process. Many things that help concurrency can become language features.
Would you agree? I for one disagree. Shared state parallelism (threads) is a huge bucket of worms. Humans really aren't smart enough to use it correctly. What we need are new languages to help us manage concurrency. Erlang and Oz spring to mind. To my mind problems like that scream out language issue. Same goes for security.
  • Comment on Re^5: Attack on Perl or Perl's need better PR (again)

Replies are listed 'Best First'.
Re^6: Attack on Perl or Perl's need better PR (again)
by tilly (Archbishop) on Dec 02, 2005 at 02:06 UTC
    I interpreted "language issue" to mean "something that you solve at the language level", in which case both statements are correct.

    Apparently you interpret "language issue" to mean "something that you can address at the language level", in which case both statements are absurd.

    What I meant should have been clarified by my second paragraph.

Re^6: Attack on Perl or Perl's need better PR (again)
by dragonchild (Archbishop) on Dec 01, 2005 at 19:54 UTC
    If you assume that concurrency and security are equivalent issues, then you're absolutely correct. Except, they're not. It's easy to demonstrate - concurrency can cause security issues. Security cannot cause concurrency issues. QED

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      That was called an analogy. YMMV.
        Apples and Oranges, maybe?

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?