Am 16.09.2016 um 15:38 schrieb Imants Cekusins:

a lot of what is often called "complexity" stems from lack of types and gaps in comments / documentation.

That's a big issue with Gradle. The third problem I know Gradle for is that it makes it surprisingly difficult to inspect the execution plan.

On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote:

Chris Kahn writes:

...

I would like to second this thought. Using Haskell for package descriptions needs to be thought out and executed with great care and attention. It's really easy to go off the rails.

Scala's build system lets you do very powerful things, but it also makes things unnecessarily complicated and mystifying for beginners. At my previous work where we used Scala extensively, there were many times where the team simply resorted to external tools because figuring out how to make some seemingly trivial change to an SBT module was too time consuming.

Let me guess (have no idea about sbt) -- unbridled Turing completeness?

Declarativity is king for configuration, and Turing completeness ain't it -- please, see my other mail about subsetting Haskell.

That's not the main problem with SBT. How do I explain it? Take this as an example of what Haskell should *not* do. # SBT made difficult Look, we all know a monad is just a monoid in the category of endofunctors, right?. Now, a SBT build configuration is just a heterogeneously-typed map from keys to monadic values that can be evaluated to a graph of setting transformers and build actions, so what's the problem? And oh, I forgot to mention keys aren't simple strings but have a hierarchy themselves, and this hierarchy is used for inheritance and overriding of settings (nothing as simple as OO inheritance, mind you, think of something like CSS but different). Isn't using Haskell supposed to require a PhD? So why would its build tools use something so simple as nested records, like Cabal does? </sarcasm> I think I'm trolling, but the above is somewhat accurate (except for any misunderstanding of SBT I might have)—I personally enjoy using SBT and its power, and once you learn it can be reasonably easy, but I think Kmett's lens library might be simpler to learn. In fairness, many SBT builds can be read without having any clue of the above, because they look like imperative programs. But as soon as you need to do a bit more or you make a type error, you end up facing some of the above complexity—if you want, the "imperative program" abstraction is extremely leaky. For instance, here's something "easy" (but count the amount of custom symbolic operators): scalaVersion := "2.11.0" scalacOptions += "-deprecation" libraryDependencies += org.scalatest" %% "scalatest" % "2.0" Then you want to use one setting when defining another, and suddenly you end up with: libraryDependencies <+= scalaVersion (ver => "org.scala-lang" % "scala-compiler" % ver) Luckily, this can be done more easily nowadays, thanks to Scala macros O_O.

https://github.com/ghc-proposals/ghc-proposals/ could be used for this purpose. There is also the Trac wiki but I find it is a bit too hard to keep under control with comments. Edward Excerpts from Harendra Kumar's message of 2016-09-17 08:05:38 +0530:

Since I triggered this discussion I feel obligated to summarize the important points that were presented. Is there a good place to record Haskell ecosystem related discussions (some wiki)?

-harendra

On 17 September 2016 at 05:57, Paolo Giarrusso wrote:

...

On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote:

...

Chris Kahn writes:

...

I would like to second this thought. Using Haskell for package descriptions needs to be thought out and executed with great care and attention. It's really easy to go off the rails.

Scala's build system lets you do very powerful things, but it also makes things unnecessarily complicated and mystifying for beginners. At my previous work where we used Scala extensively, there were many times where the team simply resorted to external tools because figuring out how to make some seemingly trivial change to an SBT module was too time consuming.

Let me guess (have no idea about sbt) -- unbridled Turing completeness?

...

Declarativity is king for configuration, and Turing completeness ain't it -- please, see my other mail about subsetting Haskell.

That's not the main problem with SBT. How do I explain it? Take this as an example of what Haskell should *not* do.

# SBT made difficult

Look, we all know a monad is just a monoid in the category of endofunctors, right?. Now, a SBT build configuration is just a heterogeneously-typed map from keys to monadic values that can be evaluated to a graph of setting transformers and build actions, so what's the problem? And oh, I forgot to mention keys aren't simple strings but have a hierarchy themselves, and this hierarchy is used for inheritance and overriding of settings (nothing as simple as OO inheritance, mind you, think of something like CSS but different). Isn't using Haskell supposed to require a PhD? So why would its build tools use something so simple as nested records, like Cabal does? </sarcasm> I think I'm trolling, but the above is somewhat accurate (except for any misunderstanding of SBT I might have)—I personally enjoy using SBT and its power, and once you learn it can be reasonably easy, but I think Kmett's lens library might be simpler to learn.

In fairness, many SBT builds can be read without having any clue of the above, because they look like imperative programs. But as soon as you need to do a bit more or you make a type error, you end up facing some of the above complexity—if you want, the "imperative program" abstraction is extremely leaky.

For instance, here's something "easy" (but count the amount of custom symbolic operators):

scalaVersion := "2.11.0" scalacOptions += "-deprecation" libraryDependencies += org.scalatest" %% "scalatest" % "2.0"

Then you want to use one setting when defining another, and suddenly you end up with:

libraryDependencies <+= scalaVersion (ver => "org.scala-lang" % "scala-compiler" % ver)

Luckily, this can be done more easily nowadays, thanks to Scala macros O_O.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.