I personally feel it caused an unhelpful epidemic of snark about technology. When you have a bug you're trying to squash and you take a break and skim Twitter, this kind of sentiment is like salt in the wound.
Sure no yeah, all of the things you talked about in the talk are valuable things to know. You didn't talk at all about why they are that way, nor did you admit that you don't know (and neither do the language creators know) why those problems exist. Nor did you disclose that the most important thing to know was that these are undefined corner cases, of which technology is full of. Now there are millions of retweets out there that do nothing to further understanding.
They amount to me taking a screenshot of your comment here and saying things like "Oh, look, he typed into a text box and the computer didn't format his sentence properly with a capital at the beginning or a period on the end! Computers are so stupid but how could he have known that it wouldn't do that for him?"
Instead, the real explanation, that this is what you wanted, is rather mundane and boring. And it is unrealistic to expect a feature like I'm suggesting because it assumes so much about what is wanted, and would be tied to directly to a general use case of English and may not work right all the time anyway.
This is a subtle nuance that can be extrapolated into real understanding of the limits of system design, and you personally continue to push this mindset that we should all point and laugh and retweet because it is a funny in-joke and I'm sorry it just doesn't help.
I will give you that it does have an element of striving for better, more descriptive error messages, and better interactions and interfaces. But I don't see anyone outside of Bret Victor really trying, and we need a million more people a little less ambitious than him to make it happen.
This all being said, you do an absolute ton of great work that honestly I can barely understand because it is either more advanced than I am, or outside my purview, but I know it is worth it to us all that you do it, so thank you so so much for that.
I will now justify some jokes that I made four years ago.
Most of my work that you've praised so highly concerns improving software quality and the experience of programming. Wat is about one of the underlying causes of low software quality and unpleasant experiences of programming.
Specifically, none of that JavaScript behavior is undefined. Brendan Eich specifically chose to define all of those conversions in those ways. JavaScript was designed to do what the programmer doesn't want (silently perform nonsensical conversions) rather than what they do want (throw an error). There are reasons for this, but in its current use context that decision is not what we want. Many people watch Wat and go on to learn all of this; there are dozens of blog posts, Stack Overflow questions, etc. where the behavior in Wat is dissected in detail. For example: http://stackoverflow.com/questions/9032856/what-is-the-expla... or http://blog.caplin.com/2012/01/27/the-why-of-wat/
Many programmers think that their tools work reliably; that they don't encounter problems often; that popular programming systems are fundamentally reasonable; that mistakes are always the programmer's fault. These people are wrong, to everyone's detriment. The easiest remedy is to show them, rather than tell them. Many people -- far too many now to count -- have said that Wat made them begin to realize how broken our tools are. That's a prerequisite to engaging with my (and others') longer-form work on improving things.
I could do a talk explaining all of this with examples and so on, but it would be full-length, not a lightning talk. My full-length talks get maybe 100k views, so the audience would be 5% of Wat's 2m views. Wat must be short, and therefore context-free, to work.
"safe-eval lets you execute JavaScript code without having to use the much discouraged and feared upon eval(). safe-eval has access to all the standard JavaScript API of the underlying engine. It is implemented using node's vm module." [1]
It's important to note that running code in vm.runInNewContext is not advised for 'untrusted code' according to the documentation. So probably not good to let random people use this bot.
"script.runInNewContext() is quite useful, but safely running untrusted code requires a separate process."[0]
Hey, yes, sorry, I had misunderstood the Facebook Messenger bot review process. Thought that it was enough to publish the Facebook page in order to be able to receive and send messages to external people. Now the page can receive messages but those messages never make it to the server where the bot is located, and hence no response ever makes it back to you.. :(
Good news is that if you follow Facebook's guide to create a Messenger bot you can easily deploy this code and play around with it yourself. It works great to receive and send messages but only for the owner of the page/bot :)
I'll update you if I get the required permission from Facebook and the bot becomes publicly accessible.
In al seriousness, I don't really use Facebook for anything and only keep an account to communicate with my daughter's teachers. But as ASIMUV grows people are always asking about it on Facebook. Now I'm planning on using it as part of the community outreach program. And I'm not even sure how it works anymore... D:
Messenger Platform docs happen to showcase very specific acceptable examples of what bots are expected to do[0]. An app like this doesn’t look likely to be approved to be publicly accessible.
Does anyone have experience getting FB’s approval for a Messenger bot?
Is sending and receiving messages through facebook messenger still limited to the official app or did they add back an API to replace the old XMPP interface?
I think that is different from what he is asking. I believe MaddoScientisto was talking about and API that could be used to create unofficial clients. The API you provided appears to be designed to create bots, and insufficient for custom clients.
