I'm suspicious of any article that's widely slated by a community yet still trending.
I feel there's a market need for a browser plugin that lets you filter out clickbait factories like his employers and all the dirty tricks they use to hijack our attention. There's no way we can keep up with them without computer assistance.
To solve the readability issue, why not use Babel to transpile JS expressions into the equivalent syntax?
To generate the first example in the readme:
import {solve} from 'logic'
function father(x,y) {
return x =='mcbob' && y == 'bob' ||
x =='bob' && y == 'bill';
}
solve(father) // a noop function used as a marker by babel
I feel like that just obfuscates it. You can no longer dynamically use it, and it's completely unobvious what javascript expressions are supported or not.
Babel has to turn it into valid JS for it to work so you'd still have the 'and' and 'or' functions. In the bottom right corner of Hzoo's example you can see what I mean (http://astexplorer.net/#/ZT6HYai08w)
It should be more obvious what expressions are supported when it's validated by a Javascript parser. This is in contrast to the 'dynamic' approach which has no problem with the following until runtime:
Something that is true of a group he is a part of isn't necessarily true of him. However, if he did want to change parties over this he'd have to drop out of mainstream politics entirely.
Google is building out a network in Kansas City because (i) they've got more money than they know what to do with and (ii) they want to intimidate the ISP industry and influence the government.
Any entrepreneur who wants to offer internet service will find they have the same economic interests as the phone company and the economic logic will lead them to behave the same way.
It may be true that you can offer somebody a service at $50 that offers 10^5 more bandwidth than a $50 phone line, but without paying for some physical plant that costs at least as much as a phone line, you can't offer phone service for 0.005 cent a month.
This differs very much between cities and suburbia.
In a city, you can run a fiber line to a 6-story building and service 30 households by just running some Cat5 cable from a fiber terminator box. And the house probably have enough underground pipes to get into, e.g. electric cable or water pipes. The next house to run your fiber to is probably physically next.
A city-based ISP can run profitably at very moderate prices. Such an ISP can serve hundreds of thousands subscribers over a few dozen square miles. I've user services of several such small ISPs in Russia and Ukraine, with rates about $20 for a 20-30 Mbit line, and even cheaper slower plans.
In a suburban setting you have to run much more cable, install more transcievers, and every house you run your cable to is one household. Then you have to connect to a backbone cable, which may be many miles away (in a city it's usually much closer). This must be much more expensive.
Looks like a good article but the url violates the same origin policy and as a result it render images. Readers will get a better looking page if they knock the 's' out of https until the owner can fix it
Sorry about the url. The falkvinge.net address in my feed is a product of the HTTPSEverywhere plugin. @Falkvinge tweeted me to find out how I got the url. He is still testing:
'I thought I'd have time to check and roll it out slowly - now, a lot of stuff is still hard-http-linked even on https.'
Let's draw a distinction between registered users and active users. Browser games have notoriously high inactivity rates. Many - perhaps most - create accounts, play once and never return. This doesn't include the number of users who have multiple accounts, macro miners etc.
There's a problem with box 2. If the IOException is thrown in the stream's constructor (FileNotFoundException) then there will be a NullPointerException if we try to call close!
InputStream in = null;
try
{
in = new FileInputStream(new File("test.txt"));
//do stuff with in
}
catch(IOException ie)
{
//SOPs
}
finally
{
try
{
if(in != null)
{
in.close();
}
}
catch(IOException ioe)
{
//can't do anything about it
}
}
Thanks, I didn't realize it's this bad. My only touch base with Java has been through Clojure.
This is just horrible. What braindead system forces you to check exceptions on closing a file handle? If everything failed silently and just produced 'null', the code would look like:
InputStream in = new FileInputStream(new File("test.txt"));
if (in) {
...dostuff...
in.close();
}
Now, that you can grasp with one glance. I'll trade the ability to write something like that with having to use malloc()/free() any day.
Silent failure doesn't carry information about how the thing failed: did the file not exist, was it not accessible because of security, was there a failure on the underlying device or file system?
How is the user supposed to figure out what went wrong with the program if the program can't even convey to the user what went wrong?
Complex problems have lots of simple wrong answers.
(Your "solution" also suggests nothing about how "in.close()" is going to get called if "...dostuff..." itself throws an exception.)
I feel there's a market need for a browser plugin that lets you filter out clickbait factories like his employers and all the dirty tricks they use to hijack our attention. There's no way we can keep up with them without computer assistance.