Hello haskellers, I have been following this list's debates for a while and I am very enthusiastic about functional programming in general and haskell in particular. I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job. The project is a Point-of-sale distributed management system with the following (non-exhaustive) list of features : - rich GUI clients (on windows platform) to allow optimizing users input speed. There will about 50-60 'screens' and half as many 'reports', - local database with possibility to replicate and aggregate data, - central repository for aggregated data, aggregation should be synchronous but may fail due to poor network connectivity, - ease of deployment/update for new versions or modules, - secured (authenticated and encrypted) communications between nodes, - ... All in all, this project is quite typical of a small to medium sized business information system which is commonplace in software services. There are no stringent performance requirements nor extraordinary functional features or tricky algorithms, but the allocated time-frame (and money :-)) is quite small and I would like to optimize design and coding time to concentrate on user acceptance, deployment and testing issues. Java and object-oriented 'paradigm' is nearly hardwired in my brain so I expect quite a painful learning process to shift towards thinking in functional terms: I know quite well the theory but never did I put it to use on a significant scale. More profoundly, I am asking myself whether this investment will be really worthwhile for this kind of software. I have read with joy and amazement S.P.Jones "Composing contracts: an adventure in financial engineering" and P.Hudak's "An experiment in software prototyping productivity", but I have also followed the discussions with J.Reymont about its poker server tester and read "Haskell vs. Erlang, Reloaded". I am not asking anyone to 'sell' me Haskell, that would be like selling ice to a penguin as I am already convinced Haskell is really interesting in itself. And I am willing to do some investment in time and money to use Haskell at the expense of another simpler but less elegant solution (read Java :-)). I would be very happy to have some feedback about these issues, regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr
Arnaud Bailly wrote:
I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job.
One snag is that I doubt you could ring up an agency and ask for half a dozen Haskell programmers. You could probably get people who did a bit of functional programming as part of a computer science degree, but that may not be enough for your needs. (Having said that, if you did manage to find contract Haskell programmers, you would probably get people who were highly skilled, and enthusiastic about the chance to use the language.) In other words, Haskell might be a good answer technically, but it could paint the client into a corner business-wise. I currently have a small amount of business logic that is implemented in Haskell, and I want to see it increase, but I'm always worried that this is going to happen. I don't want a job for life maintaining this stuff, I want to delegate it to others at an appropriate time.
All in all, this project is quite typical of a small to medium sized business information system which is commonplace in software services.
You might find that Java, for example, would have more support for this type of application, out of the box. Although Java is an unimaginative language, I find that productivity isn't too bad, mainly because there is plenty of library support for typical applications. With Haskell, writing the business logic is quicker, but some of the time saved gets spent implementing things that come as standard with Java.
Java and object-oriented 'paradigm' is nearly hardwired in my brain so I expect quite a painful learning process to shift towards thinking in functional terms: I know quite well the theory but never did I put it to use on a significant scale.
I'm finding this quite a struggle, to be honest. I can cope easily with the various homework assignments that get posted here, but I find it hard thinking about large applications in functional terms. I'm building up to larger applications, but I'd feel nervous tackling something the size you are talking about at the moment. Pete
Pete Chown <1@234.cx> writes:
Arnaud Bailly wrote:
I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job.
One snag is that I doubt you could ring up an agency and ask for half a dozen Haskell programmers. You could probably get people who did a bit of functional programming as part of a computer science degree, but that may not be enough for your needs. (Having said that, if you did manage to find contract Haskell programmers, you would probably get people who were highly skilled, and enthusiastic about the chance to use the language.)
In other words, Haskell might be a good answer technically, but it could paint the client into a corner business-wise.
Good point. I did not talk about that, but I feel I will have a hard time selling Haskell as implementation language if I cannot back this approach with something consistent. Skill shortage may definitely be an issue as well as technical dead end.
You might find that Java, for example, would have more support for this type of application, out of the box. Although Java is an unimaginative language, I find that productivity isn't too bad, mainly because there is plenty of library support for typical applications. With Haskell, writing the business logic is quicker, but some of the time saved gets spent implementing things that come as standard with Java.
I have actually done most of my programming work (~300kloc) with Java for the past 8 years, and I although I have become acquainted with the intricacies of the language, the platform, the numerous libraries and even the bytecode, I have never loved that language ! I found it really unexpressive, the type system is neither useful nor safe, it is really verbose and does not lend itself to idiomatic programmming style... It's greatest advantage lies in the power that reflection and introspection has to offer for tool and libraries builder, but it is tricky. As said by Bulat Ziganshin, Java's as well as other mainstream languages superiority when it comes to software systems development lies in the numerous libraries, tools and IDEs that alleviate some of the pain of implementing a system. But my experiences lead me to thing that they are in the end inadequate and expensive. I am dreaming awake that Haskell's versatility, safety and expresiveness could allow me to quickly build tools that could generate system components instead of coding them. I am thinking about an approach based on a sort of DSL design with Haskell then code/bytecode generation to Java/whatever platform. Does anybody have experiences with that, particularly for GUI parts ? regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr
instead of coding them. I am thinking about an approach based on a sort of DSL design with Haskell then code/bytecode generation to Java/whatever platform.
Yhc can generate a portable bytecode, and it can also generate .NET bytecode (IL), and there was a project underway to generate Java (JVM) bytecode. There is a Java interpetter and a python interpetter for Yhc bytecode as well (and of course a C one). Thanks Neil
On Tue, Mar 28, 2006 at 07:09:40PM +0200, Arnaud Bailly wrote:
I am dreaming awake that Haskell's versatility, safety and expresiveness could allow me to quickly build tools that could generate system components instead of coding them. I am thinking about an approach based on a sort of DSL design with Haskell then code/bytecode generation to Java/whatever platform. Does anybody have experiences with that, particularly for GUI parts ?
This is my dream too :-) My area is data processing. Most of my programs can afford quite a long initialisation phase, but then are required to process huge amounts of data. I am thinking about using that initialisation phase to generate C/C++ code from Haskell and compile it. This would allow me to move most of the more complicated logic to Haskell. I just hate writing parsers and the like in C++. Perhaps there is a chance for cooperation? BTW, I think it would be nice if we could use Template Haskell quoting facilities for generating code in languages other than Haskell. Best regards Tomasz
Tomasz Zielonka
Perhaps there is a chance for cooperation?
That would be a pleasure for me. I must stress that my knowledge of Haskell is purely theoretical, the only thing I ever programmed *with* Haskell was a small automata package. I have however good knowledge of the language itself (I wrote a parser for it), of its semantics and of low to intermediate level (lazy) functional programming features. I also have some knowledge of part of the theory behind haskell's type system, I understand monads, both from a practical (why it is usefeul) and a theoretical (where it comes from and why it works) point of view. As I said before, I have the intuition that Haskell should be most useful as a tool for something like executable design and specification, as it is obviously a tool of choice for producing correct code thanks to strong type system, and it has nice features for working with languages, grammars, automatas ... I don't see it as a workhorse language for programming mundane tasks like producing tens or hundreds of simple business services and processes: looking for an article, creating a sale, registering articles with it, ... I have in mind (and a bit in java code) an architecture where you would have business services hardwired and packaged, for example in C or Java. These services would be composed - possibly transactionnaly - through business processes described using a high-level language, with possible transformations/adaptations at deploy or run-time. The processes could be generated to any technological platform using kind of automata/graph traversal/encoding, with the communication medium automatically processed. The presentation layer, would be handcoded or designed with RAD tools and wired to processes. I have some small parts of this process in Java and took me a lot of efforts, I think that HAskell has built-in capabilities to do part of what I want out-of-the-box and libraries for building upon. But I am not sure this vision is true and it could be articulated in the time frame of a real-world project.
BTW, I think it would be nice if we could use Template Haskell quoting facilities for generating code in languages other than Haskell.
Sure. Looks very interesting, sort of OO reflexion at compile time ?
Best regards Idem.
BTW, are you the Tomasz Zielonka of the asynchronous automata ? -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr
On Fri, Mar 31, 2006 at 03:09:07PM +0200, Arnaud Bailly wrote:
BTW, are you the Tomasz Zielonka of the asynchronous automata ?
Probably not, because I don't know what they are :-) I just googled for 'asynchronous automata zielonka', and found Wieslaw Zielonka, who was publishing papers on this topic when I was in primary school. And no, I don't know this person. IIRC, "Zielonka" is something like 350th most popular surname in Poland. Best regards Tomasz
Pete Chown <1@234.cx> writes:
One snag is that I doubt you could ring up an agency and ask for half a dozen Haskell programmers. You could probably get people who did a bit of functional programming as part of a computer science degree, but that may not be enough for your needs. (Having said that, if you did manage to find contract Haskell programmers, you would probably get people who were highly skilled, and enthusiastic about the chance to use the language.)
Me me! Pick me! Oh I'd love to do contract work with Haskell.
In other words, Haskell might be a good answer technically, but it could paint the client into a corner business-wise.
I could easily come up with a bunch of resumes or CVs from smart #haskell people who would enjoy doing contract work in Haskell. (where bunch = at least ten, and probably more than twenty)
I currently have a small amount of business logic that is implemented in Haskell, and I want to see it increase, but I'm always worried that this is going to happen. I don't want a job for life maintaining this stuff, I want to delegate it to others at an appropriate time.
Me me! Pick me!
You might find that Java, for example, would have more support for this type of application, out of the box. Although Java is an unimaginative language, I find that productivity isn't too bad, mainly because there is plenty of library support for typical applications. With Haskell, writing the business logic is quicker, but some of the time saved gets spent implementing things that come as standard with Java.
Libraries need to be implemented only once, after that everything gets faster. Plus there's a lot more Haskell code out there than most people know about. If you're looking for something specific, ask on the #haskell channel or here on the mailing lists.
I'm finding this quite a struggle, to be honest. I can cope easily with the various homework assignments that get posted here, but I find it hard thinking about large applications in functional terms. I'm building up to larger applications, but I'd feel nervous tackling something the size you are talking about at the moment.
I'm fond of monad transformers for structuring larger applications. More details upon request... -- I've tried to teach people autodidactism, | ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson
Hello Arnaud, Tuesday, March 28, 2006, 3:58:53 PM, you wrote:
The project is a Point-of-sale distributed management system with the following (non-exhaustive) list of features : - rich GUI clients (on windows platform) to allow optimizing users input speed. There will about 50-60 'screens' and half as many 'reports', - local database with possibility to replicate and aggregate data, - central repository for aggregated data, aggregation should be synchronous but may fail due to poor network connectivity, - ease of deployment/update for new versions or modules, - secured (authenticated and encrypted) communications between nodes, - ...
it is interesting that i have about the same, Store&Sales-type application, that is written in Delphi and maintained as long as several years. Commercial environments like the Delphi has great built-in support for such typical apps, including GUI/Database/Networking libs, deployment support and so on. so, with "old languages" you will have the "fast start" and full-featured environment that greatly helps in developing gui and database part, at least. with Haskell, on other side, you will actually "reinvent the wheel" because you should start with implementing all the high-level interfaces that you need. But once you implement all these "wheels", you will be more productive than with "old languages", at least when you just write the code. of course, you will not get all the benefits of highly-integrated IDE, such as visual GUI/database development, step-by-step debugging and even project management. if someone else should work with this project, you will need to teach him Haskell. my opinion is what Haskell/ghc currently can be used for standard commercial apps (gui/databases/networking) only if you are Haskell enthusiast and interested both in using Haskell and in improving it's environment (it's rather obvious that results of your work will be at least new Haskell libs that can be used by you and other Haskellers to simplify implementation of such apps. may be you will even improve something in Haskell programming environments). development will be slower and more expensive at least first several years until you are established your production environment (reinvent all the wheels). but if you love Haskell and anyway want to hack it, you can prefer to do it as a part of your work ;) you may wonder, but not anything in this world is measured in money ps: btw, Joel's program was ideal for Haskell/ghc because it don't used gui and databases, but required high speed and high level of concurrency. But of course it was not a newbie mission, so he was successful only as long as other Haskellers consulted him how to implement tricky parts. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (6)
-
Arnaud Bailly -
Bulat Ziganshin -
Neil Mitchell -
Pete Chown -
Shae Matijs Erisson -
Tomasz Zielonka