I agree entirely with Korny's statements. As for concrete examples ? Hard to enumerate some, I can only say I agree after more than 30 years coding in various languages and finally getting out of Java hell.
When I started there were a variety of dynamic languages used in the industry and given the kind of hardware we had at our disposal (more or less the power of today's cheap pocket calculator) the so-called "Performance hit" was rarely a problem. With the hardware available today, this is not a bigger issue than 25 years ago, except maybe for some highly specific problems. I saw enough typed language driven systems performing poorly to say that statically typed languages are not bullet proof performance wise. As for "discovering" significant errors, that's a false claim. So good a compiler may be, nothing can replace your brain. If the language and its related tools make your job so complex that your brain overloads then you are shooting yourself in the foot. Luc P. > Do you guys have any concrete examples? > > Sent from my iPhone > > On 23 Dec 2013, at 10:13, Korny Sietsma <ko...@sietsma.com> wrote: > > > 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. > > -- > -- > 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. > -- Luc Prefontaine<lprefonta...@softaddicts.ca> sent by ibisMail! -- -- 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.
