5 ms·

> "For the programmer, that means we must grapple with problems such as concurrency, locking, asynchronicity,.." From my perspective, this is the problem of th

by slacka 13y ago

> "For the programmer, that means we must grapple with problems such as concurrency, locking, asynchronicity,.." From my perspective, this is the problem of this decade in HW and SW engineering. Around 2007, Intel hit the wall with single threaded CPU scaling. It has gone from doubling every 2 years to a few % increase per year. We at the beginning of this paradigm shift to massively multi-core CPUs. Both the tools and the theory are still in their infancy. In HW there are many promising advances being explored, such as GPUs, Intel Phi, new FPGA, and projects like Parallella. The software side also requires new tools to drive these new technologies. I think traditional threading will be viewed as a stopgap hack and will be replaced by some form of functional, flow-Based, and/or reactive programming models. A few years ago, I had to help our EEs write some testing software in LabVIEW. I was blow away by how elegantly it solves concurrency and fault tolerance to bad input data. It took no extra design to utilize multiprocessing and multithreading hardware. The synchronous model in our program eliminated the issue of deadlock and race conditions problems that come up when using asynchronous threads. Another project with great potential is NoFlo. What SW solutions have others run into in this field?

andyl 13y ago
Erlang / Elixir
- pron 13y ago
  Definitely. Also, for Scala/Java, there's Akka[1], for Clojure/ClojureScript there's core.async[2], and for Clojure/Java there's Quasar/Pulsar[3] [1] http://akka.io/ http://akka.io/ [2] https://github.com/clojure/core.async https://github.com/clojure/core.async [3] http://puniverse.github.io/pulsar/ http://puniverse.github.io/pulsar/
  - yareally 13y ago
    Also Scala Async[1] modeled after C#'s Async/Await, though still has a few "gotchas" in it. [1] https://github.com/scala/async https://github.com/scala/async
- rdtsc 13y ago
  No doubt. BEAM VM is a beautiful thing. Lightweight processes, per process heap, fault isolation, scheduler implementation, iolists. Looking at it after years of dealing with other VMs I find myself nodding my head quite bit saying "Yup, they got this right, aha, got this right too, and so on" Besides Elixir there is also LFE (a lisp flavored Erlang), also JOXA another lisp-like language for BEAM. Other systems usually copy and get inspired by Erlang/BEAM VM but often they pick the concurrency model. The real money is in fault tolerance. They are tied together somewhat, but they are different. As distributed systems grow larger and larger, it is nice if they scale or can parallelize their concurrent parts but they are not going to be practical if they fail. And failure modes of distributed systems are magnitudes worse than single node systems. But it is also hard to sell it. In other words telling developers look this system will isolate fault and you can restart part of it and upgrade it while it runs, is not going to get them inspired unless they are experienced and have been woken up at 3am by a pager when a large system is taken offline because a minor fault wasn't properly isolated. Many are rather more impressed by marketing and small speed benchmarks.
gruseom 13y ago
A few years ago, I had to help our EEs write some testing software in LabVIEW. I was blow away by how elegantly it solves concurrency and fault tolerance to bad input data. Could you describe this in more detail? I think it would be interesting. How does LabVIEW do those things and why did you find it elegant?
- TheLegace 13y ago
  I honestly had to use LabVIEW to generate a heart pulse(simulation for a pacemaker). God I hated it so much, so much so as to make one my passwords "labviewsux". I wish it would die, but that's just my opinion.
  - toyg 13y ago
    Eh, not much love lost for LabVIEW here as well. It put me off visual programming for good.
    - slacka 13y ago
      Yes, it's true LabVIEW has its own issues. It's a memory hog and the UI is cluttered and doesn't scale well for large projects. I don't think LV will be THE model for future programing, but I do think that its synchronous dataflow programming model could be part of the solutions to the concurrency issue that languages face today in the massively parallel domain. My experience was very different from yours. I couldn't believe how simple it was to add an additional test in parallel. It was just a copy/paste, update the functions, test parameters, and I/O. If only writing multithreaded code in C++ or Java was that simple. After my experience, I could see how LV could be a good fit for computer vision apps running on highly parallel architectures. It's too bad there not more modern, open dataflow languages out there. Massively complex modern CPUs wouldn't exist with tools like Verilog. As software grows in complexity, these tools may also offer some solutions on the software side.
  - greenmountin 13y ago
    You may not like LabVIEW, but it is extremely useful in some areas. For lab scientists who need to iterate quickly between taking useful data and running the experiment, it's nice to just copy and paste instead of naming new variables, etc. Currently other solutions are either Matlab (which sounds soul-destroying) or Python (which is still nontrivial).
msutherl 13y ago
I've been using multi-media 'coordination languages' like Max/MSP/Jitter, Pure Data, SuperCollider, Touch Designer, and vvvv for years after I got hooked on the model from my first synthesizer (the Nord Micro Modular). When I had to learn traditional programming in school (Java at first), it felt hopelessly barbaric to me. Imperative text-based languages are incredibly time consuming, error-prone, and difficult to use in comparison. Don't get me wrong, dataflow programming has its own gotchas– explicitly guaranteeing proper order can be tricky – and it's very hard for people from a traditional background to switch over (they're always reaching for the for-loop that isn't there), but it's quite clear to me that I can throw together a complex multimedia system with, say, camera input, some computer vision, effects, video playback, etc. in, say, 3 hours whereas it would take somebody starting from scratch in any other language at least twice that time if not 10 times[1]. Moreover, after they've finished, they enter a much longer period of intensive debugging, whereas dataflow systems I've built have been much closer to bug-free on the first draft. Whenever I introduce this stuff to engineers, it blows their minds. I'm beginning to feel like it's a matter of serious importance to spread the word far and wide about alternative programming paradigms that make many of the problems of this decade magically disappear and make programming more efficient and easier to learn. Shoot me an email if you're interested in more thoughts / pointers on this topic – skiptracer at gmail. [1] Somebody might be able to argue that they could be just as fast with Processing or openFrameworks, but anecdotally developing in those environments is still 2x slower and bug fixing goes on forever.
- ilovecomputers 13y ago
  Just when you think you've found all the environments for creative coding, you discover new ones and wonder who are these people outside of my clique who use them?
  - msutherl 13y ago
    Those are just some of the big ones! The list goes on: Polycode, Field, Overtone, ChucK, LuaAV, Plask, Lubyk, and many more.
    - 13y ago

by slacka 13y ago

andyl 13y ago

Erlang / Elixir

pron 13y ago
Definitely. Also, for Scala/Java, there's Akka[1], for Clojure/ClojureScript there's core.async[2], and for Clojure/Java there's Quasar/Pulsar[3] [1] http://akka.io/ http://akka.io/ [2] https://github.com/clojure/core.async https://github.com/clojure/core.async [3] http://puniverse.github.io/pulsar/ http://puniverse.github.io/pulsar/
- yareally 13y ago
  Also Scala Async[1] modeled after C#'s Async/Await, though still has a few "gotchas" in it. [1] https://github.com/scala/async https://github.com/scala/async
rdtsc 13y ago
No doubt. BEAM VM is a beautiful thing. Lightweight processes, per process heap, fault isolation, scheduler implementation, iolists. Looking at it after years of dealing with other VMs I find myself nodding my head quite bit saying "Yup, they got this right, aha, got this right too, and so on" Besides Elixir there is also LFE (a lisp flavored Erlang), also JOXA another lisp-like language for BEAM. Other systems usually copy and get inspired by Erlang/BEAM VM but often they pick the concurrency model. The real money is in fault tolerance. They are tied together somewhat, but they are different. As distributed systems grow larger and larger, it is nice if they scale or can parallelize their concurrent parts but they are not going to be practical if they fail. And failure modes of distributed systems are magnitudes worse than single node systems. But it is also hard to sell it. In other words telling developers look this system will isolate fault and you can restart part of it and upgrade it while it runs, is not going to get them inspired unless they are experienced and have been woken up at 3am by a pager when a large system is taken offline because a minor fault wasn't properly isolated. Many are rather more impressed by marketing and small speed benchmarks.

gruseom 13y ago

A few years ago, I had to help our EEs write some testing software in LabVIEW. I was blow away by how elegantly it solves concurrency and fault tolerance to bad input data. Could you describe this in more detail? I think it would be interesting. How does LabVIEW do those things and why did you find it elegant?

TheLegace 13y ago
I honestly had to use LabVIEW to generate a heart pulse(simulation for a pacemaker). God I hated it so much, so much so as to make one my passwords "labviewsux". I wish it would die, but that's just my opinion.
- toyg 13y ago
  Eh, not much love lost for LabVIEW here as well. It put me off visual programming for good.
  - slacka 13y ago
    Yes, it's true LabVIEW has its own issues. It's a memory hog and the UI is cluttered and doesn't scale well for large projects. I don't think LV will be THE model for future programing, but I do think that its synchronous dataflow programming model could be part of the solutions to the concurrency issue that languages face today in the massively parallel domain. My experience was very different from yours. I couldn't believe how simple it was to add an additional test in parallel. It was just a copy/paste, update the functions, test parameters, and I/O. If only writing multithreaded code in C++ or Java was that simple. After my experience, I could see how LV could be a good fit for computer vision apps running on highly parallel architectures. It's too bad there not more modern, open dataflow languages out there. Massively complex modern CPUs wouldn't exist with tools like Verilog. As software grows in complexity, these tools may also offer some solutions on the software side.
- greenmountin 13y ago
  You may not like LabVIEW, but it is extremely useful in some areas. For lab scientists who need to iterate quickly between taking useful data and running the experiment, it's nice to just copy and paste instead of naming new variables, etc. Currently other solutions are either Matlab (which sounds soul-destroying) or Python (which is still nontrivial).

msutherl 13y ago

I've been using multi-media 'coordination languages' like Max/MSP/Jitter, Pure Data, SuperCollider, Touch Designer, and vvvv for years after I got hooked on the model from my first synthesizer (the Nord Micro Modular). When I had to learn traditional programming in school (Java at first), it felt hopelessly barbaric to me. Imperative text-based languages are incredibly time consuming, error-prone, and difficult to use in comparison. Don't get me wrong, dataflow programming has its own gotchas– explicitly guaranteeing proper order can be tricky – and it's very hard for people from a traditional background to switch over (they're always reaching for the for-loop that isn't there), but it's quite clear to me that I can throw together a complex multimedia system with, say, camera input, some computer vision, effects, video playback, etc. in, say, 3 hours whereas it would take somebody starting from scratch in any other language at least twice that time if not 10 times[1]. Moreover, after they've finished, they enter a much longer period of intensive debugging, whereas dataflow systems I've built have been much closer to bug-free on the first draft. Whenever I introduce this stuff to engineers, it blows their minds. I'm beginning to feel like it's a matter of serious importance to spread the word far and wide about alternative programming paradigms that make many of the problems of this decade magically disappear and make programming more efficient and easier to learn. Shoot me an email if you're interested in more thoughts / pointers on this topic – skiptracer at gmail. [1] Somebody might be able to argue that they could be just as fast with Processing or openFrameworks, but anecdotally developing in those environments is still 2x slower and bug fixing goes on forever.

ilovecomputers 13y ago
Just when you think you've found all the environments for creative coding, you discover new ones and wonder who are these people outside of my clique who use them?
- msutherl 13y ago
  Those are just some of the big ones! The list goes on: Polycode, Field, Overtone, ChucK, LuaAV, Plask, Lubyk, and many more.
  - 13y ago