It may gives them less headache but if the part about the antivirus flagging the exécutable as suspicious it may give the users headaches..

I still find weird that they didn't make A,B... just after the digits, that would make binary to hexadecimal conversion more efficient..

Going off the timelines on Wikipedia, the first version of ASCII was published (1963) before the 0-9,A-F hex notation became widely used (>=1966):

- https://en.wikipedia.org/wiki/ASCII#History

- https://en.wikipedia.org/wiki/Hexadecimal#Cultural_history

The alphanumeric codepoints are well placed hexadecimally-speaking though. I don't imagine that was just an accident. For example, they could've put '0' at 050/0x28, but they put it at 060/0x30. That seems to me that they did have hexadecimal in consideration.

It's a binary consideration if you think of it rather than hexadecimal.

If you have to prominently represent 10 things in binary, then it's neat to allocate slot of size 16 and pad the remaining 6 items. Which is to say it's neat to proceed from all zeroes:

    x x x x 0 0 0 0
    x x x x 0 0 0 1
    x x x x 0 0 1 0
    ....
    x x x x 1 1 1 1

It's more of a cause for hexadecimal notation than an effect of it.

Currently 'A' is 0x41 and 0101, 'a' is 0x61 and 0141, and '0' is 0x30 and 060. These are fairly simple to remember for converting between alphanumerics and their codepoint. Seems more advantageous, especially if you might be reasonably looking at punchcards.

[0-9A-Z] doesn't fit in 5 bits, which impedes shift/ctrl bits.

I'm not sure if our convention for hexadecimal notation is old enough to have been a consideration.

EDIT: it would need to predate the 6-bit teletype codes that preceded ASCII.

They put : ; immediately after the digits because they were considered the least used of the major punctuation, so that they could be replaced by ‘digits’ 10 and 11 where desired.

(I'm almost reluctant to to spoil the fun for the kids these days, but https://en.wikipedia.org/wiki/%C2%A3sd )

I worked (a long time ago) on a C project where every int was wrapped in a struct. And a friend told me about a C++ project where every index is a uint8, uint16, and they have to manage many different type of objects leading to lots of bugs.. So it isn't really linked to the language.

I've seen some issue with this approach is that management will want to sell the prototype, bypassing the "rewrite from the lesson learned" step, and then every shortcut took into the prototype will bite you, a lot..

And things like "race conditions"/lack of scalability due to improper threading architecture aren't especially easy to fix(!)..

The Anna Karenina principle looms large in software engineer projects. Basically there are an infinite failure modes that can occur due to small actions or wrong thinking by one or more influential people, but there is only one way to make large projects successful. Basically the team has to have sufficient expertise to cover the surface area, and those individuals need enough trust from leadership to navigate the million known and unknown pitfalls that await.

You don't ever make the prototype public.

Also, there's a certain point where you can't avoid management sabotaging things.

Sometimes you don't know what needs to be built until you build it. These end-to-end prototypes are how to enhance your understanding and develop deeper intuition about possibilities, where risks lie, etc.

It's a minor detail but list starting at 1, with -1 being the last élément and 0 being 'none' is weird.. Why did you make this choice instead of 0 for the first élément, -1 for the last one? It would avoid the 0 'trap'.

Not Tomo’s developer, but my position on the 1 vs. 0 for list-like object indexing goes like…

1) using 0 as the index of the first element in a list-like object ISA holdover from C (most of the earlier languages used either 1 based or flexible base for indexing);

2) in C, 0 is the index due to the manner of C’s array indexing implementation;

3) if holding onto the C semantics (or syntax in some respects) is not an explicit goal of the language, then flexible indexing should be the default (declared at creation point for the list-like object);

4) in flexible default is not appealing to the language designer, and again, maintaining C semantics is not a goal, then 1 based should be the next reasonable default.

For me, when counting things (and most other native English speakers, if not most people in general), the first item counted is object 1. Therefore, 1 should be the index of the beginning of the list-like objects indexing.

I’m not sure how about 0 being ‘None’, but I might find it intuitive if thinking more about it.

Obligatory reference: http://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF

> Eventually both Windows and Linux programs moved to a model where the OS just gave you the window as a drawing surface, and you were supposed to fill it.

If you follow this model, how do you solve the accessibility issue?

>signed integer overflow being UB would count for C/C++

Then, I raise you to Zig which has unsigned integer overflow being UB.

Interestingly enough, Zig does not use the same terminology as C/C++/Rust do here. Zig has "illegal behavior," which is either "safety checked" or "unchecked." Unchecked illegal behavior is like undefined behavior. Compiler flags and in-source annotations can change the semantics from checked to unchecked or vice versa.

Anyway that's a long way of saying that you're right, integer overflow is illegal behavior, I just think it's interesting.

Rust has UB overflow as well, just unsafe.

https://doc.rust-lang.org/std/intrinsics/fn.unchecked_add.ht...

> Java everything is boxed anyway

Not true, there's int and Integer.

Right but you can’t use them as type arguments to Java’s generics so they’re not really relevant in this context.

> I noticed during my three week summer vacation that it took me a good week to unwind and slow down.

It depends a lot on what you do on your holiday. I think it's best to start with something "mind focussing": you're not going to think about your job while skydiving, scuba-diving etc.

For && and || I disagree: they are 'shortcircuiting' operators and as such they deserve a différent name than just 'and', 'or'. That said &| should have been named and,or which would have freed &| to use for the shortcircuit operators.