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.
