5 ms·

I recognize that we can have different goals, and you may value flexibility over safety. However, it is not a matter of opinion whether software safety (and the

I recognize that we can have different goals, and you may value flexibility over safety. However, it is not a matter of opinion whether software safety (and therefor availability) benefits from checks performed before run-time. Conversely, it is not a matter of opinion that dynamic languages allow patterns that static typing does not (eg. duck typing[sic]). These are objective arguments we can discuss, and weigh against each other. There are even studies that we can throw in here. >> Nowadays I see no notable arguments for dynamically typed programming languages. >A quick Google brought up an article from Dec 2016: https://medium.com/javascript-scene/you-might-not-need-types.. https://medium.com/javascript-scene/you-might-not-need-types.... I glanced over it the other day and wasn't very interested. I wanted to give it a more thorough look before I replied to you, but it seems it got pulled. looks meaningfully >What about Elixir and Clojure? I see your Erlang dialect Elixir with Elm (arguably a dialect of ML). The Lisp Clojure is itself a bit older dialect of Lisp, so maybe Scala for that? I think Lisp and Erlang are mostly about the paradigm and concepts, not about being dynamic, what do you say? Talking about the JVM, I'll raise you a Kotlin. Also noteworthy is that Groovy got static type checking with v2. As for the CLR, I must say I don't know that much have changed since F# (a dialect of ML). Basically, you've had a nice pair of cards, but they make your hand. What I'm trying to reiterate is that there seems to be a definite trend towards types. >Turing-complete[ness] :/ >Racket contracts [...] providing the safety guarantees in [dynamic and static] worlds. You didn't explain what they were, so I'll assume they're runtime guards. That means they're as useful as explicit runtime checks, but don't provide safety a static type checker would provide. > Dialyzer is a static type checker, which only rejects programs it knows for sure will result in error. Traditional type systems require the programmer to supply the proof that the code is correct and will refuse to type check without one. So weak (algebraic data) type inference? That's better than no checking. Now as far as weak vs strong typing goes, I'll agree to disagree about type coercion here. My default is maximum safety, but I won't claim that there are absolutely no domains where explicit conversions are a "pain" without much advantage. The suspicion that there might be some was the reason for my original challenge. I really wish someone would think that through and try and convince me. >I mentioned Forth and Assembly because these are the only languages I know of (TCL may also qualify) which are truly unityped. I suppose you'd like dynamic typing more after working with something which lacks any kind of types. I've worked with multiple assembly languages. An assembly programmer might use your "correct programs" argument and say: "Run-time checks are a pain; I don't want to check if quacking is an option, I know something clever will happen if you just jump; don't crash my program, it's correct!". I think this a valid argument only if the check overhead is prohibitively great. But what's prohibitive about compile-time checking? Time before you can run? You can reduce that with, say, incremental compilation. Don't allow certain bug types(pun) to go unnoticed and crash your program instead. It may not be as bad as what assembly would do, but it's still catastrophic. >the most accurate auto-complete you've ever seen: at any point, you know exactly which classes have which methods. I have that even when the program's not running :P >Well, in any case, you shouldn't wait to "get convinced" by someone. You should try to learn the dynamic typing side of things on your own and use it for a while. It will make you a better programmer overall, even if you get back to static typing later. I don't know why you assume my ignorance. I've used dynamically typed languages, I've studied the concepts, it's even possible I've seen the very Smalltalk talk you were thinking about before. I choose to avoid the dynamic capabilities of my otherwise statically typed language that I use at work. I'm still open to the possibility that there's gold buried somewhere, but I am not going dig just because you imply there is. People claim a lot of things are revolutionary which aren't. Give me an example why you say something's good, convince me it's worth my time. I do the same. My invitation to provide arguments, or a domain for dynamic languages still stands. EDIT: (Do not read this if you are kilbertp) Shh, I'm actually watching a video on the Dialyzer now

kazinator 10y ago
Software safety is greatly impaired by type erasure: removing type information prior to execution. The safest possible arrangement is one of static checks, backed by run-time checks (no type erasure). Run-time checks are simpler and therefore much less prone to false negatives: situations when an incorrectly typed operation is permitted to proceed, with various consequences: nonsensical values, corruption, crashing and so on. The situation of a proper type exception being thrown (dynamic language) is superior to unpredictable behavior (static-only, type-erased language where the type system failed or was subverted). Checking types and then throwing them away is like a navy using life jackets in training and then leaving them at home when embarking on the actual campaign.
klibertp 10y ago
> However, it is not a matter of opinion whether software safety (and therefore availability) benefits from checks performed before run-time. The article I linked to (it's still there for me?[1]) linked to another article[2] which in turn mentioned a paper[3], which conclusion is: > The data indicates functional languages are better than procedural languages; > it suggests that strong typing is better than weak typing; that static typing > is better than dynamic; and that managed memory usage is better than > unmanaged. [...] > On the other hand, even large datasets become small and insufficient when they > are sliced and diced many ways simultaneously, [...] Hence, we are unable to > quantify the specific effects of language type on usage. So I still think there's no way to tell, for example, if a statically typed imperative language with manual memory management is better than a dynamically typed functional language with a GC. I think it's a case of "all else being equal" in the context where "all else" varies drastically. The argument is not about if static typing improves safety (because many things do) but instead by how much and if that increase in safety is worth the drawbacks it comes with... Which again is subjective and situation-dependent. In other words, even if we agree that static typing has a positive effect on some metric (like number of bugs) it's not going to move the discussion forward. > Conversely, it is not a matter of opinion that dynamic languages allow patterns that static typing does not (eg. duck typing[sic]). Not a very good example, actually there are static type systems which use structural typing to allow for type-safe duck typing. Examples are Opa with its Power Rows, OCaml with its polymorphic variants and others. And while there certainly are techniques very hard (in terms of lines of code) to use in a statically typed language it's not like they're impossible at all (in the worst case you can write an intepreter). So the argument becomes: is a particular technique (or a set of techniques) beneficial enough to offset the lost benefits of static typing? Given that, per the paper above, we have no hard data on how exactly static typing (much less on a dynamic typing techniques...) affects the metric we're interested in, the answer to the question is - again - a matter of personal opinion. > These are objective arguments we can discuss, and weigh against each other. There are even studies that we can throw in here. I'm sorry, but I'd like to trouble you to provide such papers; as you can see above my quick search returned somewhat different results. > Basically, you've had a nice pair of cards, but they make your hand. What I'm trying to reiterate is that there seems to be a definite trend towards types. Yeah, I also feel that argument was weak :) I only wanted to show that not "all" new languages are statically typed, I didn't want to deny that the trend exists. The trend of "mainstream" moving to static typing is visible, but it's important to note that the same trend was observed more than once in programming history already. In all the previous cases it reversed (to dynamic typing) after ten to fifteen years. For the time being, I think, it's safer to assume we're going to repeat the cycle than that we arrived at the last iteration. This is however just an assumption and it may well be wrong! > I really wish someone would think that through and try and convince me. Your original thesis was that static typing is an overall win over dynamic typing. I already managed to convince you that this is not the case: you admit that there are techniques hard to pull off in a statically typed language. To me, that's enough. My belief is that static and dynamic typing are more or less equivalent and that their impact on most metrics is rather minor. I think that the typing discipline matters little and that the safety (or any other metric) of a language cannot be determined without taking all the other features into account. Of course, this is only my belief, as there is not enough evidence to say for sure (unless there is some research I'm not aware of). As such, I can only tell you what kind of projects I did in languages with dynamic typing. This is not the same as saying that dynamic typing is the best fit for these kinds of projects, just that there is a particular language which feature set as a whole seemed to be a good match for the problem. As an example, I'm writing a MUD server as a pet project. MUDs are text-based games where you interact with objects using commands: go north, kill orc and the like. It's based on LPMuds' basic design, so this particular implementation is actually more of a "multiplayer REPL": the objects are described as classes (called blueprints) with arbitrary methods which you can inherit and instantiate (clone). Every blueprint needs to be reloadable on runtime: you don't want to bring down the whole world just because you found a typo in some description. As blueprints are normal code (not just data), reloading them may change their type signatures, which needs to be handled gracefully (in both clones and inherited blueprints). Besides the predefined commands, users may evaluate arbitrary code and change the shared (persistent) environment at will. It should be possible to attach a new method to a single clone to test it without affecting anything else. I used Io as an implementation language, because it provides most of these features out of the box: whatever was missing I added in under 1k lines of straightforward code. I was able to do so in large part thanks to a dynamic, object oriented (with multiple, prototypical inheritance) type system of Io. It's just an anecdote, but it's an example of a project where dynamic, dynamically typed language is a clear win over a static, statically typed one. [1] https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b https://medium.com/javascript-scene/you-might-not-need-types... [2] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou... [3] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

kazinator 10y ago

Software safety is greatly impaired by type erasure: removing type information prior to execution. The safest possible arrangement is one of static checks, backed by run-time checks (no type erasure). Run-time checks are simpler and therefore much less prone to false negatives: situations when an incorrectly typed operation is permitted to proceed, with various consequences: nonsensical values, corruption, crashing and so on. The situation of a proper type exception being thrown (dynamic language) is superior to unpredictable behavior (static-only, type-erased language where the type system failed or was subverted). Checking types and then throwing them away is like a navy using life jackets in training and then leaving them at home when embarking on the actual campaign.

klibertp 10y ago

> However, it is not a matter of opinion whether software safety (and therefore availability) benefits from checks performed before run-time. The article I linked to (it's still there for me?[1]) linked to another article[2] which in turn mentioned a paper[3], which conclusion is: > The data indicates functional languages are better than procedural languages; > it suggests that strong typing is better than weak typing; that static typing > is better than dynamic; and that managed memory usage is better than > unmanaged. [...] > On the other hand, even large datasets become small and insufficient when they > are sliced and diced many ways simultaneously, [...] Hence, we are unable to > quantify the specific effects of language type on usage. So I still think there's no way to tell, for example, if a statically typed imperative language with manual memory management is better than a dynamically typed functional language with a GC. I think it's a case of "all else being equal" in the context where "all else" varies drastically. The argument is not about if static typing improves safety (because many things do) but instead by how much and if that increase in safety is worth the drawbacks it comes with... Which again is subjective and situation-dependent. In other words, even if we agree that static typing has a positive effect on some metric (like number of bugs) it's not going to move the discussion forward. > Conversely, it is not a matter of opinion that dynamic languages allow patterns that static typing does not (eg. duck typing[sic]). Not a very good example, actually there are static type systems which use structural typing to allow for type-safe duck typing. Examples are Opa with its Power Rows, OCaml with its polymorphic variants and others. And while there certainly are techniques very hard (in terms of lines of code) to use in a statically typed language it's not like they're impossible at all (in the worst case you can write an intepreter). So the argument becomes: is a particular technique (or a set of techniques) beneficial enough to offset the lost benefits of static typing? Given that, per the paper above, we have no hard data on how exactly static typing (much less on a dynamic typing techniques...) affects the metric we're interested in, the answer to the question is - again - a matter of personal opinion. > These are objective arguments we can discuss, and weigh against each other. There are even studies that we can throw in here. I'm sorry, but I'd like to trouble you to provide such papers; as you can see above my quick search returned somewhat different results. > Basically, you've had a nice pair of cards, but they make your hand. What I'm trying to reiterate is that there seems to be a definite trend towards types. Yeah, I also feel that argument was weak :) I only wanted to show that not "all" new languages are statically typed, I didn't want to deny that the trend exists. The trend of "mainstream" moving to static typing is visible, but it's important to note that the same trend was observed more than once in programming history already. In all the previous cases it reversed (to dynamic typing) after ten to fifteen years. For the time being, I think, it's safer to assume we're going to repeat the cycle than that we arrived at the last iteration. This is however just an assumption and it may well be wrong! > I really wish someone would think that through and try and convince me. Your original thesis was that static typing is an overall win over dynamic typing. I already managed to convince you that this is not the case: you admit that there are techniques hard to pull off in a statically typed language. To me, that's enough. My belief is that static and dynamic typing are more or less equivalent and that their impact on most metrics is rather minor. I think that the typing discipline matters little and that the safety (or any other metric) of a language cannot be determined without taking all the other features into account. Of course, this is only my belief, as there is not enough evidence to say for sure (unless there is some research I'm not aware of). As such, I can only tell you what kind of projects I did in languages with dynamic typing. This is not the same as saying that dynamic typing is the best fit for these kinds of projects, just that there is a particular language which feature set as a whole seemed to be a good match for the problem. As an example, I'm writing a MUD server as a pet project. MUDs are text-based games where you interact with objects using commands: go north, kill orc and the like. It's based on LPMuds' basic design, so this particular implementation is actually more of a "multiplayer REPL": the objects are described as classes (called blueprints) with arbitrary methods which you can inherit and instantiate (clone). Every blueprint needs to be reloadable on runtime: you don't want to bring down the whole world just because you found a typo in some description. As blueprints are normal code (not just data), reloading them may change their type signatures, which needs to be handled gracefully (in both clones and inherited blueprints). Besides the predefined commands, users may evaluate arbitrary code and change the shared (persistent) environment at will. It should be possible to attach a new method to a single clone to test it without affecting anything else. I used Io as an implementation language, because it provides most of these features out of the box: whatever was missing I added in under 1k lines of straightforward code. I was able to do so in large part thanks to a dynamic, object oriented (with multiple, prototypical inheritance) type system of Io. It's just an anecdote, but it's an example of a project where dynamic, dynamically typed language is a clear win over a static, statically typed one. [1] https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b https://medium.com/javascript-scene/you-might-not-need-types... [2] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou... [3] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf