Hacker News Reader

Comment by danbruc | Hacker News Reader

He did not need the choice but others do. And he is wrong when he says it makes no difference whether you use a byte or eight of them. Yes, it will take the same amount of time to add two of them but it will also cost eight times more cache space and memory bandwidth to move them around. It may not be an issue if you have a single number or ten of them but it certainly becomes one if you have an array with millions or billions of them.

View on HN

There are use cases where you need the choice, but most people do not need the choice.

Most programs written in the real world (enterprise-y Java apps) do not need strong control on GC, choice of integer types, or many other things offered to them. Reducing choice will increase code/tool quality.

I think that we should make the uncommon choice reallllly hard to put into place. Make it a pain to configure the GC, give specific integer types really long names. Just stop people from premature optimization and leave these tools to people who know what they're doing.

If you are unable to make good decision between different number types you better don't write software, IMHO. How do you reason about the operations you apply to your data if you are ignorant of the possible values?

I write software, and the amount of times I even have to explicitly manipulate numbers in a given week is very close to zero. Even iteration is done through iterators instead of indexes, so writing a plus sign is done pretty sparingly.

Data manipulation beyond "pull out of database" or "submit user input to database" is a lot rarer in enterprise software like this than in scientific computing. I'm not saying it's bad to be aware of it, but software is more than numbers.

I develop enterprise software, too, and I definitely think it matters there, too. You better make sure your database columns have the correct number type or you will get in trouble if your inventory numbers or monetary values start showing rounding errors.

You are comparing two different types of numbers.

What was originally compared was different sized integral types.

What you are comparing is two numeric types that have a large semantic gulf (fractions vs integers).

So your point is disingenuous in the context of the former.

I just wanted to address your point that enterprise software does usually not involve dealing with numbers.

When it comes to integers you are right - signed and 32 bits is a viable choice in north of 90 % of all cases. And when I wrote you should be able to make good decision about the number type to use I was already thinking of all the number types, however I did not express this well. But then I really don't see a lot of difference between being able to choose between integer, floating point and decimal types on the one hand and various integer types on the other hand.

Yeah, you're right, data types matter. Like sibling said, this was more in response to signed/unsigned or different bit sizes. We could get rid of minutiae while still allowing for broad choice when it actually matters.

I do think that the difference between Integer/Fractional is important, but honestly if you're dealing with money you should be using some Money datatype that's smart about this instead of raw numbers.

Even if you abstract away the indexes, when working with datasets that large you have to worry about whether the standard implementation makes the same class of error.

For example, using Java's binarySearch on arrays of length over 2^30 was broken until 2006[0][1].

[0]: http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

[1]: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5045582

>If you are unable to make good decision between different number types you better don't write software, IMHO.

Doesn't sound very humble, this "HO".

Do you know how many programmers that run circles around you (and me) have done mistakes similar to what Doug describes?

Being able to make good decisions does not guarantee you will never make a mistake. And he even explains his reasoning behind his choice and it was a justifiable decision when he made it. But I stand by what I said - if you are unable to decide between using 8 bit or 64 bit integers or a floating point type or a decimal type you should not be a professional software developer because it is really a very basic and fundamental skill.

Then what do you propose we call the people who write Ruby, Python, Javascript, PHP, etc. code for a living? Have you heard of accidental complexity?

Ruby, Python and PHP all support several types of numbers. But even if they did not this would not preclude people developing in those languages from being able of making such decisions.

In the web industry, which is the biggest part of the software industry by people employed, most developers use dynamically typed languages and very happily never make this "fundamental" choice. Should they all resign?

Not only web industry: in Smalltalk every integer can have unlimited number of bits. On 32-bit systems internally 31 bit is used first and with overflow it automatically starts using variable size integers... There is no need to make a choice on the number of bits... Just use integers as they are in the nature...

Dynamically typed does not mean that you don't have to think about number types - 3/2 and 3/2.0 may yield different results in dynamically typed languages.

And how many web developers don't know about or are unable to decide between different number types? JavaScript type coercion is such a mess, how could you get away without thinking about types, even though number types are usually not an issue?

"JavaScript type coercion is such a mess" - in what way? Seriously.

In what way it isn't? Just look at this beauty [1] and its consequences. But probably nobody uses the equality operator anymore because it is such a mess. Less than is even more messed up [2].

[1] http://people.mozilla.org/~jorendorff/es5.html#sec-11.9.3

[2] http://strilanc.com/visualization/2014/03/27/Better-JS-Equal...

`" " == 0 == false`, and `"" == 0 == false`, but `" " != ""`.

`"Infinity" == Infinity`, but `"true" != true`.

I could go on for a while like this.

And which of those persist if you use ===?

None - because === does not coerce types. Type coercion, not double-equal weirdness as such, is the gripe of the GGP. Non-transitive, inconsistent equality is nothing more than a symptom of JS's rules for implicit conversions.

Language-war disclaimer: I love javascript and everything, it's a very expressive language; but a good wodge of the tooling around it nowadays is to help people avoid things like implicit type-coercion 'surprises'.

That is not specifically type coercion, but the behavior of the equality (==) operator in JavaScript. Type coercion in JavaScript can be very useful, for example !!('foo') is coercive and easily understood (and has an unsurprising result). Thankfully the == operator is completely optional and has a more easily understood === (identity) correspondent, making your point less about a language and more about a specific operator within a language.

It is type coercion. The runtime converts both operands to the same type before making the comparison (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). This is also true of !, <, and friends.

Other operators in JavaScript may behave more intuitively than ==, but I don't think you can really make a good case for JavaScript's type coercion being 'unsurprising'.

I suppose what I meant was that you point out that the coercive behavior of some operators is counter intuitive; ergo type coercion in JS is a mess. I dont think that follows because some operators behave in a coercive fashion more convenient than many other languages.

Well, your first line doesn't make sense, since the first two comparisons are using type coercion but the third isn't, so it's like saying `0 == false` but `0 !== false` how can this be? (" " != "" is the same as " " !== "")

The second line at least uses type coercion, but still you are making the wrong assumptions. true could be coerced to many strings 't', '1', 'true', 'yes', 'on', but they chose to use '1' (You may not like it but I think it's a good choice). Infinity on the other hand has not many choices when coercing it to a string I can think of '∞' (which is difficult to type), 'Infinity', and maybe 'Inf.' so I think they made a good choice here.

I'm not saying type coercion in js has no problems, but you said that it's a mess and I just think you chose the wrong examples.

Thankfully Python fixed that discrepancy about 3/2

Anyhow, I don't agree with you: I think that getting a bug years down the road due to a too small numeric type is something that the programming language itself should avoid.... not because "developers don't ought to know it", but because mistakes happen

Anyhow, even with a dynamically typed programming language like Python or Javascript you can care about the size of your numbers.

Just import the array module (in Python) or use the Int32Array/Int8Array/etc. types (in Javascript)

I guess that most programming languages, with possible exception of COBOL, were not created with boring stuff - like enterprise-y apps or webdev, that compose most of the programming today - in mind.

I don't believe he said it makes no difference.

»But in todays CPUs there is no advantage using the short thing. You can add 64 bits or 8 bits, takes the same amount of time. And you look up what is the cash value of having saved seven bytes on a number. When you add that up it is zero. So there is no benefit.« [1]

As long as you are concerned with adding a bit of eye candy and interactivity to a web page this may be true enough to get away with the JavaScript way of making every number a double precision floating point number but there a other domains where this will not fly. And even in the world of JavaScript asm.js is trying hard to overcome this limitation.

[1] http://www.youtube.com/watch?v=bo36MrBfTk4&t=42m17s

>but there a other domains where this will not fly.

Sure, and I believe everybody, including Doug, knows this not so subtle distinction. He wasn't talking about programming HPC for NASA.

He is comparing Java and JavaScript and implies that it is a bad choice of Java to offer several options. And given the broad range of applications Java is used for I don't think this is a justifiable opinion.

But in java (64-bit JVM) this statement is true: "You can add 64 bits or 8 bits, takes the same amount of time."

Reply on news.ycombinator.com