
Haskell Live: A Live Coding Adventure - nwjsmith
http://haskelllive.com
======
runn1ng
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.)

~~~
codegeek
"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.

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

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

------
ek
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.

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

~~~
spacemanaki
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.

~~~
prezjordan
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.

~~~
spacemanaki
> 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.

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

~~~
spacemanaki
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!

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

------
Oxryly
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.

------
ReinH
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

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

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

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

------
FuzzyDunlop
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.

------
boothead
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!

------
veyron
What is the editor / configuration used in the video ?

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

~~~
veyron
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?

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

~~~
ReinH
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>

~~~
veyron
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...](https://github.com/haskelllive/haskelllive/blob/master/Guardfile)

~~~
ReinH
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.

------
tsahyt
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 ;)

------
mattvanhorn
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).

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

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

