It would be as if your Walmart dollars actually had an exchange for other currency. I would see this as a good thing. Then the poor worker who is being paid in Walmart dollars can know exactly how much they're being paid.
189 karma · joined November 4, 2016
It would be as if your Walmart dollars actually had an exchange for other currency. I would see this as a good thing. Then the poor worker who is being paid in Walmart dollars can know exactly how much they're being paid.
But anyone who is serious about writing maintainable code today should be using an IDE where the benefits of susinctness are entirely relegated by intellisense-like tools.
Trading readability for conciseness is near the top of my list of "crimes against future maintainers."
So I had never thought about this in the context of mathematical symbols, but this makes total sense and I'm strongly in favor of relegating mathematical conciseness in favor of readability and specificity.
But from a technological perspective, even if 2016 is the high water mark of the "centralized" internet, a new internet is forming. That which you lament is the natural result of a centralized system. It's something that the early creators of the internet have warned about since its inception. But now as the incumbents centralize control, a new generation of technologists (helped by many of those early creators) are constructing the underpinnings of "Web 3.0", a decentralized internet built on Ethereum, IPFS, WebTorrent, BigchainDB, SOLID et al.
There is plenty left to do, it is still a newborn child... nobody knows where this goes. But come 2030, I agree we'll look back on 2016 as the high water mark of the centralized internet. But instead of longing for how things were in the 1990s and 2000s, we'll say "good riddance".
All that said, the battle needs to happen on the political front at the same time, which makes EFF, FFTF, and ACLU so important.
A poorly enforced law provides a tool for executives (the law enforcers) to legislate (make their own laws) without any say from the real legislators. It's a loophole of sorts in the US's separation of powers.
Take marijuana. It's illegal to smoke marijuana. It's not illegal to be black. Yet the selective enforcement of the marijuana law allows authorities in any given district to shape policy on race without ever having to explicitly put a law on the books.
This is why the Computer Fraud and Abuse Act is so dangerous. It is broad enough to be used as a tool to enforce laws that would be too unpopular to explicitly pass.
It's also why threats from the US government to "ban encryption" should not be taken idly. You think to yourself, "Certainly they couldn't ban encryption, nothing would work without it." But they wouldn't enforce it across the board, only selectively.
They tried to buy Snapchat too.
Some interesting reading on how we might measure the unusual cost of Facebook's monopoly to society.
https://stratechery.com/2017/facebook-and-the-cost-of-monopo...
The complexity you're referring to may be the runtime? It is more complex than, say, Bitcoin because it has for most purposes a Turing complete language baked into the protocol.
Bitcoin is a blockchain that forms consensus on the state of a specific implementation of a data structure (somewhat arbitrarily, a list of transactions) and it has a very limited set of operations to manipulate that data.
Coming to distributed consensus on a transaction ledger is ultra-useful, as we have come to know. But there may be other data structures that may be useful for distributed consensus as well. Rather than building a blockchain for each one, why not build that flexibility into one protocol so the developer can choose?
Ethereum is a blockchain that forms consensus on the state of a more general set of data types, with a Turing complete language to operate on the data.
More complex? Yes. But the hope is that this flexibility drives a rich developer ecosystem, where innovation can happen within the network, rather than having to build your own network from scratch.
As for decentralization leading to fragmentation? This is a feature, not a bug. It is the feature that allowed Ethereum to grow in tangent with a thousand other blockchain mechanisms. Maybe fragmentation will bring its demise, but it as breath of fresh air from our rapidly consolidating tech industry.
...actually precedented by all the resources we pour into forcing the climate TO change.
And, asteroid, seriously? This is the best we can do now? May as well not eat meals anymore because hey I could get hit by a bus on the way to work.
The issue is not storing the data, just like "email" doesn't store data. It's just a protocol and a data format. This makes it interoperable across whichever industry player wants to spring up and compete for your service.
Ex:
Don't like gmail? Go to ProtonMail. And you don't lose the ability to interact with people who do use Gmail.
Don't like Facebook? Go to Ello. But now you've lost your entire network.
The decentralized web will be built on data formats and protocols that allow you to take your data with you and force companies to compete with the quality of their service, not the size of their network.
It was released 5 months ago.
Obviously, to each his own.
I'd encourage you try Typescript again though. Your given reason doesn't make much sense. Regardless of whether the language is strongly typed or weakly typed, you still need to use modules and libraries correctly. "Not having to research" means you're just going to end up throwing data at a library without knowing what it's expecting. The research has to happen in both scenarios, but with typed languages it's easier. The research is just in the code already. (Try VS Code, not a "heavy" IDE by any means, but it has native support for TS code completion.)
If I have any modular interface, you need to know what to pass me. If you're receiving data from me, you need to know the structure of what I'm sending back to you.
In a weakly typed language, you can guess at what data structure I'm going to want. You can fish around in my returned data for what you're looking for with no guarantees. You have to look for docs, which may or may not be up to date.
But in a strongly typed language, the code is the doc. You and I and your IDE and my IDE are all on the same page. And the docs are always up to date. You can't pass me data that I'm not expecting and you always know how to access the data I'm returning to you.
I use VS Code (with the Chrome debugger plugin) and that works like a charm. I don't debug javascript in the browser anymore.
TS provides source mappings to map the compiled javascript back to the source (similar to a .dll's .pdb maybe?).
It took me some time to set up the config file which proved to be a headache (because webpack was screwing with the source maps), but again once that was set up it has been a breeze to debug right in my IDE whenever I want.
I understand the frustration of someone who has used AngularJS 1.x. There is not really a straightforward and low risk path to upgrading a production app.
But that is like saying there is not really a straightforward risk to switching from AngularJS 1.x to React. They're different frameworks. AngularJS is different from Angular.
In my opinion the Angular team has created something really special with this new framework. I think it falls into a category of its own, very difficult to compare it to something like Vue.
I started using it when this app was very much a POC last summer, just as the Angular team was finishing up the 2.0 release.
I learned firsthand last summer the issues with using a framework that was still in the oven: constant updates and some dependency changes. That was no fun for some time.
But I'll say now that it was worth it. (Maybe I should have started a little later, post-2.0 release). But I'm now building out a decent sized and complex application much faster than I'd ever done before.
It is strongly typed, it is modular, and it has dependency injection. Oh and it's strongly typed. I can't emphasize the importance of this enough. I know you can use typescript without Angular, but that the Angular community and the docs are all in typescript make this a typescript-native framework.
I'll never look at JavaScript again if I don't have to. You and your IDE and the rest of your team can know an object's Type without having to scrounge around, it's such a blissful departure from JavaScript.
It definitely has a learning curve. If you're spinning up a simple web app it may or may not be for you. (...though now I use it to spin up simple web apps because I'm used to it and it's so good for that) But for anything complex that is being worked on across a team, I recommend you take the time to learn it.
It's not perfect, nothing is. But it is leagues ahead of any framework I've used on the front end. And having gone to Typescript, I will never use a native JavaScript framework again.
The rules aren't: "the code is the contract".
The rules are: "the code that is accepted by a majority of hashing power is the contract."
data privacy net neutrality
My plan is to make a sign for the next march that urges action on those specifically. Doesn't feel like much but maybe it gets on the news. Maybe 500 other people see it and associate it with issues they care about.
And if you host a million techie march, I'll join.
The point is, some is better than none. More is better than some.
So many people here pointing out holes that make it worse than a theoretically perfect system even though it's leagues ahead of where we are now.
I have always looked forward to self-driving car networks because of what I perceived to be their ultra-competitive and ultra-low margin nature.
Then two years ago everyone started talking about an Uber monopoly and I got super upset. Are we seriously seeing another industry ultra centralize due to technology?
But I'm beginning to suspect that this may be a massive miscalculation on the part of Uber and its investors. Maybe it is a low margin, highly competitive industry and Uber will be remembered as that one company that subsidized everybody's rides for a few years until it just faded into the background.