Big-Endian "is effectively dead" - <AUTHOR> http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937733 <comment><USER2> Linkbait much? Further down below, Torvalds explains precisely why BE is anything _but_ dead. All that's dead is general-purpose CPUs using it, mostly because x86 happened.

[http://geekandpoke.typepad.com/geekandpoke/2011/09/simply- ex...](http://geekandpoke.typepad.com/geekandpoke/2011/09/simply- explained-1.html)

(Edit: which is precisely why I prefer BE for anything, unless there is a pressing - usually hardware- and performance-related - requirement for the opposite. Computers are good at reading bytes in swapped order. I suck at it.)

<comment><USER3> Well, and IBM switched Power to little endian recently (the machines are dual endian, but all the new OSs are littl endian only). Power was the main BE architecture left. Most arm machines are dual endian, and NetBSD supports both, but almost everyone uses little endian on arm. There is a bit of big endian mips around still, eg the Cavium network appliances.

<comment><USER4> IBM also for years screamed at devs that you can't rely on a PPC system being BE. Which means all oldworld MacOS software was at least theoretically written by people who couldn't tell you what byte order they were writing for. (How seriously the devs took that admonition is a different question.)

<comment><USER5> The PowerPC _architecture_ was bi-endian, but classic Mac OS was very definitely big-endian. The only situation where the CPU would switch to little-endian would be if it was running Virtual PC. (And even then, it'd switch back for other applications.)

<comment><USER4> Sorry, yeah, I stated that badly:

 _Apple_ kept screaming at devs that _IBM_ couldn't be guaranteed to keep the arch bi-endian, so _Apple_ couldn't guarantee a big-endian platform and developers shouldn't assume one.

</comment></comment></comment></comment></comment><comment><USER4> ARM still lets you switch endianness, but nobody other than me ever seems to (and they claim they will probably deprecate that going forward).

What is really alarming to me is that I occasionally run into middle-endian systems on 64-bit chips (two little-endian doubles in big-endian relative order, to signify a single quad). This is an abomination and must be killed with fire.

<comment><USER6> They do. They are bi-endian and default to little on most systems I have seen. The only real big endian system I have left is an old sun Netra.

<comment><USER7> And it's funny you should mention Sun Microsystems, because this is the influence behind Java's endian-ness, and subsequently Dalvik (mentioned below in another comment), which happens to be... you guessed it... big endian.

So the big endian gene lives on in the JVM and its relatives.

<comment><USER8> Java is seriously nasty if you need to work with bitpacked representations of data structures. Big endian nonsense, no unsigned types, booleans that cannot be converted to integer types, no typedefs... gahhhh! It's really freaking hard to write optimised code in this stupid language.

<comment><USER9> > no unsigned types

Java 8 has unsigned types[1]

> boolean that cannot be converted into integer types

Don't know why you would want to do that when a boolean is a primitive type... and also has an object variant, but...

int myInt = (myBoolean) ? 1 : 0;

> no typedefs

A typedef is really like a java bean or class object... it's just a custom data structure.

> It's really freaking hard to write optimised code in this stupid language.

Not true, some of the most highly performant systems on the planet run Java... HFT, stock exchanges, banking, nuclear plant control systems, etc...

There's also the JVM with it's optimizing compiler... one of the best (the best?) optimizing compilers around. Long running Java applications eventually compile hot paths down to native machine instructions, achieving C performance without a lot of the hassle.

But then again, Java wasn't intended to do bit-twiddling, it's a higher abstraction.

[1] [https://docs.oracle.com/javase/8/docs/api/java/lang/Integer....](https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#toUnsignedLong- int-)

<comment><USER10> > Java 8 has unsigned types

Right. Now try that with a long, and you're replacing every piece of code with something that's, what, 20x more verbose? If not more? And becuase of how bad the JVM is, substantially slower.

Look at JGit.

> int myInt = (myBoolean) ? 1 : 0;

Now try to do that throughout the code. Not to mention which, that's a conditional branch for what should be (and is in bytecode) a no-op. (Well, assuming your bytecode is well-conditioned. But the JVM being the JVM, there's no such thing as a boolean, which means you can have the "boolean" value 2, for instance, which seriously messes all sorts of things up.)

Sure, the JVM is supposed to optimize that out. But you can't rely on it being able to do so. At least not if you're not going to use a mainstream JVM.

And no, the JVM is not "one of the best" optimizing compilers around. It's not even a _good_ optimizing compiler. Nowhere near. For a quick counterexample, this: [https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f8...](https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f80a76fc1911d77ae39153783fdc3)

Halving the time taken. Why? Because the JVM wasn't smart enough to realize that copying an EnumSet for a readonly foreach loop was unnecessary. Oh, and there's more low-hanging fruit there w.r.t. the amount of work (read: reflection) EnumSet has to do behind the scenes to work around Java's type system. Simple. But no, the Java compiler doesn't optimize it out, and the JVM doesn't either.

And that's _with_ adding an additional unnecessary layer of abstraction (unmodifiableSet) that you wouldn't need if Java had a sane type system.

Copying an EnumSet of a small number of elements would be, in a sane language, quite literally just a register move. Ditto, containsAll a bitwise-not and a bitwise-and. But no, "one of the best" optimizing compilers around cannot even do that.

Trying to write high-performance code in Java generally requires tossing out all the supposed advantages of Java. Write your own object pools, whee! Hardcode your own primitive types, whee! Avoid temporary objects, whee! Avoid using polymorphism, whee! Manually unpack arrays inside objects, whee!

<comment><USER11> My experience with a lot of 'Javaheads' is that they get a little _too_ emphatic about Java's optimizations, most especially the claim that it can out perform C.

BUT

In this case, to be fair, I took his statement to include Hotspot, which can do some pretty cool stuff provided you meet the requirements for it. ie, be long running, have enough memory and horsepower available on the machine to run hotspot, and have paths through the code that rarely jump around (meaning most executions go through the same path).

If you can meet those requirements, my understanding is that the Java _ecosystem_ does a damned fine job.

The issue is that a lot of javaheads will extrapolate that out to the rest of the language and tech and start making claims about Java being the best overall at X, or as fast as language Y (C or C++, take your pick).

<comment><USER10> This was something that was supposed to be about the single best case for hotspot: a single code path almost always, inside a single while loop that's doing the same thing over and over, with a couple sanity / bail-out checks that are rarely (if ever) called.

And it _still_ didn't optimize something as trivial as avoiding an unnecessary copy that it was taking ~50% of the time doing.

It's too bad - Java is a fine language in many ways (though it tends to be rather overly verbose for no good reason, but meh. Looking at you getters and setters and lack of operator overloading), but it's saddled with a reliance on the arcane to actually get non-hideous performance out of it. I mean: 13ms per copy of what should be a single integer? (Milliseconds! I'm not joking. 595ms inside 47 calls to EnumSet.copyOf (mainly inside Object.clone))

That's, and I'm saying this quite literally, more than a _million_ times slower than what it should be.

Assuming it needs to be done at all, and you can trivially show that it doesn't.

(That being said, I need to explicitly check that Hotspot does do it's full optimization pass on that chunk of code. I see no reason why it wouldn't, but maybe Hotspot doesn't want to. Though that'd be a WTF in and of itself.)

(On a side note: does Java cache hotspot optimizations? I think it does, in which case there's definitely no excuse. And if it doesn't that's a wtf in and of itself.)

(On another side note: is there a Java bytecode-to-bytecode optimizer that'll do optimizations based on the code you've got in front of you _now_?)

<comment><USER11> I honestly don't know too much about Java and its technologies outside of a general understanding of it. I specifically chose to stay out of the Java ecosystem years ago because I disliked the Java community as a whole. They had a real beef with C and C++ being more performant and constantly pushed and railed against both C and C++ to the point of being what I considered completely divorced from reality.

Java as a tech is strong, but Java as a community was full of pretentious assholes who had a complex about performance (in my opinion of course).

I have no doubt your example was most likely due to some technical issue preventing hotspot from doing what it should have. When hotspot can do it's work it's amazing, you just have to enable it, and you're right about doing arcane things to get performance. That's true in any GC'd language though, even .Net has it's boogeymen.

<comment><USER10> This isn't anything to do with GC.

This is purely an optimization issue, and one that can be done regardless of if a language is GC'd or not.

<comment><USER11> You're speaking of this specific issue, I'm speaking in general.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I'm not much into low-level CPU architectures, so I have to ask: Is there a technical reason (performance or whatever) why LE would be objectively better than BE?

I do read hex dumps & disassemblies, and there LE is a huge pain in the backend. Everything is in reverse. Why would a sane programmer voluntarily use LE?

God Save the Network Byte Order!

<comment><USER13> I think the main advantage I see in LE architectures is that integral types don't have to relocate. For example, the int32 value 30 is represented in memory as "1E 00 00 00". The int16 value 30 is represented in memory as "1E 00". So casting downwards means that the pointers are the same, and you just ignore the trailing 0s. Contrast this to BE architectures, where you have "00 00 00 1E" vs "00 1E" \-- casting from the larger to the smaller type means that you have to move the pointer.

<comment><USER14> Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x.

Contrast with a big-endian representation, where the byte at offset x would have weight 256^(length - 1 - x).

<comment><USER15> >Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x.

This is literally the opposite of how most programmers in the world write numbers naturally.

See "1234". The digit at offset x _from the right_ has weight 10^x. That corresponds to big-endian.

Considering that the only important difference between little and big endian is when people have to read or write it by hand, we should probably model it after common human representation...

<comment><USER16> By the way, this "natural" way of writing numbers comes unchanged from right- to-left writing system of Arabic. They naturally read 1234 starting from the lowest significant digit (here, '4').

Think about the irony :)

<comment><USER17> I'm not sure about Arabic, but my understanding of Hebrew (another member of the Semitic language family) is that they still pronounce the numbers left to right, and if a line break forces digits to be split across lines, the most significant digits are put on the top line.

<comment><USER16> You got me curious. I googled and found[1] that indeed they only pronounce numbers 21-99 that way, e.g. for 31 the order of words is "one thirty", but higher order components go left to right, e.g. for 25031 the order of words is "five twenty thousand one thirty".

1\. [http://arabic.tripod.com/VocabNumbers.htm](http://arabic.tripod.com/VocabNumbers.htm)

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I once heard somebody jokingly refer to MIPS as SPIM when booted in "other- endian" mode. If SPARC could do that, then it would be CRAPS.

<comment><USER19> An odd joke. SPIM is a well-known MIPS emulator, used in a great many university compiler classes.

[http://spimsimulator.sourceforge.net/](http://spimsimulator.sourceforge.net/)

</comment></comment><comment><USER20> Going against what Linus suggests, The Dalvik DEX format (used by Android) has a flag representing the endianness of the enclosed bytecode: [https://source.android.com/devices/tech/dalvik/dex- format.ht...](https://source.android.com/devices/tech/dalvik/dex-format.html) (see "ENDIAN_CONSTANT and REVERSE_ENDIAN_CONSTANT"). By default, it's Little Endian.

I've always wondered WHY this flag is present - why would an implementation wish to change the byte-order? I could understand if the file contained machine code, and would vary with different architectures - but given it's running in a VM, why bother?

<comment><USER21> Even though the bytecode is being executed on a VM, the VM itself has been ported to the architecture, which has a native endianness. Byte order in the dex that matches the host OS's will likely result in a performance gain as the VM can cast more efficiently.

<comment><USER20> That's true - do you suppose that this flag might be used if an app developer was targeting a specific CPU architecture, then?

I guess it could be argued that if you're that concerned about performance and know your target architecture, that it might be worth going native rather than running on a VM.

<comment><USER22> This is just a guess, but I think the odex pass on dalvik switches the endianness to the architecture's native.

</comment></comment></comment></comment><comment><USER23> The Web is now little-endian thanks to ArrayBufferViews exposing endianness and everyone testing only the little-endian case. It doesn't make sense to make big-endian hardware that needs to run a Web browser anymore, so chances are that big-endian will never come back.

<comment><USER24> I have a hard time believing that the whole web uses ArrayBufferViews.

</comment></comment><comment><USER25> From Wikipedia: [Gulliver's Travels] describes an intra-Lilliputian quarrel over the practice of breaking eggs. Traditionally, Lilliputians broke boiled eggs on the larger end; a few generations ago, an Emperor of Lilliput, the Present Emperor's great-grandfather, had decreed that all eggs be broken on the smaller end after his son cut himself breaking the egg on the larger end. The differences between Big-Endians (those who broke their eggs at the larger end) and Little-Endians had given rise to "six rebellions... wherein one Emperor lost his life, and another his crown". The Lilliputian religion says an egg should be broken on the convenient end, which is now interpreted by the Lilliputians as the smaller end. The Big-Endians gained favour in Blefuscu.

[http://en.wikipedia.org/wiki/Lilliput_and_Blefuscu](http://en.wikipedia.org/wiki/Lilliput_and_Blefuscu)

</comment><comment><USER26> This got me thinking if in general (outside computing) it was a good choice having numbers represented the way they are. What if we had 1234 read as "four thousand, three hundred and twenty one"? Or even more different than how we pronounce it today - in order to read the number left-to-right to spell it "one and twenty and three hundred and four thousand"! This way the last digit lingering in your mind would be the one representing the most significant part of the given number (unlike the current practice of hearing first then tuning off for the less interesting smaller parts). Would it have been practical?

<comment><USER27> If you take into account the fact that you can obtain the order-of-magnitude for most "human" numbers without actually focusing on them, then putting the most-significant digit first in the stream makes sense. 30 is easy to see, even if you look at the 3 you can at least tell there's two digits. 12,048 is pretty easy. Even 8,293,254 isn't that hard to order-of-magnitude from the near-fovea while you're focused on the 8. By the time you get into the larger numbers that are hard, well, they're hard under either order so it's a wash.

<comment><USER26> At reading, one may be indeed hit at first by the most significant digit ('8' in your last example) that is somewhat useful, but the reader can't easily figure out digit's order of magnitude without reading the entire number. There's actually more. The reader can't spell the number right away, as it has to be read entirely and compiled in mind first. This compilation involves counting all digits in the given number to determine the number's size, then starting again by interpreting and spelling accordingly in its order each digit and its designation. This double-pass doesn't appear that efficient to me. On the other hand, if the number from your last example would be written backwards (452'392'8), its reading and interpretation would come efficiently in one pass ("four fifty and two hundred, three ninety and two hundred thousand, and eight million"). Even when all we're interested in would be the most significant digit and its order of magnitude, that would still be faster to determine (i.e. again, in one pass).

<comment><USER27> "but the reader can't easily figure out digit's order of magnitude without reading the entire number."

Yes, they can; that was my entire point. Human-sized numbers fit within the eye's fovea. Numbers that don't fit easily within the fovea require effort under either scheme. Your model of having to go digit-by-digit is a computer's scanning model, not a human perception model; we do not scan that way, we scan in fovea-sized chunks, which are smaller than people may think because the brain is _very_ good at interpolating before the information hits the conscious mind, but is still large enough to fit "millions" in quite comfortably.

</comment></comment></comment></comment><comment><USER28> I would not follow Linus advice here. To stick with a given endianess for a protocol? Sure! But why to use BE if everything is LE? If you use LE at compile time you can convert the conversion calls to no operations: zero cost. The cost will be incurred only into BE systems that are every day less common. So my suggestion is to stick to a specific endianess in protocols and serialization factors but picking LE instead of BE. Macros to convert the value that will do nothing if the host is already LE are trivial to write.

<comment><USER29> That's what Linus is saying: hey, BE is basically dead and you shouldn't use it, but _if you really really want to use it_ , that's fine as long as you don't go for dynamic switching.

</comment></comment><comment><USER30> When POWER8 came out (ppc64le) the writing was pretty much on the wall. Is there any major or even minor architecture which still defaults to BE? SPARC possibly?

<comment><USER31> Yes, SPARC and zSeries. Among architectures supported by recently released Debian, zSeries is the only architecture that defaults to BE. (SPARC support is dropped.)

</comment></comment><comment><USER32> Another subjective opinion from someone who doesn't look much out of his box.

<comment><USER33> As opposed to an objective opinion?</comment></comment>


ASCII to My Heart - <AUTHOR> https://cmcenroe.me/2015/09/27/ascii.html <comment><USER2> One thing that is not mentioned and what probably is one of the major reasons ASCII kinda has stayed as relevant as it is, is the fact that it is indeed a 7-bit encoding. This allows all sorts of interesting use of the 8th bit, of which UTF-8 is maybe the most beautiful hack.</comment>


Show HN: I just launched my site giving away my art for free - <AUTHOR> http://www.getzaceramics.com

<comment><USER2> i love this. congrats. beautiful site. very "do things that don't scale" with the launch strategy.

<comment><AUTHOR> Thank you, I'm giving my art for free as an act of personal affirmation. I think the idea has the potential to scale.

</comment></comment><comment><USER3> Congrats, nice cups!</comment>


Ask YC: Did you cancel the $15k award for SUS? - <AUTHOR> Did you cancel the $15k fund award for this course at the startup school?<p>Thanks. <comment><USER2> We haven't decided whether to offer that for this course. It's a pretty big expense and we want to run SUS more often. So...TBD. (Eric SUS facilitator)</comment>


Customers given too many choices are 10x less likely to buy - <AUTHOR> http://sivers.org/jam

<comment><USER2> Here's an anecdote for you: I am generally religious about reducing the length of funnels, because length kills conversion like nothing else. This lead me to once let the customers make two choices with one click: whether they wanted download or CD of the software, and whether they wanted to pay by Paypal or Google Checkout. The four combinations were laid out in a 2x2 table.

This proved _immensely_ confusing for people, so much so that adding a shopping cart on top of two bare "download" or "CD" buttons caused sales to rise substantially, despite the fact that the shopping cart was a virtual riot of distraction and required minimally an extra click to get through.

<comment><USER3> Why the table? I can imagine being confused by something like that. I'd attempt a solution like this before using a table.

        Order a CD:
              [Google Checkout]
              [Paypal]
        Purchase a download:
              [Google Checkout]
              [Paypal]

That way, I still make the decisions in order but only click one link. The tree could be inverted and still work, but this way the label on the links match exactly where you are going.

</comment></comment><comment><USER4> This sounds reasonable. But I've always wondered about Amazon.com's UI strategy in the context of choice - they always show me much more crap than I am interested in: on the home page, on search result pages, on product detail pages, pretty much everywhere on their site. Right now I can see well over 30 'recommended' items on their homepage (and this is _after_ the huge Kindle ad). Surely they've conducted A/B tests. Why don't they see the same results?

<comment><USER5> thats not choice though, that's pretty much Amazon's equivalent of a product aisle.

<comment><USER4> Fair point, but isn't the jam example also a product aisle with 24 varieties of jam? My current frontpage recommendations include around 15 laptops and 15 books - I can't possibly buy all of them - aren't they asking me to choose? If they showed me just three from each product category, and fewer categories overall, I might actually be interested in the recommendations.

<comment><USER6> I guess its something to do with the ability make a decision and short term memory. Interchangable products makes decision making hard because they need to be considered at once. Products in other categories don't need to be held in your head while you choose between them.

</comment></comment></comment></comment><comment><USER7> Barry Schwartz on how more choice makes people less satisfied: [http://www.ted.com/index.php/talks/barry_schwartz_on_the_par...](http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html)

<comment><USER8> I think it may have been in this talk, but the solution when the customers actually demand the multiple choices is to do the best of both worlds- the "Greek Restaurant" - Have a menu filled with just about every dish imaginable, but then have a page in front in large print that says something like "Recommended Choices" and put the highest margin items on there. The customer feels like they _could_ choose something if they were in the mood, but they can feel good about simply ordering one of the suggested choices.

</comment></comment><comment><USER9> 24 different types of jams is too much. 24 different types of books is too little.

<comment><USER10> 24 different types of books on beginning HTML is still to much.

</comment></comment><comment><USER11> Cool-- I had a hunch recently that some of our weekly match reports for Yumbunny (our dating site) were showing too many potential matches in the email reports we send. I envisioned some of our users getting overwhelmed by all the options.

Anyway, this article reminded me to get that rolling so instead of top 10, we're going to try top 3 and see if engagement increases. We'll see.

<comment><USER12> You really should test that and submit your findings to HN :).

<comment><USER13> Yes - sounds like an excellent candidate for an A/B split test and an enlightening follow-up post on HN!

</comment></comment></comment><comment><USER14> Related anecdote: with our core product, customers choose a base website design/template (Flash-based) and then customize it with our cms. At one time we had around 25 designs to choose from. Some designs we thought were really slick hardly sold at all.

Recently we trimmed it down to just our best designs. Currently we are offering 9 to choose from. It hasn't been long enough to back up the article but sales are definitely stronger and there seems to be a more even distribution of chosen designs.

</comment><comment><USER15> the profession of salesperson exists because people want their choices narrowed for them.

<comment><USER16> I was about to say something along those similar lines. . .since most customers have a hard-time rationalizing a set of choices without understanding the makeup of each choice. Most customers, in a sense, out- source the decision-making to either a salesman's pitch or a product's brand. Seems like most of marketing's job is to optimize their product according to their customer's profile, which, in short, I think means each product marginalizes their customer according to a set of values called culture.

</comment></comment><comment><USER17> Not really the same thing, but makes me think of a behavior I've noticed in myself. Sometimes I'll decide to buy an item or two, and then browse around some more. Pretty soon my shopping cart is filled with stuff I want, but now instead of some minor spending I'm faced with a more significant purchase. I often decide to buy absolutely nothing.

If the store could encourage me to just purchase the one or two things I originally wanted they'd make more money off me.

<comment><USER18> Sounds like you should be using the "wishlist" instead of the shopping cart.

</comment></comment><comment><USER19> I think he missed a big point. Lead them in with features, like they are bait, THEN only present 3 packages to buy (instead of 16). Software is different than jelly.

</comment><comment><USER20> Article dating back to eight years ago:

[http://www.nytimes.com/2001/01/09/health/in-weird-math-of- ch...](http://www.nytimes.com/2001/01/09/health/in-weird-math-of- choices-6-choices-can-beat-600.html?pagewanted=all)

</comment><comment><USER21> A neologism from Douglas Coupland's 1991 book Generation X:

Option Paralysis: The tendency, when given unlimited choices, to make none.

</comment><comment><USER5> it seems that for most people, 5 is the most choices they can consider without getting a headache.

I think optimally you want the person to narrow it down to 3 choices, because at that point the person is a lot more likely to buy, since they are at a point where they can consider the items side by side and actually make up their mind.

</comment><comment><USER22> Couple of years back I read that Google Home Page was designed in such way that it should not display more than 7 features.

</comment><comment><USER23> _Surgeon Atul Gawande found that 65% of people surveyed said if they were to get cancer, they'd want to choose their own treatment. Among people surveyed who really do have cancer, only 12% of patients want to choose their own treatment.

So, if you ask your customers if they want extensive choice, they will say they do – but they really don't. _

That's a huge _non sequitur_. Research on cancer treatment preference does not imply anything about 'amount of choice' preference. Not even when combined with research on 'number of sales' as dependent on 'amount of choice', because in that case no one was asked how much choice they preferred.

<comment><USER24> Maybe people who prefer fewer choices are much more likely to get cancer. ;)

</comment></comment><comment><USER25> see the book "the paradox of choice" by barry schwartz. interesting read</comment>


What loading a home page should not look like - <AUTHOR> http://www.enchantedage.com/how-not-to-run-a-pay-for-site I don't want to be a complainypants, but the funimation.com web site is SOO BAD that it serves as an example for what not to do with your pay-for entertainment site. In all possible respects.<p>Either their developer and design and operations and coffee making person isn't given enough resoures to actually care about the site, or they just don't know how to do it, and probably don't know that they don't know. <comment><USER2> Cbs' streaming site is just as bad. I can't tell you how many times I've been watching something, and some interactive ad plays. Of course there's some bug, and the content stream never actually starts again. So frustrating. Same goes for HBO go, have seen some buggy behavior there as well.

<comment><AUTHOR> How do these disasters happen? I have to assume that companies do want to keep customers, and that they use their own service...</comment></comment>


Microsoft and Apple Double Down - <AUTHOR> https://stratechery.com/2016/microsoft-and-apple-double-down/ <comment><USER2> Yeah, tell that to the 10s of thousands of engineers that Microsoft just laid off.

While Apple is building offices in India.

</comment><comment><USER3> I feel sad about this post because Ben Thompon usually has good analysis that is defensible even if you don't agree with him, but his statement that Microsoft upstaged Apple by purchasing linked-in is ridiculous and trollish enough to make me wary of investing attention in the rest of his thinking.</comment>


We will try to stop fixing bugs in PHP - <AUTHOR> https://bugs.php.net/bug.php?id=50696 <comment><USER2> Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response:

 _... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ..._ \-- rasmus.

Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it _now_ could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it.

Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

<comment><USER3> A possible solution to this would be to put a policy together to only fix things like this in the next major version, not on the current line.

As long as it's known that these are long term fixes people can prepare for them.

<comment><USER4> "The first PHP 5.3 release candidate was back in March 2009. We put these release candidates out there so people who "will have MONTHS of work" because of small changes can chime in then and make their case. The release candidate period lasted until July."

I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release management grounds there's nothing to complain about. On general principles I'm of the opinion that the PHP project did everything called for here and the fault is pretty much 100% on the user's side here, with the only possible counterargument being that they apparently may not have called this exact change out quite as precisely as they could have (though that implies they knew, which, well, in a sloppy-type language like this this sort of thing is easy to miss). Languages don't get to version 5 without some breaking changes, but the alternative of every language being stuck with every bad decision made in version 1 forever is worse.

<comment><USER5> I once played with continuous testing using a python fresh from the Hg repo. Once you set up your CI/CT box with enough compute power there is no reason to always check your product against the upstream pre-release components.

Now that I remember it, it was a pretty nice setup - creating OpenVZ partitions from a template, making python from sources and testing the application within the machine. Too bad it was a one-off thing. I should have used something like buildbot or jenkins.

<comment><USER6> That is a wonderful idea. Knowing _now_ if your stuff will or will not break in the "future" seems worth the investment. If anyone else is doing this, I would love to see details.

<comment><USER5> There will be a couple false positives, but, in any case, you can measure the upstream development quality, and use that as an input to guide your decisions.

</comment></comment></comment></comment></comment></comment><comment><USER7> There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated.

And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP.

[1]: Coming from somebody who built a very successful startup on top of PHP.

<comment><USER5> What shocks me most is the sense of entitlement. They downloaded PHP, its behavior changes and they'd rather complain to those who changed it and annoy them until the thing works for them again than fix the bug in their code. If they are not happy with the free product and the free support, there are other options.

PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.

<comment><USER8> Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.

<comment><USER5> Then they have a couple options: fork and keep their own fork, they can pay the PHP community (or someone in it) to change it back (or to provide a backwards-compatibility mechanism) or pay developers to change their software to work with newer versions of PHP.

They can't bully their way like they tried.

<comment><USER9> > they can pay the PHP community (or someone in it) to change it back

The decision was defended on its own merit, so I would be really disappointed if bringing money to the table affected the outcome. Funding open source development is great as long as meritocracy is maintained. That's why Linus never accepted a job at a company that had a stake in pushing Linux in a certain direction.

<comment><USER5> If they could prove that the change would create a really huge expenditure and would thus damage the community, I assume a workaround could be reached through the normal democratic decision process. I imagine a config option to restore the original functionality would be a nice solution, but I'd suggest the company should fund its development (along with proper tests and associated code).

<comment><USER8> If they kept config files to control every altered behaviour PHP configuration would be an even bigger mess than it is already.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Love this snippet:

> > Please escalate this to someone who can answer the question as to why this > was changed. _\-- endosquid at endosquid dot com_

> Escalate? Oh how I wish I had someone to escalate to. _\-- firstname.lastname@example.com_

<comment><USER11> Rasmus comes across as a little kid.

Here's how I read it:

We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.

I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure."

Perhaps it isn't about being paid, but about taking pride in the work you do.

PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.

<comment><USER12> "I use it for some piddly shit because that's what it's good for."

The bigotry from this community when it comes to PHP has left me sick to my stomach.

<comment><USER13> Don't sweat it.

Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress).

I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around with servers in order to perform my job.

The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP.

TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.

<comment><USER14> > If you will ship faster and better with language X, go ahead and use it.

Absolutely, by all means, go for it. Godspeed.

> Languages are meaningless penis measuring contests of the IT world.

No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.

<comment><USER15> He meant that not in the context of Language Research, which is super-awesome and every developer should be super grateful to researches in this space, but in applied programming, where people piss on whatever language they aren't used to using/think sucks for some arbitrary reason.

<comment><USER14> But the lines between research and industry or "applied programming" aren't that clear cut (look at how much Rich Hickey's been able to mine the veins of research and bring awesome ideas to a practical and well-designed language like Clojure). I think some healthy debate, which includes pointing out languages that have severe flaws, is important and I wouldn't want to discourage it from happening, especially not on HN. I certainly don't think it needs to be dismissed as "meaningless penis measuring contests". That debate should definitely be carried out politely, of course. I'm not defending incoherent language flame wars.

<comment><USER12> "healthy debate" Yes! This is what we do need, what we do NOT need is bullshit like "piddly shit" which you seemed to be defending.

But please, tell me of one, just one, "severe flaw" you find in PHP, as it is today. And I will enter into a healthy debate with you.

<comment><USER16> I'll bite. PHP's automatic type conversion is a severe flaw.

The intent was to make it easier for beginners to pick up the language without worrying about technical details like types, but it violates the "fail fast" principle. It might make it easier for beginners to write code that works some of the time, but at a cost of making it harder to write code that doesn't break in surprising ways later. It's not just that automatic coercion exists, but that the behavior is biased toward returning values that don't produce errors. Treating the string "three" as equal to the number 0 is very unlikely to be the desired behavior. Even if not emitting an error is desired, a contagious NaN value would make a lot more sense.

There are certainly ways for an experienced user to mitigate the problem, but beginners don't know them, using them effectively requires discipline and a great deal of production code doesn't use them. The latter problem is cultural, but the language being tolerant of sloppy code naturally attracts people who write sloppy code to the language.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'.

That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.

<comment><USER18> A wrapper function is absolutely the right way. Instead, he decides to _modify the PHP source and recompile it_ , effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.

<comment><USER19> Spot on. He doesn't want to update his 50+ applications, but he wants to patch PHP and deal with the deployment of that to all the servers that support those 50+ applications. And he admits that he's not a C++ coder.

Sounds like a change management nightmare.

<comment><USER20> But it's only one change.+

\+ Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.

</comment></comment></comment></comment><comment><USER21> Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this:

       print number_format("",0);

       Warning: number_format() expects parameter 1 to be
       double, string given in Command line code on line 1

So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type:

       print number_format((int)"",0);
       0

Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.

<comment><USER22> I think there are two bigger issues:

1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways.

2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it)

You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.

<comment><USER23> I don't have a strong opinion either way, but I don't think #1 is a given.

You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: <http://en.wikipedia.org/wiki/Robustness_principle>

My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.

<comment><USER22> I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.

</comment></comment></comment></comment><comment><USER15> Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks".

For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9.

In any case, the current release is 5.4.4.

<comment><USER24> Sorry I couldn't grok what your opinion on semver was.

Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible).

PHP made an backwards incompatible change in their code so it should have been a major version increase.

So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver.

Is that not your opinion?

<comment><USER25> Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know.

In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once.

Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did.

Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different.

Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport.

And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.)

Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit.

Ruby is a bad example.

<comment><USER15> I used it as the example simply because it is normally a language that is touted _quite_ superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all.

Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.

<comment><USER26> Hahaha. People wouldn't complain. That's a knee slapper.

<comment><USER27> No more preposterous than software without bugs.

</comment></comment></comment></comment></comment></comment><comment><USER28> > After carefully reviewing this bug report with our board of directors on > 4chan, we have come to the conclusion that your "rusty C skills" should be > enough to fix the issue.

I am sad I was not invited :(

<comment><USER29> You should escalate that up at 4Chan!

</comment></comment><comment><USER30> So the options are:

      1. Change thousands of lines of code (probably `sed`-able)
      2. Patch PHP to re-introduce the original bug/feature
      3. Downgrade PHP back to the version that had the
         bug/feature you were relying on

Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.

<comment><USER31> Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP <=5.1. This allows a very effective denial of service.

Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.

<comment><USER30> Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it.

You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you _never_ use features in even remotely-unexpected ways. Like in this case.

<comment><USER32> This is why having a good suite of unit tests is so important.

</comment></comment></comment></comment><comment><USER33> "This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you cannot say he's not over-exaggerating and being a pain in the ass. Also, expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make sense. That's like saying "i expected your software to make up for me not using it correctly". Sass or not from the guy who wrote PHP, this guy is just a pain in the ass and his complaint is ridiculous.

ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.

</comment><comment><USER34> People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

<comment><USER35> I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications.

Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented.

Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.)

PS. This mailing thread is from 2010. It's really old.

<comment><USER36> Ulrich Drepper was vigorously in favour of it. If your application breaks, it's because it was written wrong.

<comment><USER37> Exactly. The only reason this bug got to production, is because the function accepted an empty string parameter in the first place.

</comment></comment></comment></comment><comment><USER38> The "is there anyone you can escalate this too" reminds me of a PERL newsgroup thread I saw where someone tried to rip Larry Wall a new one, asking (in a condescending way) him if he knew anything about PERL.

<comment><USER39> Or the time I suggested on HN that cperciva use scrypt (not noticing the username on the comment).

</comment></comment><comment><USER40> To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.

<comment><USER41> To standardize PHP is to create a new language not named PHP.

<comment><USER42> If you read it until the end you will find out that the technical support representative talking to the irate customer is the creator of PHP. As the creator, PHP can be whatever he decides he wants it to be.

<comment><USER43> And he has decided it is not a standardized language, by any stretch of the imagination. That's the guy's point, and it's spot-on.

As an aside, I didn't realize there would be people on HN who wouldn't recognize email@example.com immediately.

<comment><USER42> While there are some industry veterans here, there are also a good amount of CS students and other beginners. I myself didn't know who he was until I got to the end of the article.

</comment></comment></comment></comment></comment><comment><USER44> I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type system chose a different type this time.

Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading.

In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)

<comment><USER45> Especially for a novice, formatting a field on a web form into a number, and seeing PHP format an empty field as zero, so you can carry on with your math, makes sense. "Oh, web parsing language, sees empty number field as zero, great!"

Principle of least surprise _"for the novice web developer"_ says empty string to zero makes sense in this case.

Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.

</comment></comment><comment><USER46> So developers complain that PHP is not standardised, but when it is in a major version upgrade developers complain that it's becoming standardised?

<comment><USER47> Are you somehow under the impression that developers are the Borg? Different developers can have different opinions on what PHP should be.

</comment></comment><comment><USER48> Having _number_format_ in so many thousands of places across so many products is indicative of pretty poor code. If you have bad code, you can hardly expect to be able to upgrade to new versions of the language seamlessly.

Speaking of which, are they going to upgrade to 5.3 _without_ testing all those thousands of places across all their products?

<comment><USER49> How is that indicative of bad code? That seems like a very big jump to make. If you're using PHP at the presentation layer you are probably doing a lot of this. Why would you write some sort of abstraction around number formatting when there is an abstract function to just do it for you?

This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.

<comment><USER48> I'm just saying it's a sign, or a smell.

Just as you say older/pre-modern -- bad code or not, the same caveat applies about upgrading core language platforms. Even a strictly typed language with a much more standardized API like Java can be hard to upgrade major versions (where I would consider 5.3 a new major version).

</comment></comment></comment><comment><USER50> I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold).

It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

<comment><USER51> A) The new behaviour makes more sense.

B) The change was discovered as a difference in behaviour in two major releases that were three years apart.

C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful.

D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix.

E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea.

F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."

<comment><USER52> I disagree with point A. The old behavior makes a LOT more sense symbolically.

I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non- writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..

<comment><USER53> I don't agree with your analogy. The question is more similar to "Can you please tell me the number format of <silence>".

How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0).

In this case, NULL is definitely more appropriate, because the input is invalid.

<comment><USER54> What's the numeric representation of the volume of <silence>? 0 dB

<comment><USER55> Since dB are a log scale, more properly, it would be -Inf dB.

<comment><USER56> 0 dB = atmospheric pressure. -Inf dB = vacuum of space.

</comment></comment></comment></comment></comment></comment></comment><comment> loup-vaillant > _Find the dependencies —and eliminate them_

Excel team motto.[1]

While I understand Rasmus' response is legitimate, I also see that depending on something as crucial as a programming language implementation is less of a good idea than it might seem at first. Makes things like Maru (the programming language[2], not the cat) much more appealing: if there's something you don't like in your compiler, at least you stand a chance at fixing it (Maru is less than 2K lines, and counting down).

[1]: <http://www.joelonsoftware.com/articles/fog0000000007.html>

[2]: <http://piumarta.com/software/maru/>

</comment><comment><USER57> > _Each of those changes will have to be coded, tested, written-off, released, > tested by the clients since this is tax data and has to be precise for tax > planning and retirement planning._

Considering the filer of the report goes on to say this, at what point did they fail to realise that moving from an " _old PHP 5.1.6 Solaris 8 box_ " to an " _RHEL5 with 5.3.1_ " should have required the same level of testing and signing off?

No sympathy for a developer who completely changes their environment (OS, PHP version, at the very least) and then bitches about stuff they failed to anticipate not working. This is not a reflection on PHP, for once.

</comment><comment><USER58> I think the guy wasn't thinking the situation through entirely, but someone of (relative respect I suppose, creator of PHP is still the creator of something widely used) respect shouldn't be acting like this. It's always a shame to see people who have promise and talent show how childish they CAN act. Having his underling (someone who works on his language of no known note) make a smartassed response was in turn also pointless and negative whether he requested/urged it passively or not.

</comment><comment><USER17> Related article about the same bug report: "When does a bug turn into a feature?"

<http://lwn.net/Articles/369505/>

</comment><comment><USER38> Way to jump onto a thread that hadn't had any comments in 10-month-old joezimjs and add pretty much zero to the conversation.

</comment><comment><USER59> It was really to read that conversation. I do not care whether it was a good or bad decision to make those changes in PHP but you simply can not talk like that to a person who has put thousands of hours of unpaid work (while he could get a fat pay check easily) and you are making living because of what he has done. It's just immature.

</comment><comment><USER60> This is pretty standard with large production software. You often see grids in the documentation, e.g. this version of the app server is only certified for these brands and versions of Java. Even if you have a paid support contract with us, do not contact us re using it on something else. So in the reporter's case, their software just isn't certified for the new version until updated. No big deal.

I remember working at a company where the servers were Ubuntu, the auto-update mechanism replaced Sun Java with OpenJDK which broke countless apps and web servers, like the Concur app, the build system, etc.. God that was a nightmare. A real setup like at bigger companies I've worked at would have tested that update on developer boxes, integration boxes, testing and training boxes, and only then sent it to production.

</comment><comment><USER61> This reminds me of <http://news.ycombinator.com/item?id=3860361>. Ignoring something that needs to be fixed because it might break workarounds is a lot to expect, and it likely why the IEs stayed broken for so long.

</comment><comment><USER62> Uh, so let me get this straight. They are using number_format, which according to the documentation takes a number and formats as a string, and giving it a string as the input parameter?

They were never using the function correctly in the first place! Not sure what they have to complain about here...

</comment><comment><USER63> In April 2010 Rasmus Lerdorf joined WePay (a YC startup) in a senior position.

[http://techcrunch.com/2010/04/27/php-founder-rasmus- lerdorf-...](http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf- joins-group-payments-startup-wepay/)

He's always been like this, best I can tell.

</comment><comment><USER64> Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent.

As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude.

This has shown me the worst of the PHP community. I'm not ashamed, just more wary.

<comment><USER65> This is exactly how I feel about it.

I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.

</comment></comment><comment><USER66> Issue here is not whether it can be fixed, anything can be fixed. Issue here is why in the world they have changed things in a such way to break the old code?! Was it necessary? I don't think so... I understand the need to re- factor, and making some old stuff obsolete along the way, of course, but it's not the case here. It's just that someone wasn't really playing attention to this. And this type of negligence to the details is really killing php as language. If after 10+ years in php I need to re-read the manual every now and then to make sure if the things are still working like the last time, it's just crazy..

</comment><comment><USER67> Blaming your problems on the person making something you are consuming is always a useless endeavor. Make a function if you are using something in hundreds of places that relies on user input. Not terribly difficult.

</comment><comment><USER68> | ^ 0 isn't some magic all-encompassing number. It means 0. NULL means no number based on your shitty incorrect input, and is the correct choice.

Best response to the whole thing except for Rasmus' awesomeness.

</comment><comment><USER69> "Please escalate this to someone who can answer the question as to why this was changed. If no one knows, then why was default behavior changed?"

Mr.Rasmus, respect, for not ending the thread at this statement.

</comment><comment><USER70> In this kind of situation where there's a bug or limitation or some kind of issue with a language function we usually create a wrapper to handle the whatever rules we have internally within the company. In this case the empty string that is supposed to be NULL should be handled within that wrapper function. One function to modify instead of several places in the application.

</comment><comment><USER71> You can't win, people on one side want this weird behaviour made backwards compatible whereas people complain that the language has a large amount of weird edge cases and should be better standardised around more sane expected values.

In this case they were standardising parameter parsing code, which I think is definitely the direction you want to head.

</comment><comment><USER72> PHP is doing the right thing here. Way back when I first tried PHP out, I tried joining strngs together with a + operator.

I made a mistake, but I kept getting back zeros instead of some sort of NULL or an exception. This is a bug, in the sense of its not how _I_ wanted PHP to behave. I'm glad PHP is fixing its string-to-numeric bugs.

</comment><comment><USER73> All the discussion aside, there is so much wrong with it:

First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)

<comment><USER74> > First of all, why does the function even accept strings?

Why not?

> There should be some eception happening.

PHP's built-in functions do not _ever_ throw exceptions.

> Second, why does it return 0, i could understand NULL but not 0

Well it doesn't anymore, but it used to, and that kind-of made sense _in the context of the language being PHP_ : in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number:

        > php -r 'print (1 + "3") . "\n";'
        4

when the string _can not be parsed to a number_ (meaning it is not prefixed by something which looks like a number), it's just converted to `0`:

        > php -r 'print (1 + "whelp") . "\n";'
        1

And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.

<comment><USER73> Just shows me how broken this language is to the core.

<comment><USER75> I don't think you got to the real problem here. Weak types are quite useful for some tasks, and of course they are nothing new. Languages that convert between integer and string types automatically are well suited for text processing in general (including generating web pages dynamically).

The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check out AWK, another weakly typed language, for example:

BEGIN{printf "%5.2f\n", ""}

prints "0.00" as would be reasonable.

</comment></comment></comment></comment><comment><USER71> In the same way that projects enforce a certain subsection of c++, it is probably best in PHP to not code anything in a way that relies on unusual quirks of the language to work. None of my code gets bitten here because I never passed number_format anything but numbers.

<comment><USER76> In my opinion weak typing is an unusual quirk, but there's no way to get around that. I really wonder kind of reasons could be given to defend it; I don't think a strongly typed language like Python is any harder because of its types.

<comment><USER71> I tend to agree, these days where possible when working in PHP I try not to rely on PHPs magic type conversions behind the scenes for things like comparisons.

<comment><USER76> You can't really avoid weak typing; e.g., making a mistake in a strongly typed language would raise an error, whereas in a weakly typed language it can silently screw up everything.

</comment></comment></comment></comment><comment><USER77> a pal of mine recently upgraded a big corp's pcs from win xp to win 7 . the long wait was due to excel macros which could not run in the latter os. they couldnt switch even after him rewriting and testing them to run. [edit] typo

</comment><comment><USER78> Stop doing automagical conversions and all these problems will go away.

</comment><comment><USER79> ... and that's why you don't use PHP.

</comment><comment><USER80> In most mature programming languages we resolve this kind of dispute by pointing to the Standard. Is that not possible with PHP?

<comment><USER81> Well that's what happened to this guy. He relied on unstandard/undefined behaviour and when php switched to a standard parameter parser it broke his app.

</comment></comment><comment><USER82> Ah, the joys of dynamic typing.

<comment><USER76> No, this is about _weak_ typing (as opposed to strong typing). Static vs. dynamic is another matter.

</comment></comment><comment><USER83> Wait, endosquid writes tax software and expects that whenever a bit of data gets corrupted it should display an account balance of 0? Please share the name of this phenomenal software product.

<comment><USER84> Indeed, it's amazing that the same person could say "We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages" and "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning."

They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.

<comment><USER85> Yes this. A million times this.

Anyone who uses PHP seriously knows when accepting user input you have to do type checking rigorously. The manual states the input has to be a float. Of course in PHP this means it SHOULD be a float but why risk sending it a variable who's type is still undecided?

</comment></comment></comment><comment><USER83> Heh, if your steps to reproduce include redirecting error messages to /dev/null, it is hard to take your report seriously.

</comment><comment><USER86> This makes me so excited to be a budding Perl dev.

</comment><comment><USER87> Here's to not using PHP for anything serious! The whole point of a dynamically typed language is that arguments could be of any type. Language built-ins should account for this. Of course PHP doesn't and shouldn't be expected to. The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me.

<comment><USER88> > The fact that Facebook, MediaWiki, and WordPress are so successful is still > a mystery to me.

The fact that some developers think the language chosen has much effect on the success of a site is still a mystery to me.

</comment></comment><comment><USER89> Regardless of merit on either side, the attitude presented by the _creator_ of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled.

EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.

<comment><USER90> Can you imagine how many fools like this Rasmus Lerdorf has to deal with, every. single. day. since he created PHP? Same for Linus Torvalds. After a while, you just stop trying to sugar-coat idiocy, and just tell them as it is.

<comment><USER75> Perhaps it was not like this when PHP was created, but it surely has been for a long while now: Idiots are now PHP's target audience be it by design or by its own faults. So if Rasmus Lerdorf still maintains PHP then he should not get angry by the kind of users he chose and/or deserves.

<comment><USER90> That's a bit harsh. Like with Java or Perl, there's an enormous installed base of PHP apps which need maintaining and upgrading (and replacing, wherever possible); a lot of people end up inheriting systems they didn't build, and having to keep them up _ad libitum_.

<comment><USER75> Sure, but those who inherit PHP systems may not belong to the PHP's target audience that I was referring to. Neither must all people who choose to use PHP necessarily idiots, because PHP does have some legitimate use cases. But all in all I don't think PHP maintainers can expect sanity from their users as a general population nowadays. I know it sounds harsh, and it probably is a bit judgmental on my part too, but I hope you get the idea.</comment></comment></comment></comment></comment>


VK open sources PHP to C++ translator - <AUTHOR> https://github.com/vk-com/kphp-kdb

<comment><AUTHOR> Release notes & benchmarks:

[http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=...](http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fvkontakte%2Fblog%2F214877%2F)

</comment><comment><USER2> No tests. No documentations (even in Russian it's not enough). It is not only KPHP but also some their engines written in C. Like Search, Queue, Storage, Text and so on. All of it in just one repo.

It is a great example when sports programming works (VK.com #26 Alexa Rating).

</comment><comment><USER3> Russian-language documentation is available at [[docs/ru/]]. English documentation not available yet, sorry.</comment>


Ask HN: How to become a professional developer - <AUTHOR> Hi I've been a programmer since 6 years ago, and i can say, i'm a good programmer, but in our teams or our companies we are just programming, not any professional work (no test plan, no bug resolve routine, no prototyping and ...). I want to know is there any resource for learning حrincipled aspects of programming and  do my job in world level class? <comment><USER2> Just do it. Its a pain to get started but after a while it just feels natural. Also contributing to open source projects could help.</comment>


Yeti : an ML-derived language for the JVM - <AUTHOR> http://linux.ee/~mzz/yeti/intro.html

<comment><USER2> Here is another way to run an ML-like language on the JVM:

<http://ocamljava.x9c.fr/>

It supports all of OCaml, but it seems complicated to get running along Java with the same sophistication as Yeti. For instance, it seems that one must use the "Nickel" tool to generate Java bindings, rather than simply using "#" for Java calls as in Yeti:

<http://nickel.x9c.fr/index.html>

[http://linux.ee/~mzz/yeti/intro.html#using-java-classes- from...](http://linux.ee/~mzz/yeti/intro.html#using-java-classes-from-yeti- code)

</comment><comment><USER3> It would be nice to see a section on "How is Yeti different from Scala?".

<comment><USER4> from a quick glance ( _only_ ), and not being terribly proficient in either scala or ml, i would say:

\- yeti appears to be quite a faithful port of sml to the jvm, while scala is perhaps best thought of as the bastard offspring of java and haskell.

\- as a consequence, yeti is simpler and intended for programming in a functional style. while scala is much more complex and "object functional" (is that a recognised description these days?).

\- the integration between java and scala appears to be somewhat cleaner than that between java and yeti (although both are fairly good).

\- scala's type system is significantly more powerful. someone better educated than me can explain the difference in detail, but yeti seems to have just "simple" polymorphism, while scala has bounded types etc(1).

\- scala also has a whole pile of tricks related to getting the type system to do things "implicitly" that is, well, i guess you either love it or hate it.

\- yeti appears to be better than scala at getting optimised (ie not broken) tail calls to work.

\- scala is baroque; yeti minimal.

\- scala may be the future of java programming (which is good). yeti certainly isn't (which is a pity, imho).

\- a lot of the above parallels the difference between ml and haskell (if you ignore the laziness part). these days, haskell is a bit of a monster; ml is significantly simpler (even ocaml).

(1) what happens with yeti when you have polymorphism and mutable containers? i have no idea. perhaps runtime type errors?

<comment><USER5> I'm not sure it's a particularly faithful port of ML, and particularly not SML. It doesn't really look anything like ML. It looks like a bit of a mishmash of syntaxes, if anything, so I'm really not sure what makes it "ML derived" any more than it is Python-derived or Algol-derived.

<comment><USER2> Here is a list of features that Yeti has that are either not in Python or not in Algol. That is, none of these features is in both Algol-60 and Python:

* static typing

* discriminated unions

* first-class functions

* immutability by default

* pattern matching

These are all present in both Yeti and SML.

Yes, Yeti is not SML, but I think it's much closer to ML and Friends than it is to any other language family, even Haskell or Scala.

</comment></comment></comment></comment><comment><USER6> I don't see why this is Machine Learning -derived. Or maybe ML stands for something else here...

Edit: Thanks for clarifying. It is good to remember that there is other viewpoints :)

<comment><USER3> It is derived from the ML programming language (<http://en.wikipedia.org/wiki/ML_%28programming_language%29>). Other languages in this family are SML, OCaml, Scala, F#, and (more-or-less) Haskell.

</comment></comment><comment><USER7> do is not fun

[http://en.wikipedia.org/wiki/ML_%28programming_language%29#F...](http://en.wikipedia.org/wiki/ML_%28programming_language%29#Factorial)</comment>


SyntaxNet – An open-source framework for Natural Language Understanding systems - <AUTHOR> https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html <comment><USER2> Previous discussion for same article: [https://news.ycombinator.com/item?id=11686029](https://news.ycombinator.com/item?id=11686029)

Previous discussion after recent update announcement: [https://news.ycombinator.com/item?id=13885685](https://news.ycombinator.com/item?id=13885685)

</comment><comment><USER3> > Humans do a remarkable job of dealing with ambiguity, almost to the point > where the problem is unnoticeable;

Isn't this because we have knowledge of the world?

The sentence "Alice drove down the street in her car" won't ever be parsed as "the street is in the car" by a human because we know that streets don't go in cars.

Computers won't ever solve this without having a larger knowledge base to compare the parsed sentences and remove the ridiculous outputs.

</comment><comment><USER4> > Thursday, May 12, 2016</comment>


Show HN: Woe – A concatenative language inspired by Joy - <AUTHOR> https://github.com/sctb/woe/ <comment><AUTHOR> I'm posting this old project for curiosity's sake. The repository offers no help at all to understand what's going on, but I'm happy to respond to any question I can remember the answer to!

The language is semantically inspired by Joy and Lisp, but with more of a Factor (and Forth) feel. It's written in Whitney-style C, which I'm sure many will object to. But like, here's the GC:

      Z V gc(E e){
        S r;N t;H h,o;e->g=1;o=e->dh;e->dh=h=nh(e->dh->s);r=h->d;
        cp(e,1,&e->d);cp(e,1,&e->c); /* roots  */
        while(r<(h->d+h->u)){        /* cheney */
          t=(N)r;if(t->t==N_Q){cp(e,1,&t->v.q);}cp(e,1,&t->n);r+=ln(t);
        }e->g=0;free(o->d);free(o);
      }

<comment><USER2> That's horrible.

But I can grasp some beauty in the ugliness already.</comment></comment>


Ask HN: Is my 'blog' worth putting on my CV? - <AUTHOR>

http://int-a.github.io<p>I started this blog a bit ago while I was taking an Android Dev coursera course. I'm looking for some criticism on it. I'm trying to get started with Android Development. Right now I feel like there is no "meat" to it, not much in the way of technical content. Do you think it is worth putting on my CV? Any feed back is appreciated! <comment><USER2> a) Don't call it a blog. Cite the important essays as essays, probably by name. If your blogging does not result in individual essays important enough to cite by name, revise your strategy. b) It is absolutely the case that at least some CVs created for some purposes are improved by the addition of things which feel blog-y in character. I don't know how far it would get you if you were looking to get an academic appointment (likely less than having an article in the Journal Of Nobody Reads This Ever), but there are many people whose professional reputations are enhanced quite a bit through their writing platforms.

</comment><comment><USER3> Fix the design at least. The pictures are huge, the format is really off. Not much content would be ok, but the utter design of it is less than appealing.

As for content. You can definitely improve it if you spend more time on it.

The people who get hired for having good blogs have one of two things(sometimes both): good design or good content

Since your blog appears to have neither, I'd side with just listing your github, but not your blog unless you fix more of it.

</comment><comment><USER4> Since it's just a personal blog, I would just add it as a link in your contact info. In other words, just link to it next to where you put your github link / email / phone number.

The design is fine.</comment>


Lobbyist Holds Up Spectacular Example of the Futility of Widening Highways - <AUTHOR> http://usa.streetsblog.org/2015/12/16/lobbyist-holds-up-spectacular-example-of-the-futility-of-widening-highways/ <comment><USER2> Does this mean that the way to reduce congestion on a highway is to reduce the number of lanes?

Another approach, no being tried in the Seattle area, is to meter each lane and automatically charge tolls depending upon many factors. It will be interesting if that has any effect on congestion.</comment>


Capcom Home Arcade update server (and process) is insecure - <AUTHOR> https://www.reddit.com/r/CapcomHomeArcade/comments/dvr813/future_updates_megathread/f9m3u72/ <comment><AUTHOR> When this was first announced, they claimed it was using a source available emulator that forbade commercial use _. Now it seems it was released without any security around the update process.

How does this happen in 2019?

_([https://kotaku.com/the-emulator-in-capcoms-home-arcade-is- st...](https://kotaku.com/the-emulator-in-capcoms-home-arcade-is-stirring- controv-1834156759))</comment>


ZeroTier SDK and User-Space Networking Stack - <AUTHOR> https://github.com/zerotier/ZeroTierSDK <comment><USER2> Blog announcement: [https://www.zerotier.com/blog/?p=910](https://www.zerotier.com/blog/?p=910)

<comment><USER3> Since it looks like you might be the author, the project might make a good "Show HN".

<comment><USER4> It would be technologically but prior links suggest only peripheral titles get big upvotes:

[https://news.ycombinator.com/from?site=zerotier.com](https://news.ycombinator.com/from?site=zerotier.com)

Too bad since I'd like to read crypto and NETSEC people's evaluations of it. Im sure some here would make good points.</comment></comment></comment>


Mystery object falls from sky, area sealed off by military - <AUTHOR> http://www.theregister.co.uk/2013/08/02/mystery_object_falls_from_sky_area_sealed_off_by_military_weather_balloon_say_officials/ <comment><USER2> Spoiler alert: _Was a balloon, and it was sealed off by the bomb squad to see what is was (they happened to be from a near by military base)_.

Events like these will likely continue to rise as the barrier to get to near space lowers. There have been several stories in recent years about students who have used these High-altitude balloons [1, 2] and there are even sites which teach you [3].

UPDATED: bomb squad from bomb squid ;)

[1] [http://www.space.com/14397-teens-lego-man-space- stratosphere...](http://www.space.com/14397-teens-lego-man-space- stratosphere.html)

[2] [http://www.wired.com/gadgetlab/2009/09/the-150-space- camera-...](http://www.wired.com/gadgetlab/2009/09/the-150-space-camera-mit- students-beat-nasa-on-beer-money-budget/)

[3] [http://android.hibal.org/](http://android.hibal.org/)

<comment><USER3> _bomb squid_ : best typo I've seen in a long time. the story provokes the imagination as-is, but gets a lot better with the addition of a bomb squid.

</comment></comment><comment><USER4> They say it is a weatherballoon, but how do we know it was made on this planet?

It could be a weather balloon from another planet containing aliens.

</comment><comment><USER5> This at the end of the article made me chuckle

> The truth is out there here and here. ®

Linking to [http://www.wvec.com/news/local/Package-discovered- neighborho...](http://www.wvec.com/news/local/Package-discovered-neighborhood- turns-out-to-be-weather-balloon-217677901.html) and [http://www.wavy.com/dpp/news/local_news/norfolk/suspicious-p...](http://www.wavy.com/dpp/news/local_news/norfolk/suspicious- package-investigation-underway)

</comment><comment><USER6> As soon as I saw the picture of it on their linked sites (see rangibaby's comment) I was like "that looks like every homemade space camera I've seen on youtube."

May have been a "weather monitoring device" rather than a homemade space camera, same difference. Definitely human-made (polystyrene, circuit boards, string.)

</comment><comment><USER7> While I love me a good conspiracy theory, in this case, sometimes a weather balloon is just a weather balloon.

<comment><USER8> We don't actually know that though, considering how quickly government forces swept it away. The information came from the government.

I'm not trying to say anything, I'm not a believer and I really don't care about this stuff.

All I want to point out is that there is no way for anyone here on HN to know what it was for sure. There is only trust in the media, who trust in a press release, from the government.

<comment><USER9> > We don't actually know that though, considering how quickly government > forces swept it away.

> All I want to point out is that there is no way for anyone here on HN to > know what it was for sure

Take another look at the last sentence. :P

<comment><USER8> I'm afraid I don't follow. Perhaps my english is not the best.

</comment></comment></comment></comment><comment><USER10> [http://www.wvec.com/news/local/Package-discovered- neighborho...](http://www.wvec.com/news/local/Package-discovered-neighborhood- turns-out-to-be-weather-balloon-217677901.html)

</comment><comment><USER11> is the register a legitimate news source? The copy makes me feel like I'm reading a conspiracy theory rag.

EDIT: It also doesn't help that their site is utter trash.

<comment><USER12> They're "legitimate" in that they don't tend to outright lie or write stuff they should know is wrong, but their overall style and tone is always halfway between serious newspaper and The Onion. E.g. they for years ended "everything" in all articles about Yahoo! with exclamation marks to mock Yahoo's use of exclamation marks in their name. Unless you appreciate British humour in general and sarcasm in particular, you might find them.. odd.

</comment></comment><comment><USER13> Weather balloons, bomb squad. Reminded me of World War II:

Japanese Balloon Bomb attack on the US [http://www.bookmice.net/darkchilde/japan/balloon.html](http://www.bookmice.net/darkchilde/japan/balloon.html)

Also MeFi: [http://www.metafilter.com/60948/WWII-Japanese-Balloon- Bombs](http://www.metafilter.com/60948/WWII-Japanese-Balloon-Bombs)

</comment><comment> guard-of-terra How strange should the item be in order me to call for "authorities"?

<comment><USER14> If something non-human comes out of it, that may be a good reason to call :)

</comment></comment><comment><USER15> Maybe this explains it...

[http://www.nbc.com/saturday-night-live/video/happy-fun- ball/...](http://www.nbc.com/saturday-night-live/video/happy-fun-ball/n10032/)

</comment><comment><USER16> Is it Thor's hammer?

I guess it could be some spy satellite or drone they had.

<comment><USER17> While the nerd in me wants it to be a crashed alien probe, the most plausible scenario is that it's a crashed military satellite, drone or similar.

<comment><USER18> It's best not to check out a meteorite that hit the ground near here, Han, old buddy.

Always let the professionals take care of things.

</comment></comment></comment><comment><USER19> I always just assume these things are pieces of space junk that lost orbit. Is that even viable? Or is the junk all small enough to completely burn up on re- entry?

<comment><USER20> Almost all of it is small enough. And orbiting junk is monitored really closely (so we can time rocket launches to avoid it), so when anything large enough to reach the ground comes down (most prominently Mir: [http://en.wikipedia.org/wiki/Deorbit_of_Mir](http://en.wikipedia.org/wiki/Deorbit_of_Mir)), people know in advance.

Hey, there's even a schedule: [http://www.aerospace.org/cords/reentry- predictions/upcoming-...](http://www.aerospace.org/cords/reentry- predictions/upcoming-reentries/)

</comment></comment><comment><USER21> I haven't read anything more than the title or any comments and I trust the reputable sources at the register completely.

So i gotta say: Yup, aliens.</comment>


Celebrating Nobel Peace Prize: $4.99 Tracku App for free today - <AUTHOR> http://itunes.apple.com/us/app/tracku/id383234934?mt=8

<comment><USER2> We can celebrate the pinnacle of human intellectual achievements with some creepy stalker software? Hooray!

<comment><AUTHOR> It's not a creepy stalker, you can see your friend's position only if both of you agree to. Or you can block your friend from seeing you if you regret about the agreement made earlier.</comment></comment>