On Thu, Dec 10, 2020 at 04:23:42PM +0500, Ignat Insarov wrote:
* User experience is an afterthought.
I don't think that's fair. Making/keeping the simple things easy, without making the complex things impossible is always a challenge. Yes, starting a hello-world project should admittedly be one command with fewer required options. Presently, it is: $ mkdir hello $ cd hello $ cabal init --cabal-version=2.4 --license=NONE -p helloworld but this is not the primary barrier to Cabal's usability. Like many a tool that has evolved over decades, and supports backwards compatible historical practices, Cabal exposes more complexity and rough edges than much more recent toolchains that don't share than burden. Give me Cabal over Debian packages any day...
Cabal's user experience is horrifying.
It is likely that use of strident terms like "horrifying" does not further the kind of community building that this message aims to achieve. :-( Indeed cabal was fairly intimidating when I started out, and for a long time I used stack. More recently I've switched to cabal, as a more flexible power tool. And yet some workflows, e.g. involving internal libraries, custom builds, code generation, doctest integration, ... remain challenging to figure out. On the whole, I've seen much progress over the last few years.
It is ordinary to receive output like this:
cabal: Could not resolve dependencies:
I would posit that this is the main obstacle facing most users, and is largely not Cabal's fault. Rather it is a key property of the Hackage ecosystem that libraries can and do make incompatible changes across major version bumps, and that when one chooses a sufficiently new GHC or elects a sufficiently new feature of some library, the rest of the ecosystem may not yet be manifestly compatible with that choice. Stack side-steps the problem by freezing the compiler, base and most dependencies. This is often convenient, but is not always what you want. I don't see a high likelihood of a second community effort that produces LTS-style snapshots for cabal, nor that the Cabal and stack teams goals will align sufficiently to make the snapshot definitions a shared resource. Perhaps I'm too cynical, but I think that's the realistic assessment.
### My proposition, in particular.
* Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle.
This post seems unlikely to lead to that outcome... It has probably already started off on the wrong foot, by being more strident than constructive. It all probability reuniting development efforts that have parted ways is not possible. All that can happen is that some, but ideally not all will wither away. Nobody has succeeded in reuniting NetBSD, OpenBSD and FreeBSD. Not to mention the many Linux distributions, screen vs. tmux, GCC vs. LLVM, KDE vs. Gnome, ... More realistically, contributors to Cabal willing to devote time and energy to improving it will add the features that they care about most. Perhaps now and then someone will step up to *fund* development of some crucial feature that no volunteer is likely to build on their own accord. It all largely boils down to resources, and the fact that volunteers will work on what most interests them, and there's no benevolent dictator able to set a global agenda. -- Viktor.