while i can see the strengths of both sides, the ideal solution is imho this:
everything is statically typed. always. but you *never* have to write the type explicitly. you *can* do it, but it is always optional. i made good experiences with both scala and haskell (although i just wrote minor things in the latter). the compiler really helps spotting oops-errors early on, and the ide (in case of scala) has a lot of information about the code and can assist you in ways that are simply impossible without static typing. please, do not confuse "java" with static typing. static typing could also track all supported methods of an object as its type. imagine java, but let every class implement one interface for each method that can be called on it - its inferred type is, instead of just a simple class, the set of interfaces necessary for the code to compile. to actually write that would be completely annoying, but if a compiler actually does the work for you and breaks it down, you would have a lot of error checking and static information without losing much flexibility Am 09.10.2013 00:36, schrieb Kendall Shaw: > 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. -- -- -- 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.
