3 ms·

An elegant data type for a more civilized age

11 points by bratfarrar 14y ago

stcredzero 14y ago
> Using primitives is a good discipline, specifically because your default programming techniques should be clean, simple, efficient. The point isn’t that you should be prematurely optimizing your code, but rather that when given a choice between two nearly identical approaches, you shouldn’t irrationally choose the less performant option without a good reason. By the same token, you shouldn't arbitrarily pick the non-object solution without considering the other code interacted with. > If your language’s standard libraries included both quicksort and bubblesort, you should never choose the latter. Not entirely true. If you know n <= 8 or some small number, you might want to.
- dancast 14y ago
  No - bubble sort is pretty much always the wrong answer. All modern quicksort implementations switch to insertion sort when N is small enough.
  - stcredzero 14y ago
    In that case, it's pretty disingenuous of him to have bubble sort as analogous to Objects in his analogy.
- seanmcdirmid 14y ago
  ...or if your list is almost already sorted, but in that case better to use insertion sort instead.
deleted 14y ago
[deleted]
aardvark179 14y ago
I'm not sure how Ruby handles the numbers as objects case internally, but just because something looks like an object doesn't stop it from actually being a tagged pointer underneath, and will not have the same storage and allocation costs.
martinced 14y ago
The author of the article needs to be reminded a bit as to how Java works and as to what "good practices" are. I'm sorry but when I stumble upon such obvious mistakes I can't take such an article seriously: "Integer boxed = 0; // i.e., boxed = new Integer(0);" No, that's not how it works. Values between [-128..127] are guaranteed to give back cached instances: there's no object creation here. "on a 64-bit JVM you can double the size of every pointer" No, no and no. 64-bit JVMs do offer compressed pointers precisely to not 'waste' countless bits that are always going to be set at zero. "...in fact boxed has the advantage of also having a 'null' value which can indicate an unset value." Having objects which may or may not be initialized is not necessarily a very good way to code. What's next: using NullPointerException as flow control? Since Jetbrains / IntelliJ IDEA introduced their @NotNull annotation (years and years ago) I've been using it religiously and can hardly remember what a NPE is in my own code (it's another matter when using poorly designed 3rd party APIs of course). But what else do you expect from a "game programmer" who writes professional games in Java? Because we all know Riot Games, Blizzard, etc. all write their games in Java without using primitives right? And, from a performance standpoint, we all long for Java 10 which may not give access to primitives anymore right?
- struppi 14y ago
  So true! Also, the JIT compiler of the JVM does dome things that are pretty close to magic, at least from my point of view. And I guess Oracle will continue to improve it. I know the following is a "Sufficiently smart compiler"-type argument, but: It's not entirely impossible that future versions of the JVM - where primitives "don't exist anymore" - would simply use primitives when they detect that it's possible.

11 points by bratfarrar 14y ago

> Using primitives is a good discipline, specifically because your default programming techniques should be clean, simple, efficient. The point isn’t that you should be prematurely optimizing your code, but rather that when given a choice between two nearly identical approaches, you shouldn’t irrationally choose the less performant option without a good reason. By the same token, you shouldn't arbitrarily pick the non-object solution without considering the other code interacted with. > If your language’s standard libraries included both quicksort and bubblesort, you should never choose the latter. Not entirely true. If you know n <= 8 or some small number, you might want to.

dancast 14y ago
No - bubble sort is pretty much always the wrong answer. All modern quicksort implementations switch to insertion sort when N is small enough.
- stcredzero 14y ago
  In that case, it's pretty disingenuous of him to have bubble sort as analogous to Objects in his analogy.
seanmcdirmid 14y ago
...or if your list is almost already sorted, but in that case better to use insertion sort instead.

deleted 14y ago

[deleted]

aardvark179 14y ago

I'm not sure how Ruby handles the numbers as objects case internally, but just because something looks like an object doesn't stop it from actually being a tagged pointer underneath, and will not have the same storage and allocation costs.

martinced 14y ago

The author of the article needs to be reminded a bit as to how Java works and as to what "good practices" are. I'm sorry but when I stumble upon such obvious mistakes I can't take such an article seriously: "Integer boxed = 0; // i.e., boxed = new Integer(0);" No, that's not how it works. Values between [-128..127] are guaranteed to give back cached instances: there's no object creation here. "on a 64-bit JVM you can double the size of every pointer" No, no and no. 64-bit JVMs do offer compressed pointers precisely to not 'waste' countless bits that are always going to be set at zero. "...in fact boxed has the advantage of also having a 'null' value which can indicate an unset value." Having objects which may or may not be initialized is not necessarily a very good way to code. What's next: using NullPointerException as flow control? Since Jetbrains / IntelliJ IDEA introduced their @NotNull annotation (years and years ago) I've been using it religiously and can hardly remember what a NPE is in my own code (it's another matter when using poorly designed 3rd party APIs of course). But what else do you expect from a "game programmer" who writes professional games in Java? Because we all know Riot Games, Blizzard, etc. all write their games in Java without using primitives right? And, from a performance standpoint, we all long for Java 10 which may not give access to primitives anymore right?

struppi 14y ago
So true! Also, the JIT compiler of the JVM does dome things that are pretty close to magic, at least from my point of view. And I guess Oracle will continue to improve it. I know the following is a "Sufficiently smart compiler"-type argument, but: It's not entirely impossible that future versions of the JVM - where primitives "don't exist anymore" - would simply use primitives when they detect that it's possible.