HN user

pherq

188 karma
Posts0
Comments63
View on HN
No posts found.

The authors of Raddit tried that, but found that actually running Reddit's software, especially on low-end hardware for a smaller community, was a pain in the arse and decided it'd be easier to build their own that fit their purposes.

Assuming "floating point" refers to things fitting the IEEE754 spec at some precision, I'm pretty sure there are still only countably many of them.

After all, for any specific size of mantissa and exponent, there will be a finite number of floats of that size, and there are a countable number of options for mantissa and exponent (corresponds to N²), thus the number of floating point values is countable.

Alternatively, each of them corresponds to an arbitrary length bitstring, in addition to a pair of numbers defining the mantissa and exponent, which would put them in bijection with N³ and thus also be countable.

EDIT: to add to that, I believe that one cannot in any meaningful way encode uncomputable values (in the sense that even if one introduces distinguished bitstrings intended to "encode" a specific¹ uncomputable value one can't do anything other than treat is as a distinguished value, and especially one can't perform arithmetic on it or print its digits or similar), so you'll still be limited to a countable set of floating point numbers even with other tricks.

¹ If that term even has meaning when dealing with uncomputable numbers...

It should be noted, the LG Prada predates the original iPhone by about 6 months, with largely the same design (to the degree that LG sued Apple alleging that the design was copied). Apple managed to capture the market, however, whereas LG didn't.

This is a fair point.

I think the only axiom you need to rethink from ZF is powersets (since I think that's the only axiom that produces uncomputable sets from computable ones (ignoring the AC, briefly)). What you'd replace it with (some sort of one based on comprehension, presumably) I couldn't say though.

I tend to prefer considering the sets to encode bitstrings (encode a set as sum(2 ^ -x for x in X)), but yes the equivalence between computable sets and computable numbers is straightforward.

In this case, what you "throw out" are uncomputable (or non-recursive, depending on terminology you like) sets; i.e. sets for which the membership function is not decidable. Yes, there are an uncountable number of these sets, but they can't be defined in any useful way.

For reference, most of the surveys listed by Wikipedia[0] (not including that one, for some reason), list Firefox at about 30% in that period. I assume that the stats in your link comes from visitors to their own site, which given the focus (web development) seems like it could easily be biased towards more technical users (and thus over-represent Firefox compared to wider surveys).

[0] https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

The point I'm making is that despite FF being a better alternative for years, it didn't actually crush IE's market share. Chrome did, and I'd put that down to marketing more than quality (as evidenced by quality not being enough for Firefox or Opera).

The flaw with this notion, is that neither Firefox nor Opera beat IE.

Chrome did.

Most of the people who argue things like this seem to agree that Firefox and Opera were superior browsers to IE. If that was the case, why hadn't they eaten IE's market share long before Chrome was ever produced?

Could it be that Chrome being widely advertised on the most visited site on the internet helped?

To add to that, Google already abuses its position with Chrome (see the stuff surrounding AdNauseum in the past couple days). One company having as much power over the shape of the web as Google already has is scary enough, the notion of them "winning" the browser wars is even worse.

Doorknobs are much harder than lever type handles for people with arthritis or similar conditions to operate (since they require gripping firmly, as opposed to just pushing). However in some areas where bears are a threat, doorknobs are mandated since bears have been reported to have learned how to open lever handles (but either haven't learned or lack the dexterity/grip strength to use doorknobs), so knobs are safer.

The code example you give isn't an example of evaluation order, it's an example of different expressions not giving the same result.

Order of evaluation being irrelevant means that when evaluating

    (cons 'a (cons 'b nil))
it doesn't matter whether you first create the outer or inner cons cell. Or, for that matter, whether you do anything at all at this point (you could for instance just suspend the entire expression as a thunk and only evaluate them when you try and access values within the list -- i.e. lazy evaluation).

Sounds like Rust. If not, what do you think disqualifies it?

Rust never struck me as a functional language. It's disciplined, in the manner of ML or Haskell, but it is generally (and inextricably) an imperative language at heart. The strong type system is geared towards making imperative, stateful code safe, rather than eliminating it.

It's political first, and only incidentally technological.

"Information should be free" and "mistrust authority" are both obviously political statements, and most of the others are at least somewhat political in nature. That you don't see them as political is a reflection of you, not of some timeless pure technological nature inherent in them.

Conversely, +24 hours may fall on the same calendar date or two calendar days on from now.

Really, "tomorrow" should be the interval from the beginning of the next calendar date to the end.

What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

That particular example is fairly straightforward (at a simple level, passwd files aren't complex), but being able to express arbitrary nested structure would make various things a lot more straightforward. Line breaks and some sort of tab/colon/what have you work fine if everything has at most two levels of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the random formats for files are fairly strict about what they parse, and the ones that matter (e.g. passwd, sudoers, crontab) are conventionally edited through tools that check the syntax before committing.