Live data from Hacker News

Economics Nobel laureate Paul Romer is a Python programming convert

qz.com

71–74 of 74 posts

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

#71

Earlier quoted context omitted.

I loved using Mathematica in college. It was the first programming language I ever really used to make some cool things. I wish it was more accessible. I think one of the requirements of my dream job would be a work place that uses Mathematica. It's really fun reading through "code golf" challenges where other languages take 10-15 lines for something that Mathematica has a built in for.

Did you just say "code golf" and Mathematica in the same sentence? Then you will love these. I own like 10 copies, which I give to people for their birthdays: http://adereth.github.io/blog/2017/11/02/playing-with-wolfra...

Oh, those are quite cool. I'll have to get a pack sometime. I also think the Executed Today deck looks pretty cool (totally different card subject)

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

#72

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'm not an economist so maybe this is something about economics per se.

No, this is just a case of historical contingency, or the founder effect, depending on your preferred metaphor. Stata and Mathematica are suitable tools (and were suitable early on) that happened to be adopted by a few economists, whose choice was then spread and perpetuated via various organizations and institutions, word of mouth and curricula.

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

#73

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. However this piece is really around exploiting the amazing infrastructure that has built up around Python that empowers mathematical and statistical research, which is fair enough.

I'm surprised people needed to ask, and I was very specifically talking about the language itself rather than the libraries (so "batteries included" is not a counterargument); but here is a small non-exhaustive assortment of nonsense in Python:

1. Does 3/2 == 1 or 1.5 ? Either answer would be logical and OK, provided you stick to it. The utterly daft answer that Python gives is "it depends on what version of the language you are using, and/or whether you do "from __future__ import division""

2. Generalising 1, a painful set of breaking changes between 2 and 3 that could have largely been avoided by aliasing names or introducing new names for changed concepts / methods; eg make xrange = range; add a new function rather that redefine what 'print' is (and yes, failing to make 'print' a function in the first place was a shockingly bad decision). Read about the insane amout of effort that Dropbox put into migrating their codebase to see what a ballsup this all is - polite languages respect backwards compatibility.

3. The object system is a mess: type(some_obj_i_made) is - wat? - unless you explicitly inherit your class from object when it suddenly does something sensible; constructor inheritance is a confusing bog. Yes yes old style vs new style objects, but that's the problem. This stuff shouldn't be hard; see eg Ruby.

4. edit: scoping - oy vey

Look, it's OK. It works. The ecosystem makes up for an awful lot of this rubbish. But don't be so devoted to a technology that you're blind to its faults.

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

#74
post #39

Earlier quoted context omitted.

Some departments in the FDA require clinical trial data to be submitted in SAS formats :-/

This is a myth: http://blog.revolutionanalytics.com/2012/06/fda-r-ok.html https://www.fda.gov/downloads/forindustry/datastandards/stud...

No, by the text of that same link you provided: "... origin of this fallacy is probably related to the fact that data must be submitted in the XPT "transport format" (which was originally created by SAS)." While that post goes on to say, "This [XPT] data format is now an open standard." That is somewhat disingenuous. The XPT format requires IBM Mainframe floats and other wierdness. It's not always that easy to write XPT.
Post reply on HN