This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain.
"sometime type discussions lead to lead to early and convenient detection of bugs" - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole <richard.j.c...@gmail.com> wrote: > The things is that dynamically typed languages are easier to implement > than statically typed languages. Static typing comes down to making > statements about the program and deriving other statements from them. It > leads to all sorts of interesting work including I think into systems like > Z. However theorem provers are limited in what they can do, and it can be > both limiting and a big distraction to you as programmer to get into a > dialogue with the theorem prover about your program. It can distract you > from your original intention which was to write a program to do something > in particular. > > So simply put, dynamic languages are better than static ones because they > don't distract you with type discussions that can end up being unprofitable > or limiting. Static languages are better because sometimes the type > discussions lead to early and convenient detection of bugs and can also in > some cases make it easier for other people to understand you program or how > to use your library. Static types I think also help refactoring tools. > > Having optional typing in clojure is very nice. It allows for a lot of > experimentation and research on type systems and for them to be used to the > extent that people find them useful in their work. > > It is why I guess Alan Kay said that lisp is not a language, it's a > building material. > > If you want to know what are the current problems in static typing you > going to have to start learning what people are doing in that field, e.g. > is their foreign function interface from Haskel to Java? Why not? Can a > well typed program still exhibit bugs? If the type checking is so powerful > why do bugs persist? You might also look at what Gilhad Brakka was > attempting to do with newspeak and his notions of types being anti-modular. > You are not going to find a proof that that line of enquirely is fruitless, > you'll instead find what people can do today in that field and where > they're pushing the bounds. > > regards, > > Richard. > > -- > -- > 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. > -- Kornelis Sietsma korny at my surname dot com http://korny.info .fnord { display: none !important; } -- -- 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.
