Haskell Live: A Live Coding Adventure | Hacker News Reader

Haskell Live: A Live Coding Adventure

haskelllive.com

131 pointsnwjsmith39 comments

I have to say, I generally dislike video coding tutorials.

First, it's difficult to google/copy-paste. Second, it just goes against the way I learn new programming languages - I generally read it, then try it, then experiment with it in some other ways, list few pages back/forth, experiment more, fail, then continue. Usually copypasting/rewriting chunks of code. "What happens when I do THAT? Oh, it fails miserably. Why? Oh, that's why."

I can easily reread some parts. I can easily skim back/forth. While with the video, I don't want to hear the person more than twice, usually. The voice becomes annoying for the third time you hear it.

I feel that videos work great for demonstrating a language. I can never actually learn any language from a video tutorial.

(If you will bring the analogy of lecture - yes, this is partly true, but good lectures should be somehow interactive. The lecturer asks students, they can ask the lecturer back.)

"I can never actually learn any language from a video tutorial."

I like video tutorials/screencasts as long as they have the following :

1. Trainer starts with a basic list of topics/table of contents. Nothing fancy but give me an overall overview of what I will learn out of this.

2. A particular topic is taught gradually i.e. by starting with a simpler or even wrong way (as in best practices) and then improving it to show the more standard way. For don't just show me the final end product.Show me how to do it in a crude/simpler way, then improve the code (may be refactor etc) or add more features. Explain each improvement while you are doing it and WHY you are doing it.This makes us learn the gotchas and pitfalls and may be even best practices.For example, I can put all the code in one file to start with but then how can/should I refactor it in some recommended way? (MVC?)

2. Show me more than 1 way of doing something if it helps me learn the concept. Again, kind of related to #1.

3. Break the code on purpose and explain what the error message means. Then fix it and re-run. For example, in learning Django/Flask, if you are missing a template, it will crash/error out. So don't create the template right away. Build the code without template and let me see how it crashes. Then add the template and re-run to show me success.

4. Unless you are teaching design specifically, save the HTML/CSS/JS tricks/enhancements for the end. Show me the core product.

I am sure there are more but these help me a lot personally. In fact, I am learning Python/Flask right now and looking to write my own tutorials on how I learnt it.

These are great points and I will do my best to incorporate them in future episodes. Thanks very much for taking the time.

Also, would love to see some explanation of basic Haskell concepts

I appreciate your opinion but I will respectfully point out that I am making these videos for the other set of people who do like video coding tutorials. You should feel free to not watch them if they do not preserve the water-dorsal relationship of your water-going vessel. :)

Congratulations, really good work. Making videos is hard, at least for me cos I'm not native, and they get easily outdated.

For a .Net guy with a little knowledge of Haskell like me, in the video you can show not only the language but the IDE and the programming experience.

> First, it's difficult to google/copy-paste

That's a feature! No seriously. Among an august audience like HN people might have more discipline to properly grok the code they're copying, but I know of plenty of places where people will just copy and paste disparate chunks of tutorial code into their editor then start randomly changing lines and variables (with a hundred questions demanded of the poor folks in some irc channel) until it sort-of-but-not-quite works. Forcing people to write it from scratch, having had the construction demonstrated, seems to aid the mental digestion of the code much better. That's just my anecdotal experience anyway.

I actually enjoy these types of videos. I think actually typing stuff off of the video, and sometimes changing it a bit, works best for me. It's even better when you watch the video once, get the gist of it, then try to rewrite the whole thing.

And it's plain faster. Having this tutorial in text will probably take you more time to read than you could have saved copy pasting.

While certainly anecdotal, I attribute 99% of my opengl knowledge to the extremely comprehensive WebGL 101 videos by emoller. The video was two hours long, but it took me about 8 to get through as I copied code, made changes I liked, and made sure it compiled at each milestone.

Of course, opengl/webgl isn't a language, and the hand-holding might be more necessary.

Finally, all of his code (each finished milestone, of which there were at least a dozen) was available on github.

For the lazy: http://www.youtube.com/watch?v=me3BviH3nZc

A good video can be a huge time saver for showing workflow, how an experienced coder uses the editor/IDE, REPL, debugger, git and testing libs/CI

This is somewhat of a nitpick, but for one thing, writing code that is as obviously correct as possible is important in every language, not just in Haskell. Compositionality is one of the most valuable things we can exploit when programming.

For another thing , the assertion that enumerating all the cases for a given function instead of using a lookup makes the code more obviously correct is somewhat flawed - it violates DRY, which is, like exploitation of compositionality, important in programming in general. Suppose the showPiece function had twice the number of cases. Would enumerating the cases individually or making the assertion that the code is more obviously correct as a result be reasonable?

In my view, you are solving the same problem whether you use a lookup or enumerate the cases individually, and it's not even a very big problem - just put your tokens in the right order.

This is awesome. Nice and approachable - well explained. I'd love if you also threw in some vim commands along the way.

I'd like to respectfully offer another opinion: I would NOT love if it some vim commands were thrown in. By all means, devote a single episode to tools, since the set up demonstrated might be complex to recreate, and it would likely be something a lot of people want to use too. But I don't think tips specific to a single editor have any place in screencasts that are about one programming language in general.

An unobtrusive way to introduce editor tips that just came to mind would be to add subtitles with selected key-combos that might be nontrivial or not obvious. More than that would be a distraction, I think. Also, I don't know if YouTube supports multiple subtitle tracks... so that might be a big fu to deaf or hearing impaired programmers who want to follow along.

I'm going to have to side with spacemanaki here.

My biggest focus in using vim was to get it out of the way so that I could focus on the Haskell. I wanted the environment (editor, compiler, window manager, test runner, etc) to be as transparent as possible. This is not, in point of fact, a series of vim tutorial videos.

I will make a video that explains my dev environment as a supplement, however.

I'd be happy to answer any vim questions in the comments (github issues, which I will hopefully figure out how to embed in the site eventually), and I do like the idea of adding call out boxes (no need to use subtitles, they can go on the video itself) to highlight interesting vim trickery.

Great suggestion, that's on par with what I had in mind. I was not implying OP should have a 3-minute segment on vim commands. Maybe just casually say "and I'm going to use :tab which allows me to select multiple lines and line up the equal signs" or something similar.

> Maybe just casually say "and I'm going to use :tab which allows me to select multiple lines and line up the equal signs" or something similar.

No, I wouldn't want them to casually say anything... that's why the subtitles would be an unobtrusive compromise, since you can just turn them off. I think this would be even more important if the screencast was targeted at new users of the language or framework or whatever, since the viewer might be confused and wonder if ":tab" was something to do with the syntax of the language.

I want subtitles to perform their primary accessibility function. How about YouTube annotations?

I had forgotten about annotations, those might be ideally suited for editor and env tips. Honestly, I use Emacs, so I'm not that interested in the vim tips, I just didn't want these to turn into a series of Haskell-with-Vim casts. :) even thought your env does looks pretty slick.

Really nice video, looking forward to more!

Yep exactly. I want to keep the videos per se as env-agnostic as possible to not get in the way of the Haskell.

Seconded. Devote a short episode to tools, but don't mix the tools and programming too much.

Yes I wouldn't like it either because I don't use vim.

Very cool. I don't have many Haskell coders where I spend my time, so it is nice to watch how someone with more experience tackles fairly basic programming tasks. The guard window and quickcheck in particular were eye-opening.

Thank you all so much for your feedback. And thanks to the OP for posting this. I can't make everyone happy all the time but I'll do my best to make each episode better than the last.

<3 HN

Don't change too much, it's already a splendid format!

Good workflow, nice simple start with chess types and the serialization/deserialization thereof. Enjoyable watch.

I also really enjoyed the pacing and voice. I'm looking forward to the next episodes.

Good screencast, there's a mistake regarding the piece colouring though. They're all black because all the characters are lowercase (and I think you meant to make the bottom row uppercase).

It can be verified in the code, and in the REPL when it's being tested.

For all those interested in emacs haskell mode this http://www.youtube.com/watch?v=E6xIjl06Lr4 is about the best screencast I've seen covering the new stuff the Chris Done wrote. I'm using emacs prelude and it's a great environment right out of the box!

What is the editor / configuration used in the video ?

Looks like tmux + vim, using the Solarized Dark theme.

I gathered the vim part. Is he pressing a separate key to run the stuff in the lower-right window or is there a vim hook to do that automatically?

For that I think he's using Guard (https://github.com/guard/guard/)

I'll make a video on my setup, but:

Left: vim with Vim Haskell Mode[1], a pale imitation of emacs haskell minor mode that nevertheless gets the job done. ;)

Top right: GHCi

Bottom right: Guard, as mentioned, using guard-shell[2] to compile the file and run main using runghci.

[1] https://github.com/lukerandall/haskellmode-vim [2] https://github.com/guard/guard-shell

Maybe that info should be on the page itself somewhere. I wouldn't know to look at the github to find your guard script: https://github.com/haskelllive/haskelllive/blob/master/Guard...

Good call. I'll add that to the About. I'm going to do a quick supplemental vide on the setup as well between now and next episode.

This looks interesting. I somehow really like Haskell, although I never got around to dive into it. It's one of those languages that I want to learn one day but never have time to. So, watching those videos is kind of showing me how things are done the Haskell way, which is kind of strange for somebody like me who's entirely used to C89 ;)

This is really cool. I wish I had more free time, but I will be using what little I have for this (and learning vim as I go).

Good job!!! I'm looking forward to the next episodes.

Awesome! This is exactly the kind of learning experience that would be useful to someone who has been studying Haskell intensely for a week.

Reply on news.ycombinator.com