8th GhentFPG meeting: problem solving part

[Jasper Van der Jeugt]

Hello all,

I thought it would be fun if we would dump our solutions to
yesterday's problem somewhere. I've uploaded the solution by Pieter
and me here [1]. I'll have to admit that I have cleaned up a little,
removing unused functions and adding comments.

Secondly, we're also interested in hearing any feedback w.r.t. the
problem solving part. The strategy Jeroen and I discussed yesterday
would be that we will always try to include a (small) problem solving
part, unless we find 3 or more speakers. Any thoughts?

[1] http://gist.github.com/1058151

Cheers,
Jasper

[Luc TAESCH]

I d like quite a lot the idea of probleme solving, especially if it is
reasonably time bounded, and we can share the variety of approach
afterwards.

Also I was looking around me of how people approach the problem, some
starting with types, other with algorithm or adt..
(It myself got me into buying the Okasaki book on the way back and
finally reading it...)

I see the main value, not in finding who is the smartest, or the
fastest, etc, but in the diversity of the approach, and how we
approach the problem.

that would mean not waiting for a definitive solution to share ideas
or approach, but maybe once enogh time is spend fiddling, have a
sharing session on how we approach things and how we would tackle the
problem, ( even if unfinished).

What do you think ?

[Dieter Houthooft]

> Secondly, we're also interested in hearing any feedback w.r.t. the
> problem solving part. The strategy Jeroen and I discussed yesterday
> would be that we will always try to include a (small) problem solving
> part, unless we find 3 or more speakers. Any thoughts?

I find the "problem solving" very interesting if it keeps focus on the implementation of the solution instead of finding the solution(s). Finding solutions is fun, but maybe a waste of time in a functional programming meeting. What I found interesting: your use of a map and a Monoid for implementing your solution. My personal experience from the VPW is that more time is lost by getting for example the backtracking right rather than figuring out that you need backtracking.

So maybe a speaker needs to solve the problem before the meeting and at the meeting present an implementation which demonstrates the use of some pattern or typeclass. Because of my still very limited Haskell experience I would also find it interesting if this were to be done for more mundane software engineering problems, for example: creating a runtime plugin system for your software, library design, ...

Dieter.

[Luc TAESCH]

btw, the time issue also strikes me. espsecially for people with a
train with limited option after 22( like me), i would prefer hearing
rather than searching, on the meeting site at least

btw, why not publish it before the meeting, and at the meting we come
and All present either
- solutions ( algo/ adt/ ..)
- or implementations..

is it not an exam or a contest anyway, is it ?

the sharing and variety of approach shoud enrich all of us, bearing in
mind that the level of knowledge of haskell varies a lot and everybody
should take a litle something home..

and if some just come and listen , and cannot share anything yet,
thats fine too...

[Jeroen Janssen]

Ok, so I would propose that we post a problem a couple of days before the meeting. Then, at the meeting we give a short presentation and give everyone some extra time to think of a possible solution (without implementation), so people who didn't have time to look at the question can still think a bit about a possible solution first. After the thinking time we have some people present their solutions and can have a bit of a discussion on solution methods.

[Luc TAESCH]

sounds cool .
and I personally would be interested into a bit a meta thinking.
if people could tell "how" they came to the conclusion(s)..;

- how did I came to the solution ?
( did I wrote first adt ? algo ? data type ? )
- did I created test cases ?
- did I wrote down things ? invariant ? diagrams ?
- did I prototype ?

ie if people can watch themself thinking, that would be cool too..

(It is not so much about method or process "formally", but I do
intuition that FP leads to another "method" of thinking than
imperative, and it is "implicit" for people involved long enough. Lets
try and make it explicit? at least jsut share bet practice ?)