3 ms·

I get that we as an industry went a bit overboard when Java +ooo was in vouge novelty with entire sentences being method names, but I'm with you that all the pe

I get that we as an industry went a bit overboard when Java +ooo was in vouge novelty with entire sentences being method names, but I'm with you that all the people I see making super compressed var names with contexts longer than a for loop initializer And don't even get me started on trying to text to speak your `mCtx` or whatever

OJFord 3y ago
> And don't even get me started on trying to text to speak your `mCtx` or whatever I'm not saying TTS is there (I have no idea) but from an ideal point of view, to have it be equivalent, surely it would read 'm context', which then isn't so bad (maybe m is clear from the ..err.. context).
- hughesjj 3y ago
  From my experience with someone who has CRPS the actual tooling in place to consistently do these kinds of things is severely wanting. Dragon naturally speaking isn't great for code and is all but abandon ware, and while there's a lot of cool new ai tools out the integration isn't there just yet. That said maybe `mCtx` wasn't the best example, but in general anything other than fully pronounceable words in a normalized format (PascalCase, camelCase, snake_case, kebab-case, etc) is a huge pita for language models in our experience. Things like `i` or other single letters are generally okay. But imagine things like "wait did you mean the letter 'm' or the unit 'em'"
- ElFitz 3y ago
  You could run a LLM pass to "expand" abbreviations and acronyms before running it through text to speech. Although more expensive, it worked wonders for me with text containing units of measurement (°F, °C, m/s, etc).
  - hughesjj 3y ago
    You're right, but for non standard things configuring it for literally every project becomes quickly untenable IDK, I've yet to see a good argument for not having your variables being generally pronouncable (at least, in a way more or less consistent with the native language of your code base or English). I'm just going to lazily parrot the old adage that "code gets read more often than written, so prefer making it easier to read than write"

OJFord 3y ago

> And don't even get me started on trying to text to speak your `mCtx` or whatever I'm not saying TTS is there (I have no idea) but from an ideal point of view, to have it be equivalent, surely it would read 'm context', which then isn't so bad (maybe m is clear from the ..err.. context).

hughesjj 3y ago
From my experience with someone who has CRPS the actual tooling in place to consistently do these kinds of things is severely wanting. Dragon naturally speaking isn't great for code and is all but abandon ware, and while there's a lot of cool new ai tools out the integration isn't there just yet. That said maybe `mCtx` wasn't the best example, but in general anything other than fully pronounceable words in a normalized format (PascalCase, camelCase, snake_case, kebab-case, etc) is a huge pita for language models in our experience. Things like `i` or other single letters are generally okay. But imagine things like "wait did you mean the letter 'm' or the unit 'em'"
ElFitz 3y ago
You could run a LLM pass to "expand" abbreviations and acronyms before running it through text to speech. Although more expensive, it worked wonders for me with text containing units of measurement (°F, °C, m/s, etc).
- hughesjj 3y ago
  You're right, but for non standard things configuring it for literally every project becomes quickly untenable IDK, I've yet to see a good argument for not having your variables being generally pronouncable (at least, in a way more or less consistent with the native language of your code base or English). I'm just going to lazily parrot the old adage that "code gets read more often than written, so prefer making it easier to read than write"