Most of the value I get from HN, and social websites in general, is from people surfacing things I didn't know about.

Ironically, you have missed the point of the blog post. It wasn't written to market the service, nor to engage those who aren't engaged right now. Your comment sounds like it was written by a marketoid or a growth hacker.

What does this tell you?

SQL is declarative only when you don't care about data integrity and performance.

Maybe a bit better example for this kind of behavior are compilers. They're pretty "declarative" these days. You write what code you want to compile, and the compiler will pass it through a thousand transformation stages, deciding which trick to apply at every instruction, which code isn't really needed and so on.

Of course, then you also need to deal with compilers getting it wrong too, so you start tweaking your code with special words like "volatile" and "restricted", mess with compiler options, and sometimes even disassemble code to see why turning the "fast" options makes your code slow. But in general, high quality compilers do this dance way better than SQL.

So what's the moral here? Two things.

First, calling something "declarative" doesn't really mean anything. It means the language is built on a very thick abstraction that lets the computer do more work than usual, so you can do less work.

Second, thick abstractions are leaky. Works for basic cases, past that you'll still end up doing a lot of work, but now you have to fight your computer while doing it, as well.

The Z3 Theorem Prover is an interesting toy, but I wouldn't trust it to do anything right in the real world. Much like most Microsoft Research projects, unfortunately.

If you have never tried it out you should, maybe you will like declarative languages a little bit more afterwards.

[1] http://en.wikipedia.org/wiki/Resolution_%28logic%29

Also I wasn't suggesting that declarative languages are broadly useful (in fact I'd suggest quite the opposite), just that they are very interesting.

Nothing.

This is hardly the first time this happens. There are about half a dozen cases of this kind in mainstream media every year. Plenty more go unreported. Nothing changes, because everyone feels comfortable being outraged talking about it, but they wouldn't touch the problem with a 20 foot pole when it comes to acting about it.

Don't ask what's "more Pythonic" or "less Pythonic", Python is not a cult, it's a very practical scripting language. Ask for benefits and weaknesses of a given approach in given circumstances.

But computer languages, unlike human languages, are precise. Their intent is clear. And you'll never encounter a case where the Python 3 interpreter hasn't heard of that particular Python 3 keyword you're using.

It's also not an excuse to avoid certain features of a language, when using them leads to a better and simpler solution, just because they're less popular. Programming is not an exercise in popularity.

On the other hand, human language is fuzzy and full of phrases that consist of statements having nothing to do with their meaning. Such as me saying "your argument doesn't hold water".

Human languages also have additional layers entirely separate from the primary meaning of a conversation, such as sending social cues like "how smart am I", "do I like you", "do I fit in this group", and "am I a leader or a follower". Each layer of concern drives a certain way of expression and imitation, none of which occurs (or should occur) when writing computer code.

A better example to compare to programming code would be mathematical notation. As long as you express your intent shortly, using the available mathematical notation, people will be fine, and your intent will be clear.

I've never seen someone ask in a math forum if their formula is more Mathematic one way, or another way.

The technical approach is smart, but lazy, and the resulting emoji look bland and lack definition. No wonder, since this approach doesn't support the way artists work. It's not SVG, it's not PostScript, it's not a bitmap, it's just a glyph sandwich. No opacity, no gradients, no effects. It must be a pain to split your pictures in layers so they can be in a font like that.

As far as using this for text... the novelty of such effects faded out sometime in the 90s when Word Art was all the rage among design-blind office workers.

In the modern world of Unicode, it's even less likely we'll start making fonts with hardcoded layers of cheesy effects when you need to cover a good range of international characters, weights, cursive, hints, kern pairs, ligatures, alternate versions and so on.

Well thank god. What you call "opacity, gradients, and effects", I call "total inability to be bolded, colored, embossed, etc." Apple's and Google's emoji basically entirely ignore CSS in favor of looking, well, exactly the way they look. Styling emoji to actually fit your site's theme? Who'd have imagined?

When you set your text to be bold, that's a separate font, made by a human hand.

Browsers have a fake bold look when the font is missing, but it's not a look you want on your site. They just, well... smudge it to the right. For Emoji the fake bold look is disabled, because bold or italic emoji is just non-sense on the face of it, so they don't support weight settings.

Also, you can't set the color of Windows Emoji via CSS. They're already colored.

Because the colored glyphs use a palette instead of hard-coded colors, it's possible to assign semantic meanings or names to each palette entry and remap them. This would enable you to render a 'high contrast' version, or adjust the primary color of an emoji (for example, changing the skin tone of a face), etc.

The latter is actually a topic of concern: Most current emoji represent a caucasian or light-skinned individual, so the lack of emojis that represent other races is a problem. People are still figuring out how to deal with it.

They had nothing to gain or lose from making this into a political statement, so they invited them.

You learn about responsibility and authority when there is something to gain or lose.

1) The score isn't most important. The headline is. This is why the headline is in black, and the score is in gray. We don't come here to compare news importance, the site already does this for us by sorting. We come to read news. And having a small pale gray score replaced by a big attention-drawing glowing orange square goes against where the focus should be.

2) I do part time design and understand the temptation to style your presentation so it enhances your concept, like add perspective, drop shadows, and so on. My team does this when presenting business card designs to clients, because the actual graphic looks so simple and boring on a monitor, the client won't "get it", if we'd show it as is.

But a website isn't a 3D slab floating in space, so in this case the styling is a distraction from your presentation, not an enhancement. Keep it simple, when simple works.

I'd rather cheer for them and be disappointed, than dismiss them in advance and live my life perceiving the world through a cynical lens.

Huh. I didn't know I can write so dramatically. You catch my drift, though.

But a quick offer with a billion was made and just like that Oculus was Facebook's.

Tens of millions and being in charge of a company that improves lives for millions of people around the world in a way you'd love to keep heading up.

Wake up. You don't get to do any of that when your board is stacked with VCs.

First of all JOBS act Title 3 lets you do crowdfunding. And meanwhile there are old school alternatives:

Banks (older school than VC)

Actual profits (probably even older school)

Broker dealers (crowdfunding before there was crowdfunding)

Whether that's actually the case is less clear to me though, after following some of the other comments from the developers here.

And as for control, maybe I should just say it explicitly: we have raised investment but are still in full control of the company (aside: it'd be nuts if we weren't at the stage), and plan to keep it that way going forward. In fact, our investors decided to invest explicitly because they believe our team is the best able to make decisions on growing a sustainable business and solving the developer platform challenges. No matter how good the VC, they obviously don't have the background+skills+focus to design APIs (and likewise shouldn't).

One of our investors likes to say, "We're in your corner, but not in your kitchen," which I've always thought framed the relationship well. I know there's lots of cynicism in the tech world with buyouts/acqui-hires and swarmy VCs, so I can understand where this reaction comes from. And unfortunately I don't have a solid rebuttal other than saying "trust me" with the test of time. Clearly that doesn't work for the HN skeptics. :/

It's also worth pointing out that not all acquisitions are terrible. Google Docs came from an acquisition. So did Google Earth. Facebook continues to run Parse, and Instagram, and Beluga via FB Messenger. Sometimes these acquisitions legitimately make sense, but I think the important thing is keeping the right people in positions to make those decisions when the time comes, and not the people who are just looking for the immediate financial return.

1. If I run my own email server and do not have email addresses from yahoo, google, et al, how does this help me?

2. Is there a way to strip html off every incoming message, but retain the original intent of the formatting?

3. Is the API compatible with PGP? Can I enable PGP encryption at the server level? For example, say the client connected to the server sends unencrypted mail over the SSL encrypted connection... is there a command to automatically encrypt the message to the end user if a PGP key is found on a public server?

4. It seems, much to my surprise, that there is a push toward permanent on-line storage of email -- even though this is extremely insecure [must trust multiple unknown parties/countries/servers/continuous rule of law, etc] and prone to failure as opposed to local only storage -- is there a "local storage" option similar to pop3 for those clients that wish to store email on cheap and easily secured local drives?

5. Tons of other questions... but these are the first four I could think of...

1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.

2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.

3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.

Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.

4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.

Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.

We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.

[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.

[1] https://github.com/mailgun/flanker

[2] https://groups.google.com/forum/#!forum/inbox-dev

But if you are somebody making business decisions based on sunshine and rainbows rather than the observed failure rate of startups, then please make those decisions with your own money and your own labor.

Because otherwise, you will end up creating a bunch of cynical employees and investors.

If you want to encourage a specific culture you do this by starting with a small set of people who have this culture in their bones, then growing slowly and assimilating more people into that culture, addressing deviations swiftly and letting people get back to their work afterwards, without skipping a beat.

Not by writing manuals, and then stressing everyone with looooong, reaaaaally long and exhausting "we need to talk" style posts, where we hold hands, talk about how it's so difficult to open your mouth and say something that's not offensive, and how we're far from perfect, and in fact, we're all sinners.

It's not that the intent is wrong. But this way of going about it is so extremely taxing on everybody, creating an atmosphere where everything people say is judged on the "-isms" scale.

It means when you talk, you're terrified of what you're saying.

When you listen, you listen for someone to say something so you can point your finger at them.

A culture may be selective on very different criteria. It can easily be blind to gender, race, age, religion, nation and many more, yet have certain very specific values. And letting people in who have the opposite values are toxic to that culture.

You can't have a culture that's "open to everything". It means you have no culture, you just adopt the zeitgeist unmodified. Everything goes. If this was the goal, this thread wouldn't exist.

Are you trying to say that the field of technology development in general or programming specifically would be toxicly harmed if certain groups of people, identified by "gender, race, age, religion, nation and many more", are allowed in to it? Or are you trying to say that objecting to people attacking others on the basis of gender, race, age, religion, nationality, etc., would be toxic to the culture of the field?

It's just how humans work. We get born, have a period of growing up, gaining experience, then a productive period with big bold dreams, then settling, retirement and death.

I guess without the finger pointing the data would be so boring that it wouldn't warrant an article, so here we go.

Of course, that doesn't mean this article is correct.. since it doesn't show how old the pitchers were. It's entirely possible there is no age discrimination, if older people just dont apply (perhaps it's a raw deal.. or perhaps they don't need the money, since they have resources of their own.).