[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+.

[aseipp]

The GTK bindings it uses are pretty low level overall -- e.g. dealing with ManagedPtr's and whatnot. You could probably make it nicer and easier to read, at least, if you spent some time wrapping a few of those UI bindings with a couple data types and helpers, made it a little nicer, etc.

Overall there's going to be some unavoidable "setup gunk" though. You could make some of the code nicer, but the application is pretty small. For such a small little thing, I think abstracting away any further might end up in too much fluff, anyway.

[everheardofc]

The main function is 111 lines long but only roughly 30 lines of that are setup up code. The remaining 81 lines are the business logic that happens when a control has been interacted with.

Since when does initialising the GUI framework include all of your business logic and if it does should a non trivial application have a main function that is several thousands of lines long?

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

[flukus]

So that developers can hold the entire state of the function in their head.

It doesn't seem to be the case here as it's mostly setting up callback methods according to my limited understanding of haskell.

[stuaxo]

Comments about why you are doing things and the wider context can still be useful.