jsnathan's comments

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.

[1] https://tokenmarket.net/ico-calendar

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.

In a similar vein there is docker-mailserver [1].

[1]: https://github.com/tomav/docker-mailserver

If there is shown to be a demand for this kind of terminal UX, someone may well write a native version of it. Possibly it will push some of the existing terminal emulator projects to add new features, or someone will fork one of them.

Either way, it's nice to have options, and it's nice to see innovation, and if Electron makes it easier to innovate we should be glad of that.

Another simple tool of this kind to try out is Marp [1]. It has a live preview, and slides are exported to PDF.

[1]: https://yhatt.github.io/marp/

With this kind of money, she can easily start her own company. Or companies, for that matter.

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).

> I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...

I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions.

I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing.

And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm.

A common pattern of rationalization I often have goes like this:

"Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier."

I'm not saying that this reasoning is wrong, only that it is biased.

Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons.

The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs.

The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.

It's still being debated (for what that's worth) but there are numerous studies that indicate that they do [1].

I don't think we have any workable theory at this point that would explain how exactly (biological) neural networks produce pain, or predict how complex they need to be to do so.

[1]: https://en.wikipedia.org/wiki/Pain_in_crustaceans

I like this, this could be useful. The easier it is to access this kind of information the better.

There are services that have the specific purpose of identifying discussions about brands in real time [1].

Whether that's good or bad depends on how it's used I guess.

[1]: https://mention.com/en/

BEAM wasn't designed for OO languages where all values are mutable objects. It would be highly impractical to try to run Python on top of it.

You'd have to create a Frankenstein interpreter to get anything working.

That's not what he said.