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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
