gloob
gloob on Hacker News
> So, please forgive us our gallows humor about this.
Apologies for my pedantry, but dreaming about harming people is actually pretty much the opposite of gallows humour. A more appropriate phrase might be "power fantasy."
It's okay for you to be wrong about something.
It's unclear to me whether you want "to write a program" or to "get the maximum out of Haskell". Those are two very different goals.
But first, how about we let capital usurp the political system for its own ends? That seems like a reasonable compromise to me.
I, too, feel that perfectly uniform brace positioning is one of the critical technical challenges facing any new language today. There is no longer any excuse to get such an important and fundamental advance wrong.
By that standard, geometric population growth is killing people.
I agree with you entirely and unreservedly. The scare quotes in my comment were to poke fun at the idea that a person who holds a set of racist opinions is somehow not a racist.
I do maintain that it is, in some sense, a "reasonable" position for a racist to be more offended by incivility than by racism. Not ideal, or even good, but certainly understandable.
To be fair, that's a reasonable position for a person who's "not really racist, but holds opinions that they concede certainly sound racist when said out loud".
I feel like I'm missing something terribly obvious, but...
How does "it is getting harder and slower to move large files over the net" lead to the conclusion "therefore we should store all our large files on the net and retrieve them whenever we want, rather than keep them on local media with negligible latency and huge storage space"?
Should a Japanese octogenarian whose parents had the poor taste to spell their child's name with a character that would not make it into Unicode expect the same problem?
I look forward to being convinced that housing and car manufacturing are more stable and resilient than services.
Given that the entire website this article lives on is about roguelikes, and the author is also the developer of a roguelike (Unangband), I imagine he is likely aware of the history of randomly generated levels.
Is it normal business practice to use ultimatums instead of negotiation?
I agree that, when we are talking about high-level languages, I prefer ones that will transparently convert integers to bignum when required. I'm just replying to the contention that (paraphrased) "this is a bug in PHP's handling of floating point numbers".
This sort of thing is an intrinsic property of floating point math. It has limited precision. When the numbers get sufficiently large, that precision is insufficient to distinguish successive integers. That is to say, this is symptomatic of PHP implementing floating point stuff correctly.
This is what ghci (Haskell) says:
Prelude> 9223372036844775807 == 9223372036844775808
False
Prelude> 9223372036844775807.0 == 9223372036844775808.0
True
This is what Python says:
>>> 9223372036844775807 == 9223372036844775808
False
>>> 9223372036844775807.0 == 9223372036844775808.0
True
Here is what SBCL (Common Lisp) says:
* (= 9223372036844775807 9223372036844775808)
NIL
* (= 9223372036844775807.0 9223372036844775808.0)
T
Lua:
> print(9223372036844775807 == 9223372036844775808)
true (!!!!!)
> print(9223372036844775807.0 == 9223372036844775808.0)
true
Javascript:
alert(9223372036844775807 == 9223372036844775808)
true (!!!!!)
alert(9223372036844775807.0 == 9223372036844775808.0)
true
Other languages that will also do this[1]: Javascript, Lua. Languages that won't: anything with actual, honest-to-god integers, and not floats or doubles masquerading as them.[2] Languages that actually handle numbers sensibly: Lisp.[3] I'm not familiar with any others that actually treat rational numbers like rational numbers, but I expect there are some. (It's still, of course, impossible to treat real numbers like real numbers, meaning that this sort of thing will also happen there.)
[1] Well, not the string-to-number bit, but whatever.
[2] Except for the niggle that they'll still do this when you're using floating point numbers, because this is what floating point numbers do.
[3] https://en.wikipedia.org/wiki/Numerical_tower
Is there a "canonical" justification for why the US legislative system allows non-germane additions to a bill? Or is ball-of-mud style legislation the norm due to tradition, rather than some philosophical ideal?
You get downvoted a lot. shrugs
The correct response to that saying is to point out that regular expressions are significantly simpler than general-purpose, Turing-complete programming languages.
If you haven't seen Trusting Trust already, you should read it:
http://cm.bell-labs.com/who/ken/trust.html . It's short and smart.
The brief summary is, of course, you can almost never really know "logically what's happening", even in nice reliable languages like Java or Python or Haskell or Ruby or C.[0]
The easy solution (and the one that every working programmer makes every day) is to say: well, let's assume that the compiler is non-malicious and has relatively few bugs that will impact me. That's a fair response.
Next we run into the fact that just because you call a function, and that function happens to be called add(x,y), doesn't actually mean that the function will return the sum of x and y. In the absence of further evidence, it could be an HTTP server or fill your hard drive with infinite copies of Das Kapital or anything at all. The normal solutions proposed to this are (1) read the documentation, or (2) read the code. Those are both workable solutions.
Then macros come into the picture. I fail to see how the already-heavily-used techniques of (1) reading documentation and (2) reading the implementation of the macro, which seem to be at least tolerable and mostly workable with functions suddenly fall apart with macros.
[0] C and C++ have the preprocessor and macros anyway, which "change your program logically...prior to compilation", so I won't mention them further in this comment.
All noses are frozzle.
Some wiggles are noses.
Therefore, some wiggles are frozzle.
Much the same thing that it says about English-speakers when they have to borrow the word "entrepreneur".
I really don't think 'the public' has any more say in this than they did about how cookies work. They're as clueless about how politics and laws work as they are about technical matters.And web developers have every incentive to keep it that way.
To my understanding, it is generally accepted that the primary purpose of karma points on HN is to encourage good discussions. One of the most common reasons I've seen proposed by people who want to bring back visible scores for comments is "it'll make threads easier for me to skim". Another common reason I've seen is "how can I know what I should think without visible karma points?" I feel that it is worth bearing in mind that neither of those reasons is "bringing back visible comment scores will improve the quality of discussion." I also feel that (with the exception of borderline-trollish comments like
http://news.ycombinator.com/item?id=2495648 and "Bring back visible scores because I'm angry today!" threads) that discussion quality has improved since comment scores where made invisible, though obviously that position is up for debate. But, if we accept that the primary purpose of karma points is to encourage good discussion (and making, e.g. skimming comment threads easier is at best a secondary purpose), and (for the sake of argument) we accept that making comment scores invisible has improved discussion quality, then it is clear that the correct decision is to keep comment scores invisible, imho.
You had to give money before you were able to receive money... Sorry, that seems like a classic pyramid scheme.I'm having a hard time thinking of a single B2B company that isn't a pyramid scheme, by that definition. Pretty much everyone spends money in order to make money. Easy example: before I can build and sell my widgets, I need to buy the parts for them.
Fair enough. Ignore my second question then. Can you point me to a credible argument for the idea that all innovation relies on privacy breaches, or that only companies who hold customer data are capable of innovation, or some other causal link that would make "strong privacy laws -> no innovation ever" hold?
Perhaps you've just overstated your point, but could you provide any evidence supporting the statements that (1) stronger privacy laws would cause all innovation to stop, or (2) stronger privacy laws would cause us to revert to a 1200 AD level of technological development.
Edit: To make my point less pedantic: your argument, as you have currently phrased it, is every bit as alarmist as those you disagree with, just in the opposite direction. It's like appealing for calm by calling the people you disagree with whores. At best, such a tactic undermines itself.
Actual discussion:
It is self-evidently true that fines for data breaches would discourage companies from allowing more data breaches. You have countered this by saying such a policy would harm innovation. The snarky response would be that harming innovation in the realm of data breaches is exactly what we want to do. A less snarky response would be to ask you to provide any evidence that investing in proper network security would have made Sony less innovative in any measurable way.
My first guess: because that's how every single person who gives a shit - ranging from pundits to corporations to fanboys of every conviction - has framed it ever since Android first came onto the scene.
Given that assembly is simpler than C++ both syntactically and semantically, a reasonable argument could be made that it is a more elegant language.