skysight-inc/HackerNews huggingface dataset:
FWIW, https://en.wikipedia.org/wiki/List_of_directly_imaged_exopla... is a list of directly imaged exoplanets. These all appear as point sources. I assume you want to be able to see something the size of a continent on a planet?

There are different limits depending on your choice of technology. One is the angular resolution. https://en.wikipedia.org/wiki/Angular_resolution . The wider the telescope diameter, the better the resolution.

Here's the best that Hubble could see of Pluto - http://www.nasa.gov/mission_pages/hubble/science/pluto-20100... . A planet the size of Earth could be resolved to the same detail if it were 5.5x the distance as Pluto, or about 200-250 AU, which is about 30-35 light hours away.

The nearest star system is light years away, so Hubble won't work.

It's possible to make a larger telescope. The key realization is that "D" in the equation doesn't mean the entire telescope must be that far apart, only that the two most distant points are D. This is called https://en.wikipedia.org/wiki/Interferometry . The Cambridge Optical Aperture Synthesis Telescope, for example, "was the first long-baseline interferometer to obtain high-resolution images of the surfaces of stars other than our sun." https://en.wikipedia.org/wiki/Cambridge_Optical_Aperture_Syn...

Yellow light has a λ=580 nm wavelength. If your target resolution is 1000km (the Earth is 6,371 km across, so a 6x6 image) at Proxima Centauri some 4.24 light years away, then:

θ = 1000/4E13 = 1/4E10
D = 1.22 λ/θ = 1.22*580*40 m = 28 km across

COAST, above, is 100 meters across.

This is the limit due to diffraction. The atmosphere makes it worse, so you probably want this in space. I believe it's also a difficult engineering problem, as the wavelengths needs to be in phase - it's not simply a matter of having telescopes on both sides of the planet and combining the results.

There are other methods, like gravitational lensing. I don't know enough to say anything about it.
This title is very misleading to the point that it's the exact opposite of what the post says:

"We won’t post or share your WhatsApp number with others, including on Facebook, and we still won't sell, share, or give your phone number to advertisers."
I'm not sure you understand the modern advertising landscape... Reminding customers of your brand and products through retargeting is very big business
The post says the exact opposite of the title:

> Even as we coordinate more with Facebook in the months ahead, your encrypted messages stay private and no one else can read them. Not WhatsApp, not Facebook, nor anyone else. We won’t post or share your WhatsApp number with others, including on Facebook, and we still won't sell, share, or give your phone number to advertisers.

Edit: That paragraph relates to your WhatsApp number. It is true that they do plan to share your phone number that you signed up with. You can opt-out though: https://www.whatsapp.com/faq/general/26000016
Second tthis. The term Lisp in CS is like Romance in linguistics, it indicates a family of languages that belong to different similar but not identical cultures which contribute to them and yet still the languages come from a common ancestor and are more similar than not while at times not easily mutually comprehensible.
Whats the security update plan for Electron?
If that's what you want, you can just use Dropbox itself to store code and use one of the several deployment tools which can pull code from it (e.g. cloudcannon).

It quickly falls apart though as you don't have a proper history, reverts, or branching - it's OK for static sites but a disaster for anything more than that.
This looks quite similar to what Adapteva did with their Parallella platform- they were targeting the low end of hobbyists though rather than big data centers. Maybe that was their mistake.. https://www.parallella.org/
As far as I read correctly, you can opt out of this: https://www.whatsapp.com/faq/general/26000016
The irony in their homepage is so good:

----------------
> Why we don't sell ads
Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we dont need. - Tyler Durden, Fight Club
Yes. But they don't let you create a type whose inhabitants are rectangles.

I have no idea you mean by that. The link you provided did not help.

Immutability isn't enough.

I'm sceptical about that. I am going to need an example of a LSP violations made with immutable types.

For instance, Standard ML has immutable values (as well as mutable objects), but it doesn't solve the rectangle-square problem because the core language doesn't have subtypes to begin with. Solving the problem requires refinement types, so that squares can be defined as a refinement over rectangles.

I'm not sure what you are saying here. Does ML prevent the problem, or doesn't it? You seem to be saying that it doesn't. But according to Wikipedia, ML is type safe (for some definition of that term), and in your initial comment, you stated that type safe languages ensure adherence to LSP.

The notion of a “value object” is still problematic. A “value object” still has a physical identity in computer memory.

Because I can get the address of it in Go? So what? That's hardly something you do by accident. And if your point is about what the language makes possible, rather than what it makes likely, I assure you that you can get in wrong in any language. The only difference is how much effort it requires.

I never said that types automatically make your models correct

You pretty much did with your initial comment that type safe languages prevent violations of LSP.

you need appropriate type structure to model your problem domain correctly

No, simply not true. You can model your domain correctly in any Turing-complete language. Types may make it easier, especially as your programs grow more complex, but types can't help you choose the correct way to model your domain.

LSP is not about type errors: The symptoms of violating it are not that operations are performed on values that are not appropriate for values of that type. In the Rectangle/Square example, calling setWidth() or setHeight() on a Square are perfectly alright as far as the Type system is concerned. The problem is simply that the resulting behaviour of the program probably not what the programmer intended. If the programmer had thought to specify -- using types -- that a Rectangle’s width and height should always be independently adjustable, then it's probably a fair assumptions that the same programmer would not have accidentally made a subtype of Rectangle that violated this invariant to begin with.
Yes, I think it was designed in particular for determining addresses of fields within structures and variables on the stack, for example if you had:

struct foo
{
int field1;
int field2[10];
}

Then an access like:

fooptr->field2[index]

Would compile to:

fooptr + sizeof(int) * index + offsetof(struct foo, field2)

Which is:

lea $4(fooptr,index,4)
Basically, the point of lisp OSes, is that they allow you to seamlessly write code at all layers, from down into the darkest bowels of the system, thru and up to the highest level application scripting, all in a single integrated language and libraries and frameworks.

You don't have to reboot a machine just because you make a patch to the kernel, and at the same time, you can patch the system using the same high level development tools as you would use to develop an application.

The thing is that there's what we call an impedence mismatch between a unix kernel and applications running on it, in that the data types processed by applications which are of higher level, don't match the data types processed by the unix kernels. For example, a Ruby Integer is actually a bignum, and you cannot pass a bignum to the unix kernel: you have to provide a bit field with 32-bit or 64-bit. This is work, and this is pain. It is already pain when you write your applications in C or C++ where assumedly you already have bit field types, because your application could be compiled to run on kernels and processors using different word width! Imagine the pain it is when you write your applications in Common Lisp with very high level data types (ratios, closures, pathnames!), and when you have to map those data objects onto the lame bits accepted by unix syscalls. Consider all the literature written about logging, the byte vector logging provided by unix syslog vs. high level object logging provided by higher level libraries or other systems.

And of course, this is not limited to the interface between applications and systems, but goes beyond to the interface between applications. When the system provides a pipe abstraction where all you can pass between applications are streams of byte, this leads to a lot of suffering. You have to serialize and deserialize your data, you have to consider formats (a java float doesn't have the same syntax as a Common Lisp float!), encoding (utf-8? iso-8859-1, -15?). Have you ever been advised to never parse the output of /bin/ls? For good reasons!

Instead, if your system is written in Lisp, then you can directly pass lisp objects from one lisp application to another lisp application, and there's no need to serialize/deserialize, to parse or otherwise mangle the data: you just have lisp objects and you can use them directly. You can pass closures (which enclose the lisp object data along with the lisp functions needed to process them).
Olympic GIF ban flip-flop shows once again that Twitter can’t manage its users
UBER for skills
In that case it would lessen the chance of a competitor gaining access to your eyeballs, not a bad bargain in some cases.
I don't see it being discussed much when Electron comes up, so I'll share some of the use cases that led our company to move at least one of our web apps to Electron.

We provide a B2B service that relies on communication with a locally installed service running on the users machine. This kind of approach is one that has been heavily bombarded with new features and deprecations leaning towards a more secure web by most browser vendors, which is actually very justifiable.

The most recent one was Chrome targeting to restrict app cache usage, which we rely on currently, only to documents served through HTTPS. Given that we have an app that uses a local service that needs to work offline, we cannot use HTTPS for that without messing with stuff that needs Administrator privileges, which we really want to avoid because headaches.

So we figured we need a more flexible approach that is not so restricted as a web app living on the browser, but we already have a product. Here comes Electron, and in a couple weeks work, mostly testing things, we have it. We now deploy both to the web (just in case) and are rolling customers to the desktop.

Other features that added a lot of value where:

- No localStorage limit, was starting to become an issue, now we have breathing room to migrate to other storage

- Auto Update, actually took care a long time complaint for the necessity to keep downloading new versions of the local running server, which we now package alongside the app

- node process running directly on the client opens up a lot of new possibilities
As long as its not the last one, you can go back with `K` to the previous hunk. And forward with `J`. (The lowercase versions only go to hunks you decided to skip, but uppercase go to all, even ones you already chose an option for)
I watched the NIAC talks yesterday and a quote (paraphrased) that I found interesting was:

> Computation is innovated thanks to gamers.

The same effect might benefit programming languages.
Is there any way to keep WhatsApp and Facebook separate? It seems that either a) I use WhatsApp and have Facebook collect my data, or b) don't use WhatsApp.

There seems to be a complete lack of choice with what they do with my data.
Qt is currently a mix of old C++ and new js, you could argue whether it is modern or not.

I put it as second option since UWP is the native framework for windows 10 and should be considered first.
There were 5 HN postings about it in the last few days https://hn.algolia.com/?query=Media.net&sort=byDate&prefix&p... . The only one with comments (20) is https://news.ycombinator.com/item?id=12342889 . It was flagged, fwiw. There wasn't the sort of discussion you are looking for.
A little searching found this article by Robert Woods [1]:

> The London Bills of Mortality offer a tantalising challenge to historical demographers. Since they give the number of burials and baptisms, the causes of death, and the ages of those buried for various periods and combinations of parishes in the seventeenth and eighteenth centuries it has been tempting to use the data they provide as a basis for the estimation of mortality rates. This contribution focuses on the period 1728 to 1830 for which the age structure of burials is available. It employs the compendium of Bills material compiled by John Marshall and published in 1832 as Mortality of the Metropolis.

Even though we're only looking back a few hundred years (but perhaps also that we're looking at London of all places) the child and infant mortality rates are pretty grim:

* London, 1728-1737: child mortality rate (death before 10yo): 59.0% [1]
* London, 1841: child mortality rate (death before 10yo): 12.2% [1]

There's a pretty big drop in life expectancy at birth compared to more recent history:

* London, 1730-1739: life expectancy at birth: 26.0 years [1]
* London, 1820-1829: life expectancy at birth: 38.9 years [1]
* UK, 2012-2014: male life expectancy at birth: 79.1 years [2]
* UK, 2012-2014: female life expectancy at birth: 82.8 years [2]

* London, 1730-1739: infant mortality rate (death during first year): 26.3% [1]
* London, 1820-1829: infant mortality rate (death during first year): 17.7% [1]
* UK, 2015: infant mortality rate (death during first year): 4.38% [3]

There was also a ~1% chance of dying in childbirth, per birth:

* London, 1700-1724: maternal mortality 134 / 10,000 [1]
* London, 1800-1824: maternal mortality 63 / 10,000 [1]
* UK, 2015: maternal mortality in first 6 weeks after giving birth 9 / 10,000 [4]
* UK, 2015: maternal mortality in first year after giving birth 25 / 10,000 [4]

That's a pretty big improvement in infant and child survival over the last few hundred years.

My condolences to you, dear reader, if you have lost someone recently.

[1] http://www.localpopulationstudies.org.uk/pdf/lps77/article_1...

[2] http://www.ons.gov.uk/peoplepopulationandcommunity/birthsdea...

[3] https://en.wikipedia.org/wiki/List_of_countries_by_infant_mo...

[4] https://www.npeu.ox.ac.uk/mbrrace-uk/reports
I uninstalled WhatsApp the moment it was bought by facebook. It's so obvious that facebook corrupts this fantastic company/chat application.
Maybe much easier...

http://blogs.discovermagazine.com/fire-in-the-mind/2013/02/2...

...or maybe not.
If you want to experience the difference, maybe look into any local HEMA groups.

Full weight steel swords aren't all that heavy, especially if well balanced, but they have inertia and aren't whippy and flexible.
That's just clever wording.

> We won’t post or share your WhatsApp number with others, including _ON_ Facebook.

Is just saying that your number won't be visible to your facebook peeps. Which does not mean that Facebook (the company) won't get access to it.
Very nice introduction with relevant links. However, I feel the 'Think of it like this' section is strictly for MacOS (and Linux?) users as it doesn't behave that way in Windows and can confuse the reader.
Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain.

At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos.

On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt.

Most mortal programmers need the ability to iterate over their code to get it to a reasonable place before they want it enshrined in the blessed commit history that is shared with others or otherwise retained over time. The intermediary states, with false starts, poor implementations, hand crafted functions instead of standard functions, poorly named classes, and so on are all part of development but aren't particularly interesting to keep in the permanent history of a project.

Git's ability to manipulate the existing commit tree (amend, reset, rebase, etc.) is extremely useful for this normal 'exploratory' development. Once a stable point has been reached though (often because the tree has been published or shared with others), these commands do become inappropriate and a different set of tools becomes relevant (revert, merge, etc.).
I think the cyborg route is great so long as we can develop some standards that work over the years.
Nanoparticles that speed blood clotting
I've tested opening a few ~15MB log files (no syntax highlighting) with VS Code and Atom... I'm amazed that one editor will load within 2-3s and the other will take 15s (or more!) when they are both built on Electron.
So what happens when two developers edit the same file, or make changes to different files that in combination break the system?

You need commits, you need the ability to merge. If you don't want to force all commits to happen online and everyone to resolve conflicts immediately then you need branches. You want tags if you're going to have releases (otherwise how do you refer to them?). At that point you basically have git.

All the complicated features were added because someone thought they needed them (there are certainly a few git features where I think that someone was wrong, but not many).
It's pretty hard to return "rules" for a ML system, especially a non-linear system. Google is currently working systems that use a trillion features - I can't imagine returning some kind of rule list for that.

LIME[1] is a nice start, though.

[1] https://www.oreilly.com/learning/introduction-to-local-inter...
and maybe the life on that planet just discovered us in the process
There is no such option in the iPhone app (2.16.9 / 15 Aug 2016).
I don't think there are any other game to win for a company like Apple.
(2010) not that it matters much... TECO was long dead much earlier.
1. calculating differences

2. merging two or more different branches

3. transporting code (publishing it)

3a. accepting somebody else's patches

4. descriptions of history points

4a. pointers to parent code trees (especially with tree merges)

5. history traversals (bisecting, among the others)

Not to mention that you need either administrative privileges for creating
a snapshot or a special kind of filesystem that supports this for
non-administrator. And sysadmin still needs to prepare such a filesystem for
your $HOME.
> You can opt-out though: https://www.whatsapp.com/faq/general/26000016

This is a dark pattern. In fact, once you say "Agree" you only have 30 days to opt-out.

> After you agree to our updated Terms of Service and Privacy Policy, you will have an additional 30 days to make this choice by going to Settings > Account > Share my account info in the app.

I can't see such an option.
> we want to explore ways for you to communicate with businesses that matter to you too

Empty marketing speak, that sentence has zero information content. It just leaves me vaguely worried that they don't seem to be up-front with whatever they are about to do.

I'm just glad that FB doesn't have my number and doesn't have access to my contact list.
The last time we had this discussion the consensus bottom line was that you try to avoid rewriting history once you have pushed it to a place where others have access to it.

Once you've published it, let it go. Do not mess with history. I think we can all agree on that.

The disagreement is whether I should squish my commits before I push it and I put that in the same pile of questions as am I obligated to my significant other and society at large to shave my legs before going out in public.
Once you say "Agree" you only have 30 days to opt-out.

> After you agree to our updated Terms of Service and Privacy Policy, you will have an additional 30 days to make this choice by going to Settings > Account > Share my account info in the app.

I can't see the option either.
Funny how times change...

Some quotes from a What's App blog post from 4 years ago titled "Why we don't sell ads"[0]

"Remember, when advertising is involved you the user are the product."

"Your data isn't even in the picture. We are simply not interested in any of it."

"When people ask us why we charge for WhatsApp, we say "Have you considered the alternative?"

So they aren't showing ads themselves, but they are shipping your data out to another entity that is. Seems worse to me.

[0] - https://blog.whatsapp.com/245/Why-we-dont-sell-ads?
Is there maybe a way to annotate the commit message of HEAD without influencing the reflog?
A JavaScipt powered puzzle: get your slice of brain workout
A nice logical game.
Uber Loses at Least $1.2B in First Half of 2016
Leasing a Car vs Buying a New Car in 2016
Illustration of Business Solutions with IoT
The trends are simple and crisp indicating us how IoT can hyperloop the businesses; making our ecosystem more connected, secure, simple with a tinch of ease.
You can achieve something similar via a library: https://github.com/mcintyre321/OneOf

I also think language level support for this would be a killer feature, it turns OOP and the requirement to use polymorphism to guarantee strategy-per-type on it's head.
https://www.microfocus.com/products/cobol-development

http://www.cobol-it.com/index.php?page=rwd_products
> The ability of devs to collapse a bunch of commits into a useful summary is near zero right now

You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc.

Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that future dev can, considering the fact that you don't know what they might want?

The nice thing about git is that anyone can make a new branch from any point in the repo's history, merge, cherry pick, rebase, etc. to their heart's content, then garbage collect it once they've learned what they needed.
Like many NSA or GCHQ developers will have a public account on github
The clinical trials are what's expensive, since you have to pay thousands of people, who have the disease you're targeting, to take your experimental drug.

You raise a great point. I was talking to a CRO (contract research organization - often hired to run clinical trials) and the rule of thumb is that a phase 3 trial will cost ~$10K to $15K per patient per year. It all depends on how involved the endpoint measurements are. A simple blood test pushes it to the lower part of that range and something more involved like an MRI might push it to the top (or higher).

That doesn't seem bad until you start to look at the size and duration of trials. If you're coming up with a new heart disease drug, the FDA often requires a multi-year trial and 5K to 10K patients in each trial (two phase 3 trial are required by the FDA, generally).

So if you're running two 10,000 patient trials that last 2 years, your phase 3 bill is already $300M. And that doesn't include all the other costs that come with bringing a new drug to market.

Now that is the higher end. Oncology clinical trials or trials for orphan diseases can push that number down to 1/10th or ~$30M.
https://www.whatsapp.com/faq/general/28030012

Third part :

> This means, for example, although some information will be shared with Facebook (such as your phone number), that information will not be seen by other people on Facebook.

Yup that's just clever wording.
This line certainly makes it sound like they are sharing your phone number with Facebook to me:

"And by connecting your phone number with Facebook's systems, Facebook can offer better friend suggestions and show you more relevant ads if you have an account with them."