4 ms·

Both C# and Kotlin have a 'Dynamic' type for just that escape hatch. IMHO, That's a better way over TS - since types might not be the right thing 100% of the ti

by yyyk 7y ago

Both C# and Kotlin have a 'Dynamic' type for just that escape hatch. IMHO, That's a better way over TS - since types might not be the right thing 100% of the time, but they are 95% of the time.

Analemma_ 7y ago
I programmed professionally in C# for about eight years and in that time I can count on one hand the number of times I saw the ‘dynamic’ keyword. Nobody seems to think it’s worth the effort or confusion.
- Ididntdothis 7y ago
  Agreed. It’s also not as easily used as “any” in TypeScript. I would probably reject a C# codebase that uses dynamic widely. It’s only good for very local use like some serialization or deserialization.
- yyyk 7y ago
  That's my experience as well, I just wanted to note that the escape hatch exists. Maybe I should have amended my comments for 99% of the time? Or perhaps that there are other functionalities (e.g. tuple types, reflection) to to make working with types almost as easy as without? I use reflection very frequently...
- Fellshard 7y ago
  However, in JavaScript-world, where the external types you interact with - from other libraries, from APIs, from the browser itself - are poorly defined, having that escape hatch becomes a sanity-saver, does it not? That's where the power comes from: the squishy, fuzzy, less structured edges.
  - dpc_pw 7y ago
    The parent-parent comment was "I want an escape hatch in the language" and then the argument for it is "someone else used an escape hatch, and now I need an escape hatch". :D
    - RobertKerans 7y ago
      Well, yes, most of the packages available in the JS ecosystem were written in JS. The easiest way to retroactively write typings is to use `any` all over the place.
  - yakshaving_jgt 7y ago
    > having that escape hatch becomes a sanity-saver, does it not? No, it does not. There is no difference between static languages and dynamic languages when parsing data at runtime.
- jgalentine007 7y ago
  Samesy.I almost used dynamic last week for maybe the first time ever, but ended up with a simple generic class instead.
- WorldMaker 7y ago
  In a past life I did some real wizardry with dynamic in C#, drastically improved performance on a thing that had been using strange combinations of T4 compile-time templates, Reflection.Emit, and some very kooky multi-database lookups with a custom IDynamicMetaObject provider. It was definitely worth the effort then. I also recognize why it is a very unlikely scenario to repeat. The other place where I used dynamic most heavily in C# was that it was really great for IronPython interop where you could have a bit of "data science" done in a Python module, build that to a .NET assembly and call into the Python module from C#. (Though the other direction was more common, using IronPython to do data science around a bulk of C# models and code.) With so much more data science since that past life of mine having moved to Python, it's almost a shame that IronPython hasn't really kept up.
flyinglizard 7y ago
Not a pro C# dev but I use it quite a bit - IIRC the correct keyword for that situation would be 'var' which is similar to 'auto' in C++. It just statically infers the type from the assignment, while 'dynamic' actually does runtime casting. I use 'var' all the time, I use 'dynamic' only when working with JSON objects and such.
- uk_programmer 7y ago
  If you are unaware, you can work with JSON objects in a strongly typed way using JSON attributes on POCOs e.g. https://www.newtonsoft.com/json/help/html/SerializationAttributes.htm https://www.newtonsoft.com/json/help/html/SerializationAttri... I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up). Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name. e.g. When you should use var (it is evident from the right hand side) var name = "Joe Bloggs"; vs when it isn't evident: var myVariables = _service.SomeMethod(); It allows the code to be better read without the IDE. However obviously it is up to you.
  - philliphaydon 7y ago
    var myVariables = _service.SomeMethod(); Sure when you write non-obvious code `var` sucks. But: var product = service.FetchProduct(productId); If the type of var is not obvious to you then you have bigger problems to worry about.
    - uk_programmer 7y ago
      https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions#language-guidelines https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. > Do not use var when the type is not apparent from the right side of the assignment. > Do not rely on the variable name to specify the type of the variable. It might not be correct. Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here. TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc. There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.
bravura 7y ago
Kotlin is a backend language tho? I saw other commenter say that the benefit of using TS in the frontend and backend, then DB updates in the backend also update the frontend code: "The beauty of Gary’s setup is changes to his database update the types for the server side Code AND client side code. The value of that comes from using the same language in both platforms" Can you get this sort of benefit with Kotlin? How?
- jaredklewis 7y ago
  It’s not used widely (yet?) but Kotlin does also compile for browsers and full stack kotlin react apps are a thing. https://kotlinlang.org/docs/reference/js-overview.html https://kotlinlang.org/docs/reference/js-overview.html
  - bravura 7y ago
    I would love to do frontend Kotlin, but is it one of those things that you end up painting yourself in a corner and wishing you used TypeScript all along? "Don't do frontend development in anything else than JavaScript ... You will probably run in to an abstraction leak that causes problems if you do the frontend in Kotlin." https://www.reddit.com/r/webdev/comments/etzy5u/web_development_kotlin_full_stack/ffk4zsl/ https://www.reddit.com/r/webdev/comments/etzy5u/web_developm... I ask this seriously. I would love to do full-stack Kotlin. I just don't want to take the plunge and later realize it was a big mistake.
    - jaredklewis 7y ago
      I have only played a little with the Kotlin web stuff, but no I would not recommend doing anything serious with it. I think JS/TS are king because of the ecosystem and wealth of documentation. My experience with more "niche" front-end languages is that you have to do much more yourself or have lots of messy interactions with plain JS libraries. But even if Kotlin JS had an enormous ecosystem, I'm not sure I would love it. What I love about Kotlin is that it is a great replacement for Java. Interoperating with java has zero performance overhead and zero mental overhead. Because of this and Kotlin's general closeness to Java, many more places writing JVM code are comfortable with using Kotlin compared with other JVM languages like Scala or Clojure. Kotlin cleans up the Java syntax and adds nice features like type inferencing, non-null by default, coroutines, blocks, extension functions and so on. But if we're not on the JVM, I'm definitely not sold on Kotlin as the perfect language or anything. Sealed classes are nice, but still not as nice as tagged unions. As far as type systems go, I think the one in TS is more flexible and expressive. Like Kotlin, what I like about TS is the zero mental overhead integration with JS and the JS ecosystem. But if we're not tied to a browser, I guess I wouldn't ever really want to program in TS. Node is kind of remarkable in that it is the backend platform that is most similar to a browser, which makes these full-stack setups a little more natural. Not sure I'm sold on their value in general since most teams are going to be big enough that front-end and backend code are written separately. If you want to keep types in sync, I think graphql or protocol buffers are better solutions.

by yyyk 7y ago

Both C# and Kotlin have a 'Dynamic' type for just that escape hatch. IMHO, That's a better way over TS - since types might not be the right thing 100% of the time, but they are 95% of the time.

Analemma_ 7y ago

I programmed professionally in C# for about eight years and in that time I can count on one hand the number of times I saw the ‘dynamic’ keyword. Nobody seems to think it’s worth the effort or confusion.

Ididntdothis 7y ago
Agreed. It’s also not as easily used as “any” in TypeScript. I would probably reject a C# codebase that uses dynamic widely. It’s only good for very local use like some serialization or deserialization.
yyyk 7y ago
That's my experience as well, I just wanted to note that the escape hatch exists. Maybe I should have amended my comments for 99% of the time? Or perhaps that there are other functionalities (e.g. tuple types, reflection) to to make working with types almost as easy as without? I use reflection very frequently...
Fellshard 7y ago
However, in JavaScript-world, where the external types you interact with - from other libraries, from APIs, from the browser itself - are poorly defined, having that escape hatch becomes a sanity-saver, does it not? That's where the power comes from: the squishy, fuzzy, less structured edges.
- dpc_pw 7y ago
  The parent-parent comment was "I want an escape hatch in the language" and then the argument for it is "someone else used an escape hatch, and now I need an escape hatch". :D
  - RobertKerans 7y ago
    Well, yes, most of the packages available in the JS ecosystem were written in JS. The easiest way to retroactively write typings is to use `any` all over the place.
- yakshaving_jgt 7y ago
  > having that escape hatch becomes a sanity-saver, does it not? No, it does not. There is no difference between static languages and dynamic languages when parsing data at runtime.
jgalentine007 7y ago
Samesy.I almost used dynamic last week for maybe the first time ever, but ended up with a simple generic class instead.
WorldMaker 7y ago
In a past life I did some real wizardry with dynamic in C#, drastically improved performance on a thing that had been using strange combinations of T4 compile-time templates, Reflection.Emit, and some very kooky multi-database lookups with a custom IDynamicMetaObject provider. It was definitely worth the effort then. I also recognize why it is a very unlikely scenario to repeat. The other place where I used dynamic most heavily in C# was that it was really great for IronPython interop where you could have a bit of "data science" done in a Python module, build that to a .NET assembly and call into the Python module from C#. (Though the other direction was more common, using IronPython to do data science around a bulk of C# models and code.) With so much more data science since that past life of mine having moved to Python, it's almost a shame that IronPython hasn't really kept up.

flyinglizard 7y ago

Not a pro C# dev but I use it quite a bit - IIRC the correct keyword for that situation would be 'var' which is similar to 'auto' in C++. It just statically infers the type from the assignment, while 'dynamic' actually does runtime casting. I use 'var' all the time, I use 'dynamic' only when working with JSON objects and such.

uk_programmer 7y ago
If you are unaware, you can work with JSON objects in a strongly typed way using JSON attributes on POCOs e.g. https://www.newtonsoft.com/json/help/html/SerializationAttributes.htm https://www.newtonsoft.com/json/help/html/SerializationAttri... I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up). Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name. e.g. When you should use var (it is evident from the right hand side) var name = "Joe Bloggs"; vs when it isn't evident: var myVariables = _service.SomeMethod(); It allows the code to be better read without the IDE. However obviously it is up to you.
- philliphaydon 7y ago
  var myVariables = _service.SomeMethod(); Sure when you write non-obvious code `var` sucks. But: var product = service.FetchProduct(productId); If the type of var is not obvious to you then you have bigger problems to worry about.
  - uk_programmer 7y ago
    https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions#language-guidelines https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. > Do not use var when the type is not apparent from the right side of the assignment. > Do not rely on the variable name to specify the type of the variable. It might not be correct. Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here. TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc. There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.

bravura 7y ago

Kotlin is a backend language tho? I saw other commenter say that the benefit of using TS in the frontend and backend, then DB updates in the backend also update the frontend code: "The beauty of Gary’s setup is changes to his database update the types for the server side Code AND client side code. The value of that comes from using the same language in both platforms" Can you get this sort of benefit with Kotlin? How?

jaredklewis 7y ago
It’s not used widely (yet?) but Kotlin does also compile for browsers and full stack kotlin react apps are a thing. https://kotlinlang.org/docs/reference/js-overview.html https://kotlinlang.org/docs/reference/js-overview.html
- bravura 7y ago
  I would love to do frontend Kotlin, but is it one of those things that you end up painting yourself in a corner and wishing you used TypeScript all along? "Don't do frontend development in anything else than JavaScript ... You will probably run in to an abstraction leak that causes problems if you do the frontend in Kotlin." https://www.reddit.com/r/webdev/comments/etzy5u/web_development_kotlin_full_stack/ffk4zsl/ https://www.reddit.com/r/webdev/comments/etzy5u/web_developm... I ask this seriously. I would love to do full-stack Kotlin. I just don't want to take the plunge and later realize it was a big mistake.
  - jaredklewis 7y ago
    I have only played a little with the Kotlin web stuff, but no I would not recommend doing anything serious with it. I think JS/TS are king because of the ecosystem and wealth of documentation. My experience with more "niche" front-end languages is that you have to do much more yourself or have lots of messy interactions with plain JS libraries. But even if Kotlin JS had an enormous ecosystem, I'm not sure I would love it. What I love about Kotlin is that it is a great replacement for Java. Interoperating with java has zero performance overhead and zero mental overhead. Because of this and Kotlin's general closeness to Java, many more places writing JVM code are comfortable with using Kotlin compared with other JVM languages like Scala or Clojure. Kotlin cleans up the Java syntax and adds nice features like type inferencing, non-null by default, coroutines, blocks, extension functions and so on. But if we're not on the JVM, I'm definitely not sold on Kotlin as the perfect language or anything. Sealed classes are nice, but still not as nice as tagged unions. As far as type systems go, I think the one in TS is more flexible and expressive. Like Kotlin, what I like about TS is the zero mental overhead integration with JS and the JS ecosystem. But if we're not tied to a browser, I guess I wouldn't ever really want to program in TS. Node is kind of remarkable in that it is the backend platform that is most similar to a browser, which makes these full-stack setups a little more natural. Not sure I'm sold on their value in general since most teams are going to be big enough that front-end and backend code are written separately. If you want to keep types in sync, I think graphql or protocol buffers are better solutions.