Re: [Haskell] pros and cons of static typing and side effects ?
Hi folks, have you read this paper: http://www-i2.informatik.rwth-aachen.de/Staff/Current/michaelw/sttt-ml-haske... It contains descriptions of lots of real-world problems and how easily they are solved with Haskell (and ML, because the paper compares the two languages). Among other things it touches on the static typing pros and cons in a way that anyone who ever did serious programming will understand. vlcak
Martin Vlk
http://www-i2.informatik.rwth-aachen.de/Staff/Current/michaelw/sttt-ml-haske...
Interesting to see others' experiences, even if they are slightly negative.
It contains descriptions of lots of real-world problems and how
They are only implementing TRUTH and CWB, no?
Among other things it touches on the static typing pros and cons
One critique against the paper is that they discuss language features at great length, but conclude that: | However, it turned out in our discussions that none of us were | enthusiastic about the idea of using a functional language for a | future verification tool because of their impoverished environments | compared with mainstream programming languages. I would like to see more discussion of what is "impoverished" about the environments, and what they consider "mainstream programming languages". Certainly the authors could have discussed this in the main part of the paper? | Our impression was that SML and Haskell can play out their | advantages mainly in the prototyping stages of a project, an arena | where both would have to compete with dynamic languages like Lisp or | Smalltalk, or scripting languages like Python (which have faster | turn-aroundcycles due to absence of a compilation phase). I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*). Disclaimer: I just browsed quickly through the paper. -k -- If I haven't seen further, it is by standing in the footprints of giants
On pondělí 29 srpna 2005 8:57, Ketil Malde wrote:
It contains descriptions of lots of real-world problems and how
They are only implementing TRUTH and CWB, no?
Yes, and lots of real-world situations that they faced during the development. That's what I meant.
I would like to see more discussion of what is "impoverished" about the environments, and what they consider "mainstream programming languages". Certainly the authors could have discussed this in the main part of the paper?
Please read section 5 in the paper.
I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*).
I am very sure they are aware of them. Interactive interpreters are simply not enough of a tool for commercial development - more sophisticated tools are necessary. In Haskell we don't even have basic things like code structure visualisation, efficient browsing and fully language-aware editor with typing support etc. This is one of the ways of distinguishing the mainstream languages. Mainstream means that enough people use them for someone to put in the effort to build the tools. vlcak
Martin Vlk wrote:
On pondělí 29 srpna 2005 8:57, Ketil Malde wrote:
It contains descriptions of lots of real-world problems and how
They are only implementing TRUTH and CWB, no?
Yes, and lots of real-world situations that they faced during the development. That's what I meant.
I would like to see more discussion of what is "impoverished" about the environments, and what they consider "mainstream programming languages". Certainly the authors could have discussed this in the main part of the paper?
Please read section 5 in the paper.
I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*).
I am very sure they are aware of them. Interactive interpreters are simply not enough of a tool for commercial development - more sophisticated tools are necessary. In Haskell we don't even have basic things like code structure visualisation, efficient browsing and fully language-aware editor with typing support etc. This is one of the ways of distinguishing the mainstream languages. Mainstream means that enough people use them for someone to put in the effort to build the tools.
I have used IDEs (Borlands delphi, MS VisualC++), and I prefer working with 'vi' and multiple shell windows. vi has such a quick startup time that you can swap between files easily, and it does syntax highlighting of many languages including Haskell. Some of the languages mentioned (Python) also have no real IDE, so that kind of undermines the point. I have written commerical code in many languages (including Haskell) and I work the same way for all of them. The closest anyone in my company comes to an IDE is python programming in Zope... As for debugging I have yet to find a situation that a debugger handles better than a couple of carefully places output statements. If you want to inspect the values of variables in a loop thats going wrong, just output them, and redirect the program output to a file... you can then run the program and inspect the resulting dataset to daignose the problem. Regards, Keean.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Keean Schupke -
Ketil Malde -
Martin Vlk