HN Theater @HNTheaterMonth

> Assuming f and g are not evaluated for their side-effects...

And that is the whole point. In Haskell we can know that f and g have no side effects. If they had side effects you would not be able to compose them with the dot operator.

I don't quite understand your example but I assure you that there are elegant ways to accomplish that in Haskell. There was recently a presentation [1] at the NY Haskell meetup that talked about a new Haskell sound synthesis library called vivid.

Making functions that perform side effects is also easy. Here's a simple example:

    intToFile :: Int -> IO ()
    intToFile anInt = do
        writeFile "myfile.txt" (show anInt)

The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone.

[1] https://www.youtube.com/watch?v=xo3zUvPsizo

⬐ guipsp

>The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone.

Haskell is also not used any major project. It's an academia language.

⬐ tormeh

I think that has more to do with syntax and the overdependence on rote memorization that it requires, and less to do with the actual concepts themselves. Lots of things are silly in Haskell-land, but that's mostly because it's made to be elegant or math-like, if I've understood it correctly.

That said, multiparadigmatic programming is awesome, we just have to find some way to give as much information to the compiler in imperative instructions as we do in functional. This means that imperative programming has to be tightened up quite a bit, but I don't think it would be very drastic, really.

⬐ e12e

I don't think it's quite right to say it's (still) just an academia language -- but it's absolutely marginal. I use two (three) programs implemented in haskell on a (semi)regular basis: xmonad (and xmobar) and pandoc.

Other than that, I know of git-annex that is both actual programs and is in actual use.

That's still more than the number of programs I use that are implemented in Arc...

Haskell is academic in the sense that it is very opinionated about a few things (as this sub-thread illustrates).

Lets see how Shen, Open Dylan and clojure end up doing ... (and of those, probably only clojure have meaningful contemporary systems implemented in it - so far). Maybe there's even more life left in Common Lisp (sbcl etc) or Scheme (Racket, guile w/guix nix (haskell! yay!) ...).

Then there's OCaml of course...

⬐ e12e

> The idea that you have to be multiparadigm to function in real world settings is a fallacy.

I'm not so sure. The best solution for a subset of programmers is unlikely to be the best solution for every programmer. Somewhat like the quote about literate programming:

"Jon Bentley probably hit the nail on the head when he once was asked why literate programming hasn’t taken the whole world by storm. He observed that a small percentage of the world’s population is good at programming, and a small percentage is good at writing; apparently I am asking everybody to be in both subsets." -- According to Donald Knuth http://www.informit.com/articles/article.aspx?p=1193856

While I think there is much more overlap between good programmers that write good Forth, those that write good Ada (or other procedural code), those that write good functional programs, those that bask in the glory of Smalltalk/Self (classic oo) and those that get by in java ("modern"/class-oriented oo) -- than between good technical writers and good programmers -- I think the problem is partly the same.

There's no guarantee that haskell is the best tool for a 10 year old write interactive fiction, or automate his or her schedule -- and for a finance manager to manage numbers and for an engineer to write code for a robot -- or for high frequency trading... or etc.

Machines don't understand Haskell anyway, only humans do. If many of us find Visual Basic or Excel or SQL easier... we probably have a need for such languages (even if I don't want to touch Visual Basic with a stick...).

Multiple programming paradigms has nothing to do with computers and systems, and everything to do with human-machine interface and augmenting the capabilities of humans through computers.

⬐ jlrubin

This is awesome work -- Tidal also has a bleeding edge interface to supercollider, worth checking out. https://github.com/tidalcycles/Tidal/blob/master/examples/su...

⬐ mmarx

It's a pity that there is so much background noise on the audio, it really makes this hard to watch, especially on headphones.

Vivid is an interface SuperCollider, apparently built with livecoding in mind. The talk itself is mostly examples and provides little detail on how the system works behind the scenes.

⬐ tessierashpool

fwiw, Clojure's Overtone is also an interface to SuperCollider.

pretty awesome, because I recall vaguely when SuperCollider first began, and I don't think anybody said "this will be the common platform for live-coding libraries in functional languages in the future" at the time.

⬐ subnaught

There's also a Scala client: http://www.sciss.de/scalaCollider/

And if you go back to McCartney's original paper (http://www.audiosynth.com/icmc96paper.html), you can see that functional ideas have been in there from the beginning:

"The idea behind SuperCollider was to provide audio synthesis in a high level language with dynamic typing, lists, garbage collection and closures. Normally a language of this type is too slow to do signal processing. By creating a signal data type which represents a buffer of samples over a short time frame, and defining operators for that data type, it is possible to amortize the cost of the interpreter over many samples."

⬐ pierrec

"Normally a language of this type is too slow to do signal processing."

That is one of the founding principles of many current sound synthesis programming tools. In light of the recent developments in JIT-enhanced languages (I'm thinking of LuaJIT), it should now be possibles to work with less layers and more freedom, directly with the samples, in a high level language.

And now comes the plug: This is exactly what protoplug allows you to do, and as a VST plugin it works inside modern music-making software:

http://www.osar.fr/protoplug/

Obviously the design goals are very different from something like Vivid, and it doesn't have the SuperCollider features to back it up.

⬐ eggy

How does this compare to Euterpea [1] another Haskell-based music development DSL that can do real-time? It is Haskore and HasSound based, not Supercollider. I couldn't make the comparison after watching most of the video for Vivid.

[1] http://haskell.cs.yale.edu/euterpea/

⬐ vivid-synth

(I'm the author of Vivid) Euterpea has a high-level music language and FRP framework that Vivid doesn't (yet). On the other hand, from conversations with a developer of Euterpea, Vivid is probably far more performant for real-time. Because of its performance and design goals, Vivid is also much more suited to live performance (in my opinion).

You could say Euterpea is like writing a classical score to Vivid's rock band.

They aren't at all incompatible though, and I'd be excited to see Euterpea <-> Vivid interop.

⬐ eggy

Cool, I will give Vivid a shot since my goal is more livecoding than composing. Any chance of integrating graphics like Overtone has with Shadertone or Quil, or like Exetempore's builtin fuctions? Good work.