skysight-inc/HackerNews huggingface dataset:
"The mistake to grow from" had absolutely nothing to do with AI.

In fact, it was a repeat of the oldest AI error in the book:
zealous overoptimism. By researchers, sci-fi authors, HN posters. Whether it's marketing people over-promising, or tech people under-delivering (like Google auto-categorizing photos of black people as gorillas), it's almost as if the constant failures are Nature herself trying to tell us something.

We'll get there, but not via Tay. She's dead and she took a few careers with her.
I think it was a lot by accident. Also different languages have different needs, for instance you will really compile Java, probably not process Python source code, but you might do a ton on minimization for a Javascript product.

Many of these frameworks (especially Maven) have a "convention over configuration" attitude and that is probably easier to do the smaller the scope is.

Another factor is that many build/dep systems share metadata and package formats. For all the strong feelings JVM developers may have about gradle, sbt, maven, leinegin and the languages and other baggage that comes with them, they are compatible at the repository level and that makes life sweet.
Ask HN: Career after stepping-down from a funded company due to ethical issues?
Am curious what happens to executives when they're asked to step down from funded startups or large tech companies due to ethical issues?

Is it easy for them to get another job, or get funding for their own startup, or hire people? Is it held against them or do people feel that it might have been a one-time mistake?

Particularly interested in how they're treated by the VC community.
Hah, like there is any doubt that she'll become a Jedi. It's basically Episode IV all over again. Han Solo instead of Obi Wan, Rey instead of Luke, First Order instead of the Empire, Kylo Ren instead of Darth Vader.

We like hearing a story we already know. Rey is well on her way to become a Jedi, probably in two-movies' time.
Actually, cynicism can be fairly painful.

It grows from a lot of moments.

One moment your leader is asking all the employees if they're ready to change the world. Everyone thinks the company is a rocketship. They slave away into the moonlight and beyond. The next moment, the leaders gets everyone together and announces news that don't quite match what was promised before. Sad faces. Stiff upper lips. No worries, we can work past this.

The moment after that: more bad news starts trickling in. Then a flood. Then empty desks. Maybe, you get out first. Maybe, you're the first to discover your key card won't let you in the building anymore.

Throughout these moments, the faces of your comrades-in-arms will stay with you; the way the light in their eyes fades and fades and fades. You were "family", you were together, you were united in purpose...

And now what are you?

Fast forward years later. Your friends from the old startup no longer talk to each other. They all work at big companies. You're interviewing at a fresh up-and-comer. Someone 10 years your junior sits you down and asks if you're ready to change the world.

What do you say?

... Writing aside, I think the best company cultures tend to be filled with people who have been fooled before (the essence of cynicism) yet still manage care about what they're doing and building. These folks also tend to have meaning and identity outside of their work.
Be your own boss and embrace your rhythms.
Employers that care about this will simply ban origination of E2E secure messages from their networks. Plenty of large companies already ban web mail providers entirely, for similar reasons. So this isn't much of a factor in adoption of encrypted mail.
By SIMD concurrency, I meant that I was curious about a construct that actually translated into simultaneously executing code, not just a construct that denotes work that "could" be done simultaneously.
Ironically enough, given the recent improvements, performance and productivity...that's not really out of the question...
[Edited for clarity per downstream thread]

Both refer to native maps not being safe for concurrent use (e.g. Safe for use with Go's coroutines -- Goroutine-safe)[1]

[1] https://golang.org/doc/faq#atomic_maps
Don't forget to address the whole native advertisement issue, its exploded in recent years and has been destroying online communities.
Humans also have a harder time changing their minds when they reach a certain age. It's much easier to brainwash a child, who's impressionable and flexible.

AI would need to be designed to have the same "safeguard" (not sure what else to call it). If you didn't, an AI with a certain amount of physical power would be an easily-brainwashed child, but able to kill or destroy much better than a child could.

Saying all of that, I want to say I remember a movie or show that addressed that issue, but I can't remember what it was...
Oculus co-founder hand-delivers first Rift VR headset to a dude in Alaska
You solve it by having her NOT GO THERE. Just like you avoid certain topics at the office. IBM did it with Watson to make him safe for Jeopardy, which was a taped program.

If only there were an easily parsed list of topics to avoid...
https://en.wikipedia.org/wiki/Wikipedia:List_of_controversia...
Dropbox Develops Magic Pocket, Moves Away from AWS
Where LinkedIn went wrong – and how it can save itself
Really awesome. I wonder which JS library is used for the
plotting itself ? Is it made by you guys ? Is it open
source ?
Thanks and keep on with the good work !
The Alphabet of Stones
I agree with you, the article seems to be about depression. It starts like it is going to be about lazy troubled, but it suddenly turns into this matter.

To me it makes a lot of sense, because I didn't want to wake up when there was not hope for happiness. What the author says is that adding the duty of waking up early does not help when your life is already bad, it is only one more source of remorse.
Tree Search, Recursion, and How Computers Play Games
http://pastebin.com/ajKG8PQG
No, actually. Thanks for letting me know about that.

Regardless, my point stands: If I'm writing an app and I use a WebView or a Chrome Custom Tab, I'm going to want to know, for certain, that someone isn't switching out the underlying rendering engine.
I do understand how books are made -- that's why I know what a book knife is for. That's the essence of the gatsby joke!

But you are right -- I completely overlooked the ceremonial and curatorial uses of page turners! I was thinking of them as a mass-market device.
Comprehensions are great, but they can hurt readability and maintainability when taken too far. Most of the time you shouldn't be playing code golf with your code, iteratively seeking to pack more and more work into a single line of code. That makes the code harder to understand and harder to re-use.

While many of the examples in this helpful article are good, the first example with the octets is an excellent example of how not to do it. Look at the octet parsing code we ended up with in the article:

# Snippet 1
octets = [bbs[i:i+8] for i in range(0, len(bbs), 8)]

It's nice and tight. What does it do? I'd need to peer at it a moment and decode it, executing it in my head. This is subjective, but I think code should be self-explanatory; it's up to the computer to execute code, not people in their heads. Is there an off-by-one error in there? Here's another way to do it that'd be better.

octets = chunks(bbs, 8)

That function chunks() is something that I keep in an iterutils package which I end up using all the time. It's intuitive, and it has a doctest that shows that we definitely don't have an off-by-one error. It's also easier to re-use than the first one. Maybe it also bears mentioning that chunks() works on an iterator, while the first solution needs to keep the whole thing in memory at once. Here's the chunks method I use:

def chunks(collection, chunk_size):
"""Divides list l into chunks of up to n elements each.
>>> l = range(75)
>>> chunks(l,10)
[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9],
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19],
[20, 21, 22, 23, 24, 25, 26, 27, 28, 29],
[30, 31, 32, 33, 34, 35, 36, 37, 38, 39],
[40, 41, 42, 43, 44, 45, 46, 47, 48, 49],
[50, 51, 52, 53, 54, 55, 56, 57, 58, 59],
[60, 61, 62, 63, 64, 65, 66, 67, 68, 69],
[70, 71, 72, 73, 74]]
"""
for i in xrange(0, len(collection), chunk_size):
yield collection[i : i + chunk_size]

When you catch yourself playing code golf and trying to pack more and more meaning into a single line, look for ways that you can break the problem down into multiple components that use each other. This kind of functional decomposition is one of the things that makes functional programming so wonderful. Lots of times the intermediate steps in a complex expression have meaning and are useful on their own.
The Next Reign of Cloud Kings Won't Rule with an “Iron” Fist
I took it to mean that with Node, some functions have a traditional return value, like functions in most common languages. But if there's even the possibility that they may indirectly invoke an async function, they need to have a different signature using callbacks or promises. For example, here's a simple function:

function isValidFoo(val) {
...return boolean
}

This function is synchronous now, but its contract needs to change if it internally calls something async (say, it's updated to check a value from a cache, which may trigger a DB lookup). The new signature has to add a callback parameter and drop the return value, or return a promise. Then its callers have to change how they invoke the function, and if they were previously synchronous their signatures have to change as well. Every synchronous function up the call stack needs to care about this internal change.

To avoid a ripple effect, all functions have to be designed to be asynchronous from the beginning, but this increases program complexity significantly. It means avoiding built-in language features such as direct return values, and often means substituting async library functions for built-in looping constructs.

Other languages including Go aren't like that. You don't need to wrap a simple return value in a promise or callback just because retrieving it might someday involve I/O. Execution of the thread/goroutine simply resumes whenever the value is ready, and the function returns normally. In those languages, Node's distinction between sync and async is artificial and unnecessary.
Robots are already taking over stats
A few bits of advice to those considering this... I had a 12-drive setup a few years ago, it eventually crashed and burned, because of several errors on my part. (surrounding ZFS)

Use a MB with ECC Ram (Asus + AMD seems to be the most cost effective option here). Also, you should max out the ram on the board, especially if you're aiming for a raid z2 array of more than 10GB (I did max my ram, but didn't go ECC).

Source the same drive from as many places as possible to try to get different mfg runs. I had really bad luck here, about 3/4 of the seagate drives I'd purchased died in under 2 years... The drive model itself had a really poor quality and many people had issues with these drives dying a short death.

Ensure your "hot spare" drives work... I'd configured for 2 hot spare drives, however, there was a bug in the version of FreeNAS I was using that caused the hot spares to not go into usage automatically.

Make sure that anything important on your NAS is backed up... if it's only on the NAS, that is not a backup. Hardware can and will fail. I tend to not consider something backed up unless it is in at least 3 copies and at least 2 different locations.

Overall, it was just a piss-poor experience, in the end I went back to Synology for my NAS usage... I spent a lot of money in hopes of having a close to "final" NAS solution, with a lot of defective hardware, a lot of failures, and in general, my "backup" NAS was more reliable. There's something to be said for buying a solution vs. DIY.

I might consider it again in a few years, but am more likely to just get a 5-8 drive product over DIY again. Drives have gotten a lot larger... at the time I went with 3TB, and 4TB were just starting to come out.
Most mail is now signed with DKIM.
They are probably working 60 hours a week as they can't concentrate in the office. So then they work 65.
What's Written on Your Face
I think this is great engineering, and it shows that the Node runtime needs to consider how to actually address the needs of developers rather than smugly pointing to really frustrating solutions like Cluster that just don't provide equivalent functionality to what Go (and its predecessors in this style such as Erlang and Haskell) are providing.

There are actually a whole host of languages that would let you approach the problem with this technique and get there, so the only thing special about Go is that it is syntactically simple (although it's conceptually quite hard to build reusable code because of poor generic support the resulting bad error handling), so it makes for an easy migration.

We could see similar stories about going from Node.js to Erlang, Nim, Rust, F#, C#, Haskell, or even the newer Python & Ocaml runtimes. So it's not like Go is special here. But it's timing is special, because it's a harbinger of the industry's slow and reluctant admission that pretending everything is single threaded is okay. Even I/O multiplexing with coroutines simply cannot keep pace with even casual demands on modern infrastructure.
New programmers should learn how to use list comprehensions. They're not just some obscure Python concept, they appear in multiple other languages, as well as mathematics.
If I understand correctly, you still need guarding locks for this if reading and writing at same time, or have multiple writers. Isn't this the same as for the native map?
I'm tired of these headlines. The people who broke the internet were NPM and all of us who relied on NPM without asking important questions about unpublishing and taking over package names. Azer wouldn't even have unpublished anything without a legal threat from Kik.
Python for comprehensions are middle-ended for some reason: part of it goes backwards and part of it goes forwards. Read it as:

planets_flat = [planet for planet in episode['planets'] for episode in episodes.values()]

and it makes a lot more sense. In most languages with list comprehensions you'd write the thing you were iterating over first, e.g. (Scala):

val planetsFlat = for { episode <- episodes.values; planet <- episode(planets) } yield planet
Careers? It would be a pity to have people fired over this. I don't see it as a failure. Just another step in a long journey.
One of the most extraordinary APIs for comprehensions can be found in Clojure, where the "for" expression really changed how I view data. A single expression can generate many complex data sequences with such elegant beauty.
Because the runtime is present? I mean, why should I install Java to build my JavaScript when Node is present? And wouldn't it be weird if pip served Ruby gems or Homebrew providing chocolatey packages?
Thanks. Didn't realize that HN screws up links within angle brackets.
From the article:

"Saturation divers are incredibly well paid (around £1,500 per day)"
Another reasonable way to look at this situation is to conclude that trying to provide safely encrypted email is not a good idea. The protocol is, in this argument, simply too hostile to sound cryptography to reliably encrypt things. Instead, we should focus on:

* Getting providers to safely engage TLS for MTA-MTA mail relaying, for instance by deploying key pinning.

* Making existing non-seamless cryptography (PGP) functional enough that it can be used in exceptional cases.

* Deploying new asynchronous encrypted messaging systems --- things like what Adam Langley was shooting for with Pond --- that were designed from the start with security in mind.

Secure-by-default email would be nice to have, but it's not the only option. We could, instead, deprecate SMTP email.
Can we just let this thing loose, tell people what it is and let humanity see if they can shape it into the thing they want it to be or is there a real possibility it could do harm? I think a lot of people would have fun trying to change its mind. Worst case I see is one more horrible Twitter account, and that's just one small drop in a very large bucket.
I suspect this won't be up long once the Premier League lawyers find out. They're ultra-protective about their match data etc.
> But the thing the author fails to mention is that there are a lot of Node.js modules which help you easily scale across multiple CPU cores. E.g. PM2 https://www.npmjs.com/package/pm2

There are lots of bad things to say about Golang, but it's pretty wrong to suggest that PM2 makes it as easy to write performant systems as Go does. Go even has a really good race detector to help catch the few cases where you can get around channels.

The idea that a language cannot directly and transparently support scheduling across CPU cores is an antiquated one. Java is abandoning it. C# abandoned it long ago. Erlang showed long ago that we can do it reliably and with great performance.

Heck, even browser-level Javascript is moving away from this idea with async support, although everyone seems rather reluctant to make the plunge towards a stackless architecture.

> If you have a scalability problem with Node.js (or any language for that matter) and you can't find a simple solution that doesn't require rewriting your whole app, you're probably not qualified to manage this project at scale

I've got 13 years experience, 10 of which are as a distributed systems engineer. I've definitely hit the absolute edges of what off the shelf opensource software can manage, and more than once butted up against bugs and limitations of language runtimes. I'm extremely qualified to say that this is wrong.

Sometimes re-architecture and rewriting is the only way forward. That isn't necessarily a failure of the thing to be replaced. It's not even a failure of the architect if it is anticipated and managed correctly.
Relive the Easters of Yore. He Is Risen Indeed
This is inevitable. However, not everything is {hype}. Consider rust, for example. People have managed good stuff using that. Dropbox, Servo are widely known examples.
Repeating what I wrote in a blog post[1]:

> Humans have the tendency to imbue machine learning models with more intelligence than they deserve, especially if it involves the magic phrases of artificial intelligence, deep learning, or neural networks. TayAndYou is a perfect example of this.

> Hype throws expectations far out from reality and the media have really helped the hype flow. This will not help us understand how people become radicalized. This was not a grand experiment about the human condition. This was a marketing experiment that was particularly poorly executed.

We're anthropomorphising an algorithm that doesn't deserve that much discussion. I saw algorithm as we have zero details on what's novel about their work. No-one has been able to show an explicit learned trait that the model was taught from Tay's interactions after being activated.

It's possible the system wasn't even performing online learning - that it was going to batch learning up for later and they never got around to it.
If that's the case, it really illustrates that we've made a storm in a teacup.

All I've really seen is either overfitting or copy pasting (referred to as "quoting" in the article) of bad training data or us injecting additional intelligence where N-gram based neural networks would make us think the same thing ("hard to tell whether that one was a glitch in one of her algos — her algorithms — or a social masterstroke" from the article).

Microsoft won't add any new details as there are no wins in them for it and the story of "the Internet turned Tay bad" excuses them from their poor execution and lack of foresight. It's a win for them.

Last quote from my article, which likely has a special place on Hacker News:

> The entire field of machine learning is flowing with hype. Fight against it.

> Unless you want VC funding. Then you should definitely work on that hype.

[1]: http://smerity.com/articles/2016/tayandyou.html
Did an experiment on the dive reflex as part of an undergrad course in university; hooked up a student (volunteered and willing of course)to a heart monitor and put their face in a bowl of water.

Heart rate plummeted from 72 BPM (resting) down to 39. It was pretty cool to see
Comprehensions are not a neat trick. If you know and use Python, writing comprehensions is writing good code that can be understood by others.
Wasnt China getting better about things like this for a while there? What happened?
That doesn't work on an iterator.
As it's still early in terms of its development, it may be better to judge the language by perusing the pages of its predecessor:

• Rebol in Ten Steps: http://rebol.com/rebolsteps.html

• Rebol Overview: http://www.rebol.com/docs/expert-intro.html

Rebol is an elegant attempt at better using language to solve problems. It offers a rich vocabulary centered around words and includes natural representations of various types, such as URLs (that you can query), emails (that you can send messages to), times, dates and more. The main data structure (blocks) are instrumental in language flow and can be manipulated as data before being interpreted as code:

• More than just code—A Deep Lake: http://www.rebol.com/article/0103.html

It is different and it's not immediately apparent what it brings to the table. However, that it does have this depth and is squeezed into a < 1 meg package without dependencies hints at why there are a few of us that consider it tremendously versatile and worthy of a more prominent place in the development firmament.
> Most children wouldn't fare well if raised by poisonous "nurturers"

That's just the thing, children aren't usually just dumped out into the public to fend for themselves until their parents have slowly conditioned them and exposed them a little at a time. Tay needed some of its contacts to have a higher learning priority assigned than just strangers. And these contacts should have guided Tay through the crap by messaging Tay when she was crossing boundaries or dealing with nasty people. It would likely require a real team of people to support given the volume Tay had to deal with and some automated tools.
Well with regards to clunkiness and awesomeness, are they not still less 'naturally' composable and (as a result) less readable in composition than collection pipelines? I don't see a good reason to prefer them over:

collection
.map(x => x * 2)
...
.filter(isOdd)
.reduce(blargh)

... style syntax that most other modern, C-style languages offer now (ES6, Rust, Ruby, C# ...)
According to the Wikipedia page, this effect can be used to defibrillate infants. Really cool. I'm going to have to try this experiment out on myself now. Wonder if it has to be cold water or will warm water do.
From the article :
"Saturation divers are incredibly well paid (around £1,500 per day), but the risk they are exposed to reflects the rationale behind the pay structure."
yes, it got worse very quickly:
- does not load CSS in iframe (Windows and Linux)
- lately only a few Linux distros are supported
- poor video performance on Linux
- HTML5 (pushed by Google) has worse performance than flash on Linux
- crashes
- does not remember (load 'unsafe scripts'), no configuration option to allow 'unsafe scripts' from some sites
Attracting Developers to WordPress
An MIT lab flushing out a city’s secrets
You want Microsoft
POSIX has pthread_cancel. It's a big mess.