3 ms·

Why does anybody listen to Crockford? He wrote a human-readable data format but refused to give it comments. He wrote an obnoxious linter that bans continue;. N

Why does anybody listen to Crockford? He wrote a human-readable data format but refused to give it comments. He wrote an obnoxious linter that bans continue;. Now he's proposing to replace integers with decimal floating point type (what happens if someone wants to store a 64-bit integer?). As a C programmer, he just seems off his trolley.

mark-r 13y ago
How often have you needed a 64-bit integer where a 56-bit one wouldn't do? I rather like the idea of having only one numeric type.
- alkonaut 13y ago
  Still, hardware is inherently base-2. What I'd like to see is hardware assisted adaptive precision predicates and compilers/runtimes that make proper use of modern instructions. I have never ever thougt that float/double/decimal was too much choice.
- alextgordon 13y ago
  As a succinct example, 64-bits is 584 years of nanoseconds. 56-bits is only 2 years of nanoseconds. The problem is that many extant APIs return 64-bit integers, so if your language only has 56-bit integers you are creating a bug/vulnerability every time you want to talk to the outside world. e.g. sqlite has sqlite3_column_int64() to get a value from a result set. How do you use that safely if your language can only do 56-bit ints? Ugly. Remember the "Twitter Apocalypse" when Twitter changed their tweet IDs to be bigger than 56-bits and all the JS programmers had to switch to using strings? Also, bitboards. Bitboards are cool: https://chessprogramming.wikispaces.com/Bitboards https://chessprogramming.wikispaces.com/Bitboards. EDIT: I also reject the premise that just because there's an ugly hack available, we can get rid of useful language features. Am I working for the language or is the language working for me?
  - mark-r 13y ago
    The question is, why do APIs return 64-bit values? In general it's not because they need all 64 bits, it's because the 64-bit integer type is convenient for them. This might make Crockford's proposal completely impractical but it doesn't invalidate the argument that led to it. I reject the nanosecond example because it's completely arbitrary. 64 bits of picoseconds would only cover 0.584 years so should we claim 64 bits isn't enough? Wouldn't 2000 years of microseconds in 56 bits be good enough? I'll give you credit for bitboards though, that's one I hadn't considered.
nawitus 13y ago
>Now he's proposing to replace integers with decimal floating point type Why is that so bad? JavaScript did it.
- bruceboughton 13y ago
  I would suggest that's a strong indicator that it is bad.
- bsder 13y ago
  Wrong. JavaScript has a binary floating point type. This is proposing a decimal floating point type. Which is actually not a bad idea. This "specification" is, however, laughable. Especially since there are quite good decimal floating point specification out there that he could have just stolen^H^H^Hborrowed from.
  - nawitus 13y ago
    I stand corrected. I somehow read that as 'replace integers with floating point type'.
    - bsder 13y ago
      Which is not bad if that floating point type is decimal. All of your integers do what they're supposed to. In addition, things like the standard programming fail of using "i += 0.1;" as a loop iterator actually work when you use decimal floating point. Also, things like converting to/from strings become operations with a priori bounded limits just by taking a quick look at the number of digits if you have decimal floating point. This is not true for binary floating point. There is a reason why printf libraries are so blasted huge and have malloc issues--it's the binary floating point conversions. Much of the stupidity we encounter in dealing with floating point (inexact numbers on exact decimals, silly rounding, inability to handle significant figures, weird conversion to/from strings) simply goes away if you use decimal floating point. In addition, if you go back through the ECMAScript archives, they actually thought about this back in ECMAScript4 but rejected it for some good reasons. I don't agree with those reasons, but they did think about and discuss them.

mark-r 13y ago

How often have you needed a 64-bit integer where a 56-bit one wouldn't do? I rather like the idea of having only one numeric type.

alkonaut 13y ago
Still, hardware is inherently base-2. What I'd like to see is hardware assisted adaptive precision predicates and compilers/runtimes that make proper use of modern instructions. I have never ever thougt that float/double/decimal was too much choice.
alextgordon 13y ago
As a succinct example, 64-bits is 584 years of nanoseconds. 56-bits is only 2 years of nanoseconds. The problem is that many extant APIs return 64-bit integers, so if your language only has 56-bit integers you are creating a bug/vulnerability every time you want to talk to the outside world. e.g. sqlite has sqlite3_column_int64() to get a value from a result set. How do you use that safely if your language can only do 56-bit ints? Ugly. Remember the "Twitter Apocalypse" when Twitter changed their tweet IDs to be bigger than 56-bits and all the JS programmers had to switch to using strings? Also, bitboards. Bitboards are cool: https://chessprogramming.wikispaces.com/Bitboards https://chessprogramming.wikispaces.com/Bitboards. EDIT: I also reject the premise that just because there's an ugly hack available, we can get rid of useful language features. Am I working for the language or is the language working for me?
- mark-r 13y ago
  The question is, why do APIs return 64-bit values? In general it's not because they need all 64 bits, it's because the 64-bit integer type is convenient for them. This might make Crockford's proposal completely impractical but it doesn't invalidate the argument that led to it. I reject the nanosecond example because it's completely arbitrary. 64 bits of picoseconds would only cover 0.584 years so should we claim 64 bits isn't enough? Wouldn't 2000 years of microseconds in 56 bits be good enough? I'll give you credit for bitboards though, that's one I hadn't considered.

nawitus 13y ago

>Now he's proposing to replace integers with decimal floating point type Why is that so bad? JavaScript did it.

bruceboughton 13y ago
I would suggest that's a strong indicator that it is bad.
bsder 13y ago
Wrong. JavaScript has a binary floating point type. This is proposing a decimal floating point type. Which is actually not a bad idea. This "specification" is, however, laughable. Especially since there are quite good decimal floating point specification out there that he could have just stolen^H^H^Hborrowed from.
- nawitus 13y ago
  I stand corrected. I somehow read that as 'replace integers with floating point type'.
  - bsder 13y ago
    Which is not bad if that floating point type is decimal. All of your integers do what they're supposed to. In addition, things like the standard programming fail of using "i += 0.1;" as a loop iterator actually work when you use decimal floating point. Also, things like converting to/from strings become operations with a priori bounded limits just by taking a quick look at the number of digits if you have decimal floating point. This is not true for binary floating point. There is a reason why printf libraries are so blasted huge and have malloc issues--it's the binary floating point conversions. Much of the stupidity we encounter in dealing with floating point (inexact numbers on exact decimals, silly rounding, inability to handle significant figures, weird conversion to/from strings) simply goes away if you use decimal floating point. In addition, if you go back through the ECMAScript archives, they actually thought about this back in ECMAScript4 but rejected it for some good reasons. I don't agree with those reasons, but they did think about and discuss them.