Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Imprisoned by the Haskell Toolchain

jackkelly.name

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Imprisoned by the Haskell Toolchain

#11

Post by rsanders »

carterschonwald wrote: post #3
chimeracoder wrote: post #2

> The ultimate problem is that people insist on rolling their own sucky versions of build systems and package managers. (Though cabal and ghc --make suck less than most, I'll admit). Cabal is probably the #1 thing keeping me from writing more Haskell code. I've had so many issues with conflicting versions of various libraries being required, and incredibly cryptic error messages upon failure. Which is sad, because Ha…

Please give concrete examples of the problems you've had. Likewise, when you have concrete problems, have you asked for help on #haskell irc or the Haskell-Cafe mailing list? The community members on both those channels are super helpful and can probably help you quickly resolve / debug your problems. People: hand wavy complaints that do not give concrete examples are hard to fix. Please communicate concrete instance…

While that's all obviously true, I don't think getting his problem fixed was the intent of his comment. You're attacking the messenger of what appears to be a very common message.

Re: Imprisoned by the Haskell Toolchain

#12

Post by ezyang »

Yeah, this happened to me when I was integrating Ur/Web and Haskell; Ur/Web generated C and wanted to handle linking, but to link against Haskell libraries I needed GHC to do everything. There's a happy ending to the story, though: we patched Ur/Web to use ghc instead of gcc to do compilation, and everything worked out great. :-)

Re: Imprisoned by the Haskell Toolchain

#13

Post by carterschonwald »

rsanders wrote: post #11
carterschonwald wrote: post #3

Earlier quoted context omitted.

Please give concrete examples of the problems you've had. Likewise, when you have concrete problems, have you asked for help on #haskell irc or the Haskell-Cafe mailing list? The community members on both those channels are super helpful and can probably help you quickly resolve / debug your problems. People: hand wavy complaints that do not give concrete examples are hard to fix. Please communicate concrete instance…

While that's all obviously true, I don't think getting his problem fixed was the intent of his comment. You're attacking the messenger of what appears to be a very common message.

I was not attacking anyone. I just asked for concrete examples.

Is there ever a negative connotation to asking for concrete examples? (I'd actually like a concrete example if there is one)

Re: Imprisoned by the Haskell Toolchain

#14

Post by jacalata »

carterschonwald wrote: post #13
rsanders wrote: post #11

Earlier quoted context omitted.

While that's all obviously true, I don't think getting his problem fixed was the intent of his comment. You're attacking the messenger of what appears to be a very common message.

I was not attacking anyone. I just asked for concrete examples. Is there ever a negative connotation to asking for concrete examples? (I'd actually like a concrete example if there is one)

It can be easy to ask in a way that implies you do not believe there are any.

A: "I looked up everywhere I could before coming to ask for help" B: "You looked it up everywhere? Ok then, give me the name of at least one place you looked it up at."

Re: Imprisoned by the Haskell Toolchain

#15

Post by exDM69 »

chimeracoder wrote: post #2

> The ultimate problem is that people insist on rolling their own sucky versions of build systems and package managers. (Though cabal and ghc --make suck less than most, I'll admit). Cabal is probably the #1 thing keeping me from writing more Haskell code. I've had so many issues with conflicting versions of various libraries being required, and incredibly cryptic error messages upon failure. Which is sad, because Ha…

> Cabal is probably the #1 thing keeping me from writing more Haskell code. I've had so many issues with conflicting versions of various libraries being required, and incredibly cryptic error messages upon failure.

Cabal has recently been causing problems because the fast pace of Haskell lib development and some big changes in the language and certain core libraries has been causing lots of incompatibility problems.

cabal-dev is a new tool, based on cabal, that will use a per-project virtual environment and should "fix" all the version incompatibility issues there have been. cabal-dev is similar to python's virtualenv, ruby's rvm and other similar tools.

Re: Imprisoned by the Haskell Toolchain

#16

Post by stevekemp »

carterschonwald wrote: post #3
chimeracoder wrote: post #2

> The ultimate problem is that people insist on rolling their own sucky versions of build systems and package managers. (Though cabal and ghc --make suck less than most, I'll admit). Cabal is probably the #1 thing keeping me from writing more Haskell code. I've had so many issues with conflicting versions of various libraries being required, and incredibly cryptic error messages upon failure. Which is sad, because Ha…

Please give concrete examples of the problems you've had. Likewise, when you have concrete problems, have you asked for help on #haskell irc or the Haskell-Cafe mailing list? The community members on both those channels are super helpful and can probably help you quickly resolve / debug your problems. People: hand wavy complaints that do not give concrete examples are hard to fix. Please communicate concrete instance…

I'm not a haskell user, but I did recently try to install a haskell project on my Debian Squeeze host:

  $ sudo apt-get install ghc6 cabal-install
  $ sudo cabal update
  $ sudo cabal install hakyll
That failed with an error of the form "installing XX version YY requires FOO version BAR". That gave me zero help in completing the installation, and so I gave up.

FWIW: https://github.com/skx/static-site-generators

Re: Imprisoned by the Haskell Toolchain

#17

Post by lmm »

The reason people do this is the C toolchain is terrible, especially on linux. Want to depend on a specific version of a library? Whoops, no, you can't do that. Want to extend make? Well, you either do it in make or in shell, neither of which are nice languages. Want to compile and link your code once? Good luck fighting libtool. Want a package with dependencies? You'll have to choose whether to work on debian or on not-debian. And actually the debian maintainers are going to move all your files around anyway, because the FHS committee certainly knew better than you where your program's files should go.

It's bad enough I start to wish everyone would just use the JVM, where you have maven. Truly reproducible builds, depend on whatever range of library versions you work with (and it's no problem if two programs want to use different versions), a structured and testable plugin system for extending the build system, and you can use it to build any language (there are some benighted fools who write their own tools like SBT, but they will at least stay compatible so can usually be safely ignored).

Re: Imprisoned by the Haskell Toolchain

#18

Post by anonymous »

klodolph wrote: post #8

Given how much I've had to fight with Automake and Libtool to get really simple things done, they're hardly the things you want to hold up as shining beacons. 1. Do you want to compile certain source files with different build flags? Hah, no! Automake only supports it through obscene hacks, and those break if you're using Libtool. 2. Do you want to make a plugin? Best way is to ditch Libtool completely, make an execu…

Basically, these days I recommend cmake as the sane build system that runs everywhere. I don't know about PCs running MacOS, but it works just fine under Linux or Windows and you can do whatever magic you want; it makes simple things easy and complex ones possible.

Re: Imprisoned by the Haskell Toolchain

#19

Post by mercurial »

stevekemp wrote: post #16
carterschonwald wrote: post #3

Earlier quoted context omitted.

Please give concrete examples of the problems you've had. Likewise, when you have concrete problems, have you asked for help on #haskell irc or the Haskell-Cafe mailing list? The community members on both those channels are super helpful and can probably help you quickly resolve / debug your problems. People: hand wavy complaints that do not give concrete examples are hard to fix. Please communicate concrete instance…

I'm not a haskell user, but I did recently try to install a haskell project on my Debian Squeeze host: $ sudo apt-get install ghc6 cabal-install $ sudo cabal update $ sudo cabal install hakyll That failed with an error of the form "installing XX version YY requires FOO version BAR". That gave me zero help in completing the installation, and so I gave up. FWIW: https://github.com/skx/static-site-generators

Don't sudo cabal install whatever. Actually, avoid cabal install without sudo too, unless you're working with software using dynamic recompilation like xmonad. Use cabal-dev instead, this will save you a world of pain.

Re: Imprisoned by the Haskell Toolchain

#20

Post by klodolph »

anonymous wrote: post #18
klodolph wrote: post #8

Given how much I've had to fight with Automake and Libtool to get really simple things done, they're hardly the things you want to hold up as shining beacons. 1. Do you want to compile certain source files with different build flags? Hah, no! Automake only supports it through obscene hacks, and those break if you're using Libtool. 2. Do you want to make a plugin? Best way is to ditch Libtool completely, make an execu…

Basically, these days I recommend cmake as the sane build system that runs everywhere. I don't know about PCs running MacOS, but it works just fine under Linux or Windows and you can do whatever magic you want; it makes simple things easy and complex ones possible.

I wouldn't recommend CMake without qualifications.

It is vastly inferior from the perspective of the end user. Any autotools package can be handled with "./configure && make && sudo make install", and you can change it up by "./configure --without-gtk --enable-network --prefix=/opt/crazy CFLAGS='-O0'" and then make a package with "make install DESTDIR=/tmp/package". Try doing that in CMake, you'll see what I mean.

The syntax is also really terrible, in particular, If/Else. The documentation is not so good, in particular, it's available online as one big block of text and they want to sell you a book.

Finally, CMake doesn't solve the one problem I was complaining the most about, which was the ability to set per-file compilation flags. This is not an optional feature in my eyes -- it's necessary for avoiding cross-contamination of -D_GNU_SOURCE turds picked up by pkg-config, and it's necessary for writing libraries that use processor features that might not be available at runtime, like SSE3.

I think CMake, like Autotools, has a niche in which it does best. "Simple things easy and complex things possible" is a nice motto, but the truth is really boring -- CMake and Autotools make different things easy and different things possible. CMake's niche is medium-large projects with medium amounts of complexity. Projects that are complex, like Firefox or FFMpeg, tend use Autoconf with custom build systems.

Post reply on HN