Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Economics Nobel laureate Paul Romer is a Python programming convert

qz.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#51

Post by mynewtb »

dnautics wrote: post #40
dunpeal wrote: post #29

Earlier quoted context omitted.

What are these "stupidities" that bother you? Personally, I use Python a lot for anything related to data science. No language is perfect, but I'd say Python has a lot less deficiencies and warts than most other mainstream languages, and it's extremely well suited for tasks in data science and related fields such as machine learning. The main issue with Python is that its default platform (CPython) isn't very efficie…

Here's a classic: def a(arg = []): return arg a([1]) #==> [1] arr = a() #==> [] arr.append(1) a() #==> [1]

Function definitions are evaluated once and early. Easy rule to learn and not really problematic.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#52

Post by dunpeal »

mynewtb wrote: post #49
Insanity wrote: post #30

Earlier quoted context omitted.

Whilst that is true, for data science related things I end up using Pandas (and Numpy) often which are fast. So most of the heavy lifting is not done by python itself.

So what? Pandas and numpy are still use with Python code using their APIs. The implementation details are not something the users care about. They write Python.

Not sure what you're arguing. If you use numpy and pandas properly, most of your computations happen in optimized C routines.

So you will write Python, but get very good resource (both time and space) efficiency.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#53

Post by dunpeal »

crdoconnor wrote: post #50
dunpeal wrote: post #45

Earlier quoted context omitted.

That's slightly surprising, but I wouldn't call it a wart. A proper wart is something that bothers you even after years of using the language, not something that surprises you a couple of times as a beginner, but then ceases to be a problem - or indeed, in this case, has some good uses. The obvious alternative in this case would be to reconstruct the default value. This doesn't work very well with the language's eval…

>I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There are many warts that will never go away simply because they're embedded so much within the culture of the language and because undoing the wart would break so much working code. I love python and I've used it every day for 15 years but ther…

> "if x" started failing with an exception for non-boolean values of x

I would call that a personal preference, and one that is far from consensus, rather than a "wart".

A wart is a known problem in the language, that most users consider to exert a negative impact on their usecases. Example would be Type Erasure in Java, which is there for historical reasons, can not be fixed, and is generally agreed by Java programmers to be a Bad Thing.

There isn't anything like this consensus for the changes you are suggesting.

All other mainstream languages support use of non-booleans as predicates, including for example C++ and Java, which are statically typed.

This change would make Python more strict about typing than virtually all mainstream static languages! Given how Python is dynamically typed, I'd suspect this change would be extremely unpopular.

> strings stopped being iterable by default

Again, not something most people would use. There are many fields in which strings are used to store sequences of characters where each character has a meaning. In all those fields, `for char in string` is a very useful idiom.

I'm not sure how this is a wart or what's your usecase that string iterability is breaking. Indeed, strings being iterable is in line with the general iterability philosophy and unlikely to change (which is a good thing for most users).

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#55

Post by dunpeal »

21 wrote: post #47
dunpeal wrote: post #24

Earlier quoted context omitted.

Jupyter notebooks are ultimately just a text file, which can be version controlled, verified (via the VCS or independent hashing), and if necessary - digitally signed in a cryptographically secure manner. Given that Git is already secure, I'd say all the researcher needs to know is basic usage of Git. Version controlling the notebook satisfies all the requirements you mentioned: prevents accidental distortion, is ver…

You forget that a typical Python Jupyter notebook will import a dozen Python packages. Versioning that it's still a major problem in the ecosystem.

> Versioning that it's still a major problem in the ecosystem.

There's actually a perfectly good way to solve this problem: a virtual environment with a requirements.txt file.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#56

Post by qwerty456127 »

mxuribe wrote: post #14

Beyond the cool python angle, I find the following statement quite interesting: "...James Somers argued that Jupyter notebooks may replace the traditional research paper typically shared as a PDF..." I've only been exposed to jupyter notebook references here and there...but i guess i should become a little more familiar with them.

"Jupyter notebooks may replace the traditional research paper typically shared as a PDF..." - hardly a replacement as long as Jupyter notebooks are not self-sufficient files you can download and view offline everywhere. Even if you have up-to-date versions of Python and all the libraries installed you still have to run a server and open it in a browser which is a way more clumsy than just opening a PDF in Okular/Evince/AcrobatReader. I also doubt Jupyter notebooks are easy to view on mobile devices.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#57

Post by crdoconnor »

dunpeal wrote: post #53
crdoconnor wrote: post #50

Earlier quoted context omitted.

>I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There are many warts that will never go away simply because they're embedded so much within the culture of the language and because undoing the wart would break so much working code. I love python and I've used it every day for 15 years but ther…

> "if x" started failing with an exception for non-boolean values of x I would call that a personal preference, and one that is far from consensus, rather than a "wart". A wart is a known problem in the language, that most users consider to exert a negative impact on their usecases. Example would be Type Erasure in Java, which is there for historical reasons, can not be fixed, and is generally agreed by Java programm…

>I would call that a personal preference

shrug it's two features that I see causing two classes of bugs on an extremely regular basis.

It's a trade off that affects everybody, but it's hard to weight up the trade off without a lot of experience.

>There isn't anything like this consensus for the changes you are suggesting.

Exactly what I said, yes...

>This change would make Python more strict about typing than virtually all mainstream static languages!

I think dialing up the strictness is a good thing and so do the language designers (that was the idea behind introducing type hints).

>Again, not something most people would use.

That's exactly the point. Making strings iterable list of characters isn't something that most people use - its primary function is to cause weird bugs for functions that take lists of strings (and you get an output like 'm', 'y', 'd', etc.).

Changing it so that you'd have to do string.chars to get an iterable list would, at very little cost, cut out a pretty common class of bug.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#58

Post by bachmeier »

lellotope wrote: post #16

Am I missing something or are parts of this article really distorted? For example, this seems to set up most of the article: "Economics involves a lot of math and statistics. The most commonly used tools to crunch numbers are the spreadsheet software Microsoft Excel and programming languages Stata and Mathematica." Is this really true? Mathematica and Stata seem like established but niche products to me at this point…

> If you asked me to predict what a quantitative economist would be using, it would be Python, followed by R, and maybe followed by Java or C, or something like that.

I've never heard of an economist using Java, and very few using C. Fortran is still quite popular in some areas.

Stata is extremely popular in some areas. GAUSS and Matlab in others (though GAUSS is declining for sure). R is quite popular, particularly since RStudio came along.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#59

Post by tvanantwerp »

lellotope wrote: post #16

Am I missing something or are parts of this article really distorted? For example, this seems to set up most of the article: "Economics involves a lot of math and statistics. The most commonly used tools to crunch numbers are the spreadsheet software Microsoft Excel and programming languages Stata and Mathematica." Is this really true? Mathematica and Stata seem like established but niche products to me at this point…

I've spent most of my career working with economists, and they've got a strong preference for Stata. It's what most of them learned in university. I'm hopeful that it's a preference that will slowly be replaced with Python--we're already making that change at the think tank where I work.

Re: Economics Nobel laureate Paul Romer is a Python programming convert

#60

Post by joker3 »

lellotope wrote: post #16

Am I missing something or are parts of this article really distorted? For example, this seems to set up most of the article: "Economics involves a lot of math and statistics. The most commonly used tools to crunch numbers are the spreadsheet software Microsoft Excel and programming languages Stata and Mathematica." Is this really true? Mathematica and Stata seem like established but niche products to me at this point…

When I was finishing up grad school in 2013, I talked to a few econ grad students about what tools they were using for statistics and computing. It sounded like the people just starting out were generally familiar with and in favor of R, but among the older students it wasn't quite as popular. I don't remember anyone mentioning Python at the time.
Post reply on HN