Live data from Hacker News

Python, Machine Learning, and Language Wars (2015)

sebastianraschka.com

21–30 of 62 posts

Re: Python, Machine Learning, and Language Wars (2015)

#21
post #20
post #2

Buddha about Language Wars: Then the Buddha gave advice of extreme importance to the group of Brahmins: 'It is not proper for a wise man who maintains (lit. protects) truth to come to the conclusion: "This alone is Truth, and everything else is false'.' Asked by the young Brahmin to explain the idea of maintaining or protecting truth, the Buddha said: ' A man has a faith. If he says, "This is my faith", so far he mai…

> 'I believe this'. So far he respects truth What if he believes is objectively wrong?

He only talks about wise men who protect truth, so the truth being true is a given I'd say.

EDIT: Of course he's talking to people who swear by the truth they protect. Instead of telling them they're wrong, telling them others might be right is far more likely to get them to consider his point of view -- that other "truths" are just as equal.

Re: Python, Machine Learning, and Language Wars (2015)

#22
post #17

Earlier quoted context omitted.

As a predominantly Python-focused engineer, I've spent considerable time teaching myself R and there is a lot to like about R. For boutique statistical libraries especially. For instance, the enjoyment of using PySTAN is nowhere near as high as simply using STAN directly from R. However, when you dig into the R internals, and you learn about its generic function model of OO, and about the mangled history of S3 and S4…

>Since the times when you need "just scripting" are about 0.00001% of real-world cases I would argue the opposite is true. Most of the time an analyst builds regression trees in the mktg department for a retailer. Or similar situations like this.

That is in fact an exact situation I've been in, where it had previously been organized as a bunch do ad hoc scripts, and it caused huge problems.

It is exactly all of these fractured cases where you're running analyses in some bespoke corner of a business that it is most critical that the analysis tool is productionized and unified.

Plenty of businesses don't do it this way, but their reliance on manual scripts, manual environment and dependency management, manually tracking which versions of code produced which results, and manually calibrating on historic test data, it all adds up to incredible problems that eventually require re-writes focusing on a systematic architecture.

Re: Python, Machine Learning, and Language Wars (2015)

#23
post #22

Earlier quoted context omitted.

>Since the times when you need "just scripting" are about 0.00001% of real-world cases I would argue the opposite is true. Most of the time an analyst builds regression trees in the mktg department for a retailer. Or similar situations like this.

That is in fact an exact situation I've been in, where it had previously been organized as a bunch do ad hoc scripts, and it caused huge problems. It is exactly all of these fractured cases where you're running analyses in some bespoke corner of a business that it is most critical that the analysis tool is productionized and unified. Plenty of businesses don't do it this way, but their reliance on manual scripts, man…

Vendors are standardizing on R, so I don't think the situation is as severe as you make it out to be.

Re: Python, Machine Learning, and Language Wars (2015)

#24
post #17
post #3

As someone who's switched from Ruby to Python (for now, because the latter is far easier to teach, IMO) and also put significant time into learning R, because of how strong ggplot2 is...I was really surprised at the lack of Google results for "switching from python to r" -- or similarly phrased queries to find guides on how to go from Python to R...in fact, that particular query will bring up more results for R -> Py…

As a predominantly Python-focused engineer, I've spent considerable time teaching myself R and there is a lot to like about R. For boutique statistical libraries especially. For instance, the enjoyment of using PySTAN is nowhere near as high as simply using STAN directly from R. However, when you dig into the R internals, and you learn about its generic function model of OO, and about the mangled history of S3 and S4…

R is indeed quite weird when you get to internals. What's the problem you have with S3 though? It has it's limitations, but since I've first seen it, I thought it was by far the single most convenient and intuitive OO system out there... But yes, can't use it for everything. S4 is a bit ugly but still kinda workable -- the real problems for me start when you need to deal with environments and expressions and such, but is it really so often necessary to go there when you are designing your own tools (which I guess is what you're doing?)

As for the real-world percentage, it varies depending on the job -- R is primarily designed for the people who spend most of their time looking and thinking about the data, rather than the code.

Re: Python, Machine Learning, and Language Wars (2015)

#25
post #12
post #10

Earlier quoted context omitted.

I also think that Anaconda is great. However, I hope that in the future we could install numpy, matplotlib, jupyter, etc. just using pip.

I did that earlier today: pip install jupyter pip install numpy pip install scipy pip install scikit-learn pip install matplotlib The only problem I had was with OpenCV, which requires manual make installation if you want the contrib package. The other problem was when trying to install scikit-learn, it requires manual pip installation of scipy.

The reason you can't is because of the C libraries levaaged must be installed prior to install numpy and scipy.

For example, you can't get through PyYaml unless python-dev is installed on Ubuntu. I am not sure if wheel would fix it but I don't think so.

Re: Python, Machine Learning, and Language Wars (2015)

#26
post #21
post #20

Earlier quoted context omitted.

> 'I believe this'. So far he respects truth What if he believes is objectively wrong?

He only talks about wise men who protect truth, so the truth being true is a given I'd say. EDIT: Of course he's talking to people who swear by the truth they protect. Instead of telling them they're wrong, telling them others might be right is far more likely to get them to consider his point of view -- that other "truths" are just as equal.

[deleted]

Re: Python, Machine Learning, and Language Wars (2015)

#28
why pick just one language? with the polyglot Beaker Notebook, you can work with many languages, even in the same notebook, and your data is automatically translated between them.

each of these languages has its strong point. there is always some library you want to use in some other language. or you want to collaborate with someone. or next year you change your mind and Julia is finally good enough.

http://BeakerNotebook.com

Re: Python, Machine Learning, and Language Wars (2015)

#29
post #28

why pick just one language? with the polyglot Beaker Notebook, you can work with many languages, even in the same notebook, and your data is automatically translated between them. each of these languages has its strong point. there is always some library you want to use in some other language. or you want to collaborate with someone. or next year you change your mind and Julia is finally good enough. http://BeakerNot…

Knowing other languages is great, but there is very real overhead in learning them. Python is mature enough that you have mature libraries available for pretty much everything.

Re: Python, Machine Learning, and Language Wars (2015)

#30
post #3

As someone who's switched from Ruby to Python (for now, because the latter is far easier to teach, IMO) and also put significant time into learning R, because of how strong ggplot2 is...I was really surprised at the lack of Google results for "switching from python to r" -- or similarly phrased queries to find guides on how to go from Python to R...in fact, that particular query will bring up more results for R -> Py…

You know, I remember when I was trying my first language other than BASIC (VB6, perhaps? or maybe 1995 era JS?) and it bugged me that "x = y" wasn't the same as "y = x". Remembering it as "LET x = y" was helpful.

> it bugged me that "x = y" wasn't the same as "y = x"

it is in Prolog

Post reply on HN