Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday February 07 2016, @01:48PM   Printer-friendly
from the doing-more-than-one-thing-at-a-time dept.

"What's the difference between parallel and concurrent? How does asynchrony relate to them? What sorts of solutions fit what sorts of problems? And how do these solutions look in Perl 6?"

Read this excellent YAPC (Yet Another Perl Conference) presentation for a summary of the ways that Perl 6 helps developers conquer these problems.

Direct PDF link.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by fnj on Sunday February 07 2016, @03:04PM

    by fnj (1654) on Sunday February 07 2016, @03:04PM (#300196)

    Oriented toward Perl 6, but a great exposition of concepts.

    • (Score: 2) by Marand on Monday February 08 2016, @07:44AM

      by Marand (1081) on Monday February 08 2016, @07:44AM (#300478) Journal

      Oriented toward Perl 6, but a great exposition of concepts.

      Another good source for discussion of these concepts is Clojure's creator, Rich Hickey. He's done a bunch of talks on these subjects, often without anything in them being language-specific. He focuses on approaching the problems from a functional programming standpoint, but still tends to cover the same issues and ways to solve them.

      They can be found by online search, with many also available on YouTube. I also linked to a couple specific ones in my other comment [soylentnews.org] here as well.

  • (Score: 1, Insightful) by Anonymous Coward on Sunday February 07 2016, @03:13PM

    by Anonymous Coward on Sunday February 07 2016, @03:13PM (#300199)

    I've been trying to decide what language to deep dive and really learn next. I wanted something that helps me seamlessly utilize all the cores in my computer's CPU via functional programming. I think Haskell would match that description but I find the syntax pretty obtuse - Perhaps it's more easily understood by a math major?
    Now that I've read this presentation, I can see that Perl 6 gives me a massive amount of power while allowing me to mix and match imperative and functional programming as needed. I honestly haven't been this excited about learning a new programming language in many many years. Well done, Perl 6 community, and well done on this presentation.

    • (Score: 0) by Anonymous Coward on Sunday February 07 2016, @07:22PM

      by Anonymous Coward on Sunday February 07 2016, @07:22PM (#300282)

      Your problem with Haskell is probably not so much to do with syntax as with the underlying paradigm, functional programming (https://en.wikipedia.org/wiki/Functional_programming), which is quite different from the standard imperative one you are probably used to. Functional programming was mandatory for CS majors where I studied, though, and I had a good deal fun doing it.

    • (Score: 2) by Marand on Monday February 08 2016, @07:29AM

      by Marand (1081) on Monday February 08 2016, @07:29AM (#300474) Journal

      I've been trying to decide what language to deep dive and really learn next. I wanted something that helps me seamlessly utilize all the cores in my computer's CPU via functional programming. I think Haskell would match that description but I find the syntax pretty obtuse - Perhaps it's more easily understood by a math major?

      Now that I've read this presentation, I can see that Perl 6 gives me a massive amount of power while allowing me to mix and match imperative and functional programming as needed. I honestly haven't been this excited about learning a new programming language in many many years. Well done, Perl 6 community, and well done on this presentation.

      If you're interested in both concurrency and functional programming, another good option is Clojure [clojure.org].

      • It's a Lisp, so syntax is largely nonexistent. (Plus you get proper macros, hell yeah)
      • Designed with multi-threaded use as a focus. It encourages function purity and immutable state.
      • However, it doesn't force purity and immutability. Side effects for IO are dead simple compared to purely functional languages like Haskell, and when you need mutable data you can get it with special data types.
      • Basically, it's pragmatic about functional programming; it defaults to safe, sane choices but still gives you the tools to shoot yourself in the foot when you want or need them.

      Even if you don't use it long-term, it's a good place to start if you're interested in functional programming or concurrency. It's easy enough to get into and its use of immutable everything, while a bit weird to adjust to, ends up being great for unlearning bad habits that can bite you in the ass when using threads.

      I should probably explain that a bit more. Probably the biggest distinction of Clojure is how it treats data. All data structures are immutable and treated as values. This is normal and well-understood for primitives: incrementing 2 doesn't change 2, it returns a new value; likewise, concatenating strings "foo" and "bar" returns a new string, "foobar". But with Clojure, it's expanded to complex data structures like vectors, hash maps, and lists. If you have a hash map (key/value pairs like Perl hashes) with keys :foo :bar and :baz, then remove :baz with dissoc, it doesn't change your map, it returns a new map with only :foo and :bar keys.

      This holds true even when working with one of the mutable types like atom; if you store a hash-map inside an atom, the hash itself never changes. When you dissoc :baz from the atom, Clojure swaps out the old hash with a new one, doing some fancy tricks under the hood to keep performance up while also retaining access to previous values stored within the atom. It's sort of like git for variables.

      There are four types (var, atom, ref, agent) that have different characteristics. For example, while atoms are asynchronous and the closest analogue to another language's variables, refs works more like database transactions. In fact, you have to define transactions via dosync and put all changes within that transaction. The transaction will retry until it succeeds, guaranteeing that at no point will code outside the transaction see an inconsistent state. it's the ACI part of ACID [wikipedia.org] for variables.

      I could keep going, but it's probably better to look into talks by Rich Hickey, the creator of Clojure. The Are We There Yet? [infoq.com] talk (transcript [github.com]) is a good place to start, along with Simple Made Easy [infoq.com] (transcript [github.com]). You can also find a bunch of them on Youtube as well, though sometimes the material overlap a bit.

      He does a great job of explaining the this stuff, focusing primarily on concurrency and functional programming. A lot of it is applicable to other languages and he's usually interesting as a speaker, so even if you have no interest in Clojure itself, watch (or read) his talks, they're worth the time.

      • (Score: 0) by Anonymous Coward on Monday February 08 2016, @01:30PM

        by Anonymous Coward on Monday February 08 2016, @01:30PM (#300570)

        Thanks for the very informative response! On my reading list.

        • (Score: 2) by Marand on Monday February 08 2016, @02:02PM

          by Marand (1081) on Monday February 08 2016, @02:02PM (#300586) Journal

          No problem. If there's anything else I can try to explain I will; explaining to someone else is a good way to help clarify the concepts in my head, so it's something I like to talk about.

          Though, I should add a couple things I forgot, specifically about the Lisp origins. One, don't let the Lispiness be a turn-off. The parentheses are a benefit, not a negative, because there's almost no syntax to a Lisp. You don't have to memorise a bunch of obtuse language rules, it's all parentheses and function names. Plus Clojure can actually be less parenthesis-heavy than other lisps (and sometimes Java itself) because of syntactic sugar like the threading macro (->) and Clojure's use of vectors (e.g. [foo,bar,baz]) for things like function argument lists. It's a style design choice that hardcore lispers may criticise, but I rather like.

          The other thing I should have mentioned is that Clojure has an excellent REPL, as one might expect, but it also has a networking variant, nREPL. The nrepl, when enabled, allows outside connections (local or remote) to a running Clojure program. That means you can, for example, start a Clojure program, then connect to it with the REPL (or an editor that supports REPL interaction, like Light Table, or cider in emacs) and modify the running code. Or, even better, you can build an Android application with Clojure, run it on a device, and then connect your desktop's REPL to it and modify the app while running.

          Clojure runs on the JVM normally, but there's a .NET variant that's maintained by someone and also a dialect called ClojureScript that compiles to JavaScript; you can use the nREPL aweosmeness on any of them.

  • (Score: 2) by Snotnose on Sunday February 07 2016, @03:45PM

    by Snotnose (1623) on Sunday February 07 2016, @03:45PM (#300210)

    To be honest, I hope to never write another line of perl again. Not a bash on the language, it's pretty impressive I'm just tired of interpreting someone else's line noise, only to discover it is in fact line noise.

    That said, I've done a lot of parallel programming. The contortions you have to go through to do it right is painful. Looks to me like Perl 6 has developed some great tools that will, hopefully, get translated to other languages.

    As someone else said, the PDF is well worth reading even if you don't know Perl.

    --
    Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
    • (Score: 0) by Anonymous Coward on Sunday February 07 2016, @04:30PM

      by Anonymous Coward on Sunday February 07 2016, @04:30PM (#300229)

      A couple of other pages worth reading:

      Concurrency [perl6.org] (Perl 6 docs)
      Perl 6 "Supplies" [wordpress.com] for handling asynchronous data

    • (Score: 0) by Anonymous Coward on Sunday February 07 2016, @09:54PM

      by Anonymous Coward on Sunday February 07 2016, @09:54PM (#300329)

      People like to rant about how good python is. Enforces syntax. Yadadada. I have seen python abused. Not as easy perhaps as perl but easily doable

    • (Score: 2) by maxwell demon on Monday February 08 2016, @03:35PM

      by maxwell demon (1608) on Monday February 08 2016, @03:35PM (#300646) Journal

      Emphasis by me:

      To be honest, I hope to never write another line of perl again. Not a bash on the language, it's pretty impressive I'm just tired of interpreting someone else's line noise, only to discover it is in fact line noise.

      Well, if you are writing code (as opposed to working on someone else's code) then any line noise you encounter is your own.

      --
      The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 2) by opinionated_science on Sunday February 07 2016, @03:55PM

    by opinionated_science (4031) on Sunday February 07 2016, @03:55PM (#300213)

    A nice read. quite compact, and I feel like I've read a textbook!

    • (Score: 2) by goodie on Sunday February 07 2016, @08:20PM

      by goodie (1877) on Sunday February 07 2016, @08:20PM (#300299) Journal

      Yep, pretty good, concise, and with clear examples. I'm no Perl6 developer, but the concepts apply regardless.

  • (Score: -1, Redundant) by Anonymous Coward on Sunday February 07 2016, @04:12PM

    by Anonymous Coward on Sunday February 07 2016, @04:12PM (#300220)

    In before bla bla wharrrgarbl write only yadda yadda line noise et cetera duke nukem perl 6 zippity doo dah children script trolls

  • (Score: 2) by darkfeline on Sunday February 07 2016, @11:25PM

    by darkfeline (1030) on Sunday February 07 2016, @11:25PM (#300361) Homepage

    No Go users here?

    I've found Go's goroutines and channels by far the easiest and most straightforward concurrent programming method. You can call functions as lightweight threads whenever and use channels as queues to communicate between them.

    I also don't see the point of distinguishing parallel and concurrent. Concurrent is a superset of parallel, and I can't think of any meaningful situations where something would be run in parallel yet not be concurrent. That sounds like it would imply ingeniously devilish race conditions from start to finish.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by LoRdTAW on Monday February 08 2016, @12:30AM

      by LoRdTAW (3755) on Monday February 08 2016, @12:30AM (#300375) Journal

      Have you watched Rob Pikes video "concurrency is no parallelism" in Go? https://vimeo.com/49718712 [vimeo.com]

      • (Score: 2) by darkfeline on Monday February 08 2016, @11:42PM

        by darkfeline (1030) on Monday February 08 2016, @11:42PM (#301036) Homepage

        I don't remember, maybe I have, but he's basically saying the same thing I am. Yes, concurrency is not the same thing as parallelism, but concurrency is what's important. Once something is concurrent, you can run it parallel or not, and conversely, something that runs parallel is necessarily concurrent unless it has a lot of race conditions.

        --
        Join the SDF Public Access UNIX System today!