Don't give me that bullshit. It's not hard at all. It's not even close to hard. It would be an understatement to call it easy. Anyone complaining about this is so steeped in entitlement that if they told me such a thing in real life I'm afraid I would become animal-like. Such complaints are worse than pointless and I hope OP or whatever refers to the guy I responded to originally, and to some extent you, get some fucking perspective. It's embarrassing.
Man, I'm just tired of people crying about how hard their life online is. If someone were complaining to you in real life about how they had to not pay attention to a single line of text — so much so that they had to call it out at the time — I think I would have to just tell them how shitty I think they are. I've seen too many people doing it to pretend it's not a pervasive problem among the tech-literate. Someone needs to tell them their objections are so trivial that they ought not be aired at all. It's a strange paradox!
The title is a bit opaque but with the domain displayed next to it I don't think it's that hard to infer hash+blocksomething=bitcoin.
For what it's worth I don't like all the Bitcoin stories on the front page but sometimes they're interesting (the slow motion train crash that is MtGox) and other times, when they'd not interesting, they're not hard to ignore.
The problem isnt just the title - this whole submission is pointless.
I saw the long hash and assumed it had something to do with bitcoin. I clicked through onto the link, but I still have no idea what's going on. I'm guessing that someone sent and recieved lots of bitcoins in one transaction, but I don't know the significance of that.
Perhaps the OP could have linked to an article discussing or describing it? Or even have made the submission a text submission and commented on it himself?
This is the largest "bitcoin days destroyed" since ever. It's also most likely Mt. Gox's bitcoins that are moving as well. This transaction can be traced back to an arbitrary transaction Mark Karpeles made to prove he still had keys to his address some time ago.
- where else does $180million move without any fees, in the blink of an eye?
- some transactions after this diverted some money into Satoshi Dice, so it's most likely not the Feds who control this, and they're potentially interested in laundering potential.
This is by no means isolated to engineering or mathematics either. Nearly all students, especially in higher education, will have gaps in their understanding of topics they are expected to just know. The classroom simply isn't able to personalise learning to each student in the way that's needed. The only thing that really can help here the is clever application of technology.
This is part of the problem that I'm working to solve with my startup Ellumia. Some others are making great strides in areas like language learning, but there's still lots to be tackled. We're building a mobile platform that blends bite-sized content with a highly personalised, social experience – something that would be immensely helpful to the students mentioned in this post. If you're interested in innovative learning methods, please check us out: http://www.ellumia.com
Specifically, we offer courses that are far shorter and more targeted than a "traditional" offering (or one that you'd find on a MOOC). Content is broken down to the concept level, and available in multiple presentations. This facilitates delivering content that is most suited to a learner's personal style, as well as spaced repetition whereby a student exposed to the same information multiple times over a period of time, in an altered format or context. As I mentioned, this is on mobile, a space that's largely ignored aside from educational games in higher learning.
I hope that is a little less buzzword-heavy, though I suspect it may still not be as BS-free as it could be. Learning what messages work best for different audiences is all part of the fun with a startup…
I'm an EU citizen and it seems a bit annoying to me, too. Clearly I'm in the minority (the upvotes are against me), but if I wanted to keep track of their progress I could just as well follow their blog or Twitter.
The halting problem assumes a program from a Turing-complete model of computation. Not all computational models are Turing-complete. The parent is pointing out that if you limit yourself to a language or a sub-set of a language that is not Turing-complete, then you can make static assertions about things such as halting.
A trivial example would be a programming language that did not allow any loops or explicit backward branches. You would be able to provide upper bounds on how many operations such programs can perform.
> if you limit yourself to a language or a sub-set of a language that is not Turing-complete, then you can make static assertions about things such as halting
There's already something that is non-Turing complete, but comes with a halting guarantee -- it's called total functional programming. This paper (linked below) is actually what got me thinking about this whole thing. The author argues in it how functions in functional programming languages aren't really like mathematical functions, because they have the possibility to execute infinitely (never halt) and thus not have a proper return value. To mitigate that, he creates "total functional programming".
Total functions are guaranteed to have a return value (i.e. terminate eventually), but they could take very long to run. If we could actually have complexity bounds, or be able to determine a given function's complexity, that would be a great boon to software engineering (i.e. assuming they adopt it... which is a whole different matter).
The author also makes a very good point that most parts of your program are meant to terminate (i.e. the vast set of functions and algorithms that comprise you program). Only the top-level needs to be Turing-complete, the rest can at least be total.
I actually want to see if it's possible to push this concept further, to create a ring-like hierarchy of languages -- the lowest one being the weakest and the one we can extract the most static assertions out of, and so on. There's a language called Hume that sounds like it accomplishes at least part of this goal, but I haven't really looked into it.
One thing I really like about dispatch tables is that it forces the developer to only be able to handle the decision logic. The number of times I've had to cleanup a switch with 20-30 lines under each condition (sometimes including another switch) is too many to count.
> The performance is substantially different. The dispatch table is ~75% slower (in chrome).
Of course those are, they're doing very different things in that test case. Your first case is just returning a value, and the second is executing a function to return a value. Here's a better comparison, http://jsperf.com/switchvsdispatchtable/2
There's nothing inherently slow about dispatch tables, it all about how you implement them. As someone else mentioned, the OP should be using bind to reduce the # of function calls instead of executing a function which executes a function.
Yes it is just you. :) The original becomes horrible when the number of cases grows, when you want a default and can introduce subtle bugs if you forget a break. In the second example, there is a clean separation between processing commands and dispatching on the input. For example, you might want to extend processUserInput with "invalid command" handling, commands with arguments or even add commandTable as an argument to it so that you can reuse it for all your dispatching needs.
And to top it of, you can dynamically add new commands to the dispatch table which you can't to a switch.
It depends, sometimes if you have a few different context e.g. multiple click handlers that are being bound in different contexts of your app, that a table makes a lot more sense then repeating the switch or even wrapping the switch in a function...
While I agree with your suggestions (caching is absolutely a must, as is batched rendering etc), but I think the real issue is the lack of good-quality canvas libraries that have the kind of breadth of functionality that their native counterparts have have. All of these "performance hacks" are certainly not unique to canvas, but what is is unique is the developer (user of these APIs) having to care about them. They should be abstracted away.
Libraries like Paper.js (which I've used and extended a lot) and EaselJS are bridging the gap, but they aren't there yet — either because they aren't feature-complete in the way that they need to be, they're buggy, and/or they don't seem to be getting enough community development (or in some cases, want it).
It's actually standard UNIX quota soft/hard limits. So you have a soft limit of your (paid quota) that you can drift above for 7 days (that is the grace period) and you have a hard limit of (quota * 1.1) that is ... a hard limit.
We have an automated alerting system that emails primary and technical contacts in a progressively more aggressive fashion as you drift above the soft limit and approach the hard limit...