Yes the kind of app you are working on may make your mileage vary. But not only this criteria impacts how good you can fare with imposed data types.
One tendency in software development is to normalize everything up to a point where two values are identical but because they have been typed differently they are not comparable anymore or interchangeable. The perversion here is that data typing at some point becomes a pain in the a... Especially when you want to make changes to your software. You inherit rigidity along the way and you have to pay for it as you go and an extra fee later. Having optional type checking allows you to pay the price where it's needed. I do not see why this is a problem. In any project you have to compromise on many factors. One great example is documentation, this is the first thing that gets axed when the schedule gets tight. Why not have this flexibility with the data type system ? Some components might benefit from it while others will not. You may consider data typing as a form of documentation but do you want to pay the price down to this level ? Low level documentation fail at describing component interactions (javadoc is a great example of verbosity w/o useful content). Better dedicate some time to write a higher level document than painfully type all the values in your software wall to wall. Luc P. > Some things that I see most of the time when I read debates about > dynamic vs static are: > > 1. Statically defined types don't solve everything, so they are not useful. > > Some help is better than no help even if the help doesn't solve all of > your problems. > > Yes, you should wash your hands before dinner, even though we are all > going to die in the end anyway. > > 2. I like static typing as long as it is optional > > In the case where the point of using statically defined types is to have > a compiler catch problems instead of you needing to predict their > occurrence then static typing would have to be non-optional. > > 3. You don't need the compiler to warn you about types, because you can > write tests. > > A difficult problem is one that occurs on a rare occasion in some place > that you would not have thought to check. So, you can't expect to be > able to catch them with tests. If the problem is one that would have > been flagged as a compile-time error, then in that case it would have > been useful to have been using static typing. > > I am still unsure. It seems likely that the usefulness of statically > defined types would depend upon the application. When using statically > defined types makes development slower to an extent that outways the > benefit, then it is bad. If faster initial development as a result of > dynamic typing ultimately ends up taking more time because of problems > that would have been caught by a compiler, then it is bad. If statically > defined typing makes you not discover things you would have because of > the overhead of dealing with the static typing, then that is bad. > > Kendall > > > On 10/05/2013 08:35 PM, zcaudate wrote: > > I'm a little bit miffed over this current craze of `types` and > > `correctness` of programs. It smells to me of the whole `object` craze > > of the last two decades. I agree that types (like objects) have their > > uses, especially in very well defined problems, but they have got me > > in trouble over and over again when I am working in an area where the > > goal is unclear and requirements are constantly changing. > > > > BTW... This is no means a criticism of all the type system work that > > is going on in the clojure community. I am a huge fan of Ambrose's > > Typed Clojure project because it gives me the *option *of using > > types... not shoving it down my throat. I like the freedom to choose. > > > > My experience of programming in clojure has freed me from thinking > > about types and hierarchies and this article rings so true: > > http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. > > > > However, everywhere I look, there are smug type-weenies telling me > > that my dynamically typed program is bad because it cannot be `proven > > correct` and not `checked by the compiler`. This question on SO really > > makes me > > angry.... > > http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages.... > > > > because no one is defending dynamic languages on there. The reason is > > very simple..... because we don`t have a theory to back us up! > > > > I do want to put up an counter argument against this barrage of abuse > > against dynamic languages. And I want to put some academic weight > > behind this. The only counter I could come up with was to use Godel's > > incompleteness theorem. For those that don't know... here is an > > introduction to the man and his theory. > > http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, > > invalidated Principia Mathematica as a complete system of description. > > Principia Mathematica btw.... effectively led to Type Theory. > > > > > > According to http://en.wikipedia.org/wiki/Type_theory. "The types > > of type theory were invented by Bertrand Russell in response to > > his discovery that Gottlob Frege's version of naive set theory was > > afflicted with Russell's paradox. This theory of types features > > prominently in Whitehead and Russell's Principia Mathematica. It > > avoids Russell's paradox by first creating a hierarchy of types, > > then assigning each mathematical (and possibly other) entity to a > > type. Objects of a given type are built exclusively from objects > > of preceding types (those lower in the hierarchy), thus preventing > > loops." > > > > I'm hoping to collect a few more `proofs` from the clojure > > community... for example... if there is a paper on "why are type > > systems so bad at classifying animals"... then please forward it on. > > -- > > -- > > 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. > > > -- > ThisIsHardToRead, asIsThis. This_is_easier, unless_it_is_underlined. > This.is.easy. This-is-easy-too. Almost as easy to read as this. > > -- > -- > 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. > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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.
