Re: [Haskell-cafe] Small flexible projects a possible niche for Haskell - your statement, please...
Paul, this is what we are interested in... :-) Taken that Haskell has lots of combinator constructs on various levels as you said -- might I ask what are your personal favourites among them...? Your mentioning of early coding initiative taken domain experts and programmers in one person for early demand strongly reminds me of our concepts of knowledge techniques -- it is my hope that this is possible. Thanks a lot, Nick Paul Johnson wrote: On 16/07/10 05:41, Nick Rudnick wrote: In consequence, an 8-student-project with two B.Sc. theses is raised as a pilot to examine the possibilities of using Haskell in the combination small team with limited resources and experience in a startup setting - we want to find out whether Haskell can be an offer competitive whith languages like Ruby Co. in such a setting. I'm not sure exactly what you are asking, but I'm going to try to answer the question Does Haskell have a niche in small, flexible projects? I think the answer is a definite yes. I also think that Haskell can do great things in bigger projects as well, but successful technologies often start out with a niche that was previously poorly served, and then move out from there. Haskell developers generally start by writing down an axiomatic definition of the problem domain. To a developer raised in traditional top down development this looks like a jump into coding, and furthermore coding at the lowest level. In fact it is a foundation step in the architecture, because Haskell works well with a bottom up approach. The property that makes this work is composability, which says that you can take primitive elements and integrate them into bigger units without having to worry about mutual compatibility. A Haskell library will typically define a data type Foo and then have functions with types along the lines of mungFoo :: Something - Foo - Foo. This combinator style of library give you the basic building blocks for manipulating Foos, along with a guarantee that the output will always be a valid Foo. So you can build up your own applications that work at the Foo level rather than down in the coding level of flow control and updated variables like conventional programs. This lets domain experts read and comment on the code, which reduces defect rates a lot. But these combinator libraries are also highly reusable because they describe an entire domain rather than just being designed to fit a single application. So the best bet is to analyse a domain, write a combinator library that models the domain, and then produce a series of related programs for specific applications within that domain. That will let a small team be amazingly productive. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small flexible projects a possible niche for Haskell - your statement, please...
On 16/07/10 05:41, Nick Rudnick wrote: In consequence, an 8-student-project with two B.Sc. theses is raised as a pilot to examine the possibilities of using Haskell in the combination small team with limited resources and experience in a startup setting - we want to find out whether Haskell can be an offer competitive whith languages like Ruby Co. in such a setting. I'm not sure exactly what you are asking, but I'm going to try to answer the question Does Haskell have a niche in small, flexible projects? I think the answer is a definite yes. I also think that Haskell can do great things in bigger projects as well, but successful technologies often start out with a niche that was previously poorly served, and then move out from there. Haskell developers generally start by writing down an axiomatic definition of the problem domain. To a developer raised in traditional top down development this looks like a jump into coding, and furthermore coding at the lowest level. In fact it is a foundation step in the architecture, because Haskell works well with a bottom up approach. The property that makes this work is composability, which says that you can take primitive elements and integrate them into bigger units without having to worry about mutual compatibility. A Haskell library will typically define a data type Foo and then have functions with types along the lines of mungFoo :: Something - Foo - Foo. This combinator style of library give you the basic building blocks for manipulating Foos, along with a guarantee that the output will always be a valid Foo. So you can build up your own applications that work at the Foo level rather than down in the coding level of flow control and updated variables like conventional programs. This lets domain experts read and comment on the code, which reduces defect rates a lot. But these combinator libraries are also highly reusable because they describe an entire domain rather than just being designed to fit a single application. So the best bet is to analyse a domain, write a combinator library that models the domain, and then produce a series of related programs for specific applications within that domain. That will let a small team be amazingly productive. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Small flexible projects a possible niche for Haskell - your statement, please...
Dear all, besides good ambitions in many other areas, it is interesting to see that a great number of present Haskell projects is run by a very small number of persons and even some parts of the usual developer's toolkit, like e.g. Haddock, seem to contribute to it. Has the Haskell culture produced an environment which is especially apt for such development in small groups, possibly with low grade of division of labor? In the last three years at Duisburg-Essen university, very small but application oriented introductions to up to 100 rather non-CS centric students raised an interest whether there might be a such niche for Haskell application -- as there seems to be some evidence that certain perceptions of a steep learning curve of Haskell may be in significant correlation with an already existing imperative language culture. In consequence, an 8-student-project with two B.Sc. theses is raised as a pilot to examine the possibilities of using Haskell in the combination small team with limited resources and experience in a startup setting - we want to find out whether Haskell can be an offer competitive whith languages like Ruby Co. in such a setting. An additional focus is the question inhowfar Haskell might be an enabler in allowing a greater extent of change in the organization, like people coming and going, or choosing new roles -- here we allow to *disregard* the problem of teaching Haskell to innocents to prevent such questions from dominating the whole of the discussion: This might be another project. Our premise is the availability of a sufficient number of people at an mediocre to intermediate level in the environment. We hope this might be interesting to the Haskell community, as Haskell seems to be underrepresented in this regard, and there seem to be active prejudices by the imperative community -- which unfortunately in a positive correlation with general programming experience, to an observing third might lead to an impression that a such rejection of Haskell is a matter of computing competence. Now we -- especially the two students at their B.Sc. thesis, Markus Dönges and Lukas Fisch -- are very interested in your quote, possibly o aspects of Haskell technology you perceive as relevant or helpful, o examples in the Haskell culture / community which might be relevant, o experiences of your own and around you, and *especially*, o language properties,constructs and extensions you would see as enablers in this regard. Thank you very much in advance... :-) Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
