5 ms·

> strongly dynamic Que?

by DaiPlusPlus 5y ago

enricozb 5y ago
class A(random.choice([B, C]): ...
- rphln 5y ago
  I don't know whether to feel disgusted or fascinated by this. I find the concept of prototype-based inheritance quite elegant, but this is a bit too much insane.
  - professoretc 5y ago
    There was an experimental language called Cecil that had "conditional inheritance". You could say things like class Rectangle: var w,h class Square(Rectangle if w == h): ... You could then overload functions/methods on both `Square` and `Rectangle` and it would call the correct overload depending on the runtime values of `w` and `h`.
dgb23 5y ago
They are dynamic to a degree that facilitates interactivity and expression on a different level than one might be used to. Late binding, REPL, expression based, building up code while it is running without losing state etc.
- DaiPlusPlus 5y ago
  But none of those things you mentioned are dependent on a dynamic type system: on the contrary, plenty of statically-typed languages offer late-binding, expressions (certainly enough to implement a REPL) - I know C# certainly has all of those things. The last thing: being able to edit program code, add new types/members/functionality and so-on while it's running... that's not really a language limitation nor typing-system limitation either: that's just good tooling that is able to hot-swap executable code after the process has already started. Visual Studio has had "Edit & Continue" in debugging sessions for almost 3 decades now, and the runtime build system used by ASP.NET means that source code and raw aspx/cshtml views can still be FTP'd up to production and just work, because .NET supports runtime compilation. ------------ For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. In this situation there is absolutely no "expressiveness" that's could be gained by simply giving up on type-correctness and instead rely on unit tests (and hope you have 100% test coverage).
  - capableweb 5y ago
    > For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. There is also ways of dealing with this in dynamic languages. For example, Clojure has clojure.spec that achieves the same results, but without relying on strong typing. In the end, it's all tradeoffs. There is no "one solution" that will be perfect for everything.
  - simiones 5y ago
    > that's not really a language limitation nor typing-system limitation either: that's just good tooling that is able to hot-swap executable code after the process has already started. It's more complex than that. The language absolutely has to define these operations for them to make any sense. Modifying some code inside a function is the easy case, and supported by many environments. Modifying types is much more difficult, and usually not supported (.NET and JVM do not support any kind of type modification - neither field nor function). I'm not sure if the C++ debugger can handle this either. Common Lisp can do it, and it actually defines how existing objects behave if their type changes.
- Zababa 5y ago
  REPL and expression-based are not limited to dynamic languages. REPL-oriented programming as it's understood by Lisp/Clojure users might be, I'm not sure.
  - cutler 5y ago
    Only Lisps have a reader so I'm not sure the term REPL is accurate with other languages. Interactive console != REPL.
    - Zababa 5y ago
      Could you expand on that? I've searched a bit but the Lisp read doesn't sound too different from what other languages do.
      - simiones 5y ago
        Unlike most languages, Lisp defines how strings can be transformed to Lisp ASTs (s-expressions). In Scheme (which doesn't allow reader macros) this is a safe operation: you can read untrusted input without worry. By contrast, most other languages only have eval() - which takes a string and parses and executes it as code. In Lisp, eval() takes a Lisp list object and executes that.
        draegtun 5y ago
        Ditto for Rebol & Red. For eg. >> code: load "foreach n [1 2 3 4] [print n * 2]" == [foreach n [1 2 3 4] [print n * 2] ] >> type? code == block! >> do code 2 4 6 8
      - capableweb 5y ago
        This is probably the best blog post I've seen on the topic: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.... > If you're not familiar with Clojure, you may be surprised that I describe the REPL as Clojure's most differentiating feature: after all, most industrial programming languages come with REPLs or 'shells' these days (including Python, Ruby, Javascript, PHP, Scala, Haskell, ...). However, I've never managed to reproduced the productive REPL workflow I had in Clojure with those languages; the truth is that not all REPLs are created equal. Basically, the "REPL" you usually call a REPL is in fact a shell, and not a REPL as normally used in lisp languages.
hultner 5y ago
A strongly typed dynamic language will raise an type error if you for instance try to add two incompatible types, for instance in python Python 3.9.0 (default, Oct 10 2020, 11:40:52) [Clang 11.0.3 (clang-1103.0.32.62)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 1+"1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' While a weakly typed dynamic language like JS will allow for it Welcome to Node.js v16.0.0. Type ".help" for more information. > 1 + "1" '11'
- dragonwriter 5y ago
  If the language allows it the types are (ipso facto) not incompatible; “weak typing” is more a subjective statement about how well a language lines up with the speakers mental model of what types should be compatible than an objective one about falsifiable properties of the type system.
  - gpderetta 5y ago
    Agree. Weakly typed is so loosely defined and subjective to be a completely useless adjective. It basically a synonym for 'language I dislike'.
    - goatlover 5y ago
      How about some languages allow implicit type conversions, and others do not.
      - iso8859-1 5y ago
        Is Scala weakly typed then because it has implicits?
        goatlover 5y ago
        I don't know, but JS and PHP implicit conversions are widely acknowledged to cause plenty of issues, which Python and Ruby do not have since you have much fewer cases of implicit conversion.

> strongly dynamic Que?

enricozb 5y ago

class A(random.choice([B, C]): ...

rphln 5y ago
I don't know whether to feel disgusted or fascinated by this. I find the concept of prototype-based inheritance quite elegant, but this is a bit too much insane.
- professoretc 5y ago
  There was an experimental language called Cecil that had "conditional inheritance". You could say things like class Rectangle: var w,h class Square(Rectangle if w == h): ... You could then overload functions/methods on both `Square` and `Rectangle` and it would call the correct overload depending on the runtime values of `w` and `h`.

dgb23 5y ago

They are dynamic to a degree that facilitates interactivity and expression on a different level than one might be used to. Late binding, REPL, expression based, building up code while it is running without losing state etc.

DaiPlusPlus 5y ago
But none of those things you mentioned are dependent on a dynamic type system: on the contrary, plenty of statically-typed languages offer late-binding, expressions (certainly enough to implement a REPL) - I know C# certainly has all of those things. The last thing: being able to edit program code, add new types/members/functionality and so-on while it's running... that's not really a language limitation nor typing-system limitation either: that's just good tooling that is able to hot-swap executable code after the process has already started. Visual Studio has had "Edit & Continue" in debugging sessions for almost 3 decades now, and the runtime build system used by ASP.NET means that source code and raw aspx/cshtml views can still be FTP'd up to production and just work, because .NET supports runtime compilation. ------------ For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. In this situation there is absolutely no "expressiveness" that's could be gained by simply giving up on type-correctness and instead rely on unit tests (and hope you have 100% test coverage).
- capableweb 5y ago
  > For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. There is also ways of dealing with this in dynamic languages. For example, Clojure has clojure.spec that achieves the same results, but without relying on strong typing. In the end, it's all tradeoffs. There is no "one solution" that will be perfect for everything.
- simiones 5y ago
  > that's not really a language limitation nor typing-system limitation either: that's just good tooling that is able to hot-swap executable code after the process has already started. It's more complex than that. The language absolutely has to define these operations for them to make any sense. Modifying some code inside a function is the easy case, and supported by many environments. Modifying types is much more difficult, and usually not supported (.NET and JVM do not support any kind of type modification - neither field nor function). I'm not sure if the C++ debugger can handle this either. Common Lisp can do it, and it actually defines how existing objects behave if their type changes.
Zababa 5y ago
REPL and expression-based are not limited to dynamic languages. REPL-oriented programming as it's understood by Lisp/Clojure users might be, I'm not sure.
- cutler 5y ago
  Only Lisps have a reader so I'm not sure the term REPL is accurate with other languages. Interactive console != REPL.
  - Zababa 5y ago
    Could you expand on that? I've searched a bit but the Lisp read doesn't sound too different from what other languages do.
    - simiones 5y ago
      Unlike most languages, Lisp defines how strings can be transformed to Lisp ASTs (s-expressions). In Scheme (which doesn't allow reader macros) this is a safe operation: you can read untrusted input without worry. By contrast, most other languages only have eval() - which takes a string and parses and executes it as code. In Lisp, eval() takes a Lisp list object and executes that.
      - draegtun 5y ago
        Ditto for Rebol & Red. For eg. >> code: load "foreach n [1 2 3 4] [print n * 2]" == [foreach n [1 2 3 4] [print n * 2] ] >> type? code == block! >> do code 2 4 6 8
    - capableweb 5y ago
      This is probably the best blog post I've seen on the topic: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.... > If you're not familiar with Clojure, you may be surprised that I describe the REPL as Clojure's most differentiating feature: after all, most industrial programming languages come with REPLs or 'shells' these days (including Python, Ruby, Javascript, PHP, Scala, Haskell, ...). However, I've never managed to reproduced the productive REPL workflow I had in Clojure with those languages; the truth is that not all REPLs are created equal. Basically, the "REPL" you usually call a REPL is in fact a shell, and not a REPL as normally used in lisp languages.

hultner 5y ago

A strongly typed dynamic language will raise an type error if you for instance try to add two incompatible types, for instance in python Python 3.9.0 (default, Oct 10 2020, 11:40:52) [Clang 11.0.3 (clang-1103.0.32.62)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 1+"1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' While a weakly typed dynamic language like JS will allow for it Welcome to Node.js v16.0.0. Type ".help" for more information. > 1 + "1" '11'

dragonwriter 5y ago
If the language allows it the types are (ipso facto) not incompatible; “weak typing” is more a subjective statement about how well a language lines up with the speakers mental model of what types should be compatible than an objective one about falsifiable properties of the type system.
- gpderetta 5y ago
  Agree. Weakly typed is so loosely defined and subjective to be a completely useless adjective. It basically a synonym for 'language I dislike'.
  - goatlover 5y ago
    How about some languages allow implicit type conversions, and others do not.
    - iso8859-1 5y ago
      Is Scala weakly typed then because it has implicits?
      - goatlover 5y ago
        I don't know, but JS and PHP implicit conversions are widely acknowledged to cause plenty of issues, which Python and Ruby do not have since you have much fewer cases of implicit conversion.