pros and cons of static typing and side effects ?
[thnk 4 the previous answers !] Good [morning, afternoon, night], I try to better understand some things... maybe you can help me. Id' like to know what are the pros and cons of (not) having static typing. Same question for (direct support of) side effects. To help you to find answers, here I quote this page : http://paulgraham.com/lispfaq1.html [Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.] Thanks a lot, minh thu
mt <mtvo@info.fundp.ac.be> writes:
[Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.
I disagree. Static typing in essence gives you a lot of small unit tests for free. When refactoring code, these tests are often sufficient to ensure that the refactored code works. (Other types of errors are usually weeded out in the unfactored code, and not introduced by refactoring) Static typing also gives you the flexibility to juggle compositions of higher order functions; I almost always commit type errors when constructing a largish expression, but when the type errors are weeded out, more often than not the expression works as expected. All IME, of course. -k -- If I haven't seen further, it is by standing in the footprints of giants
Hello mt, Thursday, August 11, 2005, 12:40:39 AM, you wrote: m> [thnk 4 the previous answers !] m> Good [morning, afternoon, night], m> I try to better understand some things... maybe you can help me. m> Id' like to know what are the pros and cons of (not) having static typing. m> Same question for (direct support of) side effects. m> To help you to find answers, here I quote this page : m> http://paulgraham.com/lispfaq1.html m> [Most hackers I know have been disappointed by the ML family. Languages with m> static typing would be more suitable if programs were something you thought m> of in advance, and then merely translated into code. But that's not how m> programs get written. m> The inability to have lists of mixed types is a particularly crippling m> restriction. It gets in the way of exploratory programming (it's convenient m> early on to represent everything as lists), and it means you can't have real m> macros.] i can quote someone from this list: "if haskell compiler allow my program to be compiled then i know that there is no more errors in it". static typing is just an instrument which catches much more programmers' errors. static typing don't allow more programs tobe compiled - conversely, it prohibits a part of programs/techniques. but if you want to WORK, not hack - that is a right way m> Same question for (direct support of) side effects. it's just because Haskell is a lazy language. this rises expresivness and strongly divides program to two parts - without side effects and with side effects -- Best regards, Bulat mailto:bulatz@HotPOP.com
Bulat Ziganshin <bulatz@HotPOP.com> writes:
I can quote someone from this list: "if haskell compiler allow my program to be compiled then I know that there is no more errors in it".
I wish quotes like this weren't bandied about without mentioning that they almost entirely, but not quite, true. Of course many programs that compile have bugs in them! A more accurate statement is that static typing catches a lot of trivial errors, and can be leveraged to make more complex errors less likely to occur and faster to track down. -k -- If I haven't seen further, it is by standing in the footprints of giants
i can quote someone from this list: "if haskell compiler allow my program to be compiled then i know that there is no more errors in it". static typing is just an instrument which catches much more programmers' errors. static typing don't allow more programs tobe compiled - conversely, it prohibits a part of programs/techniques. but if you want to WORK, not hack - that is a right way
yes, that's the kind of answer i expected... that's the kind of thing you always see when reading something about haskell. but i guess there's arguments against... i'd like to make my opinion without just reading a post saying "it catches many errors". maybe this mailing list is not the right place to ask this question ;-) maybe i should ask on a lisp mailing list :)
m> Same question for (direct support of) side effects.
it's just because Haskell is a lazy language. this rises expresivness and strongly divides program to two parts - without side effects and with side effects
the way it's divided is to remain purely functional. would it be bad if the side effects part was designed without keeping a pure functional language ? i see sometimes this kind of arg : it's easier to reason with a pure functional semantic. is this hold when you have to program a fair amount of imperative code in haskell? in fact my first question was not haskell centric but more general, like if i wanted to design a new language, not like if i wondered which language to choose. regards, mt
Hello mt, Thursday, August 11, 2005, 12:09:30 PM, you wrote:
if you want to WORK, not hack - that is a right way
m> yes, that's the kind of answer i expected... that's the kind of thing you m> always see when reading something about haskell. but i guess there's m> arguments against... i'd like to make my opinion without just reading m> a post saying "it catches many errors". you must get more experience in programming in general and try to write the same things in Haskel in particular and then you can make your own conclusion on this part. my conclusion (based on C++, Perl and Ruby experience) is just that i say m> maybe this mailing list is not the m> right place to ask this question ;-) maybe i should ask on a lisp mailing m> list :) haskell-cafe is definitely better place than this list :)
m> Same question for (direct support of) side effects.
it's just because Haskell is a lazy language. this rises expresivness and strongly divides program to two parts - without side effects and with side effects
m> the way it's divided is to remain purely functional. would it be bad if the m> side effects part was designed without keeping a pure functional language ? i think, it is no matter. really, we have purely fucntional part which can be optimized just with mathematical laws, imperative part which can't be so well optmized just because imperative operations creates "optmization barriers" between statements, and unsafePerformIO to those who wants to try optmizing imperative part as functional one m> i see sometimes this kind of arg : it's easier to reason with a pure m> functional semantic. is this hold when you have to program a fair amount of m> imperative code in haskell? i don't reason anything :) while an imperative code is a "fair amount" of my program, complex (functional) computations is a part that takes most time and attention, and contains most bugs. imperative part, after all - is just sequencing of operations performed m> in fact my first question was not haskell centric but more general, like if i m> wanted to design a new language, not like if i wondered which language to m> choose. of course. there is interesting dynamic languages, such as Ruby, but i prefer Haskell over anything i know -- Best regards, Bulat mailto:bulatz@HotPOP.com
At 10:40 PM +0200 2005/8/10, mt wrote:
... Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.
Well, that is actually how lots of programs do get written. For software that is experimental and exploratory, whose code undergoes continual change and whose only users are the code's authors, static typing is arguably a dispensable nuisance. A type error that pops up during execution is probably no more inconvenient than one that's caught by static type checking. That's why Lisp is popular for AI work. On the other hand, for code that is intended for wide distribution, static typing is extremely useful. When a user swipes his card in an ATM, you don't want the machine's response to be "Sorry, type error." A successful static type check amounts to a partial correctness proof, i.e., a guarantee that a large class of possible errors will not occur during execution. That guarantee is worth some inconvenience-- or would be, if static typing were in fact inconvenient. I'd argue, however, that for software that's being written for a specified purpose, and which therefore has a well defined specification, static type checking is a definite convenience-- it automates some of the reasoning that responsible programmers are obliged to undertake in any case. Of course I have to concede that much software that's sold to customers is not actually "thought of in advance", but is developed haphazardly, with inordinate effort expended on "debugging". This regrettable practice no doubt bears much of the blame for the deplorable state of the software industry, which is the only one I know of whose products are routinely sold with a disclaimer of all responsibility for their quality. Regards, --Ham -- ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer (retired) The University of Texas at Austin ham@cs.utexas.edu hrichrds@swbell.net http://www.cs.utexas.edu/users/ham/richards ------------------------------------------------------------------
On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote:
At 10:40 PM +0200 2005/8/10, mt wrote:
... Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.
Well, that is actually how lots of programs do get written.
For software that is experimental and exploratory, whose code undergoes continual change and whose only users are the code's authors, static typing is arguably a dispensable nuisance. A type error that pops up during execution is probably no more inconvenient than one that's caught by static type checking. That's why Lisp is popular for AI work.
I find pretty much completly the opposite is true. for random hacking and evolving code, static typing is essential. There is only so much room in one's brain to keep track of how everything works. if you were meerly translating from a previous design, this isn't so much an issue. but when writing code that is evolving and changing and perhaps you don't quite know how it will turn out, your ability to recall and understand how everything works together is a major limiting factor on the scope of what you can acomplish. Static typing offloads a _ton_ of responsibility away from the programmer. you no longer need to worry or even think about what types are held in variables because you know any mistakes will be caught by the compiler. and with haskell's advanced type system, you can encode much more advanced constraints and invarients in the type system offloading even more work from your brain. Haskell's strong type system made me writing jhc alone possible, not because of the better reliability (that is great though!), but because it let me 'forget' about so many inconsequential details that they type system enforced so I only needed to use brain-space for high level constructs and my overall evolving, changing, plan. I tend to only use perl or other dynamically typed languages when writing something that I know exactly what it will do and how to do it beforehand, because I find it to be quite an inflexible language when it comes to changing code after the fact, not because of any syntatic difficulty, but because you basically have to constantly redervive everything the program does and all the unspoken invarients to understand it and how to change it. which is something that gets super-linearly harder as code size grows. John -- John Meacham - ⑆repetae.net⑆john⑈
G'day all. Quoting John Meacham <john@repetae.net>:
I find pretty much completly the opposite is true. for random hacking and evolving code, static typing is essential.
I agree with that. While you can't be certain that once your code typechecks, it's bug-free (though that does often happen), you can be almost guaranteed that if your code typechecks after a refactoring, the refactoring didn't introduce any bugs. This is a crucial property of "sufficiently typed" languages which I rely on all the time when evolving code. In addition, coming up with typed data structures tends to focus my thinking early. I think it was Dijkstra who commented that he could understand your code much better if you show him your algorithms AND your data structures, rather than showing him your algorithms alone. When programming in a less statically-typed language, I often find myself having to document the structure of the data during the "random hacking" phase anyway, even if I'm only using diagrams on paper. So why not document it in a form that the computer can also understand? One thing I do sympathise with is that programming in a statically typed language is no fun if the type system isn't flexible enough to support serious hacking. You really can feel like you're fighting the type system. Older ML variants (I have particularly bad memories of SML), and older Turner-esque languages for that matter, are no match for Haskell 98 plus Glasgow extensions or O'Caml in this respect. Cheers, Andrew Bromage
mt <mtvo@info.fundp.ac.be> writes:
Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.
Type inferencing gives you 'compile time dynamic typing', so you don't have to think too much in advance. Representing a problem domain with types is roughly equivalent to using objects for the same purpose.
The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.
Haskell has lists of mixed type, see http://homepages.cwi.nl/~ralf/HList/ I think it's more convenient to represent everything as algrebraic datatypes. ADTs are sort of 'semantic lego' in that they represent the shape of the data. For example, the Tree datatype in http://www.haskell.org/hawiki/HaskellDemo : data Tree a = Nil | Node (Tree a) a (Tree a) says that a tree value can be either Nil or a Node that holds two tree values and something else, like Int, String, Double, or whatever you choose. How do lists of mixed types affect macros? Static typing in Haskell doesn't have that many downsides. A type system and checker is a simplified proof assistant implementation. You state certain properties about your program and the system checks for you. You can use the type system heavily, or skip most of the type checking. When I'm writing new code, my approach depends on my knowledge of the problem. Sometimes I ignore the types and just get the code working, and sometimes I write down the type signatures first and figure out the code from there.
From my viewpoint, type systems are one tool in the toolbox, no silver bullet, but at least a multitool :-) -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same.
participants (7)
-
ajb＠spamcop.net -
Bulat Ziganshin -
Hamilton Richards -
John Meacham -
Ketil Malde -
mt -
Shae Matijs Erisson