3 ms·

Why didnt they use the language they already coded the API in then ?

king_magic 7y ago
This is where I’m really struggling with this story. Now, they have two places documentation can reside: in the code for the API itself, and now in a separate file encoded with a custom LISP-like language? I feel like the author is forgetting how software gets developed in the real world... or just human nature in general. Documentation created with this approach will instantly go stale, and will likely get out of sync with the true API very quickly. How is this a good solution at all? How is “tricking” people into this unsustainable situation a good thing?
- amelius 7y ago
  I'm guessing the real plan is to trick the co-workers into rewriting the entire application in Racket.
  - yowlingcat 7y ago
    It really irks me how some treat the practicalities and existing choices of real world software development as an annoying impediment to getting to use a language they're interested in. Whether you're interested in a language and whether you should use it in production can be two separate things. If you've got a compelling reason to use a given language in production, you probably don't have to trick your co-workers into doing anything, you just have a conversation with them! And if you "trick" them into using it for something small, aren't you going to sabotage your long term relationship and trust with them for minimal gain?
    - detaro 7y ago
      > If you've got a compelling reason to use a given language in production, you probably don't have to trick your co-workers into doing anything, you just have a conversation with them! Nothing in the article suggests that conversation didn't happen. The only mention of "tricked" is the headline the submitter gave it on HN.
- lukeschlather 7y ago
  It all depends on how concise and easy to use this is. My experience with yaml/json API generators is that they are extremely buggy due to myriad edge cases. If it goes stale, it's because it takes an hour to figure out how to represent what you want to say in the language, vs. just writing a json blob with some non-machine-readable type annotations. This is self-contained enough that I could see the language not mattering too much. And while I don't use Racket at all it sounds like the ideal language for this task. I'm not saying it confidently, but I wouldn't be surprised if the Racket implementation is less buggy than any non-lisp. Generating YAML/JSON is a task which lisp might be uniquely suited for.

This is where I’m really struggling with this story. Now, they have two places documentation can reside: in the code for the API itself, and now in a separate file encoded with a custom LISP-like language? I feel like the author is forgetting how software gets developed in the real world... or just human nature in general. Documentation created with this approach will instantly go stale, and will likely get out of sync with the true API very quickly. How is this a good solution at all? How is “tricking” people into this unsustainable situation a good thing?

amelius 7y ago
I'm guessing the real plan is to trick the co-workers into rewriting the entire application in Racket.
- yowlingcat 7y ago
  It really irks me how some treat the practicalities and existing choices of real world software development as an annoying impediment to getting to use a language they're interested in. Whether you're interested in a language and whether you should use it in production can be two separate things. If you've got a compelling reason to use a given language in production, you probably don't have to trick your co-workers into doing anything, you just have a conversation with them! And if you "trick" them into using it for something small, aren't you going to sabotage your long term relationship and trust with them for minimal gain?
  - detaro 7y ago
    > If you've got a compelling reason to use a given language in production, you probably don't have to trick your co-workers into doing anything, you just have a conversation with them! Nothing in the article suggests that conversation didn't happen. The only mention of "tricked" is the headline the submitter gave it on HN.
lukeschlather 7y ago
It all depends on how concise and easy to use this is. My experience with yaml/json API generators is that they are extremely buggy due to myriad edge cases. If it goes stale, it's because it takes an hour to figure out how to represent what you want to say in the language, vs. just writing a json blob with some non-machine-readable type annotations. This is self-contained enough that I could see the language not mattering too much. And while I don't use Racket at all it sounds like the ideal language for this task. I'm not saying it confidently, but I wouldn't be surprised if the Racket implementation is less buggy than any non-lisp. Generating YAML/JSON is a task which lisp might be uniquely suited for.