6 ms·

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I imp

by jbob2000 7y ago

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return. I want the flexibility to incur tech debt where I want to, I don’t want the language to get in my way. That’s what makes JavaScript great!

arusahni 7y ago
In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.
- sjy 7y ago
  I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.
  - yawaramin 7y ago
    Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/
    - june11 7y ago
      a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson https://github.com/bos/aeson
      - yawaramin 7y ago
        I was replying to someone who said they had trouble.
    - sjy 7y ago
      I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn’t exist when I first tried it) is “hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don’t help that much.“ The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you’re used to doing it in JavaScript. [1]: https://artyom.me/aeson https://artyom.me/aeson
      - yawaramin 7y ago
        I'm interested in specifically what issues you had with JSON.
  - the_gipsy 7y ago
    I've really come to love strict JSON parsing, because everytime an API call was not as expected, I get the error straight at it's source, not somewhere 20 layers deeps in my views or models, way too late, and only with this one specific combination of events.
  - hopia 7y ago
    Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types. The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.
    - marcosdumay 7y ago
      Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.
      - hopia 7y ago
        Fair enough, you're probably right, I have only used it in contexts where I build both sides of the application.
      - platz 7y ago
        You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have
        marcosdumay 7y ago
        I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat. But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for generating bad runtime messages. There is even another library for fixing this, at the cost of even more complexity. If you fall outside of its optimum usage scenario, it won't afford you more functionality than a low level parser, so you are much better saving that complexity and going with the parser.
  - deleted 7y ago
    [deleted]
danielnixon 7y ago
Counterpoint: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
quickthrower2 7y ago
Typescript has the any type when you need it. You can write your code well typed but treat api returns as any if you wish. Although entering a type definition even for 100 types isn’t a big hassle, compared to day the code that has to do something with those objects. And will probably save the odd mistake so probably comes out ahead in terms of efficiency.
gherkinnn 7y ago
I found that by explicitly having to write types, the structures become a lot less convoluted. You split things apart, give them names, spot patterns more easily, and encode all sorts of information in a type system. And knowing that all fields are there when you need them is a relief. Of course a code review can catch it. Of course careful programming can as well. But those are external constraints. Having internal constraints greatly reduces the amount of mess one can produce. Admittedly, sometimes to a point to which you’ve typed yourself in to a corner.
kjtekn 7y ago
I have a library that is much like every other library in javascript. I decided to try TypeScript on it once as a test. The idea was to implement all the correct interfaces so that people couldn't call the wrong chain of methods. The interface list was almost the same size as my entire codebase. I think TypeScript is essentially for retards. It is like "we need to lock everything down so the mediocre people we have to hire on mass can't break anything".

arusahni 7y ago

In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.

sjy 7y ago
I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.
- yawaramin 7y ago
  Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/
  - june11 7y ago
    a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson https://github.com/bos/aeson
    - yawaramin 7y ago
      I was replying to someone who said they had trouble.
  - sjy 7y ago
    I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn’t exist when I first tried it) is “hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don’t help that much.“ The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you’re used to doing it in JavaScript. [1]: https://artyom.me/aeson https://artyom.me/aeson
    - yawaramin 7y ago
      I'm interested in specifically what issues you had with JSON.
- the_gipsy 7y ago
  I've really come to love strict JSON parsing, because everytime an API call was not as expected, I get the error straight at it's source, not somewhere 20 layers deeps in my views or models, way too late, and only with this one specific combination of events.
- hopia 7y ago
  Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types. The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.
  - marcosdumay 7y ago
    Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.
    - hopia 7y ago
      Fair enough, you're probably right, I have only used it in contexts where I build both sides of the application.
    - platz 7y ago
      You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have
      - marcosdumay 7y ago
        I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat. But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for generating bad runtime messages. There is even another library for fixing this, at the cost of even more complexity. If you fall outside of its optimum usage scenario, it won't afford you more functionality than a low level parser, so you are much better saving that complexity and going with the parser.
- deleted 7y ago
  [deleted]

danielnixon 7y ago

Counterpoint: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

quickthrower2 7y ago

Typescript has the any type when you need it. You can write your code well typed but treat api returns as any if you wish. Although entering a type definition even for 100 types isn’t a big hassle, compared to day the code that has to do something with those objects. And will probably save the odd mistake so probably comes out ahead in terms of efficiency.

gherkinnn 7y ago

I found that by explicitly having to write types, the structures become a lot less convoluted. You split things apart, give them names, spot patterns more easily, and encode all sorts of information in a type system. And knowing that all fields are there when you need them is a relief. Of course a code review can catch it. Of course careful programming can as well. But those are external constraints. Having internal constraints greatly reduces the amount of mess one can produce. Admittedly, sometimes to a point to which you’ve typed yourself in to a corner.

kjtekn 7y ago

I have a library that is much like every other library in javascript. I decided to try TypeScript on it once as a test. The idea was to implement all the correct interfaces so that people couldn't call the wrong chain of methods. The interface list was almost the same size as my entire codebase. I think TypeScript is essentially for retards. It is like "we need to lock everything down so the mediocre people we have to hire on mass can't break anything".