5 ms·

"intellectual laziness of dynamically typed languages" What a claim! What an absurdity! Dynamically type checked memory safe languages (eg. Python, Ruby, Java

by timtadh 13y ago

"intellectual laziness of dynamically typed languages" What a claim! What an absurdity! Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript, etc...) enable styles of programming impossible in non-dynamically checked languages. So it certainly isn't the users who are being "intellectually lazy." Nor are the creators, who have focused on productivity and usability instead of waiting for proof systems (static type checkers) to catch up with their ideas. Laziness doesn't factor in on either side.

ionforce 13y ago
Provide an example where such a style would be deemed useful or superior to doing it the statically checked way.
- LeafyGreenbriar 13y ago
  Duck typing in dynamic languages can allow you to do some pretty cool things.
  - Peaker 13y ago
    The request was for some examples of the claim. You just repeated the claim.
  - lmm 13y ago
    Compared to Java? No question. Compared to Scala with its implicits and associated patterns? I've yet to see a case I couldn't handle in Scala.
    - deleted 13y ago
      [deleted]
    - taeric 13y ago
      An in place and efficient quick sort? :)
      - frowaway001 13y ago
        ??? https://github.com/non/spire/blob/master/core/src/main/scala/spire/math/Sorting.scala https://github.com/non/spire/blob/master/core/src/main/scala...
        taeric 13y ago
        Ha! Fair enough, though I was thinking something different in two ways. Namely, something that worked on the common collections used by people and more readable than this. Still, bad example.
        frowaway001 13y ago
        That doesn't make sense. The whole point of quicksort's algorithm is to do things in place, which requires fast indexed access and mutability. Common collections lack both of these things.
- virtualwhys 13y ago
  Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)). It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result. I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
  - lmm 13y ago
    > Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc. (Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way) > It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result. Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
    - virtualwhys 13y ago
      You're talking about simple 1-to-1 mappings where both db result and case class to json conversion are straightforward. The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
- timtadh 13y ago
  I don't really feel I need to provide you with specific examples, they are already a google away. Try: "python vs java" or "why ruby" or similar. Experiment with programming in these languages and see what type of flexibility you can get, especially during prototyping and initial development phases. Their simplicity is to their benefit when comparing to Scala which brings a lot of overhead to enable static checking of certain constructs. Furthermore, I would bet that you can do things in Python or Ruby that are not possible in Scala (for instance see Armin Ronacher's Euro Python 2013 presentation for some interesting tricks https://ep2013.europython.eu/media/conference/slides/5-years-of-bad-ideas.pdf https://ep2013.europython.eu/media/conference/slides/5-years...)
  - frowaway001 13y ago
    So, basically you have no clue what you are talking about.
  - asdasf 13y ago
    >I can't back up my absurd claim with an actual argument, so go google some strawmen for me Really? How does this kind of shit not get downvoted to oblivion?
    - timtadh 13y ago
      1. I did provide a link to a slide deck of examples. 2. This is a well written about issue. 3. I do not consider my claim absurd if I did I would not have made it. 4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
      - asdasf 13y ago
        1. The link you provided does not support your absurd claim in any way. 2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect. 3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it. 4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support. You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.

by timtadh 13y ago

ionforce 13y ago

Provide an example where such a style would be deemed useful or superior to doing it the statically checked way.

LeafyGreenbriar 13y ago
Duck typing in dynamic languages can allow you to do some pretty cool things.
- Peaker 13y ago
  The request was for some examples of the claim. You just repeated the claim.
- lmm 13y ago
  Compared to Java? No question. Compared to Scala with its implicits and associated patterns? I've yet to see a case I couldn't handle in Scala.
  - deleted 13y ago
    [deleted]
  - taeric 13y ago
    An in place and efficient quick sort? :)
    - frowaway001 13y ago
      ??? https://github.com/non/spire/blob/master/core/src/main/scala/spire/math/Sorting.scala https://github.com/non/spire/blob/master/core/src/main/scala...
      - taeric 13y ago
        Ha! Fair enough, though I was thinking something different in two ways. Namely, something that worked on the common collections used by people and more readable than this. Still, bad example.
        frowaway001 13y ago
        That doesn't make sense. The whole point of quicksort's algorithm is to do things in place, which requires fast indexed access and mutability. Common collections lack both of these things.
virtualwhys 13y ago
Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)). It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result. I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
- lmm 13y ago
  > Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc. (Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way) > It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result. Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
  - virtualwhys 13y ago
    You're talking about simple 1-to-1 mappings where both db result and case class to json conversion are straightforward. The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
timtadh 13y ago
I don't really feel I need to provide you with specific examples, they are already a google away. Try: "python vs java" or "why ruby" or similar. Experiment with programming in these languages and see what type of flexibility you can get, especially during prototyping and initial development phases. Their simplicity is to their benefit when comparing to Scala which brings a lot of overhead to enable static checking of certain constructs. Furthermore, I would bet that you can do things in Python or Ruby that are not possible in Scala (for instance see Armin Ronacher's Euro Python 2013 presentation for some interesting tricks https://ep2013.europython.eu/media/conference/slides/5-years-of-bad-ideas.pdf https://ep2013.europython.eu/media/conference/slides/5-years...)
- frowaway001 13y ago
  So, basically you have no clue what you are talking about.
- asdasf 13y ago
  >I can't back up my absurd claim with an actual argument, so go google some strawmen for me Really? How does this kind of shit not get downvoted to oblivion?
  - timtadh 13y ago
    1. I did provide a link to a slide deck of examples. 2. This is a well written about issue. 3. I do not consider my claim absurd if I did I would not have made it. 4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
    - asdasf 13y ago
      1. The link you provided does not support your absurd claim in any way. 2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect. 3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it. 4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support. You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.