andreasvc

The Stanford parser does both constituency (phrase-structure) and dependency parsing. Actually in the model that I know of, the dependency parses are derived from the constituency parses.

The base of the parser relies on a grammar to describe possible sentence structures, but actually most of the work in disambiguation is done using statistics, or with neural networks. The question what is and what is not grammar is rather arbitrary, there can be a continuum between simple rule-like and statistical regularities.

Ultimately the models in NLP are rarely making any kind of cognitive/neuroscientific claim about being plausible models, just effective ones. There's a specific field of computational psycholinguistics which does investigate those things.

> Also, it's really not the case that you get better performance out of neural network models of language, let alone "human like performance". We're very far from that still.

I wouldn't make such claims these days because deep learning methods are gaining ground very fast. There are many tasks at which the deep learning model is better than traditional models. Furthermore, there are already deep learning models which are better than humans at image labeling.

Just because people construe the post that way doesn't mean they're right. Truth is not democratic.

You can make any title more accurate by making it longer and more specific, but picking a good title is a trade off against other things as well. A charitable reader would not necessarily insist on the narrow interpretation of Python the language you insist on.

And your title is not more accurate, because it's not just the existence of certain libraries, it's also the way they can be easily glued together and incrementally improved. Compare this to say Java, where you'd have to use JNI to use those same libraries, which is much more cumbersome to the point that most people prefer to write everything in Java.

> People want to see others say good things about their favourite language

To be honest I only think this only describes people that enjoy internet debates on programming languages. If what you are interested in is getting work done, you don't care about the merits of a particular tool in isolation but about end results. Hypothetically, you could find the "perfect" language but if it doesn't have users or libraries, it's of no use, and therefore the insistence of discussing only this or that language is pointless.

The easiest is to never use .keys() or .iterkeys(), and always iterate over the bare dict:

    for k in dict:
        ...

    if k in dict:
        ...

If you do need a list of keys, list(dict) has the advantage of working in both Python 2 and 3.

First, there's no reason to only associate "Python" with "the language", it is an environment, ecosystem, etc. It's not interesting to narrowly focus on the efficiency of the interpreter.

Second, it is an inherent feature of the design of CPython that its C API allows tight integration with external libraries in C. Cython does not just glue C and Python together, it does this in a way which makes the integration easier and safer than doing it by hand (e.g., generating correct reference counting code). All of this is a direct benefit of Python and its scientific ecosystem.

Works fine. You can switch between IMAP accounts like switching between folders.

He probably has peers that speak English with him, that has a larger effect than the language spoken at home, or on TV.

You could try, but I was arguing you won't have much luck with that. Not many people will hire you if there are specific strings attached to what you produce.

> Then how do babies ever learn to speak?

How exactly that works is still a hotly debated topic, but there is a clear difference between mere exposure to TV versus interacting linguistically in an environment.

> The most fluent speakers of foreign languages are almost always immigrants, because exposure is the key to learning to speak.

In my experience it's hit and miss. Some people simply have a knack for it (or interest), others not so much. So you can just as well have a very fluent second language learner who hasn't spend significant time immersed in the language, as well as the opposite of an immigrant who still has a thick accent after 20 years.

So I agree with all your points, except that the subtitling/dubbing issue is the cause of all this. The subtitling/dubbing is an effect, not a cause. Mere exposure does not make you learn/enjoy a language. The status/prestige/coolness is a cultural thing, and this is what explains the difference in motivation to learn languages.

You don't supply an argument why that's because of dubbing/subtitling. I think the real reason for the change is that English has become more important as a cultural language, at the expense of French, in this case.

You make it sound too easy. You don't "automatically" learn a language by hearing its sounds on TV (although it most likely helps). You need to engage with a language, preferably by real life interaction. Not dubbing movies is not a silver bullet to second language learning.

I think it's much more plausible to say that the smaller countries of Europe have more of a economic necessity to be proficient in a second language (which often happens to be English).

I don't think you can do paid work and stipulate whether the they can later sell it to anyone. If you can learn something from this, it should be that next time you might be able to cut out the middle man.

Also see this 2010 paper which cites this http://projecteuclid.org/euclid.ss/1294167961

Have you looked at Youtube comments in the past few years? This claim is absolutely, demonstrably false. People say mean/stupid things when they feel there won't be any repercussions. Not having your name attached to something might have some correlation with that, but it's certainly not the cause.

You're just repeating that it is awesome and useful without saying why. I think distinguishing public & private variables offers more support for structured programming and is therefore desirable.

The language cannot force it but can encourage it. Having to make the choice between private and public is worthwhile I think.

> being able to do dir(lib) and see the namespace that is in use is a good thing.

It is, but it is most useful when what you get a curated list of members (__all__) intended to be public.

What is useful about 'import lib; lib.re'? I cannot think of a situation in which a direct important wouldn't be better, while that has many obvious advantages. The __init__.py is a special case of course, but you would only use that for a package's own modules.

> It's fairly common to dive into 3rd party packages code to see what's occurring and to use 'undocumented' things

It may be common, but it doesn't convince me that it's a good idea. It seems to me that it would be better if the language forces you to design the public API properly, than to resort to using undocumented/private APIs.

> An apostrophe or a non-ASCII character is not necessarily a word boundary!

I don't see how a regular expression library could help with that (other than proper Unicode support), because word boundaries are a language-specific, linguistic problem; i.e., you will need to supply a list of possible contractions anyway.

Tokenization of natural language text may appear like a straightforward and solved problem, but there are actually lots of messy details to get right.

I don't think this position of relying on code instead of documentation is tenable for non-trivial code. The amount of effort to understand code is generally much more than that of maintaining documentation of what a function does, meaning of arguments, and any assumptions made. Documentation can (and should) have a much higher signal-to-noise ratio.

Neat. I should consider wrapping that.

Additionally there's a newer module also named 'regex': https://pypi.python.org/pypi/regex

I wonder what the reason is to include code in a release without documenting it. Maybe this article can form the basis for finally documenting this feature?

There's also the reverse with Python: useful code in the documentation not included in the standard library.

Which re2? I maintain a fork of re2 but it's not in there [1].

If you mention re2 the main cool feature about it is that it is efficient, matching in linear time using DFA. Unfortunately unicode strings need to be encoded to utf8 but if you can design your application to work with utf8 bytestrings you can avoid that cost.

[1] http://github.com/andreasvc/pyre2

Not to detract from your point that math is important, but in that example proper methodology (e.g., cross-validation), proper feature engineering, and especially domain knowledge are probably even more important. You can be aware of the strengths & weaknesses of different machine learning algorithms without being intimately familiar with the math. Ideally, ML methods are not treated as a "black boxes", but some aspects are inherently black box, even if you do know the math (e.g., parameter tuning).

Clearly. I never understood how anyone could take the "don't be evil" slogan seriously, actually. It's comic book level of ethics. We can disagree over whether they are actually being evil though, but what is clear to me is that there is a seriously worrying potential for evil with the amount of information they control through being de-facto monopolies.

Yes that interface is bad. I think Reddit is a good example of an interface with high density that works. A page is simply a list of 25 links, while in your example there is the complexity of different kinds of elements and their relationships.

A "don't be evil kind of Facebook" could've been appealing. Unfortunately they're decidedly not that, with their real name policy, forced integration with other services, public profiles, etc.

If you're writing in Cython (not Python) from scratch you don't need to work any more iteratively than in any other language. You can start out with low level memory management with malloc and declare everything with C types.

Granted, generics and macros are a nice advantage of Nim. What I think is the essential difference here is that Nim is higher level than Cython. So it seems to boil down to a matter of preference. However, when Python is not fast enough, Cython lets you go all the way to generating C code without garbage collection, inline assembly etc. With Nim there's yet another layer between Python and C.

> I am arguing that the whole language needs to be designed differently

No I think you are arguing that you want it to be designed differently. It's like the contrast between having a high and low level language (Python, C/Cython) versus having a unified middle-level language such as Julia (see http://graydon2.dreamwidth.org/189377.html ). It's a matter of preference which is better, and an empirical matter which approach will be more successful in the end.

> Just grafting types onto Python is not enough

Clearly it is already successful though...

You have a point that adding static types can mean having to rewrite. But in practice I often start out with Cython and static types, making this a non-issue. If you use Cython in this way it can approach C with Python syntax. See also http://spacy.io/blog/writing-c-in-cython/