• 1 Post
  • 53 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle











  • As a native German speaker I agree that ChatGPT is very English-flavored. I think it’s just because the sheer amount of English training data is so much larger that the patterns it learned from that bleed over into other languages. Traditional machine translations are also often pretty obvious in German, but they are more fundamentally wrong in a way that ChatGPT isn’t.

    It’s also somewhat cultural. The output you get from ChatGPT often sounds overly verbose and downright ass-kissing in German, even though I know I wouldn’t get that impression from the same output in English, simply because the way you communicate in professional environments is vastly different. (There is no German equivalent to “I hope this email finds you well”, for example.)





  • I’m a bit split on this. I do think in general all functions and methods should have comments describing how they behave, but I also think the standard format of Javadoc or JSDoc can look a bit redundant and silly sometimes, at least wrt getters and setters. I often see things like

    /**
     * Get the customer ID.
     *
     * @return the ID of the customer
     */
    public getId(): string {
        // ...
    }
    

    Now sure, you could argue that this is more of a problem with the Java-esque way of abstracting away field access than with the documentation, but sometimes there just genuinely isn’t anything meaningful to add that isn’t already expressed by the method name and signature. In that case, these comments add visual noise to the class and no real value. As soon as there is more logic to it than that though, I completely agree that should be documented for any caller.

    I’m not sure I like it better, but I do find Kotlin’s approach to this quite interesting, where parameters and return values are referenced from the description text rather than always listed separately.