Parsing: The Solved Problem That Isn't (2011) - <AUTHOR> http://tratt.net/laurie/blog/entries/parsing_the_solved_problem_that_isnt <comment><USER2> It may also relevant to mention the language-theoretic security research program ("LANGSEC").

[http://langsec.org/](http://langsec.org/)

They've pointed out that the difficulty of parsing, and in a sense our overconfidence that we can just code up parsers for random languages and input formats when we need them, is a pretty pervasive source of security bugs.

A lot of those bugs can occur when you have two different parsers that have a different notion of what language they're supposed to recognize, so it's possible to construct an input whose meaning the two parsers disagree on. That can have pretty serious ramifications if, for example, the first parser is deciding whether a requested action is authorized and the second parser is carrying out the action!

I'm kind of sad about this because I love whipping up regular expressions to extract data even from things that regular expressions technically can't handle correctly. But there's a good argument to be made that this habit is playing with fire much of the time, at least in systems that will end up handling untrusted input. And the Shellshock bug is a recent example of the way that your intuitions about whether your software will "handle untrusted input" in some use case can go out of date.

<comment><USER3> See also this paper: [http://www.ieee- security.org/TC/SPW2014/papers/5103a198.PDF](http://www.ieee- security.org/TC/SPW2014/papers/5103a198.PDF). The authors implement a pdf file format parser and find bugs in pretty much all of the existing implementations. Basically pdf is a pretty shitty file format with several ill-defined corner cases. This is one of the reasons PDFs tend to be vectors for security breaches.

<comment><USER2> The lead author (Andreas Bogk) presented an earlier version of this work at the Chaos Communication Camp in 2011 ("Certified Programming With Dependent Types").

[http://events.ccc.de/camp/2011/Fahrplan/events/4426.en.html](http://events.ccc.de/camp/2011/Fahrplan/events/4426.en.html)

I went to that talk, and found it to be probably the most advanced and difficult math lecture I'd ever attended! (I was very grateful to see such mathematical sophistication brought to bear to protect PDF users, which is almost all of us.)

</comment></comment></comment><comment><USER4> This is probably a good place to ask; I've wanted to build a language myself -- whats the best place to begin learning about parsers and the like? About a decade ago I asked this question and was told to read the "Dragon book" but I was far too young and lacked experience. Now I really want to get stuck into something outside of my day-to-day web stuff.

<comment><USER3> Start here: [http://nathansuniversity.com/](http://nathansuniversity.com/). All the stuff in the dragon book is designed for limited memory and limited computing capability environments. There is no reason to worry about LL(k) parse table size or predict and follow sets when you don't have to. For most practical purposes you can get away with basic recursive descent or PEG parsers. The link I pointed you to starts with peg.js which is PEG parser generator in JavaScript.

If you get through PL101 then picking up the stuff in the dragon book or any other book on parsing and compiling technology will be much easier.

Another resource I like is "Compiler Design: Virtual Machines" ([http://smile.amazon.com/Compiler-Design-Machines-Reinhard- Wi...](http://smile.amazon.com/Compiler-Design-Machines-Reinhard- Wilhelm/dp/3642149081)). Still going through that one but it is very readable and if you go through PL101 then you'll have all the tools to implement the virtual machines described in that book. It is much easier to write a compiler to target machine code or some other language like C when you've built a few targets yourself and understand the trade-offs involved.

There's also [http://www.greatcodeclub.com/](http://www.greatcodeclub.com/). I think one of the projects is a simple virtual machine and another one is a compiler. Well worth the admission price if you're a beginner and want some help getting started.

Hanselman's rule about finiteness of keystrokes applies and I recently wrote some notes about budding PL enthusiasts: [http://www.scriptcrafty.com/tips- for-the-budding-pl-enthusia...](http://www.scriptcrafty.com/tips-for-the- budding-pl-enthusiast/).

<comment><USER4> You're absolutely brilliant. Thanks so much!

<comment><USER3> No problem. I think more programmers should know about this stuff so happy to help.

</comment></comment></comment></comment><comment><USER5> Jeffrey Kegler's work on Marpa is pretty exciting, but hasn't got much traction (maybe due to the implementation languages: Perl and Knuth's Literate Programming).

[https://metacpan.org/pod/Marpa::R2#A-simple- calculator](https://metacpan.org/pod/Marpa::R2#A-simple-calculator)

<comment><USER6> Yeah, Marpa is quite amazing—it inspired me to build nearley. It's probably more powerful than any other parser generator out there right now (and the fastest, because it has Leo optimizations and Aycock-Horsepool nullables). In fact, Kegler responded to this same article with [http://jeffreykegler.github.io/Ocean-of-Awareness- blog/indiv...](http://jeffreykegler.github.io/Ocean-of-Awareness- blog/individual/2012/08/the-solved-problem-that-isnt-is.html)

</comment></comment><comment><USER7> How exactly "PEGs are rather inexpressive"? Still the same BNF, with some nice bells and whistles added. As for the left recursion, it's not a big deal. You mostly need left recursion for the binary expressions, and they are much better served by a Pratt parsing (which is trivial to mix with Packrat anyway).

I moved to PEG+Pratt exclusively and never needed anything beyond that, for even craziest grammars imaginable.

<comment><USER8> One issue with PEG's (and other parsers) is that it doesn't address (unbounded) count fields (or bounded count fields in an elegant manner) or offsets. This means a pure PEG can't express e.g. PDF or ZIP files. To address this, we built a PEG-based parser generator with a few new features, Nail (paper at OSDI 14, github.com/jbangert/nail)

<comment><USER9> Another issue is that it uses at least the same memory as the the input. Not that I'm a PEG expert, but it also basically feels like a formalised recursive decent parser. Nothing wrong with that, but changing the grammar afterwards can have a rippling effect and require much more work than with a traditional LALR parser.

<comment><USER7> How is it so? If you're referring to the Packrat memoisation (which is not the only possible PEG implementation), you can do a lot of memory optimisation, like discarding memoised entries based on some rules (e.g., once a top-level entry, like a function or a class definition is parsed, all the alternative interpretations can be thrown away). You can memoise complex entries but re- parse simple tokens. And many, many more.

<comment><USER9> I was and also when scanning/lexing. My limited PEG parsing experience is with peg/leg by [http://piumarta.com/software/peg/](http://piumarta.com/software/peg/) and [http://pegjs.majda.cz](http://pegjs.majda.cz) which is a Javascript PEG parser. Both very cool projects.

<comment><USER7> Looks like they do not include the optimisations I mentioned. But for this sort of use cases that would have been an overkill anyway.

<comment><USER9> So do you have an example of a PEG parser that uses these so called memorisation optimisation techniques then?

<comment><USER7> [https://github.com/combinatorylogic/mbase/blob/master/src/l/...](https://github.com/combinatorylogic/mbase/blob/master/src/l/lib/parsing/compiler.al)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The XL programming language ([http://xlr.sf.net](http://xlr.sf.net)) has a rather unique approach to parsing. There is a short article about it here: [http://grenouille-bouillie.blogspot.fr/2010/06/xl-axioms- rec...](http://grenouille-bouillie.blogspot.fr/2010/06/xl-axioms-reconciling- lisp-and-c.html).

XL features 8 simple node types, 4 leafs (integer, real, text, name/symbol) and 4 inner nodes (infix, prefix, postfix and block). With that, you can use a rather standard looking syntax, yet have an inner parse tree structure that is practically as simple as Lisp. The scanner and parser together represent 1800 lines of C++ code with comments. In other words, with such a short parser, you have a language that reads like Python but has an abstract syntax tree that is barely more complicated than Lisp.

It's also the basis for the Tao 3D document description language used at Taodyne, so the approach has demonstrated its ability to work in an industrial project.

<comment><USER11> Judging from the article, if you parsed "if 3", you'd get back out

        (prefix if 3)

instead of an error, since `if` is just a regular prefix operator. So, presumably there's some sort of well-formedness checking that goes on after parsing? Does anyone know more? The website says very little.

<comment><USER12> Yeah that puzzles me a bit too. Multifix operators are _not_ more complicated than prefix/postfix/infix (well, only marginally). For instance, you can give each operator a left priority and a right priority and merge them when they meet with the same priority. Then `if x then y else z` would become (if/then/else x y z) or something like that. I think that's saner and easier to handle than what he does.

<comment><USER11> Yeah, that's what I was expecting too. And then XL could claim to have only _five_ node types: integer, real, text, name, and multifix :-)

<comment><USER10> In XL, a multifix is a combination of infix, prefix or postfix. Note that the various nodes exist only for the programmer's convenience, i.e. they represent a user-visible syntax. Internally, I could do with only a node with two children.

Something like [A,B,C,D] writes as:

Block with [] containing Infix , containing Symbol A Infix , containing Symbol B Infix , containing Symbol C Symbol D

So this allows me to represent multifix along with their expected syntax. I could also represent for example:

[A, B; C, D]

if A then B else C unless D

for A in B..C loop D

The last one is actually one of the for loop forms in XL

<comment><USER12> Multifix is more general than a combination of infix, prefix and postfix, though. For instance, a [] block is a multifix operator, but you can't implement it as a combination.

The advantage of supporting multifix directly is that you get a more convenient and less confusing representation. For instance, given "if A then B else C" why should I expect (else (then (if A) B) C) and not (if (then A (else B C))? It's not obvious, and both are unwieldy compared to a ternary operator like (if/then/else A B C).

<comment><USER10> Multifix is not more general than combinations of the 8 node types in XL, only more powerful than a combination of some subset.

It's not simpler. XL started with a multifix representation, see [http://mozart-dev.sourceforge.net/notes.html](http://mozart- dev.sourceforge.net/notes.html). Switching to the current representation was a MAJOR simplification.

The current representation captures the way humans parse the code. Infix captures "A+B" or "A and B". Prefix captures "+3" or "sin x". Postfix captures "3!" or "3km". Block captures "[A]", "(A)", "{A}" or indentation. Since humans perceive a difference, you need to record that difference somewhere. XL records that structure in the parse tree itself, not on side data structures such as grammar tables.

This approach also enables multiple tree shapes that overlap. Consider the following XL program (I replaced asterisks with slashes because the asterisk means "italics" for HN):

A/B+C -> multiply_and_add A, B, C

A+B/C -> multiply_and_add B, C, A

A+B -> add A, B

A*B -> mul A, B

In that case, I can match a multifix operator like multiply_and_add without needing a representation that would exclude matching A+B or A/B in other scenarios. This is especially important if you have type constraints on the arguments, e.g.:

A:matrix/B:matrix+C:matrix -> ...

A:matrix/B:real+C:real -> ...

Those would be checked against X/Y+Z in the code, but if X, Y and Z are real numbers, they would not match.

If you want to try it by yourself, you can download Tao from [http://www.taodyne.com/shop/dev/en/content/10-compare- versio...](http://www.taodyne.com/shop/dev/en/content/10-compare-versions). Tao uses XL as the basis of its dynamic document description. There's a tutorial here: [http://www.taodyne.com/presentation/tutorial-2.0.html](http://www.taodyne.com/presentation/tutorial-2.0.html). Please note that the XL implementation used in Tao has several limitations, notably with local functions and closures.

<comment><USER12> I have gone the other way with the languages I designed, from the system you describe to multifix, and have had the opposite experience. A _proper_ implementation of general operator precedence grammars is much simpler than implementing prefix, postfix, infix and blocks specifically.

Now, I'm not sure how you implemented multifix, but a good general implementation for it is not immediately obvious, so I suspect you simply used an algorithm that's more convoluted than necessary and made you overestimate the scheme's actual complexity. Implemented properly, though, it's ridiculously simple. To demonstrate, I have hacked together a JavaScript version here (sorry, I didn't get around to commenting the code yet):

[http://jsfiddle.net/ed37wy5k/2/](http://jsfiddle.net/ed37wy5k/2/)

The core of the parser is the oparse function, which clocks in at 32 lines of code. Along with a basic tokenizer, order function, evaluator and some fancy display code, the whole thing is barely over 200 LOC. I dug around for XL's source and from what I can tell, what you have is not simpler than this.

I also never suggested making multifix operators like multiply_and_add. Multifix is for operators which are inherently ternary, quaternary and so forth. For instance, when I see "a ? b : c" I don't parse it as prefix, postfix or binary infix, I parse it as ternary.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way.

When you look at the simplicity of OMeta[1] you feel the difference. But I am not aware of any (production ready) OMeta implementation for C++.

[1] [http://tinlizzie.org/ometa/](http://tinlizzie.org/ometa/)

<comment><USER13> If you don't mind incredibly long compile times for any moderately complex grammar, PEGTL is pretty straightforward compared to other alternatives.

<comment><USER14> Both are based in Bryan Ford's packrat (PEG is Ford's too). OMeta is more like PEGTL in that it's a set of facilities/library at a highish level, more than a particular grammar system (they're all packrat parsers).

[http://bford.info/packrat/](http://bford.info/packrat/)

It's all about descent parsing and memoisation (thus the name).

<comment><USER13> pegtl is not actually a packrat parser. Not all PEGs and absolutely not all recursive descent parsers are packrats.

And actually, my experience with packrat parsers (mostly in ruby) in other languages has been that they actually slow things down on moderately or more complex grammars by massively exploding memory use and thus allocation pressures. Turning it off can make it _faster_ , especially on complex grammars. It's a pretty good case study in how optimizing an O(n^2) worst case to O(n) does not always improve things.

That said, I'm not against the principle, but the shotgun approach to it can be brutally bad. You really only want to memoize the paths that are actually likely to backtrack. Or simple grammars where O(n^2) memory use is not going to balloon your memory use too much it's a clear win.

<comment><USER14> > Not all PEGs and absolutely not all recursive descent parsers are packrats.

Of course not, see the link I posted. PEGs are TDPL and recursive descent (not the other way around), and an alternative to CFGs. PEGs were coined by Bryan Ford, who then coined packrat parsing based on them.

You want to do smarter things than just memoising everything, yeah. Especially for complex grammars.

See [http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste51...](http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-mizushima.pdf)

</comment></comment></comment></comment></comment><comment><USER15> I should add Adaptive LL(* ), ALL(* ), of ANTLR 4 to the mix here. It handles any grammar you give it and generates a correct parser except for one small caveat: no _indirect_ left-recursion. It's the culimation of 25 years of focused effort to take LL-based parsing to the limit of power while maintaining simplicity and efficiency. See tool shootout in OOPSLA '14 paper I just presented [http://www.antlr.org/papers/allstar- techreport.pdf](http://www.antlr.org/papers/allstar-techreport.pdf) Until we change the requirements of a parser generator, I'm done. :)

</comment><comment><USER16> My day job used to involve parsing some fairly ill-formed languages, so I developed this: [https://github.com/Logicalshift/TameParse](https://github.com/Logicalshift/TameParse)

I noticed with the languages I was working on, the problems could be resolved by being smarter with the lookahead: this parser allows for context-free lookahead matching to resolve (or detect and defer) ambiguities.

That makes it possible to do neat things like parse C snippets without full type information or deal with keywords that aren't always keywords (eg, await in C#).

</comment><comment><USER17> It is nice to see someone summarizing this kind of information. However, really this is a continuation of the academic attitude toward parsers making them MUCH harder than they have to be.

If you want to study grammars in an abstract sense, then think of them this way, and that's fine. If you want to build a parser for a programming language, don't use any of this stuff. Just write code to parse the language in a straightforward way. You'll get a lot more done and the resulting system will be much nicer for you and your users.

<comment><USER18> That's horrible advice. Some problems are really complex and can't be solved just by working from A to B.

Your parser will probably not end up being able to handle the problems outlined in the article unless you take that theory into account before starting to program.

<comment><USER17> You never know, you might be talking to someone with actual experience.

</comment></comment></comment><comment><USER19> I've wondered why most existing LALR(1) parser generators are not replaced with LR parser generators with a higher look-ahead than 1. This improvement, considering that our computational power today does not justify these restrictions any more, would be Pareto-optimal even while it is being decided what completely alternative strategies (PEGs, boolean grammars, parser combinators, etc.) will take over.

<comment><AUTHOR> ANTLR is LL(*).

<comment><USER3> Right. It's kinda impressive what it can do. On one end of the spectrum it has all the power of PEGs and on the other it has the predicative capabilities of LL(k) so there is basically no restriction on the kind of grammar it can generate parsers for.

</comment></comment></comment><comment><USER20> This is a really interesting post. The same author recently posted another article that discusses some of the ideas from the conclusion of this post. You can find that article here: [http://tratt.net/laurie/blog/entries/an_editor_for_composed_...](http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs)

<comment><USER3> The more generic term for a lot of the stuff he talks about in that post falls under projectional editors and programming language workbenches. JetBrains MPS is one of the tools among many that help with building such editors. Here's a good talk by Markus Völter on using tools like JetBrains MPS.

<comment><USER21> I think you forgot to put in the link :)

<comment><USER3> [http://www.infoq.com/presentations/tools-language- workbench](http://www.infoq.com/presentations/tools-language-workbench)

</comment></comment></comment></comment><comment><USER22> Instaparse, a parsing library for Clojure, tries to make context-free grammars "as easy to use as regular expressions." It uses an EBNF input format that should be familiar to many programmers. [https://github.com/Engelberg/instaparse](https://github.com/Engelberg/instaparse)

</comment><comment><USER23> A tool I like in this space is Stephen Chang's Parsack, "a basic Parsec-like monadic parser combinator library implementation in Racket."

[http://stchang.github.io/parsack/parsack.html](http://stchang.github.io/parsack/parsack.html)</comment>


Genetic testing is an inexact science with real consequences - <AUTHOR> https://www.vox.com/recode/2019/12/13/20978024/genetic-testing-dna-consequences-23andme-ancestry <comment><USER2> The topic of how to deal with genetic information is an important one. There are many nuances about the technology itself which are distinct from how it could be used and potentially abused. This article does an awful job for this topic on so many levels:

> But it was too late to tell my grandma. She's dead now and I'm a liar.

The personal story is over the top and this is not the definition of a liar.

>"The science across all that is probably total junk,"

\--Jennifer King, director of consumer privacy at Stanford Law School's Center for Internet and Society.

Why would you run a quote like that?

The writer in this article clearly has an agenda and the alarmist attitude taken isn't doing this issue justice.

<comment><USER3> > _The personal story is over the top and this is not the definition of a > liar._

Well, if you take of the programmer's literal-minded hat for a second, this is probably representative of how the author feels: that she lied to her grandma. It might be incorrect but to dismiss her feelings of guilt like that is missing the point.

<comment><USER2> I don't want to belabor a secondary point too much here. But I will add there's a big difference between feeling guilty for being wrong and feeling guilty for lying.

<comment><USER4> I agree she isn't a liar. She was _lied to_ , by 23andMe, and that's an important difference.

I don't doubt that the company's fine print attempts to disclaim all responsibility for whatever errors they make in their calls, no matter how glaring; I'm quite confident that 23andMe could claim someone's ancestry is 97% derived from thoroughbred horses, and if pressed on the obviously nonsense result, they'd refer to their legal boilerplate and claim that the fault lay with whoever was credulous and foolish enough to presume they provide a product of merchantable quality in exchange for the fee that they charge.

What I don't see is why anyone needs to take them seriously in the attempt. And, as other commenters have pointed out, when we have companies in the same industry attempting to market genetic analysis for purposes from skin care to law enforcement, it's very much worth pausing for a moment, just to make sure that we aren't at risk of accidentally reinventing the justly discredited pseudoscience of eugenics, a century down the line.

</comment></comment></comment></comment><comment><USER5> I think this article grossly misapplies the term "testing" here. The 23andMe site barely contains the word "test" and that's probably because what they do does not fit with the standards and quality of actual medical testing.

Real genetic testing has very high standards for quality and accuracy and there are strict guidelines and regulations around how information is conveyed in reporting information back to requestors.

<comment><USER6> Your distinction seems to be a "no true Scotsman" fallacy. That 23andMe's genetic testing doesn't have the same high standards of "real" genetic testing doesn't mean that they're not using genetic testing. As far as 23andMe's not using the word "test" meaning anything, there is still an implication that testing is precisely what they're doing. I just Googled "genetic testing". The third result is a link to 23andMe that they themselves have titled "23andMe: DNA Genetic Testing & Analysis". From that page are links to pages like "We're all about real science, real data and genetic insights that positively impact people's lives" and "Know your genes, own your health".

</comment></comment><comment><USER7> I don't see how this kind of DNA test result is useful. It won't help you get citizenship of another country, or affect any of the cultural attributes you acquired while growing up (such as language and attitudes to science and religion). DNA has nothing to do with culture.

Are people supposed to suddenly take an interest in some place that they've previously ignored, just because they have some DNA that's commonly found in that location?

<comment><USER8> "nothing" is probably too strong

<comment><USER7> People will of course sometimes treat other people differently depending on physical attributes than can vary in different populations. E.g., skin colour or height or hair colour. But people already know what visible physical attributes they have without a DNA test.

</comment></comment></comment><comment><USER9> I thought it was common knowledge that the ancestry part of the 23andMe "project" was croud sourced and not an exact science? The "you are related to XYZ person in our database" stuff was 100% accurate, as that is coded in your genetics. But their ancestry data is based on who is related to who and what they think their ancestry is.

<comment><USER10> Directly contradicted here: [https://www.23andme.com/ancestry-composition- guide/](https://www.23andme.com/ancestry-composition-guide/)

<comment><USER11> That very long and thorough page explains the science, explains why it isn't exact, and does so in a surprisingly approachable manner. However, people seem to judge long, technical explanations as prima facie evidence for the "scientific" soundness of the product, and consider that something which is "scientific" is by definition accurate and reliable. Unhelpfully, that article buries the discussion about precision and recall at the very end. But even if they lead with it, it's perhaps too much to expect them to educate customers on statistical meaning, such as that even 95% precision means 1 out of 20 classifications will be wrong, and thus that it's entirely unsurprising for the journalist to have been misclassified as Middle Eastern.[1]

[1] Though, there's also little evidence that they _were_ misclassified, given the population flows between parts of Italy and other areas around the Mediterranean. Just because their family members came out as all Italian does not imply that the journalist's family lacks Middle Eastern ancestry.

</comment></comment></comment><comment><USER12> > Where roughly 25 percent Italian was supposed to be, Middle Eastern stood in > its place. The results shocked me.

Italy is close to the Middle East on my map.

[http://redd.it/77bj7a](http://redd.it/77bj7a)

> Middle Eastern does not refer to "Arab", but rather, is a catch-all term for > Eastern Mediterranean, including the Caucasian populations, pre-Arab > Levantine populations , and other West Asian populations.

> TL;DR- Ancestry that is Italian, Balkan, or Middle Eastern may utlimately > come from the non-diversified pool of Sicilian/Crete/EastMed populations and > may only reflect Broadly Mediterranean heritage and not ancestry from any > one specific location.

> I had made a lot of the Italian portion of my heritage ... majored in Latin > in college,

I cannot see how 23AndMe was lowering this person's sense of scientific legitimacy. 23AndMe didn't create this person's bizarre racial proclivities.

<comment><USER13> More than that, Sicily was a Muslim emirate for hundreds of years! The darker skin prevalent in Southern Italy is the result of that history, with the Moors conquering and occupying it for centuries.

When 23andme makes a guess about ancestry it is guessing where a set of people were at some arbitrary point in the past, otherwise everyone would simply be "Africa - 100%". This is clearly very inexact and is a novelty more than anything. And in this case enough of those Moors lived in the Middle East so it got categorized so. If anything this should be illuminating to her about notions of race and groupism (e.g. "No, I'm Italian!")

The ads play into this, of course, with the people in the ads suddenly embracing a different self-identity based upon the results. Which is just sad.

</comment></comment><comment><USER14> I have never heard of "inexact science" or "exact science". Googled exact science, found all results are related to a company. The term "exact science" sounds pseudoscience.

<comment><USER15> [https://en.wikipedia.org/wiki/Exact_sciences](https://en.wikipedia.org/wiki/Exact_sciences)

<comment><USER14> Interesting, Google only gives me [https://en.m.wikipedia.org/wiki/Exact_Sciences_%28company%29](https://en.m.wikipedia.org/wiki/Exact_Sciences_%28company%29)

<comment><USER9> Apparently search isn't an exact science yet ;)

</comment></comment></comment></comment><comment> cia-killer sicilian is basically arab anyways.

<comment><USER16> Some silcilian have North African or Greek as mixture.

</comment></comment><comment><USER16> DNA has one interesting thing tho, a lot of people who claim to be 'pure <insert ethnicity here>' figure out that they've some admixtures of other ethnic group too

</comment><comment><USER17> > DNA testing is an inexact science that's prone to errors throughout almost > every step of the process

This statement is correct.</comment>


How to Learn to Write iOS Apps - <AUTHOR> http://ashfurrow.com/2011/12/learn-how-to-write-ios-apps/

<comment><USER2> I wrote a 30+ page guide/book called Building iOS Apps From Scratch a few months ago, here's a link if anyone is interested. <http://designthencode.com/scratch/>

<comment><USER3> Your design tutorials look awesome, I will be picking them up. Do you have any recommendations for similar books, blogs, etc, that focus on low-level _technique_ for creating user interface elements for iOS? I really like your technique of using layer styles, etc, and have always wondered what are some other tricks of the trade are ways to create realistic UI elements. (I am proficient in Photoshop as a tool, but not really proficient in applying it to the end of creating UI elements.)

<comment><USER2> Thanks! There really aren't many, which was a key reason why I put some together. There are lots of free PSD sites, but obviously they don't include any instructional material. However they are great to poke through to see how things are constructed so I'd recommend heading to Dribbble and 365psd and poke around for some free PSDs. They're great to learn from.

<comment><USER3> Awesome, thanks. Is that generally the main way you learned in addition to just playing around? Any other tips for a newb?

</comment></comment></comment></comment><comment><USER4> -track down an example app to hack around with. this was the single biggest thing that got me from the hurdle from a Hello World app to a production full featured thing

-learn objective-c yes there is no way around it! try rewriting your favorite python or C example to get your head around some of the translation

-stackoverflow is your friend

-it's easier to get started working without Interface builder, so you can do that just to learn a thing or two with a sample app but then do the same thing _using_ IB; it will be quicker and cleaner in the end. this may be the hardest thing to start to wrap your mind around as it involves lots of clicking and less hacking

-design is everything. if you really want a quality app it's key to go from the bare bones to something a designer put skill into. once you get the hang of IB this can be a quick and amazing makeover. find a good designer to collaborate with.

What I did was make a simple app highlighting each skill I wanted to learn (Tables, Pickers, etc.).

Realize that a lot more time than you think will go into submitting to the store, provisioning, and getting your ducks in order there. Don't leave one hour to do this the first time. Also don't asume because it was easy the first time it will be the next. XCode gets very confused with multiple provisioning profiles sometimes. Things expire. etc.

I read the O'Reilly iOS book and Tapworthy along the way. And an Objective-C book or two; but I don't remember which.

<comment><USER5> > track down an example app to hack around with.

Just watch out - as with every language, there is a lot of bad code out there. While I agree with the notion of reading others' code (personally that helps me a lot to learn a new language), I'd go through the Apple-provided sample code before venturing into code of random apps.

<comment><USER6> Unfortunately, much of the Apple sample code is also pretty terrible.

Here's one heuristic: if you see any Objective C++ files (*.mm) in the project, you can probably ignore it as an example of good style.

<comment><USER7> Disagree. Some good libraries are C++, so linking to them requires you to use Obj-C++ (at very least, changing the name to *.mm).

<comment><USER6> Yeah, I meant things like sample code for plain C frameworks, where the author has just decided "hey, why not do this in Obj-C++ instead of Obj-C." As I recall, many of the AudioToolbox examples are like this.

Didn't mean to imply that there's no place for Obj-C++, just that it's not good style if you don't actually need it (like to wrap a C++ lib).

</comment></comment></comment></comment></comment><comment><USER8> For those of you thinking about making an iOS app for your startup or for profit, make a note of this:

Making the app is the easy part, it's the marketing that you really need to be working on and it's the marketing that will make or break your startup. It's the critical joint.

<comment><USER9> This is a very important point. I've got an incredibly simple app on the market, but because of some good publicity, it's gotten some good download numbers. On the flip side, I'll see great apps that've gotten < 1000 downloads simply because the author didn't get out there and write to every blog in sight.

<comment><USER8> Care to expand on the good publicity angle? Was it a blog? Was it pure luck or a well worded email? etc.

<comment><USER9> I just threw email darts at the dartboard that is Android blogs. A few of them stuck, and people started to download. That got me some decent ratings, and it's kept going from there.

</comment></comment></comment></comment><comment><USER10> It's so much easier when you already know how to program anything. I was a Perl dev and dabbled in Java. I was forced at my job to learn iOS and produce a specific app in less than 3 weeks. Wasn't pretty, but working under pressure can be good motivation too.

<comment><USER11> That is pretty impressive. 3 weeks. I hope your app didn't have to do anything database-related (sqlite/CoreData - that can suck up time)

<comment><USER10> Nah, it was actually a basic form and tableview.

However, it did have in-app purchasing and that was tedious to implement.

Not code-wise, but fiddling with xcode/apple dev center to generate ad-hoc profiles and signing and transferring to the device.

That sucked up more time than the code, at least for the first prototype build.

</comment></comment></comment><comment><USER12> Save yourself money and just go here: [https://developer.apple.com/library/ios/navigation/index.htm...](https://developer.apple.com/library/ios/navigation/index.html?section=Resource+Types&topic=Sample+Code)

Many of the how-to ebooks just add a code change here and there in the Apple Examples and publish it as their own.

</comment><comment><USER13> Thanks for this submission. I'm currently learning iOS development for the specific purpose of building an application. Ironically, my biggest obstacle has been choosing a path from the numerous options that can be found online. I've decided to pick a path that I find credible and stick with it regardless of its optimality. Your path is the way.

<comment><USER14> So what path have you chosen? I am a Ruby programmer and want to make an iOS app. I'm planning to use the Stanford course on iTunes to get started. Do you know if that's any good?

<comment><USER15> Optimize for your personal learning style.

I learn best by immersion and example, so I just picked a project and started building. I looked at prominent open source iOS apps and constantly referred to Apple iOS SDK docs, Apple example code, and several prominent books on iOS development (Hillegass, et al).

If you're more of a methodical or visual learner, use the iTunes U course videos.

<comment><USER16> Care to list those prominent open source iOS apps?

Maybe also links to their repos?

Thanks

</comment></comment></comment></comment><comment><USER17> My biggest piece of advice is to just do it. Jump right in and start writing some apps. You'll never get good if you don't actually build anything, for the most part, so just jump in and build something.

<comment><USER18> Between stackoverflow and all of the iOS blogs, google actually makes this approach ("I'll just hack until I have a question") totally reasonable. The modern Internet has very much changed the experience of picking up a new platform.

</comment></comment><comment><USER19> One of the biggest things that I stumbled over was whether or not I should code straight objective-c or use Interface Builder. In the end, I feel IB just gets in the way of being able to do cool things. I think if you're serious about making cool apps then stick exclusively to building apps with objective-c and avoid IB. (imho)

<comment><USER10> For normal interfaces XIBs are way easier to maintain and handle then a bunch of addSubView calls.

The only things that should be hard coded are interfaces that are too unique or exotic. Even then, XIBs allow you to place arbitrary UIView elements wherever you wish and you can get the best of both worlds.

<comment><USER15> How do you accomodate merging changes to XIB files within your VCS? It's already pain enough to deal with the Xcode project file. I ended up tearing out all use of IB in my large project after spending too many hours manually merging XIBs.

If I'm "doing it wrong" and there's a way to materially speed up my dev flow, please enlighten me. I can't wait. :)

<comment><USER11> Are you running into merge conflicts with other people?

Generally, we avoid any merge conflicts with XIB files. We have a small team so basically anyone who is dealing with it has an 'exclusive' lock until they are done.

That includes avoiding having a feature branch that makes changes to XIB files that might change in the main branch. Merging XIB file changes isn't for the faint hearted - and the likelihood of having a working XIB file at the end of a merge is not 100%.

</comment></comment></comment></comment><comment><USER20> The Big Nerd Ranch books are great resources and kept up to date. Kindle formats of these books are good too.

</comment><comment><USER21> iOS app development was a steep learning curve for me, coming from a C#/.NET background. After 3 years of professional iOS hacking, I created a video course a month ago, targeted to programmers. I think Stanford is a great place to start as well as the book route. The goal I had with making these tutorials was to create a see-and-do way of learning iOS. If you take the course for a spin, let me know what could be improved. <http://www.learnapps.org/?page_id=66>

</comment><comment><USER22> Has anyone written something similar for Ruby on Rails?</comment>


Ask HN: Web development language of future - <AUTHOR>

Hi guys,
It's my first post on HN so please don't kill me :)
I'm using PHP for years. I know, it's bad, it's horrible etc. Yet I like it, and it's developing quite nice.
But it's good to think about future. I was wondering about which programming languages will conquer future of web development.
My requirements:
* needs to have decent libraries which can boost development
* I want to use it for next years (it can't be a hipster choice)
* I want to be happy with it :)
My choices are:
* Javascript - I don't like that much SSJS, but it's popularity is growing
* Ruby - honestly I hate the syntax, but it's quite popular right now
* Scala
* Python
What do you think about it? <comment><USER2> For me it is Java + JavaScript. The only difference between now and the future is I expect server-side UI generation (Servlets/JSF/etc) to decline and all UI to be handed client-side by HTML/CSS/JavaScript with a RESTful/JAX-RS backend. Java is your data/transaction/communication engine.

I know it wasn't one of your choices but while Ruby/Scala/Python all have their merits I don't see any of them replacing Java (even on the JVM). The only reason I think PHP every became as popular as it is is because it worked better for shared hosting and Java hosting was expensive. Now with the Linodes and Digital Oceans of the world getting a VPS is cheap and easy allowing you to slap on something like TomEE really quickly.

<comment><AUTHOR> Thank you. I didn't mention Java because I'm a little Java hater :)

I like the idea that backend works only as an API (in fact we'll try to implement this in our future projects).

Problem is that, currently, client-side rendered pages have lots of performance problems. I guess that this shouldn't be a problem in future.

</comment></comment><comment><USER3> ruby -> you hate the syntax?? are you real? :)

<comment><AUTHOR> I am :) For me it looks a little like brainfuck. Don't be mad at me, it's just the way it looks for me :)

I'm using a little CoffeeScript, and the syntax is not so bad, yet I don't like it much. Maybe it's matter of preferences.</comment></comment>


Amazon Machine Learning – Make Data-Driven Decisions at Scale - <AUTHOR> https://aws.amazon.com/blogs/aws/amazon-machine-learning-make-data-driven-decisions-at-scale/ <comment><USER2> Meh. The more I do machine learning in industry the more I realize how little the ML part matters compares to everything else. A typical project I've seen takes 3-6 months and contains thousands lines of code, but the machine learning part will take a week or two and be 100 lines of code. What Amazon ML is doing would probably take an hour and 30 lines of R code you can easily find online.

And here's the not-too-hidden secret: the ML part is the fun part. It's a big reason we spend months creating banking.csv. Josh Willis did a very funny presentation at MLconf partly about this. It's like waiting in line at a theme park for an hour, and then paying someone to cut in line at the last minute and record the ride for you. [https://www.youtube.com/watch?v=4Gwf5zsg4vI&feature=youtu.be...](https://www.youtube.com/watch?v=4Gwf5zsg4vI&feature=youtu.be&t=657)

<comment><USER3> Agree 100%, in that light, anyone know how far we are away from having data wrangling be more automated? I saw a demo for a product called Paxata a few weeks ago, it looked like a good start. Anyone know more about things like that?

<comment><USER4> There are lots of new attempts at data wrangling approaches/tools, each with different caveats - Datameer, Platfora, Trifacta..

</comment></comment></comment><comment><USER5> Is it just Amazon's catching up with Azure ML launched last year? (And cutting prices by 80%)

 _Azure ML also supports R and Python custom code, which can be dropped directly into your workspace._

And this was even before Microsoft acquired Revolution Analytics. Amazon ML seems to be less flexible in regards to importing your own models:

 _Q: Can I export my models out of Amazon Machine Learning?

No.

Q: Can I import existing models into Amazon Machine Learning?

No._

[http://blogs.microsoft.com/blog/2014/06/16/microsoft- azure-m...](http://blogs.microsoft.com/blog/2014/06/16/microsoft-azure- machine-learning-combines-power-of-comprehensive-machine-learning-with- benefits-of-cloud/)

[https://aws.amazon.com/machine- learning/faqs/](https://aws.amazon.com/machine-learning/faqs/)

[http://azure.microsoft.com/en-us/services/machine- learning/](http://azure.microsoft.com/en-us/services/machine-learning/)

<comment><USER6> No... it's Amazon ML and Azure ML trying to catch up with BigML. They copied many things from our service but forgot to copy the ease of use. Services like Azure ML, Amazon ML and even Google Predict API work like a black box, and lock your model away, making you extremely dependent on their proprietary service. With BigML, you can easily export your models and use them anywhere for _free_. If the goal is to democratize machine learning, then the ability to extract your models and use them as you see fit is essential, and only BigML offers that level of freedom.

<comment><USER7> I just try out BigML and look awesome. I use Google Prediciton API to fill a value on form of a web request. I need the result immediately. Why BigML require two web request and take so long to get a prediction of a trained model?

<comment><USER6> If you use BigML's web forms, the first request caches the model locally so that all the subsequent predictions are performed directly in your browser.

</comment></comment></comment></comment><comment><USER8> Yeah sure, why not make your business process depend on a closed proprietary cloud-based product?

(in all fairness Amazon are better than many when it comes to unexpectedly withdrawing products)

<comment><USER9> I would be less worried about that and more worried about cost. I know of two different startups that aren't profitable but would be if they hadn't put their entire platform on amazon services. One of those startups was lucky enough to be acquired but it's going to take them many unprofitable years to migrate away.

</comment></comment><comment><USER10> So the pricing is $100 per million data points, at minimum. That doesn't seem like it scales well for big data at all.

However, that's 5x cheaper than what BigML is offering ([https://bigml.com/pricing/credits](https://bigml.com/pricing/credits)) for its ad hoc service, so I might be wrong.

<comment><USER6> BigML cofounder here. Most BigML customers doing machine learning at scale use either BigML subscriptions (starting $30/mo) or private deployments – both of which provide unlimited model training and predictions and are suitable for developers and large enterprises alike. In addition, with BigML you can export your models (for cluster analysis and anomaly detection and not just classification/regression) to run locally and/or to be incorporated in related systems and services.

</comment></comment><comment><USER11> Did they basically just put a wrapper around VW[1] ?

[1] [https://github.com/JohnLangford/vowpal_wabbit](https://github.com/JohnLangford/vowpal_wabbit)

<comment><USER12> No -- see [https://aws.amazon.com/machine- learning/faqs/](https://aws.amazon.com/machine-learning/faqs/) \--

"Q: What algorithm does Amazon Machine Learning use to generate models?

Amazon Machine Learning currently uses an industry-standard logistic regression algorithm to generate models."

But disappointingly:

"Q: Can I export my models out of Amazon Machine Learning?

No.

Q: Can I import existing models into Amazon Machine Learning?

No."

Note that they are doing classification and regression on iid feature vectors. Of course, ML is much larger than this setting, but this setting is generic enough that it has some applicability to lots of problems.

<comment><USER13> This does not mean they are not using Vowpal Wabbit. It is very easy to run Vowpal Wabbit with a logistic loss function.

Also, vw _is_ what I'd consider "industry standard."

</comment></comment></comment><comment><USER14> I am really amazed at the kind of things Amazon turns into a service. And this ML service is just wow'ing. I have fiddled with basic SVM's before, but this takes away the part of writing code and makes it sort of a end user product(you are still expected to know basics about ML). On the other hand, I also don't think this will take off very well. Maybe a few companies/startups who have cash in their pocket will use it/try it out, but the audience is really limited beyond that in my opinion.

<comment><USER15> > Maybe a few companies/startups who have cash in their pocket will use it/try > it out

Honestly, I'd see it the other way around. Small companies without a DS team might be drawn to this. I don't see how any company with a lick of sense would lock down their prediction model into AWS. They very clearly won't let you export your model once the training is done.

<comment><USER10> Small companies without a DS team will likely fall into the ML pitfalls which make the resulting analysis invalid.

</comment></comment></comment><comment><USER16> At first glance, this looks to go somewhat beyond Google's Prediction API, which (at least from my experience) is pretty limited in its usefulness.

Its nice to see tools for analyzing your data as well as multi-class classification, and some tune-able parameters but this doesn't seem to bring anything 'new' to the game.

All the hard parts, feature selection, noise, unlabeled data, etc are still up to the end user, which makes me wonder how many people will try this out and get poor results.

It would be nice to get an idea of what sort of model they are using on the backend or even having a choice of models.

<comment><USER17> What differences did you notice beyond Google's Prediction API?

<comment><USER16> This may be different now, but when I used Prediction API a few years ago, I don't remember it having any data analysis tools or multi-class classification. The UI was also pretty lacking. Haven't looked at in a while but perhaps it has gotten better?

</comment></comment></comment><comment><USER6> Did anyone actually give it a try? I only get this error with any dataset (even a humble Iris): Amazon ML cannot create an ML model: 1 validation error detected: Value null at 'predictiveModelType' failed to satisfy constraint: Member must not be null

<comment><USER18> go to the datasources tab and see if there's an error message from data source creation. i had the same error due to an issue with variable names.

</comment></comment><comment><USER19> I like the "Introduction to Machine Learning" which sort of briefly outlines the basics of machine learning for people who don't know about it.

</comment><comment><USER20> I predict we will see more cloud based machine learning services. Since machine learning is hard to learn and write for the average person, providing the services will greatly help them.

It would be good if there were an open source tool like Libreoffice that does Machine Learning in their spreadsheet app. It would be a good feature to add, and then the competitors would have to add it to their software as well.

</comment><comment><USER21> Google's competing product: [https://cloud.google.com/prediction/docs](https://cloud.google.com/prediction/docs)

</comment><comment><USER22> Cannot find it (in N. Virginia)? Is that only me?

(if anyone has the direct link for the console, please share :)

<comment><USER23> [https://console.aws.amazon.com/machinelearning/home?region=u...](https://console.aws.amazon.com/machinelearning/home?region=us- east-1#/)

<comment><USER22> Thanks!

(weird, still doesn't show in the menu)

<comment><USER24> It takes the teams a while to launch everything.

</comment></comment></comment></comment><comment><USER25> Some have already taken this kinda thing a few steps further:

[http://www.automaticstatistician.com/](http://www.automaticstatistician.com/)</comment>


Own start-up with 16 years. Do you need experience to create a start-up? - <AUTHOR>

1 1/2 years ago, when I was 15 years old, I started together with a friend the school project MessageRiver. We wanted to create a site which would display all the user's messages from different social networks in one stream and on one page. It was planned to do the project only until the term was finished. But we didn't only want the project to end in a rubbish bin. We invested lots of our free time in carrying the project. In December my friend had to leave, because it was too time consuming. I was very sad about it and knew that I only would be able to finish the project with a partner who had experience in bringing start-ups to the market, because I knew nothing about marketing, business model etc. After a few months I finally found someone and we finished up the project. Now we are excited to announce that the project entered the beta phase. You can visit it under the following web adress: http://www.messriv.com. You already forgot what about MessageRiver is? It's about this: Read all your messages from different social networks in one place and answer immediately. We currently support Facebook, Twitter and several email provider like Gmail, Yahoo! Mail, Outlook.com (Hotmail) and many more. Give it a try! You don't even have to pay ;) And sorry for my bad English ;) <comment><USER2> upvoted for being a young hacker (I'm 17 hey).

<comment><AUTHOR> any projects?</comment></comment>


What's wrong with Austin? - <AUTHOR> http://foundread.com/2008/01/10/whats-wrong-with-austin/ <comment><USER2> One of the commonly stated advantages of "not Silicon Valley" is that one isn't competing with Google, Yahoo, and the like for employees.

If your startup can't successfully compete with such companies for talent, doesn't that say something important about your startup?

If you can't compete with the best, you're not the best.

</comment><comment><USER3> Lived there for 5 years, working on 2 software startups. Very nice, though at a different scale and pace than SF bay -- which as the foundread post mentions, has benefits and costs wrt recruiting, turnover, etc. My vague impression is that the attention of investors and teams on opportunities has usually run 12-36 months behind the bay -- putting Austin slightly out-of- phase with bay funding/acquisition/exit cycles, meaning peaks are missed and valleys hit hard. So it's a better place for 5-15 year exit plans than 2-3 year exit plans.

One long-time Austinite thinks the local dominance of Austin Ventures has had a negative impact on the venture-backed software/internet space; you can see his rant in the first paragraph here:

[http://www.xent.com/pipermail/fork/Week-of- Mon-20070924/0465...](http://www.xent.com/pipermail/fork/Week-of- Mon-20070924/046573.html)

</comment><comment><USER4> Nothing.</comment>