Need inputs for a Haskell awareness presentation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Need inputs for a Haskell awareness presentation

C K Kashyap
Hi folks,

I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward. I request you to share your experiences/suggestions for the following -
1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of  object oriented bliss.
2. Handling questions/comments like these in witty/interesting ways - 
    a) It looks good and mathematical but practically, what can we do with it, all our stuff is in C++
    b) Wow, what do you mean you cannot reason about its space complexity?
    c) Where's my inheritance?
    d) Debugging looks like a nightmare - we cannot even put a print in the function?
    e) Static types - in this day and age - come on - productivity in X is so much more - and that's because they got rid of type mess.
    f)  Is there anything "serious/large" written in it? [GHC will not qualify as a good answer I feel]
    g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do AI.
    h) Any other questions/comments that you may have heard.
3. Ideas about interesting problems that can be used so that it appeals to people. I mean, while fibonacci etc look good but showing those examples tend to send the signal that it's good for "those kind" of problems.
4. Is talking about or referring to Lambda calculus a good idea - I mean, showing that using its ultra simple constructs one could build up things like if/then etc 

I'm gonna do my bit to wear the limestone!!!

Regards,
Kashyap

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Clark Gaebel-2
Regarding 2d, Debug.Trace is perfect for that.

On Thu, May 31, 2012 at 2:23 PM, C K Kashyap <[hidden email]> wrote:
Hi folks,

I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward. I request you to share your experiences/suggestions for the following -
1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of  object oriented bliss.
2. Handling questions/comments like these in witty/interesting ways - 
    a) It looks good and mathematical but practically, what can we do with it, all our stuff is in C++
    b) Wow, what do you mean you cannot reason about its space complexity?
    c) Where's my inheritance?
    d) Debugging looks like a nightmare - we cannot even put a print in the function?
    e) Static types - in this day and age - come on - productivity in X is so much more - and that's because they got rid of type mess.
    f)  Is there anything "serious/large" written in it? [GHC will not qualify as a good answer I feel]
    g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do AI.
    h) Any other questions/comments that you may have heard.
3. Ideas about interesting problems that can be used so that it appeals to people. I mean, while fibonacci etc look good but showing those examples tend to send the signal that it's good for "those kind" of problems.
4. Is talking about or referring to Lambda calculus a good idea - I mean, showing that using its ultra simple constructs one could build up things like if/then etc 

I'm gonna do my bit to wear the limestone!!!

Regards,
Kashyap

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Rustom Mody
In reply to this post by C K Kashyap


On Thu, May 31, 2012 at 11:53 PM, C K Kashyap <[hidden email]> wrote:
Hi folks,

I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward.

You (and we) may believe that but saying so usually does not work.
What is more likely to work is talking to people about what interests them (rather than you :-) ).  For example teachers of CS are usually struck by and bowled over by quicksort in 2 lines because for them teaching quicksort is considered an important activity.  Professional object-oriented programmers are unlikely to take to such an 'academic' example kindly.
Likewise those interested in algorithms and data-structures would be caught by a (tree) dfs in 1 line, or that a graph dfs and bfs are the same except that a
[x] ++ pending
becomes
pending ++ [x]
But if they were not so interested in algos and data-structures (Java programmers more than C++ are particularly prone to being using-happy, understanding-chary) this example would not work.

So in short find what matters to your audience and then survey, focus and drill into that -- using Haskell
 
I request you to share your experiences/suggestions for the following -
1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of  object oriented bliss.
2. Handling questions/comments like these in witty/interesting ways - 
    a) It looks good and mathematical but practically, what can we do with it, all our stuff is in C++
    b) Wow, what do you mean you cannot reason about its space complexity?
    c) Where's my inheritance?

Yes you need to find a hot OO guru saying that inheritance is best avoided where templates/STL etc work

    d) Debugging looks like a nightmare - we cannot even put a print in the function?

Maybe a (concocted) example of how the typechecker does most of the debugging for you? Better of course if the example is genuinely hacked out in front of the class (ideally from some thing they want to see solved) that can be convincing re things like debugging.

This also brings up what is (for me) a very important point regarding haskell -- using an interpreter, ie ghci.
-- the tight feedback loop
-- not being bound to having to write a main
-- the general sense of a workbench in which various objects (some joke here for the OO guys?) are are in different states of under construction to shrink-wrapped

Personally I do not see how I could teach (or do) haskell without emacs.  Admittedly this attracts some strongly and repels others equally strongly

    e) Static types - in this day and age - come on - productivity in X is so much more - and that's because they got rid of type mess.
    f)  Is there anything "serious/large" written in it? [GHC will not qualify as a good answer I feel]
    g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do AI.
    h) Any other questions/comments that you may have heard.
3. Ideas about interesting problems that can be used so that it appeals to people. I mean, while fibonacci etc look good but showing those examples tend to send the signal that it's good for "those kind" of problems.
4. Is talking about or referring to Lambda calculus a good idea - I mean, showing that using its ultra simple constructs one could build up things like if/then etc 

I'm gonna do my bit to wear the limestone!!!

Regards,
Kashyap

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Anton Kholomiov
In reply to this post by C K Kashyap

a) you can generate c++ with it :) (but don't tell it.
it may be regarded as offense)

b) -

c) -

d) stop debugging, you don't need it that much in
haskell. But you need profiler. If they really want
to print something in pure function you can show
them function 'trace', from Debug.Trace

e) I don't think that C++ people think that types are bad.
If they do you can tell (beside the types don't let you
mess up to much and stimulate clarity and documentation)
about how easy is to do refactoring in typed language.

f) You can show them Atom [1]. 5k Haskell code generates
20k C-code and it all works in real time in real trucks.
Or Copilot. It's going to be used in airplanes.

4. I think it's bad idea. It's better to start with
examples.

What really strikes me about haskell is the simplicity of
data types. I think the best way to start is to show
Booleans, then lists, then Trees. It's so simple and
beautiful

You can say. Do you really need to know anything
about syntax to understand this:

data Bool = False | True

or this

data Time = Time Hour Minute Second

or this

data List a = Nil | Cons a (List a)

and you can say that it is not built in. You can define it
yourself and it works as fast as any other data type
(or as slow).

You can stress the idea of haskell data types is
haskell UML.

Don't show definitions just show them types like this:

not :: Bool -> Bool
and :: Bool -> Bool -> Bool

reverse :: [a] -> [a]
map     :: (a -> b) -> [a] -> [b]

then you can show definitions and say about pattern matching.
It is very intuitive.


[1] http://hackage.haskell.org/package/atom



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Chris Wong
In reply to this post by C K Kashyap
On Fri, Jun 1, 2012 at 6:23 AM, C K Kashyap <[hidden email]> wrote:
> Hi folks,
>
> I have the opportunity to make a presentation to folks (developers and
> managers) in my organization about Haskell - and why it's important - and
> why it's the only way forward. I request you to share your
> experiences/suggestions for the following -
> 1. Any thoughts around the outline of the presentation - target audience
> being seasoned imperative programmers who love and live at the pinnacle of
>  object oriented bliss.

Rustom nailed it. Take something imperative languages are really,
really bad at and *show* how it's done in Haskell.

*   Parsing

    Haskell parser combinators make yacc look old school. By
leveraging Haskell's DSL features, parsers often end up looking like
the grammar they're implementing. Different parser combinator
libraries let you do incremental input  (Attoparsec), show clang-style
diagnostics (Trifecta), or perform crazy optimizations automatically
(uu-parsinglib).

*   Iteratee I/O

        encodeFile from to = mapOutput encode (sourceFile from) $$ sinkFile to

    It may not look like it, but the above function (using the
"conduit" package) sets up a I/O pipeline that uses constant memory.
There are HTTP, FTP, text encoding and parser libraries that can hook
into the pipeline the same way. All the resources (sockets, file
handles) tied up in the pipeline are finalized automatically when it
finishes or when an exception is thrown.

*   Epic concurrency

    GHC comes with preemptive scheduling, STM and async I/O built in.
Maybe you could demonstrate these with a ping-pong-style application.

> 2. Handling questions/comments like these in witty/interesting ways -
>     a) It looks good and mathematical but practically, what can we do with
> it, all our stuff is in C++

Anything you can do in another Turing-complete language ;)

Quite a few folks have helped push Haskell into the practical world,
with useful things like web frameworks, ByteStrings, GUI bindings...
It's suitable for practical applications already.

>     b) Wow, what do you mean you cannot reason about its space complexity?

That's not a bug, it's a feature!

C++ gives you lots of control over how your program runs.
Unfortunately, most people don't need that or don't know how to use it
effectively. So most of the time, these low-level features just add a
bunch of cruft with no real benefit to the programmer.

Haskell goes the opposite way. The Haskell standard goes out of its
way *not* to say how programs actually run -- only what the result
should be. This lets the compiler optimize much more than in other
languages.

This philosophy is reflected in a common technique called "stream
fusion". I can't be bothered writing an example for this, but Google
it and you'll find a few.

>     c) Where's my inheritance?

Right behind you ;)

>     d) Debugging looks like a nightmare - we cannot even put a print in the
> function?

Traditional debugging -- stepping through the program line by line --
fails miserably in Haskell, mostly due to (b).

Haskell programmers tend to use more "mathematical" techniques:
* Property-based testing, e.g. reverse (reverse xs) == xs. Used
extensively in Xmonad.
* Algebraic proofs (this works especially well for "framework" stuff
like the MTL).
* Sexy types: encoding invariants in the type so the compiler checks
it for you. The fb (Facebook API) package does this with the NoAuth
and Auth phantom types.

For I/O-centric code, there's the traditional HUnit and HSpec.

And as Clark said, there's always Debug.Trace.

>     e) Static types - in this day and age - come on - productivity in X is
> so much more - and that's because they got rid of type mess.

The designers of Haskell went out of their way to make sure 99% of
types can be inferred by the compiler. It's good practice to put type
annotations on things, but you don't have to.

>     f)  Is there anything "serious/large" written in it? [GHC will not
> qualify as a good answer I feel]

* Yesod and Snap and Happstack -- all mature, well documented web
frameworks. Yesod is the check-everything-at-compile-time one, Snap is
the mix-and-match one and Happstack is the use-lots-of-combinators
one.
* Warp, a simple yet full-featured web server, trashes the competition
in terms of performance -- yet consists of less than 1k lines of code.
It uses all three of the techniques I mentioned above.
* Xmonad is a window manager. I've used quite a few tiling window
managers before, and Xmonad is the only one that hasn't crashed.
* Geordi (http://www.eelis.net/geordi/), an IRC bot that compiles and
runs C++ code, is written in Haskell.

>     g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do
> AI.
>     h) Any other questions/comments that you may have heard.
> 3. Ideas about interesting problems that can be used so that it appeals to
> people. I mean, while fibonacci etc look good but showing those examples
> tend to send the signal that it's good for "those kind" of problems.
> 4. Is talking about or referring to Lambda calculus a good idea - I mean,
> showing that using its ultra simple constructs one could build up things
> like if/then etc
> I'm gonna do my bit to wear the limestone!!!
>
> Regards,
> Kashyap
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Ketil Malde-5
In reply to this post by C K Kashyap
C K Kashyap <[hidden email]> writes:

>     c) Where's my inheritance?

I was of the impression that OO has crawled our way, for instance
frowing upon (implementation) inheritance and mutable data structures.
Maybe you could find appropriate references?  Lots of language
development these days seems to be looking to functional languages for
inspiration.

>     e) Static types - in this day and age - come on - productivity in X is
> so much more - and that's because they got rid of type mess.

Don't mention static types until later - show code without annotations.
Then later explain that things are statically typed even without
annotations, and that static types helps correctness, e.g. when
refactoring code, or building complex compositions of higher order functions.
Could you reasonalby do arrows or monads etc. in a dynamically typed
language?

Moreover, I don't think STM is going to work without types separating
TVars from other data, and this shows our types are more powerful than
your grandfather's C-style type systems.

>     g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do
> AI.

...and Java, that's imperative...like Fortran, isn't it?  Nah, we don't
calculate artillery tables, so...

Btw, maybe there could be a wiki section or something with stuff like
this - I think it would be useful to collect introductory resources for
settings like this - I know I'm often being asked about this Haskell
stuff from colleagues and friends.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Bartosz Milewski-2
In reply to this post by Chris Wong
We have recently delivered a two-day hands-on Haskell training at
Qualcomm. As Chris points out, parsing and concurrency/parallelism are
the undisputed strengths of Haskell, so we used them extensively. The
first day was dedicated to writing a parser of arithmetic expressions
with symbolic variables, from scratch. We started very close to
imperative style, so we had a tokenizer, parser, and evaluator. They all
contained a lot of boilerplate code: error testing and state passing
(input string in the tokenizer, token list in the parser, and symbol
table in the evaluator). So it was very natural to abstract all this
boilerplate into monads. There was actually a big aha! when we
abstracted all these nasty control structures into bind and return and
then showed the do notation.

The second day was dedicated to concurrency and parallelism, starting
with forkIO and MVars, then going through the par monad (with some
hands-on exercises) and Repa, and finally showing Accelerate on GPUs.
The course was a great success. We didn't have to deal with any nasty
questions. We explained some of the evaluation strategies (strict,
head-normal, bang) and memory issue workarounds (foldl vs foldr, etc.).
We also showed an example of inductive proof of a simple property to
show how Haskell can help with correctness.

FP Complete and Well-Typed are planning on releasing some of our
training materials to the public soon (depending on how much time I have
to organize them).

[:Bartosz:]


On 5/31/2012 18:12, Chris Wong wrote:

> On Fri, Jun 1, 2012 at 6:23 AM, C K Kashyap<[hidden email]>  wrote:
>> Hi folks,
>>
>> I have the opportunity to make a presentation to folks (developers and
>> managers) in my organization about Haskell - and why it's important - and
>> why it's the only way forward. I request you to share your
>> experiences/suggestions for the following -
>> 1. Any thoughts around the outline of the presentation - target audience
>> being seasoned imperative programmers who love and live at the pinnacle of
>>   object oriented bliss.
> Rustom nailed it. Take something imperative languages are really,
> really bad at and *show* how it's done in Haskell.
>
> *   Parsing
>
>      Haskell parser combinators make yacc look old school. By
> leveraging Haskell's DSL features, parsers often end up looking like
> the grammar they're implementing. Different parser combinator
> libraries let you do incremental input  (Attoparsec), show clang-style
> diagnostics (Trifecta), or perform crazy optimizations automatically
> (uu-parsinglib).
>
> *   Iteratee I/O
>
>          encodeFile from to =apOutput encode (sourceFile from) $$ sinkFile to
>
>      It may not look like it, but the above function (using the
> "conduit" package) sets up a I/O pipeline that uses constant memory.
> There are HTTP, FTP, text encoding and parser libraries that can hook
> into the pipeline the same way. All the resources (sockets, file
> handles) tied up in the pipeline are finalized automatically when it
> finishes or when an exception is thrown.
>
> *   Epic concurrency
>
>      GHC comes with preemptive scheduling, STM and async I/O built in.
> Maybe you could demonstrate these with a ping-pong-style application.
>
>> 2. Handling questions/comments like these in witty/interesting ways -
>>      a) It looks good and mathematical but practically, what can we do with
>> it, all our stuff is in C++
> Anything you can do in another Turing-complete language ;)
>
> Quite a few folks have helped push Haskell into the practical world,
> with useful things like web frameworks, ByteStrings, GUI bindings...
> It's suitable for practical applications already.
>
>>      b) Wow, what do you mean you cannot reason about its space complexity?
> That's not a bug, it's a feature!
>
> C++ gives you lots of control over how your program runs.
> Unfortunately, most people don't need that or don't know how to use it
> effectively. So most of the time, these low-level features just add a
> bunch of cruft with no real benefit to the programmer.
>
> Haskell goes the opposite way. The Haskell standard goes out of its
> way *not* to say how programs actually run -- only what the result
> should be. This lets the compiler optimize much more than in other
> languages.
>
> This philosophy is reflected in a common technique called "stream
> fusion". I can't be bothered writing an example for this, but Google
> it and you'll find a few.
>
>>      c) Where's my inheritance?
> Right behind you ;)
>
>>      d) Debugging looks like a nightmare - we cannot even put a print in the
>> function?
> Traditional debugging -- stepping through the program line by line --
> fails miserably in Haskell, mostly due to (b).
>
> Haskell programmers tend to use more "mathematical" techniques:
> * Property-based testing, e.g. reverse (reverse xs) =xs. Used
> extensively in Xmonad.
> * Algebraic proofs (this works especially well for "framework" stuff
> like the MTL).
> * Sexy types: encoding invariants in the type so the compiler checks
> it for you. The fb (Facebook API) package does this with the NoAuth
> and Auth phantom types.
>
> For I/O-centric code, there's the traditional HUnit and HSpec.
>
> And as Clark said, there's always Debug.Trace.
>
>>      e) Static types - in this day and age - come on - productivity in X is
>> so much more - and that's because they got rid of type mess.
> The designers of Haskell went out of their way to make sure 99% of
> types can be inferred by the compiler. It's good practice to put type
> annotations on things, but you don't have to.
>
>>      f)  Is there anything "serious/large" written in it? [GHC will not
>> qualify as a good answer I feel]
> * Yesod and Snap and Happstack -- all mature, well documented web
> frameworks. Yesod is the check-everything-at-compile-time one, Snap is
> the mix-and-match one and Happstack is the use-lots-of-combinators
> one.
> * Warp, a simple yet full-featured web server, trashes the competition
> in terms of performance -- yet consists of less than 1k lines of code.
> It uses all three of the techniques I mentioned above.
> * Xmonad is a window manager. I've used quite a few tiling window
> managers before, and Xmonad is the only one that hasn't crashed.
> * Geordi (http://www.eelis.net/geordi/), an IRC bot that compiles and
> runs C++ code, is written in Haskell.
>
>>      g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do
>> AI.
>>      h) Any other questions/comments that you may have heard.
>> 3. Ideas about interesting problems that can be used so that it appeals to
>> people. I mean, while fibonacci etc look good but showing those examples
>> tend to send the signal that it's good for "those kind" of problems.
>> 4. Is talking about or referring to Lambda calculus a good idea - I mean,
>> showing that using its ultra simple constructs one could build up things
>> like if/then etc
>> I'm gonna do my bit to wear the limestone!!!
>>
>> Regards,
>> Kashyap
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Claus Reinke
In reply to this post by C K Kashyap
> I have the opportunity to make a presentation to folks (developers and
> managers) in my organization about Haskell - and why it's important - and
> why it's the only way forward.

Haskell is important, but not the only way forward. Also, there have been
other great languages, with limited impact - incorporating great ideas is
no guarantee for takeup. If you want to be convincing, you need to be
honest.

> 1. Any thoughts around the outline of the presentation - target audience
> being seasoned imperative programmers who love and live at the pinnacle of
> object oriented bliss.

If you approach this from the Haskell side (what is Haskell good at),
you might get some people curious, but you won't connect their interest
to their daily work. You don't want to give them a show, you want to
inspire them to want to try coding in that language.

If you really want to understand what is good about Haskell, stop using
it for a while, and work in something like Javascript (or whatever your
audience is comfortable with, but for me Javascript was an eye opener).

You won't believe how basic the issues are that "conventional" coders
are struggling with until you realize that you do not have them in Haskell.

If you have felt that pain, have understood that you can't make those
issues go away by saying "that wouldn't be an issue in Haskell", then
you can understand that their struggles and issues are real.

If you respect that, you can take one of their problems/source bases,
and translate it to Haskell. That step tells them (and you!) that Haskell
is adequate for their problem domains (which won't always be the
case - no point showing them a wonderful language that they won't
be able to apply).

The next step is to go through some of those pain points in that code
and show how to get rid of them in the Haskell version. Instead of
presenting ready-made solutions, show them how to work with code
they understand, much more confidently than they would be used to.

Go slowly, and focus on their daily pain points (which they probably
have stopped feeling because they can't do anything against them).
Explain why you are confident in your modifications, compare against
the obstacles that their current language would throw up against such
modifications. Some examples:

- types can replace basic documentation and documentation lookup

- no need to test things that the type system can check, not in test suites
    and not in the prelude of every function definition; you still need
tests,
    but those can focus on interesting aspects; you don't need to run 10
    minutes of tests to verify that a refactoring in a large code base
hasn't
    broken scoping by misspelling a variable name, or that function calls
    have the proper number and type of parameters

- thanks to decades of development, Haskell's static type system does
    not (usually) prevent you from writing the code you mean (this is
    where the proof comes in - you've rewritten their code in Haskell),
    nor does it clutter the code with type annotations; types of functions
    can be inferred and checked, unlike missing or outdated documentation;

    (careful here: language weaknesses are often compensated for through
    extensive tool usage; some IDEs may check type annotations within
    comments, or try to cover other gaps in dynamic languages)

- part of the trick is to work with the type system instead of against it:
    document intentions in code, not comments

- separation of expressions and statements

- instead of every expression being a statement (side effects everywhere),
    every statement is an expression (functional abstraction works
    everywhere)

- since functional abstraction works everywhere, once you see repeated
    code, you know you can factor it out

- you can build libraries of useful abstractions

- building abstraction libraries in the language is so easy that you
    can build domain-specific abstraction libraries

- domain-specific abstraction libraries become embedded DSLs;
    no need to write parsers, no risk to useful program properties
    from overuse of introspection

- ..

I better stop here - I hope you can see the direction:-)

Many of these do not even touch on the advanced language features,
but all of them rely on the simplicity and careful design of the core
language. All of these advantages carry over to concurrent and
parallel programming, without having to switch to another language.

Also, both functions and threads are so cheap (and controllable in
terms of side-effects) that you do not have to break your head to
avoid using them. And instead of noisy syntax, Haskell's syntax
tends not to get in the way of writing in domain-specific abstractions.

The main advantages of Haskell (as I see them at this moment;-):

- fewer problems to keep track of: can focus on higher-level issues

- great support for abstraction: you can scratch that itch and don't
    have to live with feeling bad about your code; over time, that
    means accumulating reusable ideas and expertise, *in code*,
    and concise solutions to complex problems

- domain-specific languages: the language does not get in the way

- broad base functionality to build abstractions on (graphics, speed,
    concurrency, parallelism, web, ..)

Much of this has only been possible through no-compromise
adherence to design principles in a from-scratch design, starting
with a narrow and supportive user base. Other language
committees also have very experienced members, but they can
not evolve the language as they'd like without breaking real-world
code.

Following the es-discuss list (EcmaScript) can be enlightening,
and saddening, in this respect. Haskell has been moving out into the
real world, and is now starting to feel the pains, but it has had much
better starting conditions for its design, so it still comes out ahead
(but it doesn't yet run everywhere Javascript runs, for instance).

None of this is tested with audiences, just personal opinions, from
personal experience!-) I just wanted to offer an alternative view to
the usual approach of Haskell evangelism.

I assume this isn't quite what you hoped to hear, but I hope it helps.
Claus
 


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

C K Kashyap
Thank you all very much,

I am sitting now and collating all your responses. I'll revert with questions if I may have.

Indeed, it may be better to have this kind of collateral ready for future use.

I am going to put my stuff on github .... considering markdown + pandoc.

Regards,
Kashyap

On Sat, Jun 2, 2012 at 3:06 AM, Claus Reinke <[hidden email]> wrote:
I have the opportunity to make a presentation to folks (developers and
managers) in my organization about Haskell - and why it's important - and
why it's the only way forward.

Haskell is important, but not the only way forward. Also, there have been
other great languages, with limited impact - incorporating great ideas is
no guarantee for takeup. If you want to be convincing, you need to be honest.


1. Any thoughts around the outline of the presentation - target audience
being seasoned imperative programmers who love and live at the pinnacle of
object oriented bliss.

If you approach this from the Haskell side (what is Haskell good at),
you might get some people curious, but you won't connect their interest
to their daily work. You don't want to give them a show, you want to
inspire them to want to try coding in that language.

If you really want to understand what is good about Haskell, stop using
it for a while, and work in something like Javascript (or whatever your
audience is comfortable with, but for me Javascript was an eye opener).

You won't believe how basic the issues are that "conventional" coders
are struggling with until you realize that you do not have them in Haskell.

If you have felt that pain, have understood that you can't make those
issues go away by saying "that wouldn't be an issue in Haskell", then
you can understand that their struggles and issues are real.

If you respect that, you can take one of their problems/source bases,
and translate it to Haskell. That step tells them (and you!) that Haskell
is adequate for their problem domains (which won't always be the
case - no point showing them a wonderful language that they won't
be able to apply).

The next step is to go through some of those pain points in that code
and show how to get rid of them in the Haskell version. Instead of
presenting ready-made solutions, show them how to work with code
they understand, much more confidently than they would be used to.

Go slowly, and focus on their daily pain points (which they probably
have stopped feeling because they can't do anything against them).
Explain why you are confident in your modifications, compare against
the obstacles that their current language would throw up against such
modifications. Some examples:

- types can replace basic documentation and documentation lookup

- no need to test things that the type system can check, not in test suites
  and not in the prelude of every function definition; you still need tests,
  but those can focus on interesting aspects; you don't need to run 10
  minutes of tests to verify that a refactoring in a large code base hasn't
  broken scoping by misspelling a variable name, or that function calls
  have the proper number and type of parameters

- thanks to decades of development, Haskell's static type system does
  not (usually) prevent you from writing the code you mean (this is
  where the proof comes in - you've rewritten their code in Haskell),
  nor does it clutter the code with type annotations; types of functions
  can be inferred and checked, unlike missing or outdated documentation;

  (careful here: language weaknesses are often compensated for through
  extensive tool usage; some IDEs may check type annotations within
  comments, or try to cover other gaps in dynamic languages)

- part of the trick is to work with the type system instead of against it:
  document intentions in code, not comments

- separation of expressions and statements

- instead of every expression being a statement (side effects everywhere),
  every statement is an expression (functional abstraction works
  everywhere)

- since functional abstraction works everywhere, once you see repeated
  code, you know you can factor it out

- you can build libraries of useful abstractions

- building abstraction libraries in the language is so easy that you
  can build domain-specific abstraction libraries

- domain-specific abstraction libraries become embedded DSLs;
  no need to write parsers, no risk to useful program properties
  from overuse of introspection

- ..

I better stop here - I hope you can see the direction:-)

Many of these do not even touch on the advanced language features,
but all of them rely on the simplicity and careful design of the core
language. All of these advantages carry over to concurrent and
parallel programming, without having to switch to another language.

Also, both functions and threads are so cheap (and controllable in
terms of side-effects) that you do not have to break your head to
avoid using them. And instead of noisy syntax, Haskell's syntax
tends not to get in the way of writing in domain-specific abstractions.

The main advantages of Haskell (as I see them at this moment;-):

- fewer problems to keep track of: can focus on higher-level issues

- great support for abstraction: you can scratch that itch and don't
  have to live with feeling bad about your code; over time, that
  means accumulating reusable ideas and expertise, *in code*,
  and concise solutions to complex problems

- domain-specific languages: the language does not get in the way

- broad base functionality to build abstractions on (graphics, speed,
  concurrency, parallelism, web, ..)

Much of this has only been possible through no-compromise
adherence to design principles in a from-scratch design, starting
with a narrow and supportive user base. Other language
committees also have very experienced members, but they can
not evolve the language as they'd like without breaking real-world
code.

Following the es-discuss list (EcmaScript) can be enlightening,
and saddening, in this respect. Haskell has been moving out into the
real world, and is now starting to feel the pains, but it has had much
better starting conditions for its design, so it still comes out ahead
(but it doesn't yet run everywhere Javascript runs, for instance).

None of this is tested with audiences, just personal opinions, from
personal experience!-) I just wanted to offer an alternative view to
the usual approach of Haskell evangelism.

I assume this isn't quite what you hoped to hear, but I hope it helps.
Claus




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Need inputs for a Haskell awareness presentation

Johan Holmquist
Maybe too late but here it is:

I was given a similar opportunity recently, but with only developers
in the audience (no managers), so I focused on coding examples and
functional programming in general rather than Haskell in particular
(although all code examples were Haskell).

One thing I tried to do was crushing the myth (?) that functional
programming is more difficult than imperative by showing an example of
typical imperative code and it's functional mate. I was afraid this
would not fly well because the particular code example was the
fibonacci sequence (it was the shortest most to the point example I
could think of then)[1]. To my surprise it was fairly well received
and I believe the point got through.

Other more real world code examples where shown (counting word
frequencies in a text file etc), introducing folding and mapping and
the ever useful list.


If I was to do this again, given the experience, I would try focus
more on the types of functions, to show how much can be learned about
a function's behaviour by just lookup at it's type. I feel this got
lost in my presentation due to me utilising type reconstruction to
show how writing code in a staticaly typed FPL like Haskell resembles
coding in scripting languages (succintness) but with the compiler
helping spot many errors.

Time is the obvious enemy when introducing an imperative audience to
FP. Code is mostly uninteresting for an audience who do not understand
it, so you may need to explain HOF:s, algebraic data types,  currying
(for Haskell) and maybe point free style, the ring operator etc. This
can easily steal the whole time slot if you are not careful.


I agree that using GHCI is very good, but I think you should be
careful if using emacs' ghci integration so the audience do not
believe interaction is only possible through emacs.


Best wishes!
/Johan


[1] Showing both the memoized zipWith version and the non-memoized and
incredibly inefficient version, explaining the difference.

2012/6/2 C K Kashyap <[hidden email]>:

> Thank you all very much,
>
> I am sitting now and collating all your responses. I'll revert with
> questions if I may have.
>
> Indeed, it may be better to have this kind of collateral ready for future
> use.
>
> I am going to put my stuff on github .... considering markdown + pandoc.
>
> Regards,
> Kashyap
>
>
> On Sat, Jun 2, 2012 at 3:06 AM, Claus Reinke <[hidden email]>
> wrote:
>>>
>>> I have the opportunity to make a presentation to folks (developers and
>>> managers) in my organization about Haskell - and why it's important - and
>>> why it's the only way forward.
>>
>>
>> Haskell is important, but not the only way forward. Also, there have been
>> other great languages, with limited impact - incorporating great ideas is
>> no guarantee for takeup. If you want to be convincing, you need to be
>> honest.
>>
>>
>>> 1. Any thoughts around the outline of the presentation - target audience
>>> being seasoned imperative programmers who love and live at the pinnacle
>>> of
>>> object oriented bliss.
>>
>>
>> If you approach this from the Haskell side (what is Haskell good at),
>> you might get some people curious, but you won't connect their interest
>> to their daily work. You don't want to give them a show, you want to
>> inspire them to want to try coding in that language.
>>
>> If you really want to understand what is good about Haskell, stop using
>> it for a while, and work in something like Javascript (or whatever your
>> audience is comfortable with, but for me Javascript was an eye opener).
>>
>> You won't believe how basic the issues are that "conventional" coders
>> are struggling with until you realize that you do not have them in
>> Haskell.
>>
>> If you have felt that pain, have understood that you can't make those
>> issues go away by saying "that wouldn't be an issue in Haskell", then
>> you can understand that their struggles and issues are real.
>>
>> If you respect that, you can take one of their problems/source bases,
>> and translate it to Haskell. That step tells them (and you!) that Haskell
>> is adequate for their problem domains (which won't always be the
>> case - no point showing them a wonderful language that they won't
>> be able to apply).
>>
>> The next step is to go through some of those pain points in that code
>> and show how to get rid of them in the Haskell version. Instead of
>> presenting ready-made solutions, show them how to work with code
>> they understand, much more confidently than they would be used to.
>>
>> Go slowly, and focus on their daily pain points (which they probably
>> have stopped feeling because they can't do anything against them).
>> Explain why you are confident in your modifications, compare against
>> the obstacles that their current language would throw up against such
>> modifications. Some examples:
>>
>> - types can replace basic documentation and documentation lookup
>>
>> - no need to test things that the type system can check, not in test
>> suites
>>   and not in the prelude of every function definition; you still need
>> tests,
>>   but those can focus on interesting aspects; you don't need to run 10
>>   minutes of tests to verify that a refactoring in a large code base
>> hasn't
>>   broken scoping by misspelling a variable name, or that function calls
>>   have the proper number and type of parameters
>>
>> - thanks to decades of development, Haskell's static type system does
>>   not (usually) prevent you from writing the code you mean (this is
>>   where the proof comes in - you've rewritten their code in Haskell),
>>   nor does it clutter the code with type annotations; types of functions
>>   can be inferred and checked, unlike missing or outdated documentation;
>>
>>   (careful here: language weaknesses are often compensated for through
>>   extensive tool usage; some IDEs may check type annotations within
>>   comments, or try to cover other gaps in dynamic languages)
>>
>> - part of the trick is to work with the type system instead of against it:
>>   document intentions in code, not comments
>>
>> - separation of expressions and statements
>>
>> - instead of every expression being a statement (side effects everywhere),
>>   every statement is an expression (functional abstraction works
>>   everywhere)
>>
>> - since functional abstraction works everywhere, once you see repeated
>>   code, you know you can factor it out
>>
>> - you can build libraries of useful abstractions
>>
>> - building abstraction libraries in the language is so easy that you
>>   can build domain-specific abstraction libraries
>>
>> - domain-specific abstraction libraries become embedded DSLs;
>>   no need to write parsers, no risk to useful program properties
>>   from overuse of introspection
>>
>> - ..
>>
>> I better stop here - I hope you can see the direction:-)
>>
>> Many of these do not even touch on the advanced language features,
>> but all of them rely on the simplicity and careful design of the core
>> language. All of these advantages carry over to concurrent and
>> parallel programming, without having to switch to another language.
>>
>> Also, both functions and threads are so cheap (and controllable in
>> terms of side-effects) that you do not have to break your head to
>> avoid using them. And instead of noisy syntax, Haskell's syntax
>> tends not to get in the way of writing in domain-specific abstractions.
>>
>> The main advantages of Haskell (as I see them at this moment;-):
>>
>> - fewer problems to keep track of: can focus on higher-level issues
>>
>> - great support for abstraction: you can scratch that itch and don't
>>   have to live with feeling bad about your code; over time, that
>>   means accumulating reusable ideas and expertise, *in code*,
>>   and concise solutions to complex problems
>>
>> - domain-specific languages: the language does not get in the way
>>
>> - broad base functionality to build abstractions on (graphics, speed,
>>   concurrency, parallelism, web, ..)
>>
>> Much of this has only been possible through no-compromise
>> adherence to design principles in a from-scratch design, starting
>> with a narrow and supportive user base. Other language
>> committees also have very experienced members, but they can
>> not evolve the language as they'd like without breaking real-world
>> code.
>>
>> Following the es-discuss list (EcmaScript) can be enlightening,
>> and saddening, in this respect. Haskell has been moving out into the
>> real world, and is now starting to feel the pains, but it has had much
>> better starting conditions for its design, so it still comes out ahead
>> (but it doesn't yet run everywhere Javascript runs, for instance).
>>
>> None of this is tested with audiences, just personal opinions, from
>> personal experience!-) I just wanted to offer an alternative view to
>> the usual approach of Haskell evangelism.
>>
>> I assume this isn't quite what you hoped to hear, but I hope it helps.
>> Claus
>>
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe