
Making a GTK Video Player with Haskell - lettier
https://lettier.github.io/posts/2017-08-30-haskell-gtk-video-player.html
======
anon335dtzbvc
Very nice project keep going, would love to see more haskell projects arising
from this. Code related: I'm by no means an haskell expert, but your main
function in Main.hs looks a bit lengthy, usually i dont see haskell methods
with 50+ lines, might be better to split them up and provide names for
subfunctions.

~~~
pavlov
The main function would read pretty much the same in any language. Slicing it
into multiple functions doesn't really do anything that couldn't be achieved
by adding a few comments.

I guess Haskell just doesn't do much to solve the problem of setting up GUIs,
at least when it has to interface with a framework like Gtk+.

~~~
aloisdg
If you have good function names, you do not need comment.

~~~
pavlov
If your imperative code is readable and well-commented, why break it up into
single-use functions?

~~~
mikekchar
To expose state. I haven't actually read the code, but since you asked a
really good question, I thought I would answer it generically :-)

Extract method is probably one of the most abused refactoring patterns around.
As you correctly point out, there is no benefit for extracting single use
functions _and then leaving the code like that_. It's just trading one set of
notation (function names) for another (comments), while at the same time
allowing you to confusingly arrange the code out of execution order.

You want to extract functions in order to reason about execution. You do this
by exposing state in the form of the return values from the functions you have
created. Whether you write unit tests, or (in a language like Haskell) use it
to enforce type contracts, the point is that you have a tool for detecting
when the inputs and outputs aren't matching up. This allows you to much more
quickly zero in on defects.

There are a couple of caveats with this. First, some people read code linearly
no matter what they are doing. Especially programmers without much experience
often play computer (with or without a debugger) instead of reasoning using
larger abstractions. Quite frequently the benefit of factoring code is lost
because of this. It's important to understand the techniques that your team
uses before you stick the code in the proverbial food processor.

Secondly, the main benefit of this kind of access is when you are
restructuring code. The idea is that (to paraphrase Micheal Feathers) you put
some of the code in a kind of vice, while you move the other code around. By
exposing state, you can detect when the code you put in the vice starts to
slip around. Many, many, many teams do little or no refactoring/restructuring
of code. Some teams even have rules for limiting edits, because they feel that
this will reduce breakage. On such teams, the effort of exposing state will be
worthless.

------
CyberDildonics
Is there any fully formed application made with Haskell out there?

~~~
progman
The examples mentioned in the other posts confirm my impression that Haskell
is a good language for text processing and server applications but a pain for
writing rich desktop applications.

One of the things I miss in Haskell is a way to compile to C, and a convenient
declarative GUI which also compiles to C so that all code can be linked
together, and distributed as a single binary. The GUI doesn't need to be
native. Lisp has its own GUI (McCLIM), Smalltalk has one (Squeak), Rust has
one (Conrod), why not Haskell?

~~~
orbifold
I think pretty much any Language is a pain to write GUIs in, a single property
dialogue in photoshop is ~6k loc in C++...

~~~
progman
Pascal (Delphi, Lazarus) and Visual Basic are exact counter examples. They
demonstrate how easy and convenient GUI development can be.

~~~
tentaTherapist
I really hope I'm wrong, but if you're talking about VB.NET, then my personal
experience with it has been the exact opposite of easy and convenient.

Edit: Okay, good, VB.NET is probably not the Visual Basic you were talking
about. Thanks for the history lesson!

------
d--b
I was hoping this would include an efficient H 265 decoder written in Haskell.
That would have been neat.

~~~
izacus
That's not really a one month project... and most platforms will rely on
hardware decoding anyway.

------
auvrw
here are some related programs

[https://wiki.haskell.org/Manatee](https://wiki.haskell.org/Manatee)

