Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: is Haskell practical? (Dennis Raddle)
2. comment on this debugging trick? (Dennis Raddle)
3. Re: is Haskell practical? (Blake Hyde)
4. Re: comment on this debugging trick? (Jeffrey Brown)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Nov 2015 05:17:10 -0800
From: Dennis Raddle <dennis.rad...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] is Haskell practical?
Message-ID:
<CAKxLvoqXdx-fL_2HkY0tWS1Oz+8_h-1=d7coq8eydu0fesj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Nov 25, 2015 at 9:50 AM, Martin Vlk <mar...@vlkk.cz> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151127/267a0c8e/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 27 Nov 2015 05:56:18 -0800
From: Dennis Raddle <dennis.rad...@gmail.com>
To: Haskell Beginners <beginners@haskell.org>
Subject: [Haskell-beginners] comment on this debugging trick?
Message-ID:
<cakxlvoovjs9ec_t_+-ob6yjmxfjfyoud7eqdhnrdo46q+er...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
When I design my code, I am aware of the properties I expect my internal
data representations to have, or I want input data to conform to my
expectations. For example, right now I'm writing code that reads MusicXML.
MusicXML is a crazy language, way too complicated for what it does, and the
music typesetters that export MusicXML all do their own idiosyncratic
things with it. I'm only reading the output of one typesetter, Sibelius,
and although I don't know the internals of Sibelius, I can make some
assumptions about what it's going to produce by a few examples, plus my
application doesn't use the full range of MusicXML. I don't need to handle
every case, is what I'm getting at.
However, if I should have been wrong about my assumptions when I wrote the
code, I don't want my program to behave erratically. I want to find out
exactly what went wrong as soon as possible.
Previously, I was including a lot of exception throwing, with each
exception having a unique message describing what had happened, and in
particular describing where in the code it is located so I can find the
problem spot
If I throw generic error messages like "Error: problem parsing" and I have
many of those located in the code, I need the debugger to find it. Same if
I use things like "fromJust" or "head"
I haven't had good experiences using the debugger. Maybe that's my fault,
but I like that I can locate my unique exceptions and that they are
descriptive.
But a month ago I decided this system is pretty ugly. It bloats the code a
lot, and requires writing a lot of messages for situations that will
probably never occur.
I am trying a different method now. I write the code so that surprising
behavior will result in a case or pattern exhaustion, which produces a run
time message with a file name and line number. I'm not sure why ghc gives
the location for a case exhaustion, but not something like "head".
For example, instead of using head xs I can write
x = case xs of {y:_ -> y}
This is a little bloat but not too bad. Most of the time I'm actually
structuring cases and patterns, and it actually helps me to simplify code
to think of how to write it with the fewest cases and so that a case
exhaustion will indicate something pretty specific.
Any comments welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151127/deafc5ff/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 27 Nov 2015 10:17:38 -0500
From: Blake Hyde <syr...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] is Haskell practical?
Message-ID:
<CAF2_QK6mvp1Nab7cpaJTCS_9EPT-BhVOsNhjY=SGL4=mkgx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Nov 27, 2015 at 8:17 AM, Dennis Raddle <dennis.rad...@gmail.com>
wrote:
>
> 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.
>
>
This is not unique to Haskell; this is a problem with programming in
general. People with more ability can write code that is clean, fast, and
easy to read, but which "average" programmers find confusing. I don't think
it's realistic to avoid that in any language; I've even had people review
my Ruby code that used the "Hash[]" constructor to build a hashmap from a
list and call that confusing.
>
> 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.
>
> In my opinion, thinking about the problem up front is the most vital
aspect of writing reliable, readable code, in any language. Haskell allows
you to encode those insights into the types; in other languages, they
frequently live only in your short term memory (or, if you're particularly
conscientious, docstrings--although those are neglected the minute anyone
else touches them).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151127/2f7ff435/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 27 Nov 2015 10:31:47 -0800
From: Jeffrey Brown <jeffbrown....@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] comment on this debugging trick?
Message-ID:
<CAEc4Ma1x-vgA8ZZ4Qzw+0dXZDVxSHoXwCz0rwB-0VwNuiz=c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Elliot Cameron, very smart guy, once advised me to make illegal state
invalid. Jake Brownson, another, recommended trying to use Maybes and
Eithers instead of throwing exceptions. I'm having trouble coming up with
examples but I think they're both helpful.
That said, your trick of replacing, for instance, head with a case
statement seems good to me ...
On Fri, Nov 27, 2015 at 5:56 AM, Dennis Raddle <dennis.rad...@gmail.com>
wrote:
> When I design my code, I am aware of the properties I expect my internal
> data representations to have, or I want input data to conform to my
> expectations. For example, right now I'm writing code that reads MusicXML.
> MusicXML is a crazy language, way too complicated for what it does, and the
> music typesetters that export MusicXML all do their own idiosyncratic
> things with it. I'm only reading the output of one typesetter, Sibelius,
> and although I don't know the internals of Sibelius, I can make some
> assumptions about what it's going to produce by a few examples, plus my
> application doesn't use the full range of MusicXML. I don't need to handle
> every case, is what I'm getting at.
>
> However, if I should have been wrong about my assumptions when I wrote the
> code, I don't want my program to behave erratically. I want to find out
> exactly what went wrong as soon as possible.
>
> Previously, I was including a lot of exception throwing, with each
> exception having a unique message describing what had happened, and in
> particular describing where in the code it is located so I can find the
> problem spot
>
> If I throw generic error messages like "Error: problem parsing" and I have
> many of those located in the code, I need the debugger to find it. Same if
> I use things like "fromJust" or "head"
>
> I haven't had good experiences using the debugger. Maybe that's my fault,
> but I like that I can locate my unique exceptions and that they are
> descriptive.
>
> But a month ago I decided this system is pretty ugly. It bloats the code a
> lot, and requires writing a lot of messages for situations that will
> probably never occur.
>
> I am trying a different method now. I write the code so that surprising
> behavior will result in a case or pattern exhaustion, which produces a run
> time message with a file name and line number. I'm not sure why ghc gives
> the location for a case exhaustion, but not something like "head".
>
> For example, instead of using head xs I can write
>
> x = case xs of {y:_ -> y}
>
> This is a little bloat but not too bad. Most of the time I'm actually
> structuring cases and patterns, and it actually helps me to simplify code
> to think of how to write it with the fewest cases and so that a case
> exhaustion will indicate something pretty specific.
>
> Any comments welcome.
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
--
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151127/6448bc1c/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 89, Issue 48
*****************************************
