Nando Breiter <na...@aria-media.com> writes: >> > 1. Types are useful for structures that HOLD data (ints, strings, >> > maps, arrays… ) because they provide ways defining standard >> > operations to manipulate data that make sense in the context of >> > that type of data. It is helpful to have a type checker check >> > that I am not accessing the 6th element of a hashmap or that I am >> > adding 10 to "Hello". >> >> This would be useful indeed. Although, a hard core type head would say >> "I want to distinguish between a string that is an email, someones name, >> and a day of the week". This is not unreasonable. >> >> Perhaps some may see this as an oversimplification, but ... > > If you try and add 10 to "Hello" in a typed language, you get an error. If > you try to do the same in a dynamic language, you get an error.
This depends on the type coercions which are available, rather than the static/dynamic type system divide. echo print 10 + "10" | perl 20 for instance. > The only difference seems to be that in a dynamic language, you need > to *run* the code to get the error, rather than compile it. This is a big difference, especially, if the code is hard to test. > As I understand it, in a dynamic language, if you want to check if a string > is an email, you need some function like defn (email? [str]). You'd need > the same in a typed language. To a first approximation, yes, but once you have constructed an "email" type, and got a value into that type, then in a strongly typed language, you know that you have an email. You cannot accidentally pass a string which is not an email by mistake. > I do understand, however, that typed languages are more difficult to learn > and program in, and that the same task can take longer in a typed language. I think "learn" is true. The second conclusion I think is wrong. The joyful experience of passing a map of lists when you were expecting a map of sets, or typing a keyword wrong happens to most people; and it can take a long, long time to find out where. > It also seems to me that it is easier to lose the forest for the trees in a > typed language. When we speak with each other, we don't generally say "The > number 6 plus the number 4 equals the number 10." There's a good reason for > that. "6 plus 4 equals 10" is not only sufficient, but easier to > understand. Hmmm. So when you are teaching programming to beginers and you try to explain why 20 + "20" crashes, how do you describe in, using the terms that you find sufficient? > The incidental complexity that type systems add *can* foster > programming errors, even as typed languages are supposed to prevent > them. This hasn't been my experience; I do sometimes find that it take take so longer to shut the damn compiler up and just have it do what I know will work that it's not worth the effort. Phil -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
