| |
 | Posted by Don Allen
in reply to Walter Bright |  Permalink Reply |
|
Don Allen 
Posted in reply to Walter Bright
| On Saturday, 10 September 2022 at 02:17:30 UTC, Walter Bright wrote:
> On 9/9/2022 4:43 PM, Adam D Ruppe wrote:
>>> If you're using a lot of octal literals such that this is an issue, one wonders, what for? The only use I know of is for Unix file permissions.
>>
>> I keep hitting them in random C code I'm translating. Various unix things beyond file permissions and a hardware manual for a think i had to drive (an rfid chip) used them for various bit triplets too.
>
> octal!433 is really not much different from 0433. It could even be shortened to o!433, exactly the same number of characters as 0o433.
>
> The reasons for adding language syntactic sugar:
>
> 1. its very commonplace
>
> 2. the workarounds are gross
>
> Of course it's a judgement call, and I understand you see them randomly in C code, but does it really pay off? The downside is the language gets bigger and more complex, the spec gets longer, and people who don't come from a C background wonder why their 093 integer isn't 93.
>
> > the newer imported!"std.conv".octal!433 pattern
>
> Nobody would ever write that unless they used octal exactly once, which suggests that octal literals aren't common enough to justify special syntax.
>
>
>> I often prefer using binary literals anyway, but changing something like 0o50000 to binary is a little obnoxious.
>
> I first implemented binary literals in the 1980s, thinking they were cool and useful. They were not and not. I haven't found a reasonable use for them, or ever wanted them. (I prefer writing them in hex notation, as binary literals take up way too much horizontal space. After all, C3 is a lot easier than 11000011. The latter makes my eyes bleed a bit, too.)
>
> Let's simplify D.
I couldn't agree more with this. I've made it clear that I've done some very successful work with D and have been very pleased with the outcome. But this work involved porting C code I wrote 10 years ago that had become ugly (or maybe it always was) and difficult to maintain. The D version is a big improvement.
But if I were starting with an empty editor buffer, would I choose D? Especially to write a garden-variety application rather than bashing hardware registers? Perhaps not. Some of that would be simply that a higher-level language would be more suitable, e.g., Haskell or Scheme, both personal favorites. But some of that would be due to the hangover from C and C++ that D stills exhibits. My opinion: C was a bad language in 1970 and it is horrifying today. C++? Words fail me, unless they are scatological. I think the more D can detach itself from its C heritage and emphasize modern programming language practice (in other words, take advantage of what we have learned in the last 52 years), the better.
|
