A couple months ago, I queried the list about what languages they find most 
useful for computer music. I was disenchanted with Python, and thinking of 
switching to Lisp or Haskell.

I started a study of Haskell two months ago. Oh my goodness! As a functional 
language, it is vastly different than the imperative languages most programmers 
are used to. Its fundamental concepts are difficult to understand. Programs in 
Haskell are often very short, and to the beginner's eye cryptic as all hell. 
It's not easy to grasp WHY a Haskell program does what it is supposed to do.

Learning Haskell, you get a good exposure to the mathematical literature that 
forms the basis of functional programming. VERY different experience than 
learning Python or Java.

However, the good news is that all this stuff is supposed to be intuitive and 
fit together neatly, once you learn it. We tend to forget how much experience 
went into learning imperative programming, and don't realize how much of that 
learning has to be replicated in undertaking functional programming.

I've made some progress. Maybe the biggest progress is that I don't tremble in 
fear when I see statements like "Applicative functors are also pointed when 
defined on a monoid."

But, I'm beginning to wonder if there is really a practical payoff for what I 
want to do. I would be interested in hearing from the member(s) on this list who 
use Haskell.

Thanks,
Mike

Intrigued by that discussion about Haskell, I read quite a bit about it, 
and it looks like a very nice language. But I obeyed a rule in IT that 
says that when you can choose from a number of tools, you shouldn't only 
consider the features of the tools, but also which tool you (or your 
team) knows best. Learning a new tool may be interesting, but is also 
time consuming, especially if it is a very different way of doing 
things, like Haskell is.

For CSound I'm just fine with Python, I don't see what Haskell could 
offer that makes things so much better that I can justify spending a lot 
of time on it. Actually I know C++ much better, but you can store Python 
code in a Blue project, a big plus, so I use Python.

Mark

Michael P Mossey wrote:
> A couple months ago, I queried the list about what languages they find 
> most useful for computer music. I was disenchanted with Python, and 
> thinking of switching to Lisp or Haskell.
>
> I started a study of Haskell two months ago. Oh my goodness! As a 
> functional language, it is vastly different than the imperative 
> languages most programmers are used to. Its fundamental concepts are 
> difficult to understand. Programs in Haskell are often very short, and 
> to the beginner's eye cryptic as all hell. It's not easy to grasp WHY 
> a Haskell program does what it is supposed to do.
>
> Learning Haskell, you get a good exposure to the mathematical 
> literature that forms the basis of functional programming. VERY 
> different experience than learning Python or Java.
>
> However, the good news is that all this stuff is supposed to be 
> intuitive and fit together neatly, once you learn it. We tend to 
> forget how much experience went into learning imperative programming, 
> and don't realize how much of that learning has to be replicated in 
> undertaking functional programming.
>
> I've made some progress. Maybe the biggest progress is that I don't 
> tremble in fear when I see statements like "Applicative functors are 
> also pointed when defined on a monoid."
>
> But, I'm beginning to wonder if there is really a practical payoff for 
> what I want to do. I would be interested in hearing from the member(s) 
> on this list who use Haskell.

> A couple months ago, I queried the list about what languages they find 
> most useful for computer music. I was disenchanted with Python, and 
> thinking of switching to Lisp or Haskell.

maybe it would help if you described the kind of algorithm you have in 
mind. in my view no specific language is best suited for computer music, 
but certain languages are definitely better for specific people and 
mindsets.

I do not know Haskell but I do code a lot in a functional perspective 
(mostly in Lisp). I wonder what you expect *precisely* from a functional 
language, and for example what you did not find in Python.

how would you map musical concepts and structures as functional 
programming constructs ? maybe we could start the discussion from this 
point and see later on if this mapping can actually be more easily 
implemented in a specific language.

regards,

Stef

One point no one has mentioned with regard to choosing a language is the
likelihood of its long-term life.

Over the years I have written interesting music applications in various
languages that seemed easy to learn and use, only to find that they no
longer are available on newer platforms. For this reason I decided to use
Java, not because of anything about the structure of the language, but
because I felt secure that my programs would be portable to new platforms
and that Java was so widely used as to have substantial longevity.

There was a discussion recently about the longevity of Csound itself, and
that is also an important factor for me. While LISP has been around for a
very long time, I'm aware of its many dialects. The existence of these
dialects is like an alarm bell for me: it means that the community that
supports LISP is splintered, and that cannot be good for its users.

-Lou


On 5/20/09 7:21, "    jlato@mail.utexas.edu" <    jlato@mail.utexas.edu>
wrote:

> This is definitely a valid point, but the answer is not
> straightforward.  In your analysis, you question whether the benefits
> of learning a language outweigh the cost of doing so.  Unfortunately
> this can't be properly answered until after you've learned the
> language (see discussions of blub).
> 
> In the end, I think it comes down to how much the individual values
> knowledge for its own sake.  You have to be willing to invest time
> into something that may or may not be useful to you simply for the
> sake of learning it.
> 
> John L.
> 
> Quoting Mark Van Peteghem :
> 
>> Intrigued by that discussion about Haskell, I read quite a bit about
>> it, and it looks like a very nice language. But I obeyed a rule in IT
>> that says that when you can choose from a number of tools, you
>> shouldn't only consider the features of the tools, but also which tool
>> you (or your team) knows best. Learning a new tool may be interesting,
>> but is also time consuming, especially if it is a very different way of
>> doing things, like Haskell is.
>> 
>> For CSound I'm just fine with Python, I don't see what Haskell could
>> offer that makes things so much better that I can justify spending a
>> lot of time on it. Actually I know C++ much better, but you can store
>> Python code in a Blue project, a big plus, so I use Python.
>> 
>> Mark
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


---------------------------
Permanent email:           loucohen@jolc.net
Music and video:            http://ruccas.org/wiki.pl/Lou_Cohen
More music and video:   http://www.youtube.com/loucohen
Astronomy:                    http://www.jolc.net
Open Sound:                 http://www.opensound.org
QFD:              
http://www.pearsonhighered.com/educator/academic/product/0,3110,0201633302,0
0.html
----------------------------

hi

On Wed, May 20, 2009 at 10:07 AM, Lou Cohen  wrote:
> There was a discussion recently about the longevity of Csound itself, and
> that is also an important factor for me. While LISP has been around for a
> very long time, I'm aware of its many dialects. The existence of these
> dialects is like an alarm bell for me: it means that the community that
> supports LISP is splintered, and that cannot be good for its users.

but isn't csound similarly splintered? think of all the add-ons and
special versions and front end packages that have come and gone over
the years.

isn't this what happens when a lot of different people want to work on
the same thing? [divergence] isn't this just a manifestation of the
variety of humanity?

maybe i am looking from the wrong perspective ...

-- 
\js  [ http://or8.net/~johns/ ]

But csound5 still runs trapped composed for MUSIC11 (see
earlier Dr B post). I can't call this splintered.

Victor
----- Original Message ----- 
From: "john saylor" 
To: 
Sent: Wednesday, May 20, 2009 5:21 PM
Subject: [Csnd] Re: Re: Re: Re: Haskell for computer music


> hi
>
> On Wed, May 20, 2009 at 10:07 AM, Lou Cohen  wrote:
>> There was a discussion recently about the longevity of Csound itself, and
>> that is also an important factor for me. While LISP has been around for a
>> very long time, I'm aware of its many dialects. The existence of these
>> dialects is like an alarm bell for me: it means that the community that
>> supports LISP is splintered, and that cannot be good for its users.
>
> but isn't csound similarly splintered? think of all the add-ons and
> special versions and front end packages that have come and gone over
> the years.
>
> isn't this what happens when a lot of different people want to work on
> the same thing? [divergence] isn't this just a manifestation of the
> variety of humanity?
>
> maybe i am looking from the wrong perspective ...
>
> -- 
> \js  [ http://or8.net/~johns/ ]
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

All the stuff in the Vercoe Students folder on
The Csound Catalog was originally music11 stuff
that I would use to test Csound in 1985, 86.

-dB


Dr. Richard Boulanger  -  rboulanger@berklee.edu



On May 20, 2009, at 12:49 PM, victor wrote:

> But csound5 still runs trapped composed for MUSIC11 (see
> earlier Dr B post). I can't call this splintered.
>
> Victor
> ----- Original Message ----- From: "john saylor" 
> To: 
> Sent: Wednesday, May 20, 2009 5:21 PM
> Subject: [Csnd] Re: Re: Re: Re: Haskell for computer music
>
>
>> hi
>>
>> On Wed, May 20, 2009 at 10:07 AM, Lou Cohen   
>> wrote:
>>> There was a discussion recently about the longevity of Csound  
>>> itself, and
>>> that is also an important factor for me. While LISP has been  
>>> around for a
>>> very long time, I'm aware of its many dialects. The existence of  
>>> these
>>> dialects is like an alarm bell for me: it means that the community  
>>> that
>>> supports LISP is splintered, and that cannot be good for its users.
>>
>> but isn't csound similarly splintered? think of all the add-ons and
>> special versions and front end packages that have come and gone over
>> the years.
>>
>> isn't this what happens when a lot of different people want to work  
>> on
>> the same thing? [divergence] isn't this just a manifestation of the
>> variety of humanity?
>>
>> maybe i am looking from the wrong perspective ...
>>
>> -- 
>> \js  [ http://or8.net/~johns/ ]
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Csound has not diverged at all in the important senses:

Early compositions still render on current Csound.

Alternative versions of Csound appeared, but the only one still being
maintained is still the lineal descendent of the original version.
Some of the ideas from the alternative versions have migrated into the
original version, which is good.

In short, adding new capabilities does not harm compatibility as long
as existing capabilities continue to work.

I think Csound is in pretty good shape for what it is, and if we can
get it working smoothly on multiple cores it should have at least as
long a life in the future as it has had up till now.

Regards,
Mike




On 5/20/09, Dr. Richard Boulanger  wrote:
> All the stuff in the Vercoe Students folder on
> The Csound Catalog was originally music11 stuff
> that I would use to test Csound in 1985, 86.
>
> -dB
>
>
> Dr. Richard Boulanger  -  rboulanger@berklee.edu
>
>
>
> On May 20, 2009, at 12:49 PM, victor wrote:
>
>> But csound5 still runs trapped composed for MUSIC11 (see
>> earlier Dr B post). I can't call this splintered.
>>
>> Victor
>> ----- Original Message ----- From: "john saylor" 
>> To: 
>> Sent: Wednesday, May 20, 2009 5:21 PM
>> Subject: [Csnd] Re: Re: Re: Re: Haskell for computer music
>>
>>
>>> hi
>>>
>>> On Wed, May 20, 2009 at 10:07 AM, Lou Cohen 
>>> wrote:
>>>> There was a discussion recently about the longevity of Csound
>>>> itself, and
>>>> that is also an important factor for me. While LISP has been
>>>> around for a
>>>> very long time, I'm aware of its many dialects. The existence of
>>>> these
>>>> dialects is like an alarm bell for me: it means that the community
>>>> that
>>>> supports LISP is splintered, and that cannot be good for its users.
>>>
>>> but isn't csound similarly splintered? think of all the add-ons and
>>> special versions and front end packages that have come and gone over
>>> the years.
>>>
>>> isn't this what happens when a lot of different people want to work
>>> on
>>> the same thing? [divergence] isn't this just a manifestation of the
>>> variety of humanity?
>>>
>>> maybe i am looking from the wrong perspective ...
>>>
>>> --
>>> \js  [ http://or8.net/~johns/ ]
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Stéphane Rollandin wrote:
>> A couple months ago, I queried the list about what languages they find 
>> most useful for computer music. I was disenchanted with Python, and 
>> thinking of switching to Lisp or Haskell.
> 
> maybe it would help if you described the kind of algorithm you have in 
> mind. in my view no specific language is best suited for computer music, 
> but certain languages are definitely better for specific people and 
> mindsets.
> 
> I do not know Haskell but I do code a lot in a functional perspective 
> (mostly in Lisp). I wonder what you expect *precisely* from a functional 
> language, and for example what you did not find in Python.
> 
> how would you map musical concepts and structures as functional 
> programming constructs ? maybe we could start the discussion from this 
> point and see later on if this mapping can actually be more easily 
> implemented in a specific language.
> 

I'm not looking for a definite answer. I don't know what algorithms I'll be 
using in the future. My mindset is that of "computer scientist"... looking 
at software as something beautiful. And Haskell is much more beautiful than 
most languages. It's documentation is beautiful, too, and its support 
community is amazing. (On #haskell I can get high-quality answers by 
chatting with other Haskellers, and it's usually humming 24/7.)

One thing I dislike about imperative languages in general is the difficulty 
of proving your code correct (this is far easier in functional languages) 
and the amount of repetitive boilerplate code (Haskell specializes in 
abtracting to a very, very deep level and having a terse elegant syntax).

Some of what I will be doing is combinatorial search, and I think 
functional programming is probably well suited for that.

In summary, my desires are probably more about the whole experience of 
programming in a language than about how well suited it is for specific jobs.

Mike

My initial response to your post is below. On re-reading your post, I
see that you indeed appear to be more interested in computer SCIENCE
than in computer MUSIC.

In that case, I would urge you to look very closely at the whole
family of languages that appeals to you. Select the one in which the
most actual software has been written, especially computer music
software, and which runs the fastest. You may need to try starting
projects in several languages before you are happy. I think Haskell is
probably a good choice, but plain old Lisp might be a good choice also
-- of course there already are mature computer music systems in Lisp
or Scheme (Nyquist and Common Lisp Music/sndlib, to start).

Original response follows...

I will repeat something that I have said several times in the past. It
is based on extensive personal experience, both in music programming,
and in programming trading systems in the financial industry (my day
job).

To cut to the point, use C++ if the user is not going to be
programming, and use Python if the user is going to be programming.

As it happens, the people who write commercial music software,
academic signal processing researchers, and the military all tend to
use C++ or C. This is for very good reasons. I think that if you make
another choice, you have to have even better good reasons, and I don't
think your personal "taste" is a good reason unless you are just
trying to have fun with computers, and whether anything gets computed
in the end, like sound or music, is not really the priority.

The only reason to use a computer is that it is faster than a pencil
and paper. So, the faster it is, the better it is. C and C++ are the
fastest high-level languages and this is not likely to change anytime
soon. In addition to being essentially as fast as C, C++ provides
facilities that make it possible to write software on a large scale
and not get bogged down: classes and templates.

In the real world, this is more important than the elegance of
functional programming.

I think it also should be a very large consideration for anyone
programming complex software how much other software is available for
easy re-use. Again, the universal interface to libraries in complex
systems is a "C" API.

Please, think why the engineers who write software for fighter jets
and for analysing particle accelerator experiments and for
experimenting with wavelets all use C++ or  C. Think why almost all
software sound synthesis systems are written in C or C++, and ALL the
ones in wide use are.

Hope this is relevant,
Mike










On 5/20/09, Michael Mossey  wrote:
>
>
> Stéphane Rollandin wrote:
>>> A couple months ago, I queried the list about what languages they find
>>> most useful for computer music. I was disenchanted with Python, and
>>> thinking of switching to Lisp or Haskell.
>>
>> maybe it would help if you described the kind of algorithm you have in
>> mind. in my view no specific language is best suited for computer music,
>> but certain languages are definitely better for specific people and
>> mindsets.
>>
>> I do not know Haskell but I do code a lot in a functional perspective
>> (mostly in Lisp). I wonder what you expect *precisely* from a functional
>> language, and for example what you did not find in Python.
>>
>> how would you map musical concepts and structures as functional
>> programming constructs ? maybe we could start the discussion from this
>> point and see later on if this mapping can actually be more easily
>> implemented in a specific language.
>>
>
> I'm not looking for a definite answer. I don't know what algorithms I'll be
> using in the future. My mindset is that of "computer scientist"... looking
> at software as something beautiful. And Haskell is much more beautiful than
> most languages. It's documentation is beautiful, too, and its support
> community is amazing. (On #haskell I can get high-quality answers by
> chatting with other Haskellers, and it's usually humming 24/7.)
>
> One thing I dislike about imperative languages in general is the difficulty
> of proving your code correct (this is far easier in functional languages)
> and the amount of repetitive boilerplate code (Haskell specializes in
> abtracting to a very, very deep level and having a terse elegant syntax).
>
> Some of what I will be doing is combinatorial search, and I think
> functional programming is probably well suited for that.
>
> In summary, my desires are probably more about the whole experience of
> programming in a language than about how well suited it is for specific
> jobs.
>
> Mike
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

namaste

On Wed, May 20, 2009 at 12:49 PM, victor  wrote:
> But csound5 still runs trapped composed for MUSIC11 (see
> earlier Dr B post). I can't call this splintered.

but [to keep to the lisp comparisons], couldn't you say the same about
lisp? not being a lisp programmer, i don't know ...

but isn't this just 'backward compatibility'?
[a noble goal and well done in csound as many have pointed out here]

-- 
\js  [ http://or8.net/~johns/ ]

It definitely depends. I'm a professional programmer, in that case 
learning a new language for a project is usually not affordable. But 
when you can do it in your spare time, and you want to spend some time 
learning Haskell instead of writing music, why not?

jlato@mail.utexas.edu wrote:
> This is definitely a valid point, but the answer is not 
> straightforward.  In your analysis, you question whether the benefits 
> of learning a language outweigh the cost of doing so.  Unfortunately 
> this can't be properly answered until after you've learned the 
> language (see discussions of blub).
>
> In the end, I think it comes down to how much the individual values 
> knowledge for its own sake.  You have to be willing to invest time 
> into something that may or may not be useful to you simply for the 
> sake of learning it.
>
> John L.
>
> Quoting Mark Van Peteghem :
>
>> Intrigued by that discussion about Haskell, I read quite a bit about
>> it, and it looks like a very nice language. But I obeyed a rule in IT
>> that says that when you can choose from a number of tools, you
>> shouldn't only consider the features of the tools, but also which tool
>> you (or your team) knows best. Learning a new tool may be interesting,
>> but is also time consuming, especially if it is a very different way of
>> doing things, like Haskell is.
>>
>> For CSound I'm just fine with Python, I don't see what Haskell could
>> offer that makes things so much better that I can justify spending a
>> lot of time on it. Actually I know C++ much better, but you can store
>> Python code in a Blue project, a big plus, so I use Python.
>>
>> Mark
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"
>

-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

john saylor wrote:
> hi
>
> On Wed, May 20, 2009 at 10:07 AM, Lou Cohen  wrote:
>   
>> There was a discussion recently about the longevity of Csound itself, and
>> that is also an important factor for me. While LISP has been around for a
>> very long time, I'm aware of its many dialects. The existence of these
>> dialects is like an alarm bell for me: it means that the community that
>> supports LISP is splintered, and that cannot be good for its users.
>>     
>
> but isn't csound similarly splintered? think of all the add-ons and
> special versions and front end packages that have come and gone over
> the years.
>
> isn't this what happens when a lot of different people want to work on
> the same thing? [divergence] isn't this just a manifestation of the
> variety of humanity?
>
> maybe i am looking from the wrong perspective ...
>   

In some frontends and tools there are variations of the code, like Blue 
that has a syntax to put the value of a graphical widget in instrument 
code, or Score11 that has extra features in the score. So you need some 
editing to use code elsewhere. But that situation doesn't feel like it 
is splintered.

If e.g. two different versions of CSound would add an optional parameter 
to an opcode, each with a different meaning, or introduce two different 
opcodes with the same name, that would definitely be splintering. But I 
don't know of such things.


-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

Michael P Mossey wrote:

> But, I'm beginning to wonder if there is really a practical payoff for what I 
> want to do. I would be interested in hearing from the member(s) on this list who 
> use Haskell.

While I do use Haskell, I don't use it for Computer Music. All of
my audio/music work is still done in C which is probably the 
language most appropriate for the kind of work. I did do some 
dabbling in Csound some time ago, but simply haven't had time to
pursue that recently.

Outside of audio/music I use Ocaml and more recently Haskell for
tasks where most other people choose Python. Ocaml and Haskell
give the ease of development of Python but allow me to write more
robust, reliable code than I could ever write in Python.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Victor.Lazzarini@nuim.ie wrote:

> AFAICS Python would also support well a functional styleof
> programming (although this appears to me to be moreof a state
> of mind, so the language might not matter so much ;)

Haskell offers much more than just a functional style of
programming, it offers a type system and compiler than can
find bugs at compile time that in Python would result in a
run time error.

For people using Python to compose and then render their music,
then they can probably live with the ocassional run time error.
For people doing live computer aided performance, the possibility 
of run time errors may be enough to make them want to explore 
languages like Haskell that provide better static guarantees
of program correctness.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Well, for me, I always consider Csound SCO a data format rather than a
language.  That's always helped me in how I work with it.  It'd be the
same as calling MIDI a language, but it's just a data format.  (This
is ignoring the features of Csound SCO like sections, repeats, loops,
etc. that I don't care for). The interface for music making I think
generally happens on a higher level of abstraction for most people,
hence we have visual environments like sequencers and notation
programs, or how we use programming languages to work with an
abstraction of music that best fits our musical needs.

For my own way of working, I prefer to have different ways to
represent music depending on musical need.  I use python mostly in
blue, python for expressing a singular musical idea, while using the
timeline to coordinate ideas in time.  I also will use plain SCO if
the idea is more of a singular sound.  I also have access to
pianoRolls, trackers, and pattern editors for when those are best for
expressing the musical idea I am interested in.

Technically, using blue's external object, one should be able to
program a musical idea in Haskell as well, probably calling ghci or
whatever Haskell interpreter you may use (would probably be best to
use an interpreter and not a compiler with blue's external object).
This would create a dependency for your project on the Haskell
interpreter existing on the computer the project is opened on, but if
you're comfortable with that then it's all good.

In differing with Michael, I'm concerned with speed but also balance
it with long term viability.  C/C++ has too much dangers for my taste
when it comes to developing visual programs, and one still needs to
protect themselves from different hardware.  Java adds a VM with
strict definitions of size of data, etc., and generally protects
developer from hardware differences.  Running Java apps works too
without recompilation on 64-bit CPU's with VM's compiled for them. I
can run applets from 1997 with VM's today without recompilation.
Having a VM for compiled applications, or using interpreted languages
I have come to the conclusion best provide longevity.  It's why Csound
(an interpreted music system) has lasted so long, IMO.  I'm more than
happy with the performance of Java for bigger applications, and find
Python more than expressive enough for the musical work I do.

Just some thoughts.  I think everyone should use the tool best for them. :)

steven

On Wed, May 20, 2009 at 2:36 PM, Martin Rodgers
 wrote:
> On Wednesday 20 May 2009, Michael P Mossey wrote:
>> But, I'm beginning to wonder if there is really a practical payoff for what
>> I want to do. I would be interested in hearing from the member(s) on this
>> list who use Haskell.
>
> You might find the answer in Paul Hudak's book, esp in the final chapters. I
> know I did. http://www.haskell.org/soe/
>
> With Haskore, I can express music in a notation that makes sense to me.
> Csound's numeric score language doesn't do that for me. That makes sense in a
> non-musical way, as it talks about events, but Haskore talks about *music*. It
> lets me talk about music in the way I want to. When I want to talk about the
> event-level, I find the Csound orc language works, not the score language.
>
> This is not a criticism of the score language. That's an ideal language for
> the two programs to communicate with. When I'm designing non-MIDI instruments,
> I really do need to talk about the event-level details, and the score language
> is ideal for that.
> --
> Martin Rodgers http://www.wildcard.demon.co.uk
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Michael Gogins wrote:
> My initial response to your post is below. On re-reading your post, I
> see that you indeed appear to be more interested in computer SCIENCE
> than in computer MUSIC.
> 
> In that case, I would urge you to look very closely at the whole
> family of languages that appeals to you. Select the one in which the
> most actual software has been written, especially computer music
> software, and which runs the fastest. You may need to try starting
> projects in several languages before you are happy. I think Haskell is
> probably a good choice, but plain old Lisp might be a good choice also
> -- of course there already are mature computer music systems in Lisp
> or Scheme (Nyquist and Common Lisp Music/sndlib, to start).

Well, I have at least two goals in life: (1) to make music. (2) to do my day job 
as best I can. Learning more computer science can contribute to both endeavors. 
I also enjoy computer science. So my plan is to use doing music and working my 
day job as a chance to pick up some computer science along the way. Earlier this 
year I got very dissatisfied with my stagnation---I've done nothing but Python 
programming for four or five years, and even then I was mainly focused on the 
job and didn't try to pick up new ideas. So I have resolved to spend 10-15% of 
my time learning new things.

I suspect that Lisp is a better choice than Haskell, Lisp being a flexible 
language (many possible programming styles), plenty of books about it (books 
that would be a good introduction to new ideas), and quite practical for 
actually getting things done. But, seeing that I've committed this much time to 
Haskell, I want to see it through.

-Mike

But is it only me or is Haskell not a hard language to read?
Would the time gained not bothering with possible bugs not be lost
just understanding what the heck is going on in this code?
Monads, heh? Just spent half an hour trying to figure that one
out.

Some people seem to have strong opinions about stuff, like
here http://www.andromeda.com/people/ddyer/topten.html.
My take is that most of it is non-sense, just a bit of experience
with C will cover all those holes cited there.

But I suppose, my uses for programming languages are probably
meagre compared to many of you. I just need to get audio in
and out from somewhere and do something with it, if possible
in less time than it would take to play it back, but not strictly.
I also would like to be able to prototype ideas for doing this and
be able to display results in various ways. A few years back
I would only use C or C++ for all this (which made some people
bark back at me saying that I was mad or something for prototyping
in C or C++). Then I discovered Python and scipy etc, so I have
farmed out the prototyping side to it.

While it would be cool to know all these complex typing systems
and whatnot, I might find it hard right now to make some real use
of it. But who knows? It might help with DSP, although I am
actually thinking learning to use SAGE http://www.sagemath.org/
might make a good time investment. And on the functional side,
FAUST http://faust.grame.fr/ is very promising for the stuff I do.

A funny aside: Erik kept mentioning OCamL and I kept thinking that
is interesting, you know the parallel language used in transputers,
is that still around, might be useful to learn, etc,
because I mistook it for Occam! Only now I realised what he is
going on about. Just shows how dumb I am.

Victor

----- Original Message ----- 
From: "Erik de Castro Lopo" 
To: 
Sent: Wednesday, May 20, 2009 11:26 PM
Subject: [Csnd] Re: Re: Haskell for computer music


> Victor.Lazzarini@nuim.ie wrote:
>
>> AFAICS Python would also support well a functional styleof
>> programming (although this appears to me to be moreof a state
>> of mind, so the language might not matter so much ;)
>
> Haskell offers much more than just a functional style of
> programming, it offers a type system and compiler than can
> find bugs at compile time that in Python would result in a
> run time error.
>
> For people using Python to compose and then render their music,
> then they can probably live with the ocassional run time error.
> For people doing live computer aided performance, the possibility
> of run time errors may be enough to make them want to explore
> languages like Haskell that provide better static guarantees
> of program correctness.
>
> Erik
> -- 
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

victor wrote:
> But is it only me or is Haskell not a hard language to read?
> Would the time gained not bothering with possible bugs not be lost
> just understanding what the heck is going on in this code?
> Monads, heh? Just spent half an hour trying to figure that one
> out.
> 

My experience learning Haskell is that it's like going back to
basics. It's like when you were learning imperative
programming for the first time---we tend to forget how much
time that took. But most programmers can read imperative
code fluently. You can get that fluency with Haskell---it's
really quite intuitive and elegant, and those cryptic-looking
programs don't require genius to read---AFTER
you've put in the time with the basics. I've been reading
and working exercises for about two months now and starting
to relax into monadic code. Haskell is a language that has
so much expressive potential you can spend years mastering
it, but I think useful production coding in idiomatic
style would take maybe six months to learn.

One tremendous advantage of Haskell is the support
community. The quality of books, tutorials, and mailing
lists is the highest I've seen. On beginners@haskell.org,
you can post a problem, and you will get two or three
PhD. computer scientists gladly answering your problem,
perhaps even with detailed code and instructional
annotation. For free. Usually with a two-day turnaround.
Good luck finding that in another language. Or you
can get instant answers for simpler questions on the
IRC channel #haskell. Chatters are available almost
around the clock. Again quality of answers is very
high.

-Mike

victor wrote:
...
> 
> A funny aside: Erik kept mentioning OCamL and I kept thinking that
> is interesting, you know the parallel language used in transputers,
> is that still around, might be useful to learn, etc,
> because I mistook it for Occam! Only now I realised what he is
> going on about. Just shows how dumb I am.
> 

Occam is still around, with a dedicated following, and now cross-platform:

http://freshmeat.net/projects/kentoccam/

The aspect of Haskell that caught my eye was the intrinsic support for 
parallelism, concurrency and multi-core generally. If/when I ever get 
hold of a suitable machine, I will give it a go. Both C and C++ are 
intrinsically serial languages inasmuch as you write one instruction 
after another. Making it suddenly support concurrency has created as 
many problems as it has solved (maybe more...); there is a natural 
appeal in a language designed from the bottom up with concurrency in 
mind. The general argument seems to go, that these languages are strange 
to the eye not only because of their functional idioms, but also because 
a language in which concurrency is innate is bound to look strange to 
anyone steeped in serialism.  So Haskell may be double jeopardy for C 
programmers.

The only real question is if it enables cool (and fast) concurrent audio 
and music designs in ways that C and C++ do not. As comes as no surprise 
to folks on this list, computer musicians  demand something close to the 
hardware, to run as fast as possible, but also as high-level as 
possible, to reflect how musicians think.

I still hold the view that music and audio are amongst the most 
formidable tests for both hardware and software (it's not rocket science 
- its harder than that), and hence deserve rather more support from the 
research funding bodies than it does. Researching the use of languages 
such as Haskell for audio (with hardware etc that will exercise it 
fully) is yet another useful project that probably will never get funded...

Richard Dobson

The Glasgow Haskell Compiler does appear to support parallel execution
of concurrent code.

Does anyone on this list have any personal experience with this feature?

Regards,
Mike

On 5/21/09, Richard Dobson  wrote:
> victor wrote:
> ...
>>
>> A funny aside: Erik kept mentioning OCamL and I kept thinking that
>> is interesting, you know the parallel language used in transputers,
>> is that still around, might be useful to learn, etc,
>> because I mistook it for Occam! Only now I realised what he is
>> going on about. Just shows how dumb I am.
>>
>
> Occam is still around, with a dedicated following, and now cross-platform:
>
> http://freshmeat.net/projects/kentoccam/
>
> The aspect of Haskell that caught my eye was the intrinsic support for
> parallelism, concurrency and multi-core generally. If/when I ever get
> hold of a suitable machine, I will give it a go. Both C and C++ are
> intrinsically serial languages inasmuch as you write one instruction
> after another. Making it suddenly support concurrency has created as
> many problems as it has solved (maybe more...); there is a natural
> appeal in a language designed from the bottom up with concurrency in
> mind. The general argument seems to go, that these languages are strange
> to the eye not only because of their functional idioms, but also because
> a language in which concurrency is innate is bound to look strange to
> anyone steeped in serialism.  So Haskell may be double jeopardy for C
> programmers.
>
> The only real question is if it enables cool (and fast) concurrent audio
> and music designs in ways that C and C++ do not. As comes as no surprise
> to folks on this list, computer musicians  demand something close to the
> hardware, to run as fast as possible, but also as high-level as
> possible, to reflect how musicians think.
>
> I still hold the view that music and audio are amongst the most
> formidable tests for both hardware and software (it's not rocket science
> - its harder than that), and hence deserve rather more support from the
> research funding bodies than it does. Researching the use of languages
> such as Haskell for audio (with hardware etc that will exercise it
> fully) is yet another useful project that probably will never get funded...
>
> Richard Dobson
>
>
>
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I further note that the current version of Haskell comes with an
interpreter that supports the parallel execution of concurrent code.
This raises the usefulness of Haskell for computer music to a much
higher level, in my opinion.

I will investigate further.

Thanks,
Mike

On 5/21/09, Michael Gogins  wrote:
> The Glasgow Haskell Compiler does appear to support parallel execution
> of concurrent code.
>
> Does anyone on this list have any personal experience with this feature?
>
> Regards,
> Mike
>
> On 5/21/09, Richard Dobson  wrote:
>> victor wrote:
>> ...
>>>
>>> A funny aside: Erik kept mentioning OCamL and I kept thinking that
>>> is interesting, you know the parallel language used in transputers,
>>> is that still around, might be useful to learn, etc,
>>> because I mistook it for Occam! Only now I realised what he is
>>> going on about. Just shows how dumb I am.
>>>
>>
>> Occam is still around, with a dedicated following, and now
>> cross-platform:
>>
>> http://freshmeat.net/projects/kentoccam/
>>
>> The aspect of Haskell that caught my eye was the intrinsic support for
>> parallelism, concurrency and multi-core generally. If/when I ever get
>> hold of a suitable machine, I will give it a go. Both C and C++ are
>> intrinsically serial languages inasmuch as you write one instruction
>> after another. Making it suddenly support concurrency has created as
>> many problems as it has solved (maybe more...); there is a natural
>> appeal in a language designed from the bottom up with concurrency in
>> mind. The general argument seems to go, that these languages are strange
>> to the eye not only because of their functional idioms, but also because
>> a language in which concurrency is innate is bound to look strange to
>> anyone steeped in serialism.  So Haskell may be double jeopardy for C
>> programmers.
>>
>> The only real question is if it enables cool (and fast) concurrent audio
>> and music designs in ways that C and C++ do not. As comes as no surprise
>> to folks on this list, computer musicians  demand something close to the
>> hardware, to run as fast as possible, but also as high-level as
>> possible, to reflect how musicians think.
>>
>> I still hold the view that music and audio are amongst the most
>> formidable tests for both hardware and software (it's not rocket science
>> - its harder than that), and hence deserve rather more support from the
>> research funding bodies than it does. Researching the use of languages
>> such as Haskell for audio (with hardware etc that will exercise it
>> fully) is yet another useful project that probably will never get
>> funded...
>>
>> Richard Dobson
>>
>>
>>
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

victor wrote:

> But is it only me or is Haskell not a hard language to read?

At first yes, but show Fortran to someone whose first language
was Java and it will look at least as foriegn as Haskell.

> Would the time gained not bothering with possible bugs not be lost
> just understanding what the heck is going on in this code?

Its definitely very different from the vast majority of other
langauges but once you get over the initial hurdle, this is
definitely not the case. I know Python better than Haskell
and rate them about the same in terms of readablity.

> Monads, heh? Just spent half an hour trying to figure that one
> out.

The best initial approach to monads is to just gloss over them
with as extra type information. This means when you have two
functions:

    fa :: String -> String

    fb :: String -> IO String

you can see that both take a string parameter and return a string,
but the second also does some I/O (maybe print the string, or look
up a database or launch missiles). However, the first function
above is pure, it has no side effects, it does no I/O.

Deferentiating between the two functions above, one pure and one
doing monadic IO allows the compiler to exploit optimisations
which are not possible in languages which don't differentiate
between them. There are also potential payoffs for multi-core
programming which Haskell is starting to reap the benefits of.

> Some people seem to have strong opinions about stuff, like
> here http://www.andromeda.com/people/ddyer/topten.html.
> My take is that most of it is non-sense, just a bit of experience
> with C will cover all those holes cited there.

This is definitely true when programming in the small but
programming in the large (large code bases, large teams, code
developed outside your group) things become much more difficult.

As an example, look at libsndfile. Its about 50k lines of C code
mostly written by me. I always compile with all the warning flags
GNU GCC will allow me, I fix every warning, I have a test suite,
I have used expensive static analysis tools and I am obsessed
with the quality of this code. However, even with all this, there
have still been two exploitable security advisories against it
this year:

   http://www.mega-nerd.com/erikd/Blog/CodeHacking/libsndfile/rel_20.html
   http://www.mega-nerd.com/erikd/Blog/CodeHacking/libsndfile/rel_19.html

Neither of those two bugs, which are potentially remotely
exploitable could have happened if libsndfile was written in
Haskell. Unfortunately if it was written in Haskell, the
performance would not be acceptable. However, with each new
Haskell compiler release performance is improving.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Michael Gogins wrote:

> The Glasgow Haskell Compiler does appear to support parallel execution
> of concurrent code.
> 
> Does anyone on this list have any personal experience with this feature?

My experience is second hand. A member of the Sydney function
programming group (FP-Syd), Manuel Chakravarty was part of the 
team that implemented the latest Nested Data Parallel (NDP) stuff
in the GHC compiler.

Manuel gave a presentation at FP-Syd late last year and at that stage
the NDP stuff was basically working but still had a few problems in
the runtime that was hindering performance. However, he seemed
confident that these problems would be overcome in the near future.

Basically its not there quite yet, but could well be there soon.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/