Siri's creators say they've made something better - <AUTHOR> https://www.washingtonpost.com/news/the-switch/wp/2016/05/04/siris-creators-say-theyve-made-something-better-that-will-take-care-of-everything-for-you/ <comment><USER2> According to an episode of Acquired[0], none of Siri's original technology is present in Apple's current products. Siri originally licensed Nuance's (also an SRI spin-out company) voice recognition technology and built some pretty (comparatively) simple tech on top of it, never changing out the speech-to- text engine. All current players (Google, Amazon, etc) use neural nets, so Apple scooped up many Nuance employees to double down and compete[1]. Rosenthal and Gilbert agreed that Siri was a failure: "the only thing I use Siri for is setting alarms." I'd have to agree from personal experience. They chalked the failure up to the disadvantages of a UI where the full extent of the functionality is hidden and difficult to understand, leading to bad experiences. I imagine this technology will have many of the same struggles.

[0] [http://www.acquired.fm/episodes/2015/12/14/episode-5-siri](http://www.acquired.fm/episodes/2015/12/14/episode-5-siri)

[1] [http://9to5mac.com/2014/06/30/why-is-apple-hiring-nuance- eng...](http://9to5mac.com/2014/06/30/why-is-apple-hiring-nuance-engineers- apparently-to-replace-siris-nuance-powered-backend/)

<comment><USER3> I think the biggest problem with voice commands is that if the command doesn't work the first time, it would have been faster to simply input the command yourself. I'm not confident that "get me directions to <place>" will actually get me those directions. Because of that, I also use Siri exclusively to set alarms (which does work every time).

<comment><USER4> This is the #1 problem with anything based on voice recognition and natural language processing IMO. It has to work 99% of the time to overcome this issue, but it seems like the nature of the technologies ensure that it will only asymptotically approach this threshold, and is currently stuck at 75% reliability at best.

Plus, even if it did work, it's just a really inexact and inefficient way to do anything. You always end up trying to see through the abstraction layer (natural language in this case) to the much more well-defined hidden system underneath. It's like reverse engineering an expert system, as a UI paradigm.

Programming languages made to resemble natural language face a similar poison pill, AppleScript being a prime example.

I totally get the appeal of trying to make software understand people better instead of forcing people to understand software, but in practice it just ends up being one more abstraction layer users have to struggle to get past in order to unlock the functionality of the underlying system.

<comment><USER5> The funny thing is that voice recognition is no longer the problem. For years the reason you couldn't do voice command interfaces was that transcription didn't work, but today transcription works amazingly well. My commands are transcribed perfectly, even in my car when I'm doing 65 on the freeway with my phone stuck in a cupholder.

The problem now is Android randomly kills the "OK Google" background listening process, or it fails because it can't handle a handover between wifi and cell data, or it "can't open microphone" even though it _just heard_ me say OK Google, or any one of many other Android problems rears its ugly head.

The reliability of voice transcription now is far better than the general reliability of Android on my Nexus 5X, and the Android team ought to feel pretty bad about that.

<comment><USER6> Exactly this - There is a bug where if your phone is locked, and in a position where it thinks it's in landscape, when you say 'OK Google' the phone will unlock in portrait, start listening, rotate to landscape and in the process kill the app listening to your voice, and then rotate back to portrait and lock itself again.

It's also incredibly easy to fall off the blessed path where you can interact solely with voice - when setting a reminder, for example, if it doesn't hear 'Yes' when it's expecting to it'll just sit there and you need to touch the screen to continue - defeating the whole point of voice interaction.

Google's voice search has incredible voice recognition and text to speech and can tap into an amazing amount of information through the knowledge graph, but they don't seem to be capable of fixing the basic bugs and UX issues preventing all that technology from actually being usable.

<comment><USER7> > It's also incredibly easy to fall off the blessed path where you can > interact solely with voice...

I had this happen with Google Maps the other day. I was driving into San Francisco with the turn-by-turn directions when it said something like, "There is a faster route available in two miles. It will save 5 minutes. Tap 'Accept' to take this route."

So I had to fiddle with my phone in a hurry, in traffic (after all, traffic was why there was a faster route coming up), and hope I don't tap the wrong button or crash into anyone while looking for it.

Why couldn't I just have said "Yes! Please and thank you. Of course I want the faster route, why wouldn't I? Oh, sorry, I mean 'Accept'!"

The funny part was that the "faster route" was the way I usually go into that part of town anyway, but Maps had been sending me a different way because of congestion on the usually-faster route. Why did it even ask me to "accept" the faster route instead of just redirecting me the way it does automatically on most occasions?

Like the time I was heading south on 101 through Morgan Hill and Gilroy and Maps had me get off the freeway and take a side street for a couple of miles because traffic was stopped on the freeway due to a car fire. It didn't ask me to tap Accept then, it just gave me some very practical directions on the fly. That's how it should work.

</comment></comment></comment></comment></comment></comment><comment><USER8> It sounds like they still have to partner with the different services to create custom integrations with their APIs so they can interact only with these preprogrammed services. But the real impressive AI thing would be if it could figure how to do the order of a service on its own: mimicking how humans do it by using forms on the webpages or writing e-mails or making phone calls for reservations. That would make the interaction look like just a regular order from the service providers perspective, so there would be no need to create partnership for the API integrations with each service provider.

<comment><USER9> Having bots fill out forms and write emails is optimistic, but Google already publish how to structure your (HTML) data to make it readable by their bots so that it can extract useful information for their knowledge graph.

Ideally we would have a standardized declarative service description language that "digital assistants" can use to not just answer questions (already possible) but also purchase services and goods.

Although we can't just trust any "service" discovered on the internet, someone would need to actually vouch for it before it can be used by a digital assistant.

</comment></comment><comment><USER10> The main problem is that Siri wasn't opened up to third party apps to hook into, and thus remained rather limited and stupid.

Each app could have bundled a voice interface, and Apple's phone would have been the first futuristic and extensible "star trek computer". Oh well, opportunity missed. And by a company whose founder had the Mac speak onstage. I think Jobs would have gone in this direction and demoed the crap out of it!

As usual, there is a systems level challenge to solve for building a foundation for app developers. Namely, how to make a fair and EFFECTIVE way for app developers to all share the same namespace / tree of commands?

If I was in charge of the Siri team, I would have made the following changes:

1) Fork OpenEars or another open source package and spearhead it as a first pass on the phone to eliminate the need for internet connection.

2) Have apps register prefixes for commands

3) Have apps register for "voice intents" and verbs that connect like they have for inter-app audio and app extensions

4) When an app is open, have a way to speak to the app through using the iOS library. This can be used to issue commands or dictate an email etc.

5) Feature apps that make ingenious use of voice commands and have them pitch PR stories about how the iPhone is becoming like Star Trek and is far ahead of Android.

<comment><USER11> Or do the same, but on Android. Why can't devs add new voice commands to the system?

</comment></comment><comment><USER12> Hopefully they'll stop focusing on converstional UI, as it's wildly innefficient. I'd much rather interact visually and spatially.

I'll give these guys the benefit of the doubt, but it seems like all of these businesses miss the big picture and try to emulate the way humans communicate. In trying to deal with the UI fragmentation problem, they're greatly decreasing the user experience. We don't need a chat bot, we need an app that does everything, where the GUI is the language.

I don't want to describe a location verbally, I want to point to it in a map. Most of the time, I don't know what I precisely want, and prefer to browse options rather than have a tedious conversation.

There is no doubt in my mind that the UI of the future will be more like Akinator/Tinder (Yes/Maybe/No) than English.

All the pieces already exist. All we need is some interface over a knowledge graph. Why don't people see this?

<comment><USER4> Agreed 100%. I felt the same way 10 years ago when people would always bring up the Minority Report UI as some sort of holy grail we should all be working towards. It looks cool (or demos well, in the case of conversational UIs), but outside of a few very specific use cases it would be horribly inefficient to use all the time.

Conversational UIs almost seem like the ultimate form of skeuomorphism to me- it's only an illusion that it works like something from the non-computer world that you're already familiar with (talking to another person, in this case), but the reality is something far more complicated and far less robust than it leads you to believe.

<comment><USER13> Yes, I think for a conversational UI to work, it needs to be aware of the human world - like JARVIS from Iron Man.

</comment></comment></comment><comment><USER14> I always find these articles (and the response to them) a bit strange.

The hard part of this problem _isn 't_ the voice-part - that is doable. The hard part is parsing the question or order! That is so, _so_ far from being solved. Accuracy rates on QA tasks in academia are around 60-70% (depending on the task), which is much worse than the 95-99% accuracy achievable with speech-to-text.

 _That 's_ why the pizza ordering thing is impressive - the software has to understand intent.

<comment><USER15> But it didn't sound any easier than calling the pizza shop, which is something I hated doing before the internet solved that problem for me. The unpleasant experience was caused by the cognitive load of having an unpredictable real- time interaction with something that wasn't laid out in front of me, not by the fact that the thing I was conversing with was human

</comment></comment><comment><USER16> The example of the pizza ordering is technologically impressive, yes... But from an end-user perspective it is at best "as hard" as calling the pizza place and talking to a human taking your order.

There are many use cases where it could actually provide value, but I found it funny that they chose to demonstrate one to the press that really afforded end-users no advantage.

<comment><USER17> What if the pizza cost half as much now because it didn't require a human to standby and take the order?

<comment><USER18> I can already order my pizza with an app or with Yo Dominoes... and they cost the same...

Not sure if it's because the person on the phone is doing other stuff at the same time or if it's more like eBooks where they cost the same as Paperbacks because "more profit".

<comment><USER19> That is the case. Only when the store is very busy will they have dedicated phone order takers. The rest of the time the drivers who are waiting for the next delivery, the pizza makers, and/or managers handle the phones.

Used to work at a Dominos, though it was pre-internet days. Not sure how much online business the typical store now gets, I know I still always call when I order pizza because it's faster than dealing with the website.

Annoyingly at Dominos they now also have an automated attendant answer the call initially, which reads off the daily specials. That's a big reason I don't often order Dominos anymore but instead call a competitor who still has live humans answering the phone.

When I was at Dominos we had a standard of no more than two rings before a person picked up. People would sprint across the store to get the phone before the third ring.

<comment><USER20> Why not get headsets like they have at fast food places? Edit: I feel like that would be a lot cheaper than even one worker comp claim slipping on a flour-covered floor in a pizza place.

<comment><USER21> I think it's optimistic to think the pizza making process at Domino's involves any loose flour. I would have imagined frozen and/or refrigerated lumps of premade dough on a rack.

<comment><USER22> I don't know about Dominoes, but when I worked for Papa Johns many years ago loose flour was involved in the process of shaping the refrigerated lumps of premade dough into a pizza crust.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I wish them luck, and the ability to hook into 3rd party APIs is good, but ordering a pizza is essentially just straight forward form filling, and quite frankly, something I could do 30 years ago. SoundHound's Hound[0] shows refinement and retargetting, which is much harder because you have to entity resolution on implied subjects / objects, pronouns. Now maybe VIv can do that too, but that's not what they demoed. What they demoed isn't actually all that interesting.

[0] [http://www.soundhound.com/hound](http://www.soundhound.com/hound)

</comment><comment><USER24> > It was their first real test of Viv, the artificial-intelligence technology > that the team had been quietly building for more than year.

I think they mean "first real demonstration." It would have been tested thousands of times before reaching the board room.

That gripe aside, the real test (for me, at least) of whether a service like this will be usable is whether it can run offline without uploading my entire life to the mothership. I won't use Google Now or Siri or anything similar because it would make my life (even more of) an open book to a single huge provider. It's bad enough that Google (through Gmail) has access to my emails, I don't want them having a log of my moment-to-moment location, voice conversations, routines, etc.

</comment><comment><USER25> I have my doubts when it comes to replacing colorful, tactile user interfaces with voice conversations.

I don't like the idea at all. I want to interact with my device using a visual interface, which I can "feel" and interact with, rather than a metallic voice.

I want to see what that pizza looks like, not imagine it.

Voice interface is totally unusable in a place were there are several other people - an office, train, bus, doctor's office - places were we tend to dive into our devices.

<comment><USER26> > I want to see what that pizza looks like, not imagine it.

I think you're confusing the matter by lumping voice input and voice output into one bucket.

Think star trek 'Computer show me a map of the omnicrom system and highlight possible habitable planets within 10 light years of our current position'

<comment><USER25> You're right, I'm lumping them together, as per the article:

> Then, a text from Viv piped up: "Would you like toppings with that?"

That's not a very good UX in my opinion.

 __*

> Think star trek 'Computer show me a map of the omnicrom system and highlight > possible habitable planets within 10 light years of our current position'

Yes, it would be a nice additional input method , although sometimes _pointing_ things out (like selecting with the mouse or finger) is a lot more efficient than trying to explain it - "highlight that one.. no, no, not that one, the other one! ... stupid toaster!"

I can see voice input being useful when combined with all the other input methods plus good realtime visual feedback.

My prediction is that we'll have really interesting programming environments and programming languages based on voice input in the next couple of years.

 __

Still, voice input is practical in an isolated space, were there are no other people using voice input as well, so although I see a niche, I don 't see it replacing mobile devices just yet.

</comment></comment></comment><comment><USER27> I _almost_ hate to say it, because my hopes were uncharacteristically high, but I feel like making something better than Siri is a rather low bar.

</comment><comment><USER28> Another example of government funded invention being converted to dollars using capitalist innovation. People still don't understand how much our government is involved in bringing us the tech we have now. government invests and about 10-20 years we see it in our homes.

</comment><comment><USER29> Didn't Microsoft present the technology for the exact same thing (even used the same pizza-ordering example) during their Build conference this year?

<comment><USER12> Perhaps that's because it's the most trivial of ideas and every single person in history has had that thought at some point in life?

<comment><USER30> Pretty sure the first iPhone demo involved Steve Jobs ordering a pizza to the Moscone

<comment><USER31> He ordered Starbucks coffee not pizzas.

</comment></comment></comment></comment><comment><USER32> How is this different than a pizza app using Microsoft's Cortana API in Windows?

</comment><comment><USER33> The original Siri app acquired by Apple was more useful than Siri in its current incarnation, so this headline doesn't really say much.

</comment><comment><USER34> They'd better have their ducks in a row with the proof that this is entirely separate from Siri. The lawsuit is inevitable.

</comment><comment><USER35> It can't be hard considering how stupid Siri is.</comment>


Bilingual speakers experience time differently, study finds - <AUTHOR> http://www.lancaster.ac.uk/news/articles/2017/language-shapes-how-the-brain-perceives-time/ <comment><USER2> I am confused by what the article says. At least in Spain we don't use volumetric relative measures for time (big/small) but linear ("corto"/"largo", short/long). This is particularly true when for the examples in the article ("duración" duration: "larga duración" o "corta duración"; "wedding", a "big wedding" is a wedding with a lot of people, a "long wedding" is a wedding that takes a lot of time). The only case that might be different is that in Spanish it is common to use "mucho/poco" (a lot, little) as an adverb with "durar" ("to last") as in "sth lasts a lot" as opposed "sth lasts long" or "cuanto dura?" ("how much it lasts/takes?")

As other pointed out, the "now" that blends into the future is maybe a more interesting feature of how time is understood in Spanish vs other languages.

<comment><USER3> It is probably something to do with cultural habits in different geographic areas, not necessarily language. I moved from an English speaking region (Ontario, Canada) to another English speaking region (British Columbia, Canada) 5,000 km away. In BC people seem to measure distance using time but in Ontario they use distance. In Ontario they will say that a town is 150 km away but in BC they say that a town is 45 minutes away. Possibly this has to do with the mountainous terrain of BC which restricts your travel routes and speed, while Ontario is relatively flat, allows many different routes between point A and B, and you can speed without dying.

On the other hand, I also speak Russian, and switch between Russian and English several times per day. When I speak/think in Russian I tend to not worry about the time order of things that I speak about because Russian has few verb tenses and makes it easy to function in an eternal now where actions are either ongoing or completed. Good for getting an overall perspective on things.

<comment><USER4> Albertan here; we're flat and our roads are straight, but we also measure distances by travel time, whether in the city ("I live 20 minutes from the mall") or across the province ("Calgary is three hours from Edmonton").

I suspect that it's a western thing more than a terrain thing. I wonder if that applies to the western USA as well?

Another interesting thing that I've noticed is that Europeans and North Americans have a very different concept of historical time and relative distance. To me, a building that has stood for 100 years is OLD, and 200km (Somewhere that's "about an hour and a half to two hours away") is a day trip that's nothing out of the ordinary. When I was in the UK, I noticed that people held the opposite view - 100 years ago was just yesterday, relatively speaking, while traveling 200km for a day trip was inconceivable.

<comment><USER5> as a european, in canada and the US I was constantly confused by directions. america uses street names and cardinal directions (turn north on I-??? then west on ...). europeans think in terms of sequences of towns (to get to munich I must drive on the autobahn via Stuttgart, Ulm, Augsburg).

I once travelled from toronto to chicago by car and decided to write down my own directions from google maps because I felt the ones provided were useless. Boy, was I lost when I didnt see a roadsign for windsor/detroit.

<comment><USER6> In the UK Google Maps does road numbers wrong. So A4042 should be "ay four o four two" but Maps says the less efficient "ay four thousand and forty-two" (it's also wrong, it's a code not a number; like calling 0b20 "twenty").

It throws me much more than it should.

<comment><USER6> 0h20! lol ... there are 10 types of people in the world ...

</comment></comment></comment></comment></comment></comment><comment><USER7> As being bilingual in Italian and English, this seems … contrived to me. I don't believe I perceive time any differently when I speak one language or the other: I simply learned the idiomatic way to say it in that language. Same thing with using different prepositions: just because I use a different preposition in one language doesn't change the way I perceive the reality or relations of that situation.

<comment><USER8> I took an intro linguistics class that focused a lot (like, weirdly more than I expected) on linguistic relativity, or the idea that the language you use affects your perception of reality.

It's one of the things I'm really hoping neuroscience can answer better before I die, because honestly the class gave me the impression that the entire field is incredibly contrived stuff like this.

My suspicion is that there's significant truth to it, but we still have such an awful understanding of cognition that almost all testable hypotheses we can imagine re: linguistic relativity are hopelessly naive. The only one that seemed really well founded to me was that Russian speakers distinguish shades of blue better because they have separate "light blue" and "dark blue" colors.

[https://www.newscientist.com/article/dn11759-russian- speaker...](https://www.newscientist.com/article/dn11759-russian-speakers-get- the-blues/)

<comment><USER9> I think about it from the perspective of computing, when you learn jargon, are you just learning an idiom, or are you learning the model through which you will think? It's definitely the latter to some extent.

In my family, we have the eternal 'coming in five minutes', which is never five minutes, but which may be anywhere from 12 minutes to never. Essentially it's a way of putting a future task on a queue which will be checked at an indeterminate time in the future. This doesn't exactly reflect a precise parsing of the phrase, which might be tempting for a linguist, but I do think that the way you express yourself in language and the way that language is understood by others affects the way you think and behave. The eternal five minutes definitely has a habit of making us late.

</comment></comment></comment><comment><USER10> I can understand how this happens.

For example, telling time in Norwegian took me viewing time differently. English tends to place importance on the last whole hour that passed: Half past six, six thirty-five, six twenty. It isn't until we approach the next whole hour that we give it any credit: Quarter 'til seven.

Norwegian, on the other hand, seems to focus more on the "now" and the future, orientated around the nearest 15-minute mark and the next whole hour, only focusing on the hour that has passed for the first 15 minute. _it is quite possible I 've flubbed on the exact phrasing: While my Norwegian is on the upper end of adequate and passed the state tests, I am still far from truly fluent_

6:20? Ten 'til half seven. 6:30? Half seven. 6:35? Five over half seven.

<comment><USER11> The first thing I learned in the US: nobody says half past or ten to or any of those things. They only make sense on analog round clocks.

What people say is stuff like "six twenty", "four fiftyfive" etc

<comment><USER12> I grew up being taught how to say "half past or ten to" in school, but I think people stopped doing it when digital clocks became cheap and ubiquitous (in the 90s).

<comment><USER13> For a while, as a joke, I used to say stuff like "it's 5 till a quarter past X" or "it's 20 past a quarter to Y". It tends to throw people off.

</comment></comment></comment></comment><comment><USER14> At first glance, his is too naive a conclusion. This isn't simply language- specific, it is further locale-specific in addition to simply the language, here's why:

 _Ahorita_ in Spanish (USA) means something else from Spanish (Nicaragua) for example. If a Greyhound bus driver were to use that word to indicate the bus is departing "Ahorita", I would assume that to mean the next 10-15 minutes whereas in Nicaragua, I would have no idea if it means 10 minutes, 30 minutes or even 60 minutes, so my follow-up question would be, "Do you mean 15 minutes or less?" To me, this is more a cultural thing, not a linguistic thing since in fact the language in use is the same, i.e. Spanish. As another example, "later" (EN-US) is not the same as in EN-IN.

Or maybe I'm missing the point of the research entirely ...

<comment><USER15> Funny, in Mexico we use a lot "Ahorita" too, which it's just the diminutive for "Ahora" ("Right Now" in English). The word is very ambiguous here, it can mean "Right now" or "In a few minutes/hours/days" or if used sarcastically "Never".

Edit: ohh my gosh I just remembered another case where it's used for past events:

\- Perdí mis llaves (I lost my keys)

\- ¿Cuándo? (When?)

\- Ahorita (Just a few seconds/minutes ago)

<comment><USER16> \- Ahorita (just now)

Same in english, no?

<comment><USER17> Maybe "in a second" or "in a minute", which is almost never a second, or minute, respectively.

Or "shortly". Heard that one a lot. We'll be departing shortly. Which could be 2 minutes or 15 minutes, or something in between.

</comment></comment></comment></comment><comment><USER18> The movie Arrival (2016) incorporated this idea as its primary plot element.

<comment><USER19> This is the premise of the movie indeed, language shape your perception of everything around you. If you missed it, you absolutely need to see it. It's the best SF movie of the decade.

[http://www.imdb.com/title/tt2543164/](http://www.imdb.com/title/tt2543164/)

</comment></comment><comment><USER20> If I paraphrase the results of the research: Researcher finds that bilingual folks express numbers in different ways depending on the language they use. So they _experience_ numbers differently.

The jump to the conclusion is certain far-fetched, and it's a question of habit, practice and context rather than "experiencing" anything differently.

</comment><comment><USER21> This reminded me of an interesting example of "a difference experience of time". There is a tribe in South America, whose language use describes the future as being "behind" them. When they talk about their ancestors they gesture waving behind their back, and for their descendants (children, grandchildren), they gesture in front of them. To me, that's a clear example of how language can shape people's experience of time. (And also makes me think about "spatial metaphors" to describe time, which is what a clock is essentially..)

[http://ucsdnews.ucsd.edu/archive/newsrel/soc/backsfuture06.a...](http://ucsdnews.ucsd.edu/archive/newsrel/soc/backsfuture06.asp)

</comment><comment><USER22> interesting, and to put in relation with those other articles

Mother tongue may determine maths skills [0]

Does the Language I Speak Influence the Way I Think? [1]

[0]: [https://www.newscientist.com/article/dn9422-mother-tongue- ma...](https://www.newscientist.com/article/dn9422-mother-tongue-may- determine-maths-skills/)

[1]: [http://www.linguisticsociety.org/content/does-language-i- spe...](http://www.linguisticsociety.org/content/does-language-i-speak- influence-way-i-think)

<comment><USER23> The [0] study itself said in its introduction "Whereas previous neuroimaging studies have revealed differential activation patterns during reading processes [...], the question remains whether these differences are derived from culture characteristics rather than ethnic or hereditary factors (1, 9)." but does not give any information about the races the two studied groups.

The Chinese speaker group is most likely made exclusively of Han people while the English one may be racially more diverse but probably mostly non East- Asian people. So basically it compares groups that have an average IQ difference of at least 5 points and that may explain the math advantage of Chinese "speaker".

To avoid that issue this kind of study should use groups of people of some A origin rise in A and B language environment (like Asian Born Chinese speaking exclusively English vs Chinese speaker from China).

</comment></comment><comment><USER24> Interesting. This appears to bolster the Sapir–Whorf hypothesis[1] which has been the subject of a fair degree of criticism[2], particularly from Steven Pinker.

[1] [https://en.wikipedia.org/wiki/Linguistic_relativity](https://en.wikipedia.org/wiki/Linguistic_relativity)

[2] [https://www.quora.com/What-are-the-main-criticisms-of- Whorfs...](https://www.quora.com/What-are-the-main-criticisms-of-Whorfs- theory-of-linguistic-determinism-and-relativity)

</comment><comment><USER25> Interesting. Never really noticed any effects of that, however. On the other hand, in Russian there is no distinct time metaphor - it can be a short pause, it can be a small break.

</comment><comment><USER26> "A-lalla-lalla-rumba-kamanda-lindor-burúmë"

[http://folk.uib.no/hnohf/entish.htm](http://folk.uib.no/hnohf/entish.htm)

<comment><USER27> That was an interesting read. But now my vision's gone all pink because of the bright green background—looking at the world through rose-coloured lenses, I suppose.

<comment><USER26> My sincere apologies.

</comment></comment></comment><comment><USER28> Idk, I do have different personalities in my two native languages, so I suppose the different mental makeup could affect things.

But I'm not sure how much of this hypothetical difference is due to cultural differences assimilated into each part of my mind through differences in exposure via the two languages, vs the languages themselves. A worthwhile distinction imo.

</comment><comment><USER29> Neuro-Linguistic Programming is often labelled as pseudoscience, but I think this gives implicit credence to some of their methods (like Timeline Therapy, which is all about manipulating your own mental representation of time in order to eg get over phobias or achieve goals better).

<comment><USER30> >Neuro-Linguistic Programming is often labelled as pseudoscience

There's a definite link between language and cognition: e.g. semantic priming effects. Clearly if we're able to be convinced by verbal argumentation, it follows that language can (in some sense) shape cognition.

Where NLP becomes a pseudoscience is when it's presented as therapeutic, or at least as _systematically_ therapeutic. In other words, the first principles of NLP are (generally) sound. The application is not.

<comment><USER29> _Where NLP becomes a pseudoscience is when it 's presented as therapeutic, or at least as systematically therapeutic. In other words, the first principles of NLP are (generally) sound. The application is not._

I looked into scientific backing just now - seems its therapeutic effect is mostly not backed by science. Ie it doesn't cure phobias, as it says it does. Then again, I would have to look at those 18% of studies that DO show an effect, and see if they are doing something different than the ones that don't show an effect (NLP can mean a lot of things).

[https://www.degruyter.com/view/j/ppb.2010.41.issue-2/v10059-...](https://www.degruyter.com/view/j/ppb.2010.41.issue-2/v10059-010-0008-0/v10059-010-0008-0.xml)

<comment><USER30> Yes ... that was exactly my point. Sorry, I'm a bit confused by your comment. Are you agreeing or refuting?

</comment></comment></comment></comment><comment><USER31> As a multi(poly?)lingual person I had never consciously thought of this but after going over every language I know I can see, I perceive time in distance, volume as well as sizes.

Interestingly a couple of languages I know depict time in distance as well as sizes depending on the context.

<comment><USER32> Do you "perceive time" or do you "express time". As a multilingual person myself. I don't "think in a language". I "think" in something innate which can't be described as any language I know. The thoughts are formed instantly and then I simply express them in the language the other party will understand. Almost automatically.

I don't have to work to "translate" between these innate collections of ideas to spoken language, it happens automatically.

Some people tell me their inner thoughts are in a certain language, but that's not the case for me.

So I would like a clarification. Do you "think in a language"?

<comment><USER31> I do think in a language but that changes based on situations too. For abstract thoughts I think in English, for planning thoughts I think in another language, etc. It is not a conscious choice, my brain somehow picks a language for thought

</comment></comment></comment><comment><USER33> Paper: [https://sci- hub.ac/http://psycnet.apa.org/?&fa=main.doiLandi...](https://sci- hub.ac/http://psycnet.apa.org/?&fa=main.doiLanding&doi=10.1037/xge0000314)

</comment><comment><USER34> I apologize for my ignorance, but am I the only one who consider this study a total bullshit?

<comment><USER35> No need to apologize and no you aren't.

</comment></comment><comment><USER36> I recently watched the scifi film Arrival and it suggests that language can not only allow you to experience time differently, but to [1] (spoiler).

I wonder if there's any truth in what it suggests, or if its just scifi mumbo jumbo.

[1] " _see_ " the future.

<comment><USER37> If my wife tells me she ordered pizza for dinner, that use of language lets me "see" an hour into the future when a delivery person will arrive with a couple flat boxes and a plastic bag holding a soda bottle.

Nothing "mumbo jumbo" about it.

<comment><USER38> And other times you can "see" w/o finding anything.

In Brazil, when you were supposed to meet a friend at a certain time and they aren't there, you call/text them and ask where they are. They'll usually say: "já estou saindo" (I'm leaving already [from their house]), but according to the cultural norms, this actually often means "I haven't left yet and I'm getting ready, or thinking about getting ready".

Likewise, if you're out and about, and pass by some acquaintances, you make quick chit-chat to be nice and then make plans to get together next weekend. Both parties generally know this will not happen, and it's only being said for appearances.

This leads to a joke I like to imagine where situation 2 leads to situation 1. That is, "let's meet up next weekend!" and the response, "Ok, I'm leaving my house already". Everyone knows it's BS but they say it anyways.

</comment></comment></comment><comment><USER39> Would love to access the journal publication, but can't figure out how to get to it.

<comment><USER40> Just stick the DOI (i.e. 10.1037/xge0000314) into Sci-Hub.

If you feel that this is morally reprehensible, you might also be able to find it from your nearest university library.

<comment><USER39> What I find morally reprehensible is paywalling research that was taxpayer funded - I didn't know about this approach, so thank you several times over for mentioning it!

</comment></comment></comment><comment><USER41> I would suggest that the study reinforces that bilingual & polyglots naturalise other ways of thinking, or contexts for thinking, and that is for the brain, what habitualised exercise is for the body.

</comment><comment><USER42> Our language alters how we _reason_ with reality because words are the smallest unit of reason. Reason is not experience. However, we do experience our reasoning, and we also act upon it.

</comment><comment><USER43> Different cultures can learn good things from another and adopt it. Got bilingual kids in the languages the article describes.

</comment><comment><USER44> Anybody know the sample size? At this point I'm pretty skeptical of "amazing" behavioral psychology finds.

</comment><comment><USER11> Yeah well, if you become fluent in a particular alien language (Heptapod B) you can remember the future. Ted Chiang was onto something!

</comment><comment><USER45> The Time Paradox by Philip Zimbardo and John Boyd explores different time perspectives and how the affect our lives.

6 min TED talk that covers some of the ideas in the book [https://www.ted.com/talks/philip_zimbardo_prescribes_a_healt...](https://www.ted.com/talks/philip_zimbardo_prescribes_a_healthy_take_on_time)

</comment><comment><USER46> Humans are not very good at telling time and since their observations are subjective we can dismiss such experiments as anecdotal.

</comment><comment><USER47> I don't know what the standards of research in experimental psychology are, but this term project paper ended up a bit contrived. We took some superficial vocabulary characteristics of two languages (of which native speakers probably aren't even mindful) and somehow managed to distort this into a relativistic theory of language-based time perception that manages to prove that bilingual speakers have Neo-like abilities to transcend time, almost moving into 'What the bleep do we know' territory.

<comment><USER48> The purpose of the term project paper is not to produce truthful research, but for you to practice how to do it. And you wasted that opportunity.</comment></comment>


Sum Types Are Coming (2015) - <AUTHOR> https://chadaustin.me/2015/07/sum-types/ <comment><USER2> Once you get the hang of algebraic data types (ADTs), definitely check out generalized ADTs (GADTs). They reduce the amount of code required to express a solution, make the type system do a ton of work for you to prevent bugs from compiling, and make it easier to embed domain-specific languages in your code. A lot of the GADT tutorials out there are a little abstract for my taste and I wish there were more examples with tangible applications, but this one is decent:

[http://joeyh.name/blog/entry/making_propellor_safer_with_GAD...](http://joeyh.name/blog/entry/making_propellor_safer_with_GADTs_and_type_families/)

<comment><USER3> Why do they reduce the amount of code?

They add the ability for constructors to carry constraints, which aids expressivity in some cases.

But the majority of GADT uses purely add safety. Can use ordinary ADT without a type-variable that is correlated with the data constructor, and crash at runtime if the constructors don't match.

<comment><USER4> > Why do they reduce the amount of code? [...] crash at runtime if the > constructors don't match.

You answered yourself: If you cannot have these runtime type mismatches, you don't need to write the corresponding bookkeeping and checking code.

<comment><USER3> You don't have to write it - you just have to avoid -Wall :-)

</comment></comment></comment></comment><comment><USER5> The last couple of years I've been doing a lot of exploring different languages and language features. Sum types are one of the few features I've come across that seem to have the potential for large, practical benefit. Not only do you get the potential to eliminate null from a language with Option or Maybe types, but many cases where you might use multiple classes and files to express some hierarchy, can be replaced with just a few lines of code that is so easy to read you can even show it directly to the non programmers working on the project, to work through the definition together.

This especially happens nicely when the syntax is built into the language in a succinct way as in F# / OCaml (possibly others as well!)

<comment><USER6> It's also a convenient way to implement "value-based" state machines (where the entire machine is a single type with a value for each state, as opposed to type-based where each state is implemented as a different — and possibly completely incompatible — static state).

<comment><USER7> +1. They are a huge help for managing things like connection state. You can create powerful, statically-enforced invariants, like that a lifetime of a socket is 1:1 with a state of your state machine.

</comment></comment></comment><comment><USER8> Note that TypeScript and Flow have implemented sum types since this post was published.

<comment><USER9> No, they haven't. Union types and sum types are semantically very different from each other.

<comment><USER10> How do they differ?

<comment><USER11> The Union of Int and Int is exactly Int; the Sum is not.

The union of two types contains all values that are in either component type. The sum of them contains all of the values of the first type, each one associated with a tag like "I came from the left side" plus all of the elements from the second type with a similar tag.

The Union of Bool and Bool has 2 values, the Sum has 4.

If we define Maybe[A] to be the process of unioning on "null" to the values of A then Maybe[Maybe[A]] = Maybe[A]. If it's defined with a Sum then that equation doesn't hold.

</comment></comment></comment></comment><comment><USER12> Sum types are one of the best things, as they empower very good `match` style conditionals.

<comment><USER13> I can attest to this. I've just done a project in F# -- my first experience using a statically typed functional language beyond messing around in a REPL -- and the expressive power of this combination is intoxicating. I may have gone overboard; I found it hard to write procedural code in F#, so I split up my procedures into steps, with a type to model each step and a sum type to model the whole procedure. Coming from C / Python, where I was used to procedural code mostly working most of the time and then failing in hilarious ways, this was a revelation. A language where I can make the compiler check my procedural logic for me! Liberating!

<comment><USER14> Does f# have a good repl?

What ml style language has the closest thing approaching a lisp style repl?

<comment><USER4> Not saying it's the closest to what you have in mind, but you could look at the Emacs Tuareg mode for OCaml. Here is a reference card: [http://www.ocamlpro.com/files/tuareg- mode.pdf](http://www.ocamlpro.com/files/tuareg-mode.pdf)

If you are a SLIME fan, you might notice that some of the key bindings to interact with the toplevel (the OCaml word for "REPL") are identical in Tuareg.

That said, although this will sound tongue-in-cheek: Having used Isabelle and Coq with their interactive editors, I find their approach better than a REPL. In these systems, you execute code directly from your source file, as opposed to (conceptually) sending snippets of code to a REPL. There is no concept of code you have written in the source (or the REPL) which is not synced up with the state of the REPL (or the source code, respectively). I wish other languages had modes like this. There seems to be one for Prolog, but I've never used it and don't know how well it works in practice: [https://www.metalevel.at/ediprolog/](https://www.metalevel.at/ediprolog/)

</comment></comment></comment></comment><comment><USER15> Hopefully flow typing will be next. It's a really cool idea and I'm surprised it hasn't caught on more.

[https://en.wikipedia.org/wiki/Flow- sensitive_typing](https://en.wikipedia.org/wiki/Flow-sensitive_typing)

<comment><USER16> One of my favourite features of Flow is the '*' type and having Flow handle the given type based on control flow via "if" checks. You can achieve it somewhat in TypeScript too, IIRC. Neither are quite as powerful as I would like, but then what I would like is basically magic!

</comment></comment><comment><USER17> Are they really coming? When I was a student, I have encountered them the first time in Ada83 (discriminant records) in 1990, then in gofer (a variant of Haskell developed at Oxford) in 1992, then in Caml light (the ancestor of OCaml) the same year.

<comment><USER18> I think maybe "coming to the mainstream" fits better. I too saw it in Ada in school, and of course Haskell and friends have had them for ages.

There does seem to be recent trend of popular, highly visible languages that are adding the feature though. I think the biggest thing though is really that the pattern matching syntax that makes them so easy to use is becoming more common.

You can have Sum types without pattern matching, and vice versa, but it seems to be much more common now to expect any new language to include pattern matching.

</comment></comment><comment><USER19> One thing I really need is getting at "the type field". This is useful information by itself, and I want it most of the time - but I think in Haskell it's not possible to get at it without manually defining a "type type" and a function that computes that type from a given sum-typed data.

I don't think that lambdas/closures have such a problem in most programming languages. It's still unclear how to handle function pointers for lambdas/closures, but it should be a lot easier to make a lambda into a real function than changing a datatype definition when it's already used across the codebase.

So, I think sum types are really another one of those ideas which may prevent some bugs sometimes, but in the end are not generally super useful, and are just a little too clever and end up causing a more work than they save. At least unless there's a well-defined representation from which we can extract the type information, in which case I'd probably be happy to use them.

<comment><USER4> Could you give an example in a (possibly hypothetical) programming language of your choice of what you mean by "the type field", and what you would do with it? Maybe we could point you to something that does what you want.

Though I do wonder if reflection on type information (at runtime?) would be useful and easy for you if you find basic algebraic data types "a little too clever" and "causing more work than they save".

<comment><USER19> Regarding the type field, look for "enum EventType type;" in the article. (In practice I would not use "enum EventType", but simply "int" \- but anyway).

What I would do with it? Like the result of (x+y), or any type of data, I can use it for whatever I need. I might simply want to count the number of occurences of each "type". Often I'm simply not interested in the data besides the "type", and in these cases I find that case-matching is a lot of boilerplate. And it doesn't reify the "type" to authoritative runtime values. Which, as you say, might be done with reification support from the language, but I don't want to bother with that -- and it would not allow me to choose the possible values of the type field, which might be a requirement if the options are defined somewhere else.

<comment><USER4> > Regarding the type field, look for "enum EventType type;" in the article.

OK. If I understand correctly, you want to use that field in other contexts than doing a switch on it, whereas in Haskell the usual way of consuming the type tag is to do such a switch, as in the article's example:

        case event of
            ClickEvent x y -> <do click stuff>
            PaintEvent color -> <do paint stuff>
            // there are no other possible cases, so no default case needed

> For example, I could separate a large array of sum-type data into separate > arrays, and also process them separately.

Sure, but you can do that with a case expression as above. Here is a complete example:

        data Event = ClickEvent Int Int | PaintEvent Int

        -- separate a list of Events into two lists, the first holding the payloads
        -- of the click events, the other the payloads of the paint events
        separate :: [Event] -> ([(Int, Int)], [Int])
        separate [] = ([], [])
        separate (event : events) =
            case event of
                ClickEvent x y -> ((x, y) : clicks, colors)
                PaintEvent color -> (clicks, color : colors)
            where
                (clicks, colors) = separate events

        example = [ClickEvent 1 2, PaintEvent 42, ClickEvent 3 4, PaintEvent 23]

Running it:

        > separate example
        ([(1,2),(3,4)],[42,23])

You can now go ahead and process the list [(1,2),(3,4)] separately from [42,23].

(Depending on the exact specification and performance requirements, the code might be written a bit differently in the real world.)

EDIT: Ah, you edited your post while I was writing. Oh well. Regarding reifying constructors as integers or whatever, yes, you might have to write a two-line function to do that.

<comment><USER19> Yep, sorry for the edit. I did the arrays example but then noticed it was not really an answer to your question, since it can be done with sum types in almost the same way.

</comment></comment></comment></comment></comment><comment> s-kim Hi everyone, similar to the link, I wrote a tech memo about an algebraic data type to share what I have learned while studying the data type.

[https://kstreee.github.io/techmemo/algebraic.pdf](https://kstreee.github.io/techmemo/algebraic.pdf)

</comment><comment><USER20> For Python (as a library, not a core language construct):

[https://github.com/radix/sumtypes/](https://github.com/radix/sumtypes/)

(Same year - 2015 - as the original post ;)

<comment><USER21> If you're looking for a simple sum type without associated value, the standard library's _enum_ works quite well: [https://docs.python.org/3/library/enum.html](https://docs.python.org/3/library/enum.html)

</comment></comment><comment><USER22> Since this article was written c++17 has added std::variant and things like std:any. But his complaint about c++ matching being verbose is really AI complaint that c++ typically doesn't have a first class type system (unless rtti is used, and even then you can't create new types at runtime). This lack is either a limitation or benefit depending on your objectives for the program you are developing.

There isn't a One True Approach; I do all my work in Common Lisp or C++ and although both are multi-paradigm languages they aren't substitutable for each other.

</comment><comment><USER23> What is the difference between these 'sum types' and Swifts enum type?

Also I think the name 'sum type' is bad. Nothing gets added or summed up, just combined and selectively chosen. For this reason I find supercharging 'enum', like Swift does, a more logical solution.

<comment><USER24> Swift enums are sum types.

Various languages use different keywords to access the same concept:

\- Rust: 'enum'

\- Swift: 'enum'

\- Haskell: 'data'

\- F#: 'type'

\- Ocaml: 'type'

 _> Also I think the name 'sum type' is bad. Nothing gets added or summed up, just combined and selectively chosen. For this reason I find supercharging 'enum', like Swift does, a more logical solution. _

They're the same solution...

In any case, the name sum comes from viewing types "algebraically" as the article discusses. Doing addition of types with a sum type has a lot of similar properties to doing addition of numbers, and similarly doing multiplication of types with a product type (tuple, struct or class, in Swift) has a lot of similar properties to doing multiplication of numbers.

<comment><USER25> why would you want to view a programming language algebraically?

<comment><USER26> It lets you reuse your existing knowledge about algebra to transform programs. For example if you have a data type that has two different cases (= sum) each of which has a bunch of fields (= factors in a product) some of which are shared (= common factors in a sum of products) then you can literally factor them out, just like you can factor A * B * C + A * D * C into A * (B + D) * C.

<comment><USER27> Conjunction and disjunction are more apt anologies that have the same properties. There is also no division types while subtraction is used very rarely.

<comment><USER28> I didn't think to call it that at the time, but I think that I came across a division type in react-redux the other day: [https://github.com/DefinitelyTyped/DefinitelyTyped/blob/8f8f...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/8f8f6c439296ade0ab205751a72dfd626dd73364/types/react- redux/index.d.ts#L50)

Playing with that a little, if adding a property to an interface is a product, eg:

        interface Foo {
            foo: string;
            bar: number;
        }

where Foo is a product of string and number, then removing a property from an interface is division:

        type Diff<T extends string, U extends string> = ({ [P in T]: P } & { [P in U]: never } & { [x: string]: never })[T];
        type Omit<T, K extends keyof T> = Pick<T, Diff<keyof T, K>>;

        interface Foo {
            foo: string;
            bar: number;
        }

        interface Bar {
            bar: number;
        }

        type Out = Omit<Foo, keyof Bar>;

the output type Out is equivalent to:

        interface Out {
            foo: string;
        }

or phrasing it another way:

        Out = Foo / Bar = (string * number) / number = string

I can't think what a 1/number type would be used for other than to remove number from a a T*number, in other words I can't think what a rational type would be used for unless it simplified down to a "normal" type. But I wouldn't like to bet that there's no other use :-)

<comment><USER27> What is the set theory intuition of that? If product is intersection, division is...?

<comment><USER26> Product is _not_ intersection. The equivalent to product types in set theory is the Cartesian product ( [https://en.wikipedia.org/wiki/Cartesian_product](https://en.wikipedia.org/wiki/Cartesian_product) ).

The closest thing to a division would be a quotient set ( [https://en.wikipedia.org/wiki/Quotient_set](https://en.wikipedia.org/wiki/Quotient_set) ), but there you're dividing by an equivalence relation. It is however possible to define an equivalence that undoes set multiplication: (A × B)/~ ≅ A if (a₁, b₁) ~ (a₂, b₂) holds iff a₁ = a₂, ignoring the other component.

<comment><USER27> That isn't how product (intersection) types work in typescript. If we are talking about typescript, of course.

<comment><USER26> Product and intersection are different things in TypeScript, as well. The product of string and number would be a type like { first: string; second: number }, which combines two different values into one; whereas the intersection string & number is the type of all values that are both strings and numbers.

<comment><USER27> Right, but if we are going to call union types as sum types, why aren't interesection types called as product types? Anyways, this is why the whole sum type thing breaks down and Union is more apt, since we can describe A|B and A&B using the same terminology family.

<comment><USER26> A | B and A + B are only "the same" (but not identical) if A and B are disjoint (i.e. there is no value that is in both types). That's why + is also called _disjoint union_. You can simulate + with | by introducing artificial tags to make A and B disjoint, but in the end they are different operations. TypeScript doesn't really have first-class support for sum types because it needs to remain interoperable with JavaScript, so this simulation is the closest you are going to get.

<comment><USER27> I agree, so it really isn't an example of the popularity of sum typing. Typescript does have support for user-supplied tagging, so you can also approximate it to some extent.

<comment><USER28> Yea, support isn't first class. When I was learning to use union types in TypeScript, initially I wrote custom type guards to distinguish them, using any property that was unique to a particular constituent type to differentiate them.

Nowadays I consider that a mistake, and all unions have a discriminator property, and there is no need for custom type guards (exceptions would be when writing .d.ts files for JS that uses them untagged, that sort of thing) since it makes the code much more explicit.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Of course there's nothing new under the sun, this is one of the features of Algol68 (1968) that Wirth discarded when he made Pascal

They're not coming, they've been and gone, probably a couple of times

<comment><USER4> All I know about Algol 68 is what I just gleaned from Wikipedia, but there I got the impression that what it had was a limited form. Namely, the type indexed things mentioned in the featured article as present in C++ and D, where you don't have tags and thus cannot usefully distinguish different variants with the same underlying type.

<comment><USER29> nope, A68 unions had hidden tags (strictly speaking the spec didn't say they had tags but it was the only obvious implementation) it did have a case statement to switch on the tags and extract the values as described above

</comment></comment></comment><comment><USER30> I prever the c++ name variant, super usefull and new addition to c++17

<comment><USER31> Also, std::optional, which is analogous to Maybe.

Of course, both have been in boost for some time now. C++ so far has been doing this at the library level. But it remains to be seen if they will make their way into actual interfaces, for example in standard algorithms.

</comment></comment><comment><USER32> sum types are are not all that different from subtyping+inheritance, it's simply the other side of the expression problem.

<comment><USER33> Unlike subtyping, sum types are bounded - you can't add new variants without modifying the originally-defined type.

That's a huge difference in terms of code architecture - it enables things like _exhaustive_ pattern matching, and allows the programmer to enforce stronger invariants in the code.

<comment><USER34> Subtyping can be closed, too (see Scala's sealed classes, for example) and algebraic data types can be open (see OCaml's extensible variants [1] or polymorphic variants [2]).

This is simply a distinction between closed and open sum types.

[1] [https://caml.inria.fr/pub/docs/manual- ocaml/extn.html#s%3Aex...](https://caml.inria.fr/pub/docs/manual- ocaml/extn.html#s%3Aextensible-variants)

[2] [http://caml.inria.fr/pub/docs/manual- ocaml-400/manual006.htm...](http://caml.inria.fr/pub/docs/manual- ocaml-400/manual006.html#toc36)

</comment></comment></comment><comment><USER35> Do we really need a new name for this? It's basically "safe C-style unions", but pretty much everything in C is unsafe, so you might as well just call it "unions".

<comment><USER36> This is not a new name... in the theory of algebraic data types there is a model of what it means to add and multiply types, resulting in "sum" and "product" types. I am not 100% sure but I believe these terms have been used since the early 70s.

The term "union" as used in C is highly related but not quite the same. If you add a tag to the union (and so have a "tagged union", often represented in C as a struct with an enum and a union) then you are equivalent in an information sense (but the usage is still different, as a C union says something very specific about how memory is used).

<comment><USER29> as mentioned elsewhere 'union' originally came from Algol68 where (eventually) they were implemented exactly as described in the article

</comment></comment></comment><comment><USER37> I sure hope so

<comment><USER12> same <3</comment></comment>


From AI to Twitter, Wall Street Outraces Regulators - <AUTHOR> http://www.thefiscaltimes.com/Articles/2011/03/14/Wall-Street-Outraces-Regulators.aspx

<comment><USER2> Will there ever be a time when the government -isn't- outpaced by tech. innovation?</comment>


Ask HN: Amex Files Patent for "Transferring Value via a Social Network" - <AUTHOR> http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20140006297&OS=20140006297&RS=20140006297 It sounds like Amex is trying to file a patent for our service (and many others). What should we do?
US Patent 20140006297 filed on July 2, 2013:
An integrated, end-to-end, automated system that enables a first social networking user to seamlessly transfer value to a second social networking user, even if the second user is not registered with the money transfer service from which the first user initiates the transfer...
Our service:
PikaPay.com
https://www.PikaPay.com/
Send Bitcoins to anyone on Twitter, as easy as a Tweet!
PikaPay is a Bitcoin wallet integrated with the Twitter API and is one of the fastest and easiest ways to use Bitcoin. Just like in the Amex patent, with PikaPay the recipient doesn't need to have a PikaPay account to receive bitcoins.
We were the first to start sending bitcoins on Twitter back in 2011. But we're sure that scores of other companies have been doing "value transfer via social networks" even earlier.
Do we have to take that Amex patent application seriously in any way, and is there anything specific we should do?
We Tweeted AmEx about it recently:
https://twitter.com/PikaPay/status/420231417117683713 <comment><AUTHOR> It sounds like Amex is trying to file a patent for our service (and many others). What does HN think we should do?

US Patent 20140006297 filed on July 2, 2013 (from link above):

An integrated, end-to-end, automated system that enables a first social networking user to seamlessly transfer value to a second social networking user, even if the second user is not registered with the money transfer service from which the first user initiates the transfer...

Our service:

PikaPay.com : [https://www.PikaPay.com/](https://www.PikaPay.com/)

Send Bitcoins to anyone on Twitter, as easy as a Tweet!

PikaPay is a Bitcoin wallet integrated with the Twitter API and is one of the fastest and easiest ways to use Bitcoin. Just like in the Amex patent, with PikaPay the recipient doesn't need to have a PikaPay account to receive bitcoins.

We were the first to start sending bitcoins on Twitter back in 2011. But we're sure that scores of other companies have been doing "value transfer via social networks" even earlier.

Do we have to take the Amex patent application seriously in any way, and is there anything specific we should do?

We Tweeted AmEx about it recently:

[https://twitter.com/PikaPay/status/420231417117683713](https://twitter.com/PikaPay/status/420231417117683713)

We're curious about what others here think about the patent and how they would approach this issue.</comment>


How to Be a More Productive Web Developer - <AUTHOR> http://sixrevisions.com/project-management/ways-more-productive-web-developer/

<comment><USER2> I would add either using the noprocrast option on this site, or a hosts entry pointing news.ycombinator.com to 127.0.0.1 for a huge increase in productivity.</comment>


Ultimate Setup for Your Next Python Project - <AUTHOR> https://towardsdatascience.com/ultimate-setup-for-your-next-python-project-179bda8a7c2c <comment><USER2> A cookiecutter for this was a cherry in the top of a cake, but... Thank you!!!

</comment><comment><USER3> Thank you. Added to my favorites</comment>


Why we're suing the CIA - <AUTHOR> https://www.muckrock.com/news/archives/2014/jun/11/why-were-suing-cia/ <comment><USER2> As bad as governmental abuses can be in the U.S. I find it somewhat comforting that suing the CIA doesn't mean some people are going to start disappearing. I'm guessing not too many Russians sued the KGB.

<comment><USER3> It's a shame you would compare a Developed country, supposedly one of the best, with one that's knows to be not so good.

It's like comparing your sports team to one that consistently finishes low on the ladder - your team will always look good, even when they are far from the top.

If you want a comparison that will lead to improvement, compare your country to those known to have excellent human rights and freedom of information track records.

<comment><USER4> Let's just go with Norway, Sweden, Finland, and Denmark for now, with New Zealand and Singapore thrown in to prove that you don't have to be Scandinavian to have an uncorrupted government.

<comment><USER5> Sweden? The country trying to illegally force EU countries to extradite Julian Assange in clear violation of EU law?[1]

That Sweden?

[1][http://cjicl.org.uk/2012/06/20/assange-v-swedish- prosecution...](http://cjicl.org.uk/2012/06/20/assange-v-swedish-prosecution- authority-the-misapplication-of-european-and-international-law-by-the-uk- supreme-court-part-i-2/)

I assume you are ignoring the corruption detailed in

[http://www.business-anti-corruption.com/media/3831417/TI- Sve...](http://www.business-anti-corruption.com/media/3831417/TI- Sverige_ENIS_studie-2.pdf)

<comment><USER4> I do not claim that those governments are not in any way corrupt. They are simply the least corrupt of an inherently corruptible tradition.

The point is that we should be following our hopes rather than fleeing from our fears. Comparing yourself to the worst of your peers and patting yourself on the back because you are still somewhat better is blinding yourself to the absolutely unacceptable backsliding that has been occurring. Even comparing yourself to the best of your peers and dreaming about surpassing them is not enough. The ultimate, unattainable goal is zero corruption and perfect transparency. Effort required increases asymptotically as we approach that limit.

So it would seem that the only way to avoid having corruption in your government is to not have one at all.

<comment><USER6> We could have made the participatory government 20 years ago.

I always explain it like this (try to):

Our ancestors did not have Internet, direct participation was not possible. We therefore cant expect those ancestors of ours to have seriously considered it - at any stage. Arguably, before the Internet, everyone did his best to participate as much as they could. The new ingredient our generation introduced is for voters not to have influence on par with the technical possibilities.

If we would be overly modest we could allow that single vote to be changed when the voter wants to change it. If the voter cant change his vote the election program is not legally binding. One can say whatever he likes to get elected and enjoy 4 whole years without any consequences.

Technically we should be participating in the debate about specific issues at hand. Our officials would have little to do beyond the organization of that information (a feat easily automated) If we can do social networks and we can do flash trading then we need very little beyond a tech team and a few symbolic figure heads to make a kick ass democracy.

We can do considerably more than vote 1 time, ideas from citizens are a type of resource, value waiting to be extracted. Extraction will help it grow faster. Clearly we are missing out on incalculable riches, just sitting there, expiring while waiting for exploitation.

<comment><USER4> It would be more accurate to say that direct participation was not scalable past a certain population size.

But now, well... Nintendo even made a free Wii amusement called "Everybody Votes Channel". If people are willing to waste time voting on silly things just to see what other people in their tribe and around the world selected, they can certainly vote on things that actually matter to them, like taxes and laws.

The difficult problem nowadays is not the technical ability to get everyone participating, but how to avoid the pitfalls of democracy, such as an arbitrary majority tyrannizing an arbitrary minority, or a focused minority advancing a specific agenda over a relatively apathetic majority.

There would almost have to be a submission petition with a certain number of supporters, an initial 50% majority of those who care to vote to trigger spending development resources on the issue, then a funding round, where supporters have to supply the required budget directly, and finally a ratification round, where a supermajority, perhaps 67% of all possible voters, where non-voters automatically vote to reject, determines whether to proceed to implementation or not.

But that's all irrelevant detail when it is likely that those who currently hold power would use it to prevent a new system from taking it away from them. The status quo likes where it stands now. The system is ripe for disruption, but it is also quite good at retaliating against existential threats.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> MuckRock and the Beacon Reader are also working on uncovering law enforcement across the country using "Stingray" rouge cell tower equipment: [http://www.beaconreader.com/projects/the-spy-in-your- pocket](http://www.beaconreader.com/projects/the-spy-in-your-pocket)

Please chip in $5 if you can towards their goal.

</comment><comment><USER8> Recursive FOIA requests. Very neat :) Breadth first or depth first is going to be their main problem. The plus for the government is that if they lose a document they now have an off-site backup. Presumably the CIA is not playing ball because they have their own backups.

What a fantastic project.

<comment><USER9> In Canada, similar requests had partially liberated the information contained in the Coordination of Access to Information Requests System that the Federal Government used to centrally manage ATI requests (our FOIA), so that people could do this kind of recursive research. The Conservatives disbanded the database in 2008 in order to remove this resource from being the target of ATI requests, and make it harder to get information to the public.

</comment></comment><comment><USER10> Love these guys! They're doing a Beacon crowdfunding project as we speak - help em' out! [http://www.beaconreader.com/projects/the-spy-in-your- pocket](http://www.beaconreader.com/projects/the-spy-in-your-pocket)

</comment><comment><USER11> Yeah MuckRock! Get 'em!

I use MuckRock to FOIA the CIA quite often, and they are probably the third- worst agency to deal with (behind the NSA and the US State Department). They don't even accept FOIA requests via email!

Hopefully, this will lubricate them a little bit.

</comment><comment><USER12> I really appreciate these guys following through with this. I've benefited from the information they have set free. That we have to pull it kicking and screaming out of the bureaucracies is sad.

<comment><USER13> If it's not very private matter, could you tell us how you benefited from the information? I'm really curious.

</comment></comment><comment><USER14> Nice try, but likely nothing will happen. Even if a judge in a moment of insanity ruled in your favor, the CIA will simply say it's a national secret or whatever and nothing will change.

<comment><USER15> "Don't bother trying" \-- great advice.

<comment><USER16> "Don't waste your time on this approach" isn't defeatist, it's saying you'll get a better outcome with another approach. There are lots of worthless activities that will change nothing, and a very few that are effective. It's important to think about how to invest. That said.. It's more helpful to hear alternate ideas than just "this won't work".

<comment><USER17> I see your point but I think it's still fair comment when the parent isn't suggesting a better approach, they're just saying "don't use this one".

</comment></comment></comment></comment><comment><USER18> yes, you should sue the cia.

</comment><comment><USER19> "Who's right doesn't matter, who has the power does" \--Thucydides</comment>


How to Acquire Users - <AUTHOR> http://brackin.quora.com/How-to-Acquire-Users

<comment><USER2> So, Quora blogs show up in HN as coming from a (quora.com) domain with no subdomain (like x.tumblr.com)?

That's going to get annoying very fast.</comment>


Ask HN: Why is there no Snapchat API? - <AUTHOR> <comment><USER2> There is a Snapchat API. The Snapchat client uses it. Several years ago, many, many third-party apps also used it, resulting in the release of huge numbers of pictures that users thought were private[1].

Since then, Snapchat took measures to prevent the use of its API by third- party clients[2].

Besides issues like that, Snapchat has no incentive to provide an API. They use their official client to show ads and therefore make money.

1\. [https://www.forbes.com/sites/quora/2014/01/03/should-you- wor...](https://www.forbes.com/sites/quora/2014/01/03/should-you-worry-about- the-snapchat-data-leak/)

2\. [https://pando.com/2014/12/22/snapchat-cracks-down-on- third-p...](https://pando.com/2014/12/22/snapchat-cracks-down-on-third-party- apps-to-bolster-user-security/)

<comment><USER3> You could probably still MITM your phone to see their private API calls

<comment><USER4> Even with certificate pinning? Maybe if you can patch the app.

<comment><USER5> You can also just hook the process in the real time to bypass it.

Going out on a limb here, they most likely HMAC sign their requests using a secret key embedded in the application, so you'd have to reverse that too.

</comment></comment></comment></comment><comment><USER6> They aren't interested in yet another way to not profit.

</comment><comment><USER7> What incentive would there be to offer one? Snapchat has in-app adverts, an API would offer no such profits.</comment>


How NOT to redact a PDF – Nuclear submarine secrets spilled - <AUTHOR> http://nakedsecurity.sophos.com/2011/04/18/how-not-to-redact-a-pdf-nuclear-submarine-secrets-spilled/

<comment><USER2> Adobe blogged the correct way to redact a PDF after similar spills in 2009 (video): [http://blogs.adobe.com/security/2009/12/how_to_properly_reda...](http://blogs.adobe.com/security/2009/12/how_to_properly_redact_pdf_fil.html)

Here's the step-by-step version from the Acrobat help page: [http://help.adobe.com/en_US/Acrobat/9.0/Professional/WS5E28D...](http://help.adobe.com/en_US/Acrobat/9.0/Professional/WS5E28D332-9FF7-4569-AFAD-79AD60092D4D.w.html)</comment>


Architecture of The Internet Archive [2008] - <AUTHOR> http://www.cs.huji.ac.il/~kirk/IAArchitecture.pdf

<comment><USER2> This is too old to be very useful. Here is another old link about their infrastructure:

<http://archive.org/web/hardware.php>

Since then they've gone through several iterations of improvements on their infrastructure, drives have gotten _much_ larger and the object they're trying to archive has grown enormously as well.

Funding drive thread from a short while ago:

<http://news.ycombinator.com/item?id=4901148>

An update on their current infrastructure might get a lot of eyeballs in time for their 31st of Dec. deadline with respect to the 3:1 matching.

<comment><AUTHOR> I thought there architecture was pretty interesting for 2008 and the amount of data trying to be indexed/stored. It has some pretty traditional concepts that seem to work well along with a few cool tweeks like udp broadcast for object discovery.</comment></comment>


The Early History of Smalltalk (1993) - <AUTHOR> http://worrydream.com/EarlyHistoryOfSmalltalk/

<comment><USER2> > The mental image was one of separate computers sending requests to other > computers that had to be accepted and understood by the receivers before > anything could happen. In today's terms every object would be a server > offering services whose deployment and discretion depended entirely on the > server's notion of relationship with the server.

1993 called and wants its micro-services. That is great. At least it seems like he is describing Go's channels, Rust's tasks, and most of all Erlang's processes.

It is interesting, perhaps it is a reflection on how some of these concepts are abstract that anything can be read into it, but it seems that the initial design and motivation behind OO has been perverted by C++ and Java.

I started with C++ and Java in college. To me OO was inheritance, composition, and polymorphism, and so on. Years later, when distributed and scalable computing is talked about other languages and platforms seems more OO than the classic OO.

And finally one more excerpt:

>

\---

      1. Everything is an object

      2. Objects communicate by sending and receiving messages (in terms of objects) Objects have their own memory (in terms of objects)

      3. Every object is an instance of a class (which must be an object) The class holds the shared behavior for its instances (in the form of objects in a program list)

\---

Pretty funny. Replace 'object' with 'process' and you have Erlang, the last language you'd call OO : 1) everything is a process 2) processes sending messages to each other. Each process has an isolated heap (won memory). 3) Functions in modules hold the shared behavior of many possible process instances spawn from it.

<comment><USER3> > _1993 called and wants its micro-services. That is great. At least it seems > like he is describing Go 's channels, Rust's tasks, and most of all Erlang's > processes._

Hmm, don't know about the others, but Go's channels seem much much more primitive and bare than the description you quoted.

<comment><USER2> I meant coupled with a goroutine. But yeah also no isolation.

OS processes though with some IPC mechanism also fit the pattern. But that is not a language anymore as a standard library and OS API

</comment></comment></comment><comment><USER4> Glad to see someone posted this again. This is without a doubt one of the best papers I've ever read. Drives home that Alan Kay is truly brilliant.

</comment><comment><USER5> Here's a better one, with a github for corrections: [http://worrydream.com/EarlyHistoryOfSmalltalk/](http://worrydream.com/EarlyHistoryOfSmalltalk/)

<comment><USER6> Ok, we'll change to that (from [http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html](http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html)).

</comment></comment><comment><USER7> I want to enjoy reading this as much as it deserves to, but there are so many typos ;_;

Nevertheless, I shall persist and so should you.

<comment><USER8> Smalltlak?</comment></comment>


Show HN: Ranking mainstream News on Twitter in real-time, an experiment. - <AUTHOR>

http://newspo.st/dev-preview.html
I'd like to hear some feedback about this App I've been working on lately.
It's exactly what everyone tells you not to do: a "news app", but I strongly believe this one is different: News are ranked by real-time Twitter popularity, you can see what people says on Twitter about a specific topic and you can download full articles as well. I think personalization narrows the scope of articles you can come across, while sometimes it's good to read about stuff that matters to everyone. The first raw version of the app is now available on iTunes.
If you need further infos you can check the landing page at: http://newspo.st <comment><AUTHOR> Clickable: [http://newspo.st/dev-preview.html](http://newspo.st/dev- preview.html)

</comment><comment><USER2> That looks nice. Could you provide it as a web app instead?

<comment><AUTHOR> Not on the top of my list right now, but I could definitely consider it in the future.

</comment></comment><comment><USER3> where have you heard not to do a "news app"?

</comment><comment><USER4> Any web app?</comment>


LuaJit 2.0 is out - <AUTHOR> http://luajit.org/download.html <comment><USER2> HUGE congrats to Mike Pall. No amount of praise to him is enough.

Hopefully, sponsors will continue to donate to this project to keep Mike fully employed and ensure long-term commitment of this project.

I encourage sponsors to considered donating [1]

On a side note, I wish the Programming Language Shootout [2] would add back in LuaJIT to demonstrate just how fast LuaJIT is in comparison to other languages. It's just amazing.

[1] <http://luajit.org/sponsors.html>

[2] <http://shootout.alioth.debian.org/>

<comment><USER3> Are there any other current benchmarks around for LuaJIT vs for instance java?

<comment><USER4> <https://github.com/darius/superbench> is not a big fancy cross-language shootout, at all, but I tried a few little programs I actually cared about. LuaJIT 'won' in the sense that of the languages I tried it had the best combo of performance and pleasant productivity, informally. I didn't try to quantify the latter.

(Also, no Java because I wouldn't seriously consider it for hacking-for-fun.)

<comment><USER2> Where are the results of the benchmark?

<comment><USER4> You can run superopt/benchmark.sh on your machine. I'm away from home and the machine with the various languages installed.

</comment></comment></comment></comment></comment><comment><AUTHOR> I wish I could understand LuaJit completly. I think if there is any (reasonably sized) software I would like to completly understand its this one.

There is not only lots of good algorithms but also a lot of fantastic engineering. Things that you can not learn by reading papers.

Congrats Mike Pall. Now lets see if you can do the same for GC community that you did to the JIT community. Good Luck.

<comment><USER5> Yeah I agree it's a very interesting piece of software.

But do you understand the prequisites -- namely processor microarchitecture? I know that's why I don't understand it. I imagine if I did it might not be that hard to understand.

Most people's knowledge of the stack stops somewhere around C. C hasn't changed for 40 years. It's a portable assembly language, i.e. the common mental model is that each construct in C is a handful of assembly instructions on any processor. But to get LuaJIT-type performance you have to understand exactly how the CPU works, i.e. pipelining and reordering, internal caching algorithms, internal branch prediction algorithms, and maybe to some extent multicore, although I guess LuaJIT is single-threaded like Lua.

Mike Pall's mental model is for sure not C (since a lot of it isn't even written in C), but the lower level CPU architecture. And that has changed a lot in the last 10 years. I think even if you coded a lot of assembly language in the 80's it wouldn't necessarily translate to working on something like LuaJIT. My impression from skimming some online posts is that he has read hundreds of pages of Intel/ARM reference documentation from cover to cover, for multiple CPUs. I think there are a limited number of people with the patience to do that, since it's non-portable and changes relatively quickly.

Another problem is I think that the open source tools that are available don't work at the right level. Like when you are running profilers, they are helping you profile assembly code generated by a C compiler. The performance characteristics he's taking advantage of are at a lower level. I think you need CPU-specific performance counters and so forth, and there's a different way of getting those for each make/model. Are there even open source tools that allow you to get this information? I'd appreciate a pointer.

It's just a different level of abstraction than most programmers are working with. Not that many people are even writing "low level" C these days, e.g. something like redis. A lot of "application level" C code you see these days is old and/or not particularly fast.

I would be interested if anyone has any pointers for this style of code other than "read a bunch of CPU manuals". :)

<comment><USER6> I think that most sampling profilers like oprofile (<http://oprofile.sourceforge.net/news/>) or perf (<https://perf.wiki.kernel.org/index.php/Main_Page>) will give you CPU-level profiling and performance counters. The UI of those tools isn't super- friendly; if you're on OS X the "Instruments" app gives the same information with a far superior UI.

I have written a JIT that uses LuaJIT's dynamic assembly language engine DynASM (<http://luajit.org/dynasm.html>). DynASM is an incredibly piece of engineering, it lets you write really readable code for generating machine code at runtime, and is extremely small and low-overhead.

I keep meaning to write an article that demonstrates how to use LuaJIT for a small but interesting JIT. I just never quite get around to it. I always wish that I could use to implement the Universal Machine from ICFP 2008 (<http://www.boundvariable.org/task.shtml>), which is absolutely the most delightful problem ever, but as I recall it makes extensive use of self- modifying code which makes JIT-ting much more difficult and less effective.

<comment><AUTHOR> > I keep meaning to write an article that demonstrates how to use LuaJIT for a > small but interesting JIT. I just never quite get around to it.

Please do.

</comment></comment></comment></comment><comment><USER7> There have also been a few changes in the roadmap for LuaJIT, as announced here:

[http://www.freelists.org/post/luajit/LuaJIT- Roadmap-20122013...](http://www.freelists.org/post/luajit/LuaJIT- Roadmap-20122013-UPDATE)

</comment><comment><USER8> Changelog: <http://luajit.org/changes.html> (extremely detailed)

</comment><comment><USER9> What are people using LuaJit for in the wild?

Particularly interested in Android integration - has anyone used it for any projects? From my admittedly small experience using it, I love the language, and would really like to use it in some way practically.

<comment><USER10> I'm using it for <http://www.instahero.com/>. Not mobile development, but I love the speed and sandboxing features.

<comment><USER9> Thanks for the reply!

How are you using it? With a lua web framework, or more low level stuff?

edit: great looking site btw.

<comment><USER10> Thank you! I'm not developing the site in it, I'm using it for allowing the users to write their own analytics reports in an easy, fast and secure manner. It's just the bare LuaJIT interpreter with some simple libraries I'm developing for analyzing reports more efficiently.

<comment><USER9> Ah, kind of like webscript.io!

The sandboxing does seem to afford it a lot of cool use cases

</comment></comment></comment></comment></comment><comment><USER11> Something tells me there is an MC Hammer joke in here regarding being 2.0-Lua- Jit-To-Quit, but I'm not sure I can find the phrasing to excite the level of humor I was hoping for...

Oh well, congrats on the release anyway! :)

<comment><USER12> haha nice, this is like, one version only joke, once they hit 2.1, that wont fly

<comment><USER10> 2.1-Lua-Jit-To-Quit-.1

</comment></comment></comment><comment><USER13> Huge congrats to Mike Pall on the release. The man is a machine when it comes to this sort of thing.

</comment><comment><USER14> I understand that for LuaJIT 2.0, the whole VM has been rewritten. What's changed? What's new?

<comment><USER15> If you're referring to LuaJIT 1 vs 2, the big differences are that LuaJIT 2 has a trace-tree JIT, and interpreters for each platform written in assembly. The improvement in performance is significant: LuaJIT2's interpreter alone is faster than LuaJIT1's JIT.

It's hard to compare LuaJIT1 and 2, since LuaJIT2 is the most advanced JIT for a dynamically-typed language on the planet. The performance it can achieve with zero type annotations still blows me away.

<comment><USER16> Pedantry: it's actually not a trace-tree JIT. It doesn't treat traces as trees. See: <http://lambda-the-ultimate.org/node/3851#comment-57679>

<comment><AUTHOR> Yes. Thats a very importend point, its one of the majar diffrences between LuaJit and most other advanced trace jits.

Also everybody should read that thread, at least once a year.

</comment></comment></comment></comment><comment><USER17> I wonder if a kickstarter could convince him to look at a Ruby VM ;)

<comment><USER18> well, he does have plans until luajit3... maybe we can book him in advance? I'd still like a fast ruby in five years :D

<comment><USER19> May be someone should work on Ruby to Lua instead? Using Lua and LuaJIT as a underlying languages. Like Coffescript to Javascript.

That would be a lot faster then working on Ruby VM. And since Ruby 2.0's VM is still as slow as hell compared to LuaJIT

</comment></comment></comment><comment><USER20> Is possible to use this for build a language? (I wanna to create my own language, but hope for something easier than LLVM, java, do it from zero in C)

<comment><USER21> Yeah people are trying to port clojure on LuaJIT.. It is possible.

<comment><USER22> I got curious and looked into this. The relevant effort seems to be this, a new backend for the ClojureScript compiler which compiles to Lua instead of JavaScript:

<https://github.com/raph-amiard/clojurescript-lua>

<http://raph-amiard.github.com/ClojureScriptLua.html>

<comment><USER21> Actually they use clojurescript because, the compiler is already writern in clojure. They just need to bootstrap it to th VM.

</comment></comment></comment></comment><comment><USER23> I'd like to use Lua, partly to take advantage of LuaJIT and partly because it's an interesting language, but it drives me crazy that it lacks things like 'continue' and '+='. Maybe I should use MoonScript, but that completely discards Lua's aesthetics, which is hardly better.

<comment><USER24> Lua 5.2 added "goto", which basically solves the lack of "continue". LuaJIT supports it too.</comment></comment>