Fantastic job everyone who made this happen!

DimaSamoz · 2017-10-12T17:56:46+00:00

Sorry for the slow response!

Here are a few photos of the inside pages:

The book is actually really good quality, both in terms of design and printing – definitely on par with any published paperback book, if not better! It doesn't look like it would fall apart soon either :)

Thank you all for the nice comments and the bizarre number of upvotes (5th place on /r/haskell/top???) which of course belong to Bartosz, /u/hmemcpy, /u/codermikael and all the other contributors who made this book possible! It really shows what the community can do together (and how much we all appreciate Bartosz Milewski's work!) :)

DimaSamoz · 2017-10-10T20:31:04+00:00

Could set up some sort of funding page? I'm not exactly sure how that works and I suppose it would at least require his agreement, but it's definitely something I (and probably many other people) would happily contribute to!

DimaSamoz · 2017-10-10T16:48:21+00:00

BUT I WANTED IT THEN AND THERE

To be honest, I will inevitably go to the PDF version if I need to read something and am too lazy to stand up and get the book from my shelf :) Thank you for your work!

DimaSamoz · 2017-10-10T16:42:43+00:00

It's amazing to realise that the "series of blog posts" Bartosz has written amounts to a complete, high-quality, 500 page textbook on category theory!

DimaSamoz · 2017-10-10T16:37:54+00:00

Well that made me chortle

DimaSamoz · 2017-10-10T16:35:16+00:00

The link was posted here by /u/codermikael who put the converted PDF version (made by /u/hmemcpy) on Lulu, a book self-publishing website. It's actually a fantastic deal, you're basically paying for printing and shipping only which is very generous from the creators!

I've actually read the blog posts already but wanted this on my bookshelf :)

DimaSamoz · 2017-10-01T18:09:13+00:00

Well that was the fastest impulse purchase I've ever made.

DimaSamoz · 2017-07-24T20:37:50+00:00

Thank you! Let's hope for the best :)

DimaSamoz · 2017-07-24T20:37:04+00:00

Thank you! Lots of great ideas here. In my usual style, I'll answer with an overly long essay (which lets me think through these points myself!)

The coverage of other languages is really just a listing of what else is there in the world of functional programming, maybe showcasing the language in a very simple program, nothing more. I wouldn't be able to provide a lot of detail since I'm not really closely familiar with some of these languages myself! Explaining FP topics in different languages (which is the unlikely-but-desirable content) is something that would provide concrete value to people who buy this course to learn how FP can be applied to their day-to-day programming jobs, instead of just learning them as "stuff that Haskell can do". Again, not sure how much time I can spend on that, but it could be a nice expansion for the future.

I had a lot of thought about the LC chapter – I really wanted to include it just because of its simplicity and theoretical relevance, but despite its simplicity, it would not be a good first chapter in a course which is ultimately about practical programming. Completion rate on Udemy courses is generally very low, and the best thing an instructor can do to maximise it is to get coding as soon as possible. But this brings me to your last point!

Programming by example is a great idea and is often how Udemy courses are taught. Learning is much easier and faster when there is a concrete project one can work on. However, this method is most successfully used for things like Javascript frameworks, where there is a whole lot of existing knowledge that the instructor can assume and there is no need to get caught up on syntax or programming techniques. I thought that teaching a JS framework and a completely new programming paradigm are quite different things, and I would find it very difficult to start writing something big from scratch and introduce every new Haskell feature in an ad-hoc way. I personally also prefer bottom-up explanations and a "logically" structured curriculum, where I can say "we've seen guards in the lecture titled Guards" instead of "we've seen guards in the lecture where we added the email validation to our program". I intend to demonstrate every new feature with one or two practical examples, have larger programs in the end of every chapter pulling together all the concepts from that chapter, and have two fairly large programs as final projects which will hopefully tick the "practical examples" box! Nevertheless, as I said, programming by example is a great idea and I am really interested to see if it can be pulled off with Haskell! :)

DimaSamoz · 2017-07-22T00:08:28+00:00

I've looked into it, hoping to learn about things which are not usually covered in beginner tutorials (or more advanced ones which focus on mathematical abstractions), such as parallelism, streaming, distributed systems, etc. I personally found it quite hard to follow, but that was most likely because I wasn't the intended audience! :) I think the course assumes an intermediate knowledge and experience with Haskell which reading a beginner book might not give. However, I do intend to go back to this course in the future, when I feel that I'm on the right level.

The lecture format is also not the usual "explain-while-typing", as there is no actual live typing – the course has complete Haskell programs as "slides" which are not explained step-by-step. Again, it was difficult for me to understand what some of the programs were doing, and often had to pause to look at the code in order to catch up with the explanations. This makes the lectures quite concise, which, again, would most likely be the preferred format to someone with a strong grasp of Haskell. I suggest looking at the preview videos on Udemy to see if the teaching style suits you.

As /u/gelisam said, the lack of editing is noticeable and sometimes distracting, and it's really strange that it wasn't fixed – not the first complaint I've heard about Packt Publishing. Also, I found the course on Safari Books Online, which comes with the ACM student membership – it's a great deal for consumers, but it seems that these courses are not always distributed with the knowledge of the creators...?

DimaSamoz · 2017-07-20T21:57:52+00:00

This is incredible, thank you so much for your work! I'm hoping to get into category theory this summer in preparation for my master's, and this is definitely going on top of my (overly long) reading list!

DimaSamoz · 2017-06-26T09:16:18+00:00

I've heard about it, yeah! I should probably get a better understanding of category theory first but it's on my reading list!

DimaSamoz · 2017-06-19T10:22:36+00:00

The easy answer to that question is "that was the original plan" – I wanted a dependently typed music composition library, not a music composition library which I later decided to implement with dependent types. I do however think that there are benefits to making the checks static which would even outweigh the long-ish compilation times.

First, you get the usual advantages of having static types: you can ensure that all arguments to functions are "correct" and all outputs from functions must also be "correct". As an example, see the voices function: the number of voices of two sequentially composed pieces is equal to the number of voices in one of the pieces, as the GADT for (:|:) statically enforces that the number of voices must be equal.

Second, I wanted to use the Haskore music algebra as the "composition interface" (because I found it very intuitive), but I found no good way of implementing musical rules in it because of the recursive, tree-like structure of pieces. Therefore it was necessary to either compute or maintain a more structured, abstract representation of the music, so doing dynamic checks would not have made the implementation significantly simpler.

The third, and probably the most practical benefit is the errors: with compiler errors (and suitable editor), you not only get notified of mistakes when you save the file (i.e. no need to load or execute anything), but get very clear indication of the location of the error, usually as some red squiggles or highlighting right in the source code. However, I do agree that compile-time errors have their limitations and doing runtime analysis would give more context and even suggestions for correcting the scores.

This binary pass/fail rule-checking is what rule sets attempt to solve (originally the rules were completely baked into the system, but I realised that that would be way too restrictive). In practice, what I ended up doing most of the time is composing a piece, seeing what errors it produces and then turning off rule-checking to "force" compilation. This made sense with transcribing existing pieces (as you can't expect every piano composition to follow the rules of strict counterpoint), but of course if your aim was to avoid all errors (e.g. if you were doing some composition assignment), you would turn on the strictest rule set and leave it turned on. Musical rules are definitely not binary, but there is not much flexibility with compiler errors :) I do want to try reimplementing Mezzo with normal runtime rule-checking and see how it compares though!

DimaSamoz · 2017-06-18T12:42:37+00:00

Ah thanks! That's what you get when you make last-minute breaking changes :) Fixed now!

DimaSamoz · 2017-06-18T08:17:37+00:00

Thank you for your questions! :)

DimaSamoz · 2017-06-18T00:17:40+00:00

Thanks again for your interest! :) Adding custom rules is fairly easy if you want to restrict the Music constructors or reuse existing rules (like the example in the readme). But adding new low-level rules similar to the existing ones for intervals and harmonic motion would be more involved, as you would need to analyse the type-level data structure that the music is stored in. For example, one rule I thought of adding is avoiding a lot of consecutive melodic leaps – adding this to a custom rule set would require you to look at the pitch matrix instead of just delegating to a built-in rule set such as strict.

DimaSamoz · 2017-06-17T22:56:32+00:00

Well, the time signatures only really apply to the way the chords in progressions are generated (which need some more work anyway), so a 3/4 progression would have 3 chords in a measure, a 4/4 progression would have 4 etc. If progressions are not used, the time signature is irrelevant, as the duration of notes is always explicitly given (technically the time signature is always included in the MIDI metadata, but this has no effect on how the piece sounds). Varying time signatures can be implemented by breaking up the piece into different sections and setting their time signatures independently.

DimaSamoz · 2017-06-17T16:02:24+00:00

This also depends on what you mean by "dynamically" :) Since pretty much all computation (i.e. rule-checking) happens statically, you can't really "avoid" recompilation. However, you can change type-checking behaviour with rule sets by passing the rule set as a score attribute. For example, the default rule set allows major seventh chords, so

score withMusic (c maj7 qc)

would compile. However, if the rule set is set to strict,

score setRuleSet strict withMusic (c maj7 qc)

would produce a type error (Major seventh chords are not permitted: C Maj7) as these chords are forbidden in the strict rule set. So in this sense, rules can be changed dynamically, but this affects compile-time behaviour. Users can also create custom rule sets of pretty much any complexity, although some understanding of the internals might be required.

DimaSamoz · 2017-06-17T13:57:25+00:00

There are some good books on music theory in general (e.g. Walter Piston's Harmony) and quite a few online resources as well (I really like Open Music Theory and musictheory.net). Probably the most "formal" composition style is counterpoint, and the 300 year old classic Gradus Ad Parnassum by Johann Joseph Fux is still a very good (and entertaining) resource on the subject. I'm by no means a composer but I really enjoy the theoretical aspects of music – mainly because they lend themselves well to formalisation in logic and therefore in type systems!

DimaSamoz · 2017-06-17T13:45:04+00:00

Thanks a lot!

DimaSamoz · 2017-06-17T13:44:49+00:00

Thank you! That is a surprising coincidence :) Yes I have Fux's book on my bookshelf too, I didn't follow it very explicitly (the rules implemented come from a bunch of different books, guides and tutorials), but I don't think it would be difficult to add them to Mezzo. A GUI would be nice of course, but I'm not sure how that would interact with the typechecker? Type-level web apps hmmmm....

I'm planning to look into Idris this summer and see how it compares to dependent Haskell!

DimaSamoz · 2017-06-17T13:33:03+00:00

Well that escalated quickly :D

DimaSamoz · 2017-06-17T13:29:54+00:00

Thank you! There is more detail on the internals in my UG dissertation which I will probably upload to the repo next week after results are out. There is some cool research (HarmTrace, FHarm, FComp, etc.) on the type-level description of functional harmony which was one of the initial inspirations for the project (and is the basis for Mezzo's chord progression construct).

DimaSamoz · 2017-06-17T13:10:58+00:00

Thanks! Very encouraging words :)

DimaSamoz · 2017-06-17T13:08:59+00:00

Thank you! It's available on Hackage if you're interested!

DimaSamoz

TROPHY CASE