HN user
OP here. Sorry if I misunderstood the guidelines, but these are not the same stories. The proposal to scrap the term limits was announced two weeks ago, which is what those stories talk about. This new story is about the proposal having been approved by the parliament (a couple hours ago). Though I suppose there was little chance of it not passing, I did think it's a historic vote, so I thought I'd post this as well.
It's only my impression, really. But I have seen a slew of articles about how jQuery is dead, and very few people still writing articles about it's benefits. Many libraries that use it are also unmaintained now (though they often still work, of course).
If you want some numbers, compare e.g. the dates on popular HN posts for jquery[1] vs react[2] and vue[3]. Most popular articles for jQuery are 4-6 years old, while for React and Vue the popular stories are much more recent. Of course, HN might be somewhat special.
[1] https://hn.algolia.com/?query=jquery [2]: https://hn.algolia.com/?query=react [3]: https://hn.algolia.com/?query=vue
If you simply want the latest stable docker version, try:
curl -o /tmp/get-docker.sh https://get.docker.com && bash /tmp/get-docker.sh
curl https://get.docker.com | bash
This article alleges that there may be a hidden bias against female scientists receiving Nobel prices. If the author had included a long list of female scientists that deserved a Nobel price, but did not receive one, it would have gone a lot further to making its case.
However it only names one (Vera Rubin [1]). However one possible case seems insufficient evidence to prove a bias here.
Not saying such a list cannot be drafted - just saying it's not presented here, and so it's hard to buy into the bias argument.
I feel like the core value proposition is something like "public expressions that can be consumed quickly and produced with little forethought". I think it's important that Twitter gives you the excuse to be less precise: there isn't enough space.
It's a small thing sure, but if you look at the differences between the popular social platforms, it's all about small differences. If Twitter loses that which distinguishes it from everyone else, that may give them an initial boost when it's a new feature, but then the novelty will wear off and maybe they will have lost what makes them unique.
I'd like to compare this to Hollywood. It feels like the kind of alteration a studio might come up with by relentlessly screen-testing a movie using test audiences. It's one way to guarantee a bland, non-specific result, that won't command any lasting mindshare.
Clearly moving from 140 characters to 280 characters isn't yet that just-like-everything-else end result, but it somehow feels like a step in that direction to me.
I'm not sure what to make of this.
I suppose there is nothing inherently ideal about the (arbitrary) 140 character limit on tweets. Why not 180, or 280, etc?
Still, my first reaction was, this is .. a bad idea: the 140-character limit is iconic, it's at the core of their value proposition, and Twitter is going to dilute their brand if they abandon it.
I think it's not only that people sometimes feel limited by the 140 characters that matters, it's also all the other times when people don't feel social pressure to write up longer, perhaps more thoughtful messages, that's important here.
Specifically, he compares compares blockchains to the Internet and railroads:
"It is a bubble. This is going to be the largest bubble of our lifetimes, and so .. remember, bubbles happen around things that fundamentally change the way we live. The railroad bubble, railroads really fundamentally changed the way we live; the Internet bubble changed the way we live. And so, prices are gonna get way ahead of what they should be. You can make a whole lotta money on the way up. And we plan on it. At one point you're going to have to sell."
The term 'usage rights' is a bit confusing here. I think it may be intended to refer to 'use' as defined in the previous half of the sentence, i.e. 'including the rights to run, read, copy, change, distribute and sell'.
Maybe this should be made clearer somehow, e.g. 'and including any herefore necessary license to patents the authors may hold'.
The 'software' is what is provided by the original author(s), and the rest refers to the patents held on 'it'.
What you describe would be a 'derivative work', as mentioned in the second paragraph.
It might be clearer if it was capitalized like in the MIT license, but I think it's pretty clear as it is.
Using the 6.3 Richter scale, the energy released would be ~43 kilotons of TNT.
That's curious. Every yield estimate I've seen so far was substantially higher than this. Could you explain how you arrive at this number?
Hi, thanks for the link. I've seen this paper, but it has nothing to do with strongly typed languages, as far as I can tell. In fact, there is no mention of types in the paper at all, it's strictly automated analysis.
When a test suite finds a bug, that proves that the program is incorrect for some inputs. When a type system doesn't reject a program, that proves that the program is correct for all inputs.
Which one to use depends on the impact of an error. In the case of a system that controls lots of money, you'll want a guarantee that all inputs lead to a correct balance. That suggests to use a type system.
When a test suite passes that proves that the program is correct for a subset of all inputs. But I do not see how the same can be said about a type system.
Types do not usually capture semantics - unless we are talking about something a lot more powerful than what I'm used to seeing in real programming languages.
I think a good compromise would be a language that allows you to annotate your types with arbitrary properties, but doesn't complain if it can't type-check them, so long as you write a test.
But why do I need types for this? Why can't I just assert the properties outright, writing assertions only in terms of the code interface? It's not the types that tell me what arbitrary properties my code should have!
Property testing [1] is about semantics, the same as regular testing, and it does not require code annotations. [Edit: It's more like "fuzzing" than "model checking".] Type systems on the other hand aren't usually powerful enough to capture semantics.
They allow you to say things like, this function takes in a list of Foo objects, and returns one Foo object. But they don't really let you express whether the object returned is or is not part of the original list, and if it is, that it was chosen according to the right mechanism. That's what tests are for.
Without being able to express the semantics of code, I don't see how you can trust it. There may not be any type mismatches, but there sure can be lots of bad logic in there.
[1] http://hypothesis.works/articles/what-is-property-based-test...
Are we talking about automatic type inference then?
Otherwise you'll still have to work out each type before it becomes "automatic". Which is not entirely dissimilar from working out a test suite.
Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts.
Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs.
But I'm more excited about things like property testing than I am about things like strong type systems. And I'm wondering specifically what is the value they bring.
No offense, but all of the answers I've gotten so far are very vague, and don't really address my question. I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites.
Let me give you an example, say we have a hypothetical language with a strict type system, and we declare a variable to be of type List[Foo]. Then later we use that variable as if it was really of type Foo. That's not gonna work, and a type-checker would catch that at compile-time. But a test suite (that covers the variable access) is going to catch that as well, because the code won't behave as it should.
At which point is a strong type system going to surface a bug that a good test suite would not have? Like, can you give an example?
Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?).
The line is as variable as the strictness of the type system we would compare it to.
I guess one could argue that a type system will force the programmer to satisfy it, while a test suite can be written very sloppily. So maybe there is some kind of signalling value in using these types of languages.
I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system?
I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway?
I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not?
Note I'm not saying that tests guarantee bug-free code, or that you can't do both. I'm just wondering about which different kinds of bugs you might catch.
Yes there are a number of models, but since the quality of the results depends a lot on the training data as well, which I wouldn't know how to find or evaluate, and possibly might require tweaking algorithms for different languages, which I wouldn't know how to do, it's not really 'usable' (for me).
I figured someone would have gone to the trouble of combining models with a maintained collection of datasets to produce an open source alternative to Google Translate by now. I've been wondering that for years and it never seems to happen. Not saying anyone should feel obligated - I'm just curious why we don't see this, when we see so many other open source software projects that are competetive with their commercial alternatives.
Is it difficult/expensive to acquire these datasets? Is it a lot of effort to actually fine-tune the algorithms to reach passable results?
It seems (without knowing the details myself) that the state of the art in actually usable machine translation tools is always locked up in commercial IP, even though it feels (at least to me) like something that should be a free public service and therefore an ideal candidate for the 'open source' treatment.
On a slight tangent, are there any fully-trained ready-to-work state-of-the-art open source distributions of translation systems available?
I've never been able to find one, but maybe I just haven't looked hard enough.
Knowing that you have less than people somewhere far away isn't necessarily a strong motivation to desire more. The one's wanting to flee the regime are those who are oppressed by it. That isn't everyone though. There are always many people who find the status quo perfectly tolerable, else it would not be stable.
Generally, most people only care if they have more than their neighbors (re: materialism) and about their standing in the community they are embedded in (re: ideology).
This creates a self-reinforcing effect. For example, while most people will say that they [edit: the NK elite] are worried about their families being hurt, I would argue they are more primarily worried that their families and friends will disapprove.
Sure there is a real risk to dissenters, but you don't start out as a full-blown dissenter; you start out embedded in the society with maybe some innate doubts about certain things. It's the internalization of the projected negative reactions of those around you (basically your 'conscience') that makes people unlikely to ever allow themselves to mentally oppose the regime, if they have no strong incentives to do so (i.e. suffering unbearable hardships and oppression - and again this is often judged relative to what your neighbors are going through).
As a government scientist in NK you are part of the elite, so you're a pretty good position. You're essentially in equilibrium with your environment and I would imagine something would have to come in and shatter that equilibrium before you would consider going against everyone around you.
Controversy and hostility are not the same thing.
I haven't read the Tezos paper yet but I will add it to my reading list. Thanks!
I do think there is a lot of potential room for improvement in how blockchain governance works, especially in terms of delegate voting.
Maybe it is more reasonable to expect a majority portion of one chain and a majority portion of another chain to merge, leaving behind two stragglers, and then allow those who continue to hold the old tokens to buy in later at a decreasing discount.
Right, and that's a lot like agreeing on an acquisition price in the case of a merger. There too stock in the acquired company is commonly traded for stock in the acquiring company at agreed upon prices.
And technically, I think it must remain possible as long as you can always simply issue a new token with a certain starting distribution.
Chains splitting off is a very interesting phenomenon. Just like with Ethereum Classic splitting off Ethereum, the value of the original chain can be divided into two, albeit unequal, parts. The process may even create new value - though I suppose it might just as well destroy value.
What I've also wondered about though is multiple chains combining into one. Does anyone know if this has happened before?
I believe there is a strong analogy here to how company stock can evolve, when companies are either split out as separate entities, or merged into one, respectively.
In the example code used, the random number which determines the winner is derived from the previous block hash. Since the lottery-owner determines when the function is run, they could call the function when the previous block hash favors their own bet, or else modify their bet before calling the function.
Yes, but the author does point to [1] for a better way of generating randomness for such a contract using commitments.
[1] https://ethereum.stackexchange.com/questions/191/how-can-i-s...
You might also want to pass --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost" to Chrome to avoid leaking DNS queries [1].
Edit: typo
[1] https://www.chromium.org/developers/design-documents/network...
I like to trot out this link whenever this comes up [1].
[1] https://semaphoreci.com/blog/2016/11/11/python-versions-used...
Check out TokenMarket [1], it might serve your need.
It is not enough to develop technical solutions to circumvent the privacy erosion, as these will soon be branded as aiding crime or the enemies of the state, and eventually regulations like these will be passed almost everywhere.
Companies standing up for the privacy of their users should be held to a higher standard than simply imposing limits on their own data collection.
They must band together to actively lobby to counter these kind of policies to not run the charge of moral hypocrisy.
Another problem is that the party leadership on all sides is often more or less in favor of these policies.
If there is to be any effective political opposition to this it must be organized from the bottom up.