I love how cryptocurrency is like a history lesson for Libertarians with regressive economic attitudes. They get to learn the hard way why each discrete financial regulation we have today was enacted.
Even if I conceded every point you made about shortening terms, none of those benefits outweigh the benefits of legalizing noncommercial infringement, which is why I find mainstream copyright reformers so insufferable. The Lessigs of the world get really excited about shortening terms and have nothing to say about the far more important issue of legalizing noncommercial infringement.
That's why we should legalize noncommercial infringement first. We can debate terms afterward.
The way people celebrated public domain day was quite telling. People were like, "Yay now I can consume this content for free," not "Yay now I can create commercial derivatives."
People often say "why not both?" I'll tell you: we already have an originality crisis in popular culture. Are you tired of the constant reboot culture in Hollywood? I sure am. It would only get worse if more stuff entered the public domain.
Legalize noncommercial infringement. That's what we should be focused on. Not shorter terms.
"An insider's groundbreaking investigation of how the global elite's efforts to 'change the world' preserve the status quo and obscure their role in causing the problems they later seek to solve."
It's time to abandon proprietary IM services and start using Matrix. The most popular client/server is Riot but you can run your own server and use different clients if you like.
Unlike all the different services competing in this space, Matrix is objectively the best. One of the biggest reasons is that it is federated. Like Google Talk was when it was a proper XMPP server back in the day.
Don't fall for another big on hype low on substance service like Signal, which is just as centralized as Hangouts and could one day be ruined just as Google Talk/Hangouts was.
Use something that is fully open source, fully federated, and built to last. Use Matrix.
Cherrypicking applies in contexts where the momentum is against the data being cited. Nobody can deny the momentum is JS' side being the most popular programming language. Citing data that implies that it is not yet the case is an example of cherrypicking. Citing data that implies that it is, not so much.
Dunno man, this feels kinda like the climate change "debate" to me. Sure you can cherrypick data sets that show JS isn't quite there yet, but there seems to be a growing consensus that JS has already hit that tipping point. And if miraculously everyone is wrong about that, it won't be long before even the most stubborn surveys have to admit JS hit that tipping point. The momentum is rather obvious.
That seems unlikely. I'm not aware of any efforts to get something other than JS writing directly to the DOM via wasm. That would be a loooooot of DOM APIs that would have to be replicated in Java or whatever.
Besides, by the time something other than JS has full DOM access, ES7, ES8, ESwhatever will be out and JS will have slowly evolved into a usable language, eroding the appeal of switching to something less popular because the aesthetic differences won't be so vast anymore.
It's a lot of unnecessary process and meetings. Daily standups, biweekly planning meetings, retrospectives, endless backlog grooming sessions etc. I've been at companies that burn 10-20% of the team's time each "sprint" in unnecessary meetings to discuss work rather than actually doing work.
The meetings impose heavy burdens on anyone who doesn't want to be interrupted at that time. A typical 10am standup meeting is too early for night owls and too late for parents who drop their kids off to school at 7am, as there's a useless 3 hours between school and standup where you can't get anything done because there's a meeting soon. Scrum amps up context switching which prevents people from getting into the zone. Having lots of meetings and interruptions shreds your day to bits.
Then there are the Scrum-specific tools. Rather than using modern project management tools that get out of your way like GitHub or GitLab, you've got regressive, redundant nonsense like Rally or Pivotal Tracker being thrown around. All so you can play planning poker in the cloud. Shoot me now.
Defenders of Scrum tend to use no true Scotsman arguments. "Oh that wasn't Scrum." Or "that was Scrum being done badly." And so forth. Meanwhile the number of companies and teams doing it "correctly" seems to be few and far between. Perhaps because "correctly" is such a fuzzy thing to define. Means different things to different people. Seems to me where it "works," teams are successful in spite of Scrum, not because of it.
Basically it's popularly understood that Scrum basically exists to micromanage the shit out of dev teams. The managers who like it are the shoulder tap types whose management style is straight out of 1950. Marshall McLuhan is rolling in his grave.
Because of course one of the people involved in creating one of the worst management fads ever would also join the JavaScript hate train.
"The Pragmatic Programmer." Hardly. Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.
Ever notice how prolific JS users rarely defend the language? Of course it's badly designed. We use it because it's pragmatic to use the lingua franca of programming.
What isn't pragmatic is using languages with declining market share because they feel aesthetically "better," or imposing horrible management fads like Agile/Scrum on your team against their will.
Except this is the first generation who will be statistically speaking worse off than their parents. The millennials have a right to bitch about the boomers in a way that no previous generation in living memory has.
Boomers are the current generation who won't shut up about kids these days being lazy.
They seem oblivious to the fact that their parents said the same thing about them.
They also seem oblivious to the fact that their kids would be doing a lot better right now if they hadn't joined the cult of supply-side economics and shredded the safety net.
The argument that "my app is too complex for PE" is intuitive and popular, but the trouble here is people tend to project far more complexity on to their projects than is actually there. The vast majority of web applications are simple CRUD with some UI polish, but the authors of many such apps think they're building some crazy complex thing that's incompatible with PE. Rarely is that ever the case. I worked on some of the most complex web applications ever written in Silicon Valley and I can say from personal experience the majority of them didn't need a thick client JS framework. The ones that were using them would've been better codebases if they were vanilla JS + a collection of small single purpose modules. Almost all single page apps can and should be built with PE and very few wouldn't benefit from it. There are exceptions, but they're very, very rare.
I've been aghast at the broad adoption of thick client JS frameworks on the open web and a growing open hostility towards progressive enhancement, as if it's somehow not possible to build a single page app without totally breaking everything that makes the web a great platform.
There is a reasonable argument to be made that the vast majority of websites should not be using one of these, as the majority of these frameworks are incompatible with progressive enhancement and progressive enhancement is still the best way to build most sites. I firmly believe vanilla JS should be everyone's default. There are exceptions, but those exceptions are very narrowly tailored. I think this article which outlines those exceptions should be required reading for every web developer.
It seems like a lot of people these days don't realize you can build single page apps using progressive enhancement. And when you do, they perform better and are more fault tolerant while avoiding an unnecessary hard JS dependency. This whole stereotype you hear from people about single page apps being the future and progressive enhancement being the past is the most annoying false dichotomy ever. You can do both so long as you consider choices other than big, largely badly designed frameworks. It seems like most people who use Angular just want to make websites that don't reload the page when you click links. Maybe consider using a client-side router library instead of a giant monoframework. Way less code that has to be dumped on the user.
I'm not saying it isn't possible to use the big monoframeworks responsibly. The article above outlines good use cases for them. If you're building a client-only Electron app for instance, then go nuts with React or whatever if you like it. But seeing people design regular websites on the open web that are mostly just text, forms, and images using things like Angular and React is the biggest, most depressingly popular cargo cult antipattern we've seen since the days of Flash sites.
I didn't think good sci-fi was getting made anymore until I came across The Expanse. The novels are terrific (especially the 5th novel) and Syfy's TV adaptation is surprisingly good as well. Both are worth a look.
The premise is a near-future sci-fi setting with as little magic tech as possible. Almost all sci-fi tech in the story consists of reasonable derivations of current technology. Newtonian physics in space is respected. There's no inertial dampeners. There are no relativity-busting star drives. Gravity in space is through rotation or constant acceleration. And the story is solid.
It's up there with BSG and Firefly in terms of emphasis on depicting space realistically (by comparison to the looser realism of Star Trek/Farscape/Stargate/etc anyway). I still enjoy BSG's and Firefly's stories and characters a bit more, but The Expanse is far superior in terms of scientific accuracy.
Notably, for any Game of Thrones fans out there, George RR Martin is a fan of The Expanse and it is frequently referred to as the Game of Thrones of sci-fi.
Slashdot Mirror
Yes, the fundamental dynamics of Twitter should be rethought: It should be broken up into a dozen Mastodon instances.
Are you sure about that?
I love how cryptocurrency is like a history lesson for Libertarians with regressive economic attitudes. They get to learn the hard way why each discrete financial regulation we have today was enacted.
Even if I conceded every point you made about shortening terms, none of those benefits outweigh the benefits of legalizing noncommercial infringement, which is why I find mainstream copyright reformers so insufferable. The Lessigs of the world get really excited about shortening terms and have nothing to say about the far more important issue of legalizing noncommercial infringement.
That's why we should legalize noncommercial infringement first. We can debate terms afterward.
The way people celebrated public domain day was quite telling. People were like, "Yay now I can consume this content for free," not "Yay now I can create commercial derivatives."
That implies what we need is not shorter copyright terms, but to legalize noncommercial infringement.
People often say "why not both?" I'll tell you: we already have an originality crisis in popular culture. Are you tired of the constant reboot culture in Hollywood? I sure am. It would only get worse if more stuff entered the public domain.
Legalize noncommercial infringement. That's what we should be focused on. Not shorter terms.
This was not only the best book I've read all year, but the best book I've read this decade:
Winners Take All: The Elite Charade of Changing the World by Anand Giridharadas.
"An insider's groundbreaking investigation of how the global elite's efforts to 'change the world' preserve the status quo and obscure their role in causing the problems they later seek to solve."
It's time to abandon proprietary IM services and start using Matrix. The most popular client/server is Riot but you can run your own server and use different clients if you like.
Unlike all the different services competing in this space, Matrix is objectively the best. One of the biggest reasons is that it is federated. Like Google Talk was when it was a proper XMPP server back in the day.
Don't fall for another big on hype low on substance service like Signal, which is just as centralized as Hangouts and could one day be ruined just as Google Talk/Hangouts was.
Use something that is fully open source, fully federated, and built to last. Use Matrix.
Are there any implementations for Linux?
Got you covered!
I'll provide a non-condescending response to counter the AC. We agile critics are not all like him.
Cherrypicking applies in contexts where the momentum is against the data being cited. Nobody can deny the momentum is JS' side being the most popular programming language. Citing data that implies that it is not yet the case is an example of cherrypicking. Citing data that implies that it is, not so much.
Dunno man, this feels kinda like the climate change "debate" to me. Sure you can cherrypick data sets that show JS isn't quite there yet, but there seems to be a growing consensus that JS has already hit that tipping point. And if miraculously everyone is wrong about that, it won't be long before even the most stubborn surveys have to admit JS hit that tipping point. The momentum is rather obvious.
That seems unlikely. I'm not aware of any efforts to get something other than JS writing directly to the DOM via wasm. That would be a loooooot of DOM APIs that would have to be replicated in Java or whatever.
Besides, by the time something other than JS has full DOM access, ES7, ES8, ESwhatever will be out and JS will have slowly evolved into a usable language, eroding the appeal of switching to something less popular because the aesthetic differences won't be so vast anymore.
The official WebAssembly FAQ throws shade at that attitude.
It goes on to say that WebAssembly is meant to encourage hybrid stacks.
It's much more likely the end result will be an ecosystem similar to Node.js, where some stuff is in JS, and other stuff is in native node modules.
Me: "Nobody denies JavaScript is aesthetically distasteful. But you don't pick the best tool for the job based on aesthetics."
You: "But JavaScript is aesthetically distasteful!"
k.
Did you miss the numerous articles like this published over the past few years? https://arc.applause.com/2016/...
Seems pretty clear JS hit the popularity tipping point already. It's the world's most popular programming language. (For better or worse.)
It's a lot of unnecessary process and meetings. Daily standups, biweekly planning meetings, retrospectives, endless backlog grooming sessions etc. I've been at companies that burn 10-20% of the team's time each "sprint" in unnecessary meetings to discuss work rather than actually doing work.
The meetings impose heavy burdens on anyone who doesn't want to be interrupted at that time. A typical 10am standup meeting is too early for night owls and too late for parents who drop their kids off to school at 7am, as there's a useless 3 hours between school and standup where you can't get anything done because there's a meeting soon. Scrum amps up context switching which prevents people from getting into the zone. Having lots of meetings and interruptions shreds your day to bits.
Then there are the Scrum-specific tools. Rather than using modern project management tools that get out of your way like GitHub or GitLab, you've got regressive, redundant nonsense like Rally or Pivotal Tracker being thrown around. All so you can play planning poker in the cloud. Shoot me now.
Defenders of Scrum tend to use no true Scotsman arguments. "Oh that wasn't Scrum." Or "that was Scrum being done badly." And so forth. Meanwhile the number of companies and teams doing it "correctly" seems to be few and far between. Perhaps because "correctly" is such a fuzzy thing to define. Means different things to different people. Seems to me where it "works," teams are successful in spite of Scrum, not because of it.
Basically it's popularly understood that Scrum basically exists to micromanage the shit out of dev teams. The managers who like it are the shoulder tap types whose management style is straight out of 1950. Marshall McLuhan is rolling in his grave.
It's the world's most popular programming language, so yeah, it's a lingua franca.
No doubt. But I'm not gonna wait around for that. Gonna use the lingua franca in the mean time.
Because of course one of the people involved in creating one of the worst management fads ever would also join the JavaScript hate train.
"The Pragmatic Programmer." Hardly. Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.
Ever notice how prolific JS users rarely defend the language? Of course it's badly designed. We use it because it's pragmatic to use the lingua franca of programming.
What isn't pragmatic is using languages with declining market share because they feel aesthetically "better," or imposing horrible management fads like Agile/Scrum on your team against their will.
So I'll pass on joining this guy's fan club.
Except this is the first generation who will be statistically speaking worse off than their parents. The millennials have a right to bitch about the boomers in a way that no previous generation in living memory has.
There are bugs in a beta? What a shock!
Boomers are the current generation who won't shut up about kids these days being lazy.
They seem oblivious to the fact that their parents said the same thing about them.
They also seem oblivious to the fact that their kids would be doing a lot better right now if they hadn't joined the cult of supply-side economics and shredded the safety net.
The argument that "my app is too complex for PE" is intuitive and popular, but the trouble here is people tend to project far more complexity on to their projects than is actually there. The vast majority of web applications are simple CRUD with some UI polish, but the authors of many such apps think they're building some crazy complex thing that's incompatible with PE. Rarely is that ever the case. I worked on some of the most complex web applications ever written in Silicon Valley and I can say from personal experience the majority of them didn't need a thick client JS framework. The ones that were using them would've been better codebases if they were vanilla JS + a collection of small single purpose modules. Almost all single page apps can and should be built with PE and very few wouldn't benefit from it. There are exceptions, but they're very, very rare.
I've been aghast at the broad adoption of thick client JS frameworks on the open web and a growing open hostility towards progressive enhancement, as if it's somehow not possible to build a single page app without totally breaking everything that makes the web a great platform.
There is a reasonable argument to be made that the vast majority of websites should not be using one of these, as the majority of these frameworks are incompatible with progressive enhancement and progressive enhancement is still the best way to build most sites. I firmly believe vanilla JS should be everyone's default. There are exceptions, but those exceptions are very narrowly tailored. I think this article which outlines those exceptions should be required reading for every web developer.
It seems like a lot of people these days don't realize you can build single page apps using progressive enhancement. And when you do, they perform better and are more fault tolerant while avoiding an unnecessary hard JS dependency. This whole stereotype you hear from people about single page apps being the future and progressive enhancement being the past is the most annoying false dichotomy ever. You can do both so long as you consider choices other than big, largely badly designed frameworks. It seems like most people who use Angular just want to make websites that don't reload the page when you click links. Maybe consider using a client-side router library instead of a giant monoframework. Way less code that has to be dumped on the user.
I'm not saying it isn't possible to use the big monoframeworks responsibly. The article above outlines good use cases for them. If you're building a client-only Electron app for instance, then go nuts with React or whatever if you like it. But seeing people design regular websites on the open web that are mostly just text, forms, and images using things like Angular and React is the biggest, most depressingly popular cargo cult antipattern we've seen since the days of Flash sites.
I didn't think good sci-fi was getting made anymore until I came across The Expanse. The novels are terrific (especially the 5th novel) and Syfy's TV adaptation is surprisingly good as well. Both are worth a look.
The premise is a near-future sci-fi setting with as little magic tech as possible. Almost all sci-fi tech in the story consists of reasonable derivations of current technology. Newtonian physics in space is respected. There's no inertial dampeners. There are no relativity-busting star drives. Gravity in space is through rotation or constant acceleration. And the story is solid.
It's up there with BSG and Firefly in terms of emphasis on depicting space realistically (by comparison to the looser realism of Star Trek/Farscape/Stargate/etc anyway). I still enjoy BSG's and Firefly's stories and characters a bit more, but The Expanse is far superior in terms of scientific accuracy.
Notably, for any Game of Thrones fans out there, George RR Martin is a fan of The Expanse and it is frequently referred to as the Game of Thrones of sci-fi.