4

I have been working on Software-Defined Radio projects for almost a year. This is an area which requires lots of signal processing (digital filters and FFTs), communication theory (modulation, equalization and synchronization) and information theory (specifically, coding theory, as Huffman, Linear and Convolutional codes). I program mostly in Matlab (for simulations) and C++ and Python (for practical applications using GNURadio and the USRP).

As you can see, those areas require lots of mathematical concepts. As I've been studying Haskell, I see that it is a good programming language for applications that involve heavy math.It seemed a good idea to program in Haskell for problems in the area I have been working on.

On the other hand, there doesn't seem to be a lot of people doing this. There seems to be a Haskell DSP library, but there aren't many projects using it available on the web. I've also found a thesis where Haskell was used to implement a Viterbi coder/decoder and it seems quite an elegant solution.

But it seems to me that people in the communication industry and research still don't use a lot of Haskell in their codes. Maybe this coulde be because many of them still haven't heard about Haskell.

What would be upsides and downsides of applying Haskell to those kind of problems? What will be key benefits of doing SDR in Haskell? What about Haskell would make it a bad choice for SDR? Should I expect severe pain points using Haskell for SDR (what are they?).

closed as primarily opinion-based by mattnz, GlenH7, Tangurena, david.pfx, Ampt Jul 22 '14 at 15:45

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Is there any way that you can rewrite this so that it is less opinion-based? What is your specific question? Words like "good idea," "bad idea," and concepts like popularity seldom make good questions; they provoke opinion-based responses, not expert advice. – Robert Harvey Jul 3 '14 at 21:56
  • 2
    Maybe asking for some the "Good, Bad and Ugly" points about applying Haskell in this field? – franchzilla Jul 3 '14 at 21:57
  • This Google Search yielded some very useful results. I believe that your primary concern is going to be getting results from Haskell in real-time or near real-time. – Robert Harvey Jul 3 '14 at 22:22
  • 1
    Haskell might be great for signal processing, but there's also the practical matter of whether it's worth rewriting the plethora of well-proven libraries that do DSP and the underlying math functions. Many of those libraries are written in FORTRAN or C, which makes them accessible from pretty much anywhere else. – Blrfl Jul 4 '14 at 22:05
  • Suggestion: if you must label yourself as a zealot, would you rather like to be a Language zealot or a DSP zealot? If you value DSP highly, you may want to ask the simple question of "How to do <some DSP stuff> in Haskell or FP", on dsp.stackexchange.com – rwong Jul 4 '14 at 22:17
3

I won't be able to provide answers to everything in your question, but I'll give ya what I know.

Good points

Flexibility of the language

Haskell should be a good language for writing code for the SDR domain:

Besides having good support for Embedded Domain-Specific Languages (EDSLs), Haskell code is highly composable, which will make it easy to work with signal processing concepts at a high abstraction level.

A library such as Pipes or Conduit will make it simple/easy to create filters (as functions) and chain them together to form processing pipelines. Arrowized Functional Reactive Programming (AFRP) might be another means to this end. (It uses some crazy circular programming wizardry under the hood.)

Libraries and external code

Haskell has what I've heard is a very good Foreign Function Interface (FFI) which lets it interface with C code, so you should have access to lots of libraries for doing signal processing through this. (I've not used the FFI directly myself, but I've used libraries which have.)

Some libraries pertinent to signal processing already have Haskell wrappers: the HMatrix library (warning: slow-loading PDF) is a wrapper around the LAPACK, BLAS, and GSL libraries, the first two of which I believe Matlab uses under the hood. The syntax of the Haskell code in this library seems like it should be easy to pick up for someone familiar with Matlab (I did a lot of Matlab back in school; I've only ever looked at HMatrix, not used it, but it looks niiiice).

Purely Functional

Haskell is purely functional which makes testing and verifying code easier than with an imperative language or one which supports mutability.

Bad points

Purely Functional

Haskell is purely functional, which means mutability can be tricky and it takes a different way of thinking to get things done. This shouldn't be too big of a problem if you go with a pipeline style architecture using one of the libraries I mentioned above.

Laziness

Haskell is a lazy language, which means that a value isn't computed until you try to use it*. If you're going to need a value right-away and it hasn't been computed yet, this can screw things up.

*This is probably a gross oversimplification.

Garbage collection

As with any language using garbage collection, there is a possibility it might kick in at the wrong time.

Why isn't it in use?

I think you may be correct in that people simply aren't aware of it in this field. Also, Haskell has a fairly steep learning curve, so people probably just stick with what they know.

0

How will anyone use the result of your efforts? If you intend others to use your result, you either have to provide a library that can be used from the mainstream programming languages, or work in that language. If you don't care, I suppose there is no point in asking the question, except that others may find your code harder to read, or they will not bother to read it. Certainly Haskell software is easier to reuse than Matlab software.

The only pain points for the language would be garbage collection delays and ensuring you have the correct data types for mathematical precision and speed.

  • I would go as far to say it would be a brave boss that let you use Haskell, knowing that no one else in the world with the domain skills will know the language, let alone the language paradigm. – mattnz Jul 10 '14 at 8:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.