AMS Meeting in Austin

Speaking of big conferences, while it’s true that the climate action of late has mostly centered on the American Geophysical Union rather than the alternative American Meteorological Society (which makes sense, because of the paleoclimate and geochemistry aspects of climate), the AMS meeting is also coming up next month, and this time Austin is the host city.

It’s also a pleasure to note that the meteorological community is adopting Python as its de facto standard, and hopefully will be gradually emerging from the dark ages of post-1977 Fortran, an inelegant botch. (Word on the street is that Python performance may be competitive with Fortran’s on array computations soon.) No less than three of the eleven short courses being offered are centered on Python, including an introductory course by Johnny Lin, a fellow former postdoc in Ray Pierrehumbert’s group.

If there are P3 readers attending, let me know. I’d be happy to arrange a meet-up.

 

Comments:

  1. I actually prefer Fortran to Python. (Please don't throw tomatoes at me.) Loosely typed languages drive me crazy, until I get used to not declaring variables, at which point my programming has become so sloppy that I can't transition back to a more rigorous language. I also prefer to decide for myself where and how I want to indent - using terms like "endif" and "endfor" seems by far the most logical way to organize control structures without getting lost in brackets.

    • Kate, the whitespace thing is a nuisance if you have the wrong text editor, true. Without a block indent/outdent feature it's really usable only for short scripts. But that's, frankly, a pretty shallow reason for rejecting a language.

      As for the strong typing, there are better ways to deal with that than by doubling the size of the code, but it requires developing a bit of a sense of OOP, something most scientists don;t really understand and most books don't explain very well.

      There are tasks for which Fortran is hardly better than Python, and a science undergrad will have you doing them, but even then I'd strongly recommend Matlab or Octave, simply because it keeps you away from the compile/link/insert print statements for debugging loop. Fortran by its nature can't easily be interacted with on the fly, so it gets hard to track down problems. And the graphics options are all bolted on clumsily.

      There is a broad area of computation where pure python is too slow and mixed python/C/F77 or the various other alternatives is too much trouble. This is, as I understand it, being repaired.

      But anyway, the indentation problem is pretty superficial, and I consider that gripe to be a sign that the complainer hasn't spent enough time with python to appreciate its remarkable charms.

      • Well, maybe I'll give it another shot one of these days. I do like Python's interpreter mode, and the obvious benefit over languages with similar features (i.e. IDL) is that it's free.

      • I haven't heard a peep from IDL in a while - are they still in business?

        I recall it was quite robust. But it's an especially poor choice of platform for an undergrad because it's an expensive license which your graduate institution may not provide, so if you have a choice I'd avoid it. Even if this is not an issue you are at risk of your code going away if by chance it ends up with no company supporting it, though Wikipedia says there is a nearly complete GNU equivalent (which is implemented in Python and C++, which may tell you something).


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>