4 ms·

The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (

• WalterBright 6mo ago
  > 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, whether it's a 32 bit machine or a 64 bit machine. The result was we haven't had porting problems with integer sizes.
  • afpx 6mo ago
    That's a reasonable answer. But, I meant they seemed to have little understanding or interest. I don't interview much, and I'm probably a poor interviewer. But, I guess I was expecting some discussion.
    • WalterBright 6mo ago
      I ran into some comp sci graduates in the early 80's who did not know what a "register" was. To be fair, though, I come up short on a lot of things comp sci graduates know. It's why Andrei Alexandrescu and I made a good team. I was the engineer, and he the scientist. The yin and the yang, so to speak.
      • sas224dbm 6mo ago
        Oooh, saw Andrei's name pop up and remember his books on C++ back in the day .. ran into a systems engineer a while ago that asked why during a tech review asked why some data size wasn't 1000 instead of 1024.. like err ??
  • switchbak 6mo ago
    It's substantially worse on the JVM. One's intuition from C just fails when you have to think about references vs primitives, and the overhead of those (with or without compressed OOPs). I've met very few folks who understand the overheads involved, and how extreme the benefits can be from avoiding those.
    • Quarrelsome 6mo ago
      Conversely I've met many folks who come into managed environments and piss away time trying to wrangle the managed system into how they think it should work, instead of accepting that clever people wrote it and guidelines when followed result in acceptable outcomes. The sort of insane stuff I've seen on the dotnet repo where people are trying to tear apart the entire type system just because they think they've cracked some secret performance code.
      • andai 6mo ago
        >on the dotnet repo You mean the .net compiler/runtime itself? I haven't looked at it, but isn't that the one place you'd expect to see weirdly low-level C# code?
    • awesome_dude 6mo ago
      My favourite JVM trivia, although I openly admit I don't know if it's still true, is the fact that the size of a boolean is not defined. If you ask a typical grad the size of a bool they will inevitably say one bit, but, CPUs and RAM, etc don't work like that, typically they expect WORD sized chunks of memory - meaning that the boolean size of one but becomes a WORD sized chunk, assuming that it hasn't been packed
      • KnuthIsGod 6mo ago
        ". While it represents one bit of information, it is typically implemented as 1 byte in arrays, and often 4 bytes (an int) or more as a standalone variable on the stack "
    • gf000 6mo ago
  • m463 6mo ago
    Even more fun is pointers, especially when windows / macos were switching from 32-bits to 64-bits (in different ways).
    • WalterBright 6mo ago
      Microsoft tried valiantly to make Win16 code portable to Win32, and Win32 to Win64. But it failed miserably, apparently because the programmers had never ported 16 bit C to 32 bit C, etc., and picked all the wrong abstractions.
    • AdieuToLogic 6mo ago
      > Even more fun is pointers, especially when windows / macos were switching from 32-bits to 64-bits (in different ways). And yet even more of a fun time with porting pointer code was going from the various x86 memory models[0] to 32-bit. Depending on the program, the pain was either near, far, or huge... :-D 0 - https://en.wikipedia.org/wiki/X86_memory_models https://en.wikipedia.org/wiki/X86_memory_models
  • andai 6mo ago
    Why did they design it like that? It must have seemed like a good idea at the time.
    • WalterBright 6mo ago
      C is a portable language, in that programs will likely compile successfully on a different architecture. Unfortunately, that doesn't mean they will run properly, as the semantics are not portable.
      • LPisGood 6mo ago
        So what’s the point of having portable syntax, but not portable semantics?
        • WalterBright 6mo ago
          C certainly gives the illusion of portability. I recall a fellow who worked on DSP programming, where chars and shorts and ints and longs were all 32 bits. He said C was great because that would compile. I suggested to him that he'd have a hard time finding any existing C code that ran correctly on it. After all, how are you going to write a byte to memory if you've only got 32 bit operations? Anyhow, after 20 years of programming C, I took what I learned and applied it to D. The integral types are specified sizes, and 2's complement. One might ask, what about 16 bit machines? Instead of trying to define how this would work in official D, I suggested a variant of D where the language rules were adapted to 16 bits. This is not objectively worse than what C does, and it works fine, and the advantage is there is no false pretense of portability.
    • jandrewrogers 6mo ago
      In ancient computing times, which is when C was birthed, the size of integers at the hardware level and their representation was much more diverse than it is today. The register bit-width was almost arbitrary, not the tidy powers of 2 that everyone is accustomed to today. The integer representation wasn't always two's complement in the early days of computing, so you couldn't even assume that. C++ only required integer representations to be two's complement as of C++20, since the last architectures that don't work this way had effectively been dead for decades. In that context, an 'int' was supposed to be the native word size of an integer on a given architecture. A long time ago, 'int' was an abstraction over the dozen different bit-widths used in real hardware. In that context, it was an aid to portability.
  • account42 5mo ago
    > That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. Don't you mean Windows instead of Mac? Most Unix-like operating systems use LP64 while Windows uses LLP64.
• ekidd 6mo ago
  I mean, as a senior developer, the number of bits in an "int" is "who the hell knows, because it has changed a bunch of times during my career, and that's what stdint.h is for." And let's not even talk about machines with 32-bit "char" types, which I actually had to program for once. If the number of bits isn't actually included right in the type name, then be very sure you know what you're doing. The senior engineer answer to "How many bits are there in an int?" is "No, stop, put that down before you put your eye out!" Which, to be fair, is the senior engineer answer to a lot of things.
• SAI_Peregrinus 6mo ago
  How many bits are in an `int` in C? What do you mean "at least 16", that's ridiculous, nobody would write a language that leaves the number of bits in basic elementary types partially specified‽
  • bluGill 6mo ago
    It is a good idea - most of the time you don't care, and on slower systems a large int is harmful since the system can't handle that much and it cost performance - go to the faster system with larger ints when you need larger intw.
• estimator7292 6mo ago
  On the one hand, in today's world asking how many bits is in an int is exactly as answerable as "how long is a piece of rope" On the other, the right answer is 16 or 32. It's not the correct answer, strictly speaking, but it is the right one.
  • jandrewrogers 6mo ago
    An 'int' is also 64 bits on some platforms.
  • fragmede 6mo ago
    It's the wrong question. How many bits is uint64 is a much better question, if we're at a place where that's relevant.
• i_am_a_peasant 6mo ago
  I had one tell me all ints are 16 bits, and then they said 0xffff is a 32bit number.