[Haskell-cafe] The last decade: what has changed, was has stayed the same?

[Joachim Durchholz]

Thanks Albert!

Am 16.11.2015 um 01:06 schrieb Albert Y. C. Lai:
> On 2015-11-13 02:43 PM, Joachim Durchholz wrote:
>> After learning the bare language, how long does it take a competent
>> programmer to become confident in the performance of his Haskell code?
>>
>> After learning the bare language, how long does it take a competent
>> programmer to know when and when not to use strictness
>> annotations/operators?
>
> These two questions unify into one; choosing the right strictness is
> part of making an efficient program.

I meant the first question to be "how well can I predict the performance 
of my code".

The second question was "if performance is insufficient, how well can 
people wield the tool that they have for it".
If the optimizer is good enough, the second question would rarely matter 
enough.

> Confidence is a treacherous end; by the Dunning-Kruger effect, it only
> takes a month for one to be fully confident and totally wrong. (Under
> one week if the person has been competent in past things so they think
> they're infallible in all future things.)

Oh, a competent programmer can see whether he's under Dunning-Kruger or 
not: If haskell-cafe is talking about issues and problems he hasn't seen 
yet, he isn't good enough yet. That's easy enough if you're training to 
watch out for these things.

> It is more objective and productive to ask: how long does it take to be
> measurably successful?

That's a bit too open-ended because everybody's definition of "success" 
varies. Some people feel successful if their code compiles, others feel 
successful only if they can control cache locality across asymmetric MP 
cores.

It's still an interesting question.

> The following aids are available now but not back then. If
> you start today, it may take you less time and puzzlement:
>
> http://www.vex.net/~trebla/haskell/lazy.xhtml  (I wrote it after I
> really figured out lazy evaluation, so of course it didn't exist when I
> was learning)
> https://hackhands.com/guide-lazy-evaluation-haskell/
> https://github.com/takenobu-hs/haskell-ghc-illustrated

I'll take a look at these. I'm a bit sceptical that I'll be able to 
become competent just by reading them though :-)

>> I'm seeing a lot of typesystem golf happening.
>> Is this teachable to the average competent programmer?
>> Is it relevant to everyday programming such as business logic,
>> database access, or webpage generation? (If no, for what programming
>> endeavours is it relevant?)
>
> I am not fond of most of their advanced type-level games which are
> far-fetched encodings of dependent types in a non-dependent type system.
> They remind me of how I felt enlightened for five minutes when I first
> realized how to simulate malloc and free in BASIC. It lasted for only
> five minutes because it was false enlightenment. The true enlightenment
> should be: This is why you ditch BASIC for Pascal or C.

Heh. I can understand that sentiment. My knee-jerk reaction to the first 
experiments (encoding integers in the type system to get stuff like 
square matrices typed) was "gee, we should really unify all this stuff 
in general assertions about types&values and have the compiler check 
these as far as possible!" (Unfortunately, that would not be Haskell 
anymore.)

Still, not being competent with Haskell in any way, I need to listen to 
divergent views. (I regret having written "typesystem golf", it can be 
seen as derogatory and shapes the answers.)

> But a very elementary use of GADTs and phantom types improves safety of
> databasee access a lot.

Yeah, that's really important. I'm pretty much in the same boat with you 
on that issue; the usefulness of a type system trick (or any language 
trick) needs to be multiplied by the percentage of people able to 
understand and use it in practice.

> At a low level, of course you still have the very unsafe and very
> vulnerable
>
> raw_query :: ByteString -> IO [[ByteString]]
> -- I omit a Connection parameter for this sketch
> -- also perhaps it should be IO (Either SQLError [[ByteString]])

You can also have warnings. Or errors AND a result.
(I happen to know that after half a decade of doing Oracle via JDBC.)

> But you can say you don't use it directly; you use a safer, higher level
> wrapper, less vulnerable to type errors.

Everybody is doing that :-)
Including the Java guys.

Some of the Java guys are even doing pretty declarative designs even if 
imperative. Try a look at Jooq, it's built to deal with database 
incompatibilities AND be easy to use: http://jooq.org/
(Disclaimer: It was on my shortlist once, but never made it into 
production use for me, so I don't know how well the approach holds up in 
real use.)

Thanks!
Jo

(Hope somebody takes the time to look at the other aspects of the 
question...)