Can´t agree more. Haskell may die slowly for industry if we don´t push it. For me this issue is clearly this is the major obstacle for creating high level languages close to each domain problem.

Haskell can not success in other ways, because EDSLs is the natural form in which Haskell present a solution, in the same way that in Ruby is a customizable Web application, in DotNet a windows application in C is a library or console application.

Believe it or not, there are problems out there that are more complicated that monads or profunctors. And these people have enough with their problems, they neither want nor need to understand your monads. They want solutions that speak in terms of their language, not yours. 99% of them will never convert themselves into a small haskell software house to have the three or four EDSLs that they need. that does not make economic sense. But they would buy haskell consultancy services to extend, integrate and install EDSLs. The day to day work can be done by the domain problem experts, since the EDSLs uses their respective jargon.

As soon as there is something out there that do 20% of what haskell can do for creating high level EDSLs, with decent customizable and understandable error messages for people that know a little of programming but are intersted in having a rapid and flexible solution for their problem, then the days of Haskell as a promising language for industry may have passed away.

2014-11-23 21:42 GMT+01:00 Wojciech Danilo <wojciech.danilo@gmail.com>:

Richard - did you think about some way of funding Haskell development? I think a lot of people are talking about low people-hours spend on GHC, but nobody ever told that a good solution here will be funding of its development. We've got so many options here - dotations, companies, vc's, community funding (maybe even kickstarter). You know, this would help MUCH Haskell and overall - everyone from this community. But in general - people are not working this way, that if somebody will tell - this is a good idea, everybody woudl do it. I'm writing exactly to you, because you are somebody very close to GHC and we all see, you "want" to do something good. Why not get funding for Haskell and GHC? I would love to help, really - as much as I can. But if everyone agree, we have to do something with it, as fast as possbile, othercase, Haskell will slowly die - taking in consideration how much moneyu is put in Scala, Go etc. These languages are getting better everyday - and of course, they've got another asusmptions than the best programming language I've been suing in my life, they have got many man-hours more spend on development than we do.
What do you think?

All the best,
Wojciech

Sun Nov 23 2014 at 8:42:29 PM użytkownik Artyom <yom@artyom.me> napisał:
On 11/23/2014 09:01 PM, Alberto G. Corona wrote:

It is so evident that this is THE problem of Haskell

Unfortunately, it’s not evident. Note that I’m /not/ saying it’s not
“the” problem of Haskell; merely that

*

I consider myself to be somewhat intelligent

*

and – without having put much thought into this question – I don’t
find it evident at all that the incomprehensibility of error
messages arising when using DSLs is “probably the biggest barrier
for the acceptance of Haskell on Industry”

Therefore, unless you’re sure for some reason that I’m an outlier and
the majority of programmers /do/ find it evident but prefer to pretend
they don’t (for pragmatic, evil, or other reasons), I would suggest
writing an article attempting to persuade the community that it’s indeed
a major problem – or, better yet, the problem which has the biggest
utility/complexity-of-implementation ratio. I remember that what got me
into Haskell was simply a handful of “mind-blowing” examples – an easily
readable parser in a few lines of code, the elegance of |map| versus a
|for| loop, things like that. A post with side-by-side comparisons of
real-world GHC error messages arising when working with various DSLs
(parsec, attoparsec, blaze, binary, diagrams, etc.) vs. mockups of
improved error messages, alongside with a section describing the current
research done in this direction and outlining general ideas/concepts,
would probably do the trick.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Alberto.