On Wed, Nov 25, 2015 at 4:56 AM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

If the tables were turned and denotative programming were the norm and imperative programming the fringe community (not that denotative programming is entirely fringe as it were), you would no doubt have posed the opposite question.

I don't agree. Having worked for 16 years in a government aerospace contractor doing C++ and Python programming, what I saw is that maybe half the programmers struggled with precise thinking and abstraction. They thought of programs as step-by-step recipes and implemented those recipes in exactly the same way they themselves had always thought about a problem. Also having worked as a math tutor, I see many people who struggle with abstract thinking. So my feeling is that at least half of the programmers I knew would reject Haskell outright and would feel it was pointlessly non-intuitive. Would they have thought it was intuitive if they were raised on it? I don't think so, because I think these same people were among those who struggle with all forms of abstract thought, like math students who may someday be able to appreciate a little math but are light years away from being math majors. We can pose a world in which the "tables were turned" but for that world to come into existence a lot of things would have to be changed about the current world, particularly increasing interest in abstract math from a young age. Okay, having written all that, please feel free to tear holes in my argument. I would like to be wrong and I don't have experience outside one workplace (and some math tutoring). My workplace was much better than a contractor we briefly hired. Those folks had about a 90% struggle ratio with using things like object orientation. "Just get it done, quick and dirty" was how they thought. My own workplace had some very intelligent people but between the high numbers who were just barely competent programmers, and a more "practical" orientation in the management (documentation was highly emphasized, testing was highly emphasized, but elegant code was practically unimportant), I just can't see the adoption of Haskell by them, not in this lifetime, not in this universe. Can an "okay" imperative programmer become an "okay" Haskell programmer? Does the necessary skill, work, motivation, and talent to program at an "ordinary" imperative level serve as a sufficient prerequisite for functional programming? I really don't think so, but I could be wrong.

However, the tables aren't turned, and you aren't posing the opposite question, so let me give you a brief answer: Yes, Haskell is practical.

To elaborate some: it is used in academia and industry. Not as much as some languages, but then again more than some other languages. Big universities like Chalmers use it, and big companies like Facebook use it. It is the primary language I myself use in industry as well.

Let me repeat myself: Yes, Haskell is practical!

If you have more specific questions, do not hesitate to ask.

Yes, I do have more specific questions. For example is the conciseness part of what makes it practical in these uses? Is the conciseness somehow bound up with what makes it practical? In other words, could we imagine a simpler language with the same level of practicality but less of a learning curve? By the way, I *love* conciseness and have experienced the possibility of it becoming intuitive. It's amazing once I understand an elegant piece of Haskell, once I have wired my brain to think in harmony with it, that it becomes immediately legible. So I know it's possible to make progress. I'm not saying that conciseness must forever remain an obtuse language. But I wonder if the same mechanisms that make Haskell concise (which are some of the things that make it hard) also are bound up with its practical advantages so that they can't be separated. Dennis

Yes Haskell is practical except for finding Haskell replacement programmers. -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Nov 25, 2015 9:50 AM, "Martin Vlk" wrote:

Dennis Raddle:

...

On Wed, Nov 25, 2015 at 4:56 AM, Alexander Berntsen < alexander@plaimi.net> wrote:

<snip>

...

I don't agree. Having worked for 16 years in a government aerospace contractor doing C++ and Python programming, what I saw is that maybe half the programmers struggled with precise thinking and abstraction. They thought of programs as step-by-step recipes and implemented those recipes in exactly the same way they themselves had always thought about a problem.

Also having worked as a math tutor, I see many people who struggle with abstract thinking.

<snip>

...

Can an "okay" imperative programmer become an "okay" Haskell programmer? Does the necessary skill, work, motivation, and talent to program at an "ordinary" imperative level serve as a sufficient prerequisite for functional programming? I really don't think so, but I could be wrong.

What'd be the definition of an okay programmer? If we agree that's the one that "learns how to solve a few standard problems and then applies the same thing over and over without much creativity", then I'll argue this will work with Haskell just like with any imperative language. If you train them on Haskell that is. :-)

<snip>

...

But I wonder if the same mechanisms that make Haskell concise (which are some of the things that make it hard) also are bound up with its practical advantages so that they can't be separated.

What you mean by practical? Does it mean that you can find enough people able to use it in your real-world project, without putting too high requirements on training them?

If so, then we could say that given the current state of affairs, where the mass of okay programmers are trained on a different paradigm, Haskell is not all that practical.

But if practical means that the language is well suited for solving real-world problems, in beautiful ways, once you get it, then it is uberpractical! :-)

M. _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

"lowest common denominator" Right on, Sean. That pretty much sums up the state of affairs. I would however say that the sort of culture, mindset, if you will, agile development encourages might not be entirely compatible with the thinking process and general view of the universe that FP requires. I could be mistaken on this entirely, but agile strikes me as something that would b much more at home in an essentially business-oriented environment used by people of that background e.g. people who thrive on using UML. Matthew On 26/11/2015, emacstheviking wrote:

I read all the above. I have to agree with KC... I have been a software developer for 30+ years now and I would dearly love to be able to use Haskell in my day to day tasks when being paid. As an IT contractor in the UK however that just isn't going to happen. By and large the management / project planning mentality is "lowest common denominator" when it comes to large IT projects. It's not hard to understand the reasons and from a commercial and business perspective it makes sense, of course it does.

I've been working on the UK MOT programme (now complete) for the last 18 months and it was all PHP, Zend Framework 2 and Doctrine because that skill pool is huge compared to Haskell and when it comes to having a ready supply of code capable meat-sacks to deliver stories on time, LCD is where it will always be. TIOBE says that Java has been top dog for ever. I rest my case.

Us in the haskell world realise that people that can use Haskell effectively would be much more productive, and probably produce a lot more functional(!) code in a shorter space of time, have a high sprint velocity, deliver more stories etc. Quickcheck is inspired!

The thought of being on an Agile team using haskell, wow, that's too much to hope for...

All the best, Sean Charles

On 25 November 2015 at 18:13, KC wrote:

...

Yes Haskell is practical except for finding Haskell replacement programmers.

-- --

Sent from an expensive device which will be obsolete in a few months! :D

Casey

On Nov 25, 2015 9:50 AM, "Martin Vlk" wrote:

...

Dennis Raddle:

...

On Wed, Nov 25, 2015 at 4:56 AM, Alexander Berntsen < alexander@plaimi.net> wrote:

<snip>

...

I don't agree. Having worked for 16 years in a government aerospace contractor doing C++ and Python programming, what I saw is that maybe half the programmers struggled with precise thinking and abstraction. They thought of programs as step-by-step recipes and implemented those recipes in exactly the same way they themselves had always thought about a problem.

Also having worked as a math tutor, I see many people who struggle with abstract thinking.

<snip>

...

Can an "okay" imperative programmer become an "okay" Haskell programmer? Does the necessary skill, work, motivation, and talent to program at an "ordinary" imperative level serve as a sufficient prerequisite for functional programming? I really don't think so, but I could be wrong.

What'd be the definition of an okay programmer? If we agree that's the one that "learns how to solve a few standard problems and then applies the same thing over and over without much creativity", then I'll argue this will work with Haskell just like with any imperative language. If you train them on Haskell that is. :-)

<snip>

...

But I wonder if the same mechanisms that make Haskell concise (which are some of the things that make it hard) also are bound up with its practical advantages so that they can't be separated.

What you mean by practical? Does it mean that you can find enough people able to use it in your real-world project, without putting too high requirements on training them?

If so, then we could say that given the current state of affairs, where the mass of okay programmers are trained on a different paradigm, Haskell is not all that practical.

But if practical means that the language is well suited for solving real-world problems, in beautiful ways, once you get it, then it is uberpractical! :-)

M. _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

On Wed, Nov 25, 2015 at 9:50 AM, Martin Vlk wrote:

What'd be the definition of an okay programmer? If we agree that's the one that "learns how to solve a few standard problems and then applies the same thing over and over without much creativity", then I'll argue this will work with Haskell just like with any imperative language. If you train them on Haskell that is. :-)

<snip>

Martin, One issue I can foresee is having both good Haskell programmers and non-creative Haskell programmers on the same team. The good ones can easily write code that is incomprehensible to the non-creative ones. It actually happened in my team twice that C++ code was thrown out and assigned to someone else for a complete rewrite, because the senior software engineer deemed that the original code was incomprehensible. In both cases it was code that used a few tricks that I think were good, and in both cases the replacement code was buggier.

...

But I wonder if the same mechanisms that make Haskell concise (which are some of the things that make it hard) also are bound up with its practical advantages so that they can't be separated.

What you mean by practical? Does it mean that you can find enough people able to use it in your real-world project, without putting too high requirements on training them?

If so, then we could say that given the current state of affairs, where the mass of okay programmers are trained on a different paradigm, Haskell is not all that practical.

But if practical means that the language is well suited for solving real-world problems, in beautiful ways, once you get it, then it is uberpractical! :-)

Very well put. I didn't really think about what meant by "practical," and it depends on context. I am gaining some Haskell momentum, and I see how the potential for conciseness seems to encourage the kind of thinking about a problem that leads to simplifications and optimizations. When I spend some time thinking about a good way to write it in Haskell, it's guiding me toward a better understanding of the problem itself that would potentially be helpful no matter what language I'm using. But using Haskell provides the impetus for this thinking. Dennis