I’ve been working with Turbo Basic on the Atari 8-bit, and it allows hex as constants. It does it like so:
10 SCRPTR=DPEEK($58):REM peek in hex
20 LOW=SCRPTR&$FF:REM little endian with bitwise AND
30 HIGH=SCRPTR DIV $FF:REM integer divide
PRINT $FF
255
Just a suggestion, but it also has a command for outputting numbers in hex as a string.
PRINT HEX$(4096)
1000
JavaScript (before strict mode became pretty much the default choice) had particularly bad handling of octal. I once stored numbers up to 99 (decimal) packed into a string with two characters per number - numbers less than 10 were given a leading zero. This worked fine with ‘00’ to ‘07’ when converting them back to numbers, because although JavaScript treated them as octal, that made no difference to the value. But 08 and 09 aren’t valid octal numbers, so JavaScript just ‘helpfully’ converts them both to zero, with no complaint! A very hard bug to track down before you learn the elephant traps built into JavaScript (or nowadays, switch on strict mode).
I never found octal particularly useful, but I’m sure there are programmers out there who like it a lot.
Octal made sense in the era of 6-bit character sets, because you could store two octal digits in a character. One everything went to 8-bit syllables octal didn’t make sense any more, and hex did. But these things have momentum so there was still octal in the late 70s but I do t recall seeing it at all by the early 80s.
I think it also depends on the architecture and how you expect it to be used, as well. For example, to the modern mind, it seems inexplicable that the PDP-11, a 16-bit word machine, is normally an octal device rather than a hexadecimal device. However, the designers expected it to be programmed in assembly or even machine language (to at least a significant degree), and the instruction set breaks down cleanly into mostly three-bit boundaries; for single operand instructions, the operand is normally two three-bit fields (one for addressing mode and one for register, with 8 addressing modes and 8 registers), and double-operand instructions have four three-bit fields. In both cases the remainder of the instruction is simply an opcode that has (relatively) less internal structure. Add to that the fact that the original Unibus had (or very rapidly developed) an 18-bit address space (even though the processor addresses were 16-bit without memory mapping), and poof, a 16-bit octal processor was born. C was then developed on the PDP-11, where all of the address constants for devices and such were normally expressed in octal, and the assembly language normally understood only octal and decimal, and there you have it – octal gets primacy over hex in notation.
My understanding, at least what I’ve read, is that someone up-high in DEC decreed that they use octal for the '11…
The PDP-8, a 12-bit system did use octal and it made sense there- 4 groups of 3-bits, 8 instructions and so on, so people coming to the PDP-11 from the PDP-8 already had some octal brain-cell fusing going on so there was some momentum there already… But maybe it should have stayed with the PDP-8…
And I still remember 177700 / Load Address / Run … Bootstrap the PDP 11/40 I used in 1980…
-Gordon
Are programs in gibl called giblets?
I think, as long as there were still console lights and switches, octal was much easier to parse. Parsing binary to octal and vice versa is easy, even intuitive, hexadecimal not so much. (I guess, 7 segment readouts and keypads, and later on-screen consoles, where a prerequisite for the dominance of hexadecimal.)
For DEC, it may be relevant that the PDP-11 was the first architecture with a bit width that was not a multiple of 3… everything before that was 12, 18 or 36 bits.
On the other hand, before the ‘0o…’ notation was universally implemented and the leading zero notation was throwing an error in strict mode, some things were just absurd. Which also gave us a rare look into a world without octal notation. E.g, we may have had to write code like this in strict mode:
// 18-bit ones' complement addition
ac += operand;
if (ac & parseInt('1000000', 8)) ac = (ac + 1) & parseInt('777777', 8);
if (ac == parseInt('777777', 8)) ac = 0;
So, strict mode wasn’t really an option, if you needed octal.
Mind that when JavaScript was introduced in the mid 1990s, the scenario that some code you wanted to port (esp. “serious” one) was using octal (e.g., a PDP-11 source or something derived from such a source) was quite real. And there are some obvious performance issues with all these string conversions. You really want a viable octal notation for some tasks.
(In this case, we may do with defining some constants, like “OCT_770000”, but the list may grow significantly. And the DX is just awful, if you have to define your own numbers.)
BTW, since it’s that day of the year, obligatory programming joke:
Why do programmers get Halloween and Christmas mixed up?
Because
31OCT = 25DEC.
(I know, it’s old… but there is seldom an opportunity as fitting as this one… 
)
Oh, I like that!
However it will then confuse those who want to mis-pronounce GIBL - might it then be:
Oh joy…
Thanks,
-Gordon
Ps. 3 is correct!
Religious wars of this sort are a sign of a healthy community, no?
Going with the theory that it’s better to talk about it than not to, then … Yes, I think so…
-Gordon
There was a sound clip of Linus demonstrating his pronunciation of Linux… and I think I’ve seen the GIF inventor pronounce the name of his invention too. But in both cases, I have my own variant preference!
Which is to say, by all means Gordon publish a video of your pronunciation of GIBL… but don’t expect me necessarily to follow you…
RetroBASIC 1.8.5 is up. It supports &CAFE, 0xCAFE, 0hCAFE, 0o7272, 0b11001100.
Fixes a few other bits and pieces as well. Still tracking down the bug in amazing.bas which is driving me a bit nuts.
Having documentary proof of the “correct” pronunciation — either via the Internet or via a .au sound clip of Linus saying the thing included with early distros — rather ruins the whole autodidact background of computing for me.
Old computer stuff was learned by reading, not listening. If you heard a term spoken, for me, that’s taking someone else’s word for it. The truth is in the text. Preferably in all-caps.
Personally, I’ll pronounce GIF the “official” way when I start pronouncing Gordon’s name the same as I’d pronounce the name of that river that flows into the Dead Sea …
Fun and true (while lower-case) example, I was somewhat devastated learning the true pronunciation of “char”, as it was pretty clear to me that this was just the front half of character. On the other hand (and back to the topic of BASIC), I wasn’t really sure whether everybody was pronouncing the “$” in “A$” as “string” or if this was just a local habit.
There’s no such thing as a true pronunciation! I think Usenet group names are one example where British and American Englishes take different routes. So it is with char, I think.
For me, A$ is pronounced (or subvocalised) as “A dollar.” It’s one little difficulty I have with APL, I need to subvocalise, and I don’t know all the names. And one or two I might have seen and rejected!
That’s a major problem for me, too, and, while I’m quite fascinated by the concept, never really tried APL. There’s an argument for semi-verbose languages. (This may have contributed to the popularity of BASIC, C, Perl, and some others, which may have hit a sweet spot in this regard.)
I went over this topic a few months ago when I also decided to implement hex/oct and binary bases for my Continuum 93 retro computer. I implemented that for the assembly language interpretor, so it’s not BASIC, but maybe it helps. After a bit of research I decided to add these following notations:
0xFF ; hexadecimal
0b11111111 ; binary
0o377 ; octal
Each of these has a specific purpose. Hexadecimal is broadly used so I won’t go into that. Binary I decided to implement since I do have interrupts that take bit flags (such as which video page to force a draw on) and it’s convenient to represent a number by bits for more readability. Octal I decided to use since my video architecture uses 256 color palettes (8 bit) where RGB values are again conveniently represented by the octal base.
The notation I chose is somehow inspired by higher programming languages and is consistent if you’d like to introduce other bases.
One thing I recommend, if it makes sense for your project, is to introduce a visual separator, such as _ that you’d simply discard when compiling or interpreting. This way, certain numbers can be made more clear to follow:
LD CDEF, 1_000_000_000
LD CDEF, 0x0A_0B_0C_0D
LD CDEF, 0b11110010_00110111_00000001_01100111
Hope this helps, good luck!