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?
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 ?
On Fri, Jul 1, 2011 at 11:23 AM, Jasper Van der Jeugt <m...@jaspervdj.be> wrote:
> 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?
> 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, ...
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...
>> 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, ...
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.
> 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...
> On Fri, Jul 1, 2011 at 2:39 PM, Dieter Houthooft > <dieter.houtho...@lin-k.net> wrote:
>>> 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, ...
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 ?)
On Fri, Jul 1, 2011 at 5:13 PM, Jeroen Janssen <jejan...@gmail.com> wrote: > 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.
> On 01 Jul 2011, at 15:35, Luc TAESCH wrote:
>> 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...
>> On Fri, Jul 1, 2011 at 2:39 PM, Dieter Houthooft >> <dieter.houtho...@lin-k.net> wrote:
>>>> 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, ...
