I do both UI (desktop, not web) and internal guts.

The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).

In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.

In the non-UI domain, I took a lesson from a number of products that started out as DSLs usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.

One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.

So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.

I do both UI (desktop, not web) and internal guts.

The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).

In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.

In the non-UI domain, I took a lesson from a number of products that started out as DSLs usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.

One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.

So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.

I do both UI (desktop, not web) and internal guts.

The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).

In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.

In the non-UI domain, I took a lesson from a number of products that started out as languages usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.

One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.

So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.

I do both UI (desktop, not web) and internal guts.

The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).

In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.

In the non-UI domain, I took a lesson from a number of products that started out as DSLs usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.

One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.

So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.