The Python IAQ: Infrequently Answered Questions | Hacker News Reader

The Python IAQ: Infrequently Answered Questions

norvig.com

83 pointsalbertcardona36 comments

I dunno why people think functional programming jobs are vanishingly scarce. They are not. If you can demonstrate skill in functional languages, you might even get recruited.

It's true there are more wage-slave code-a-day jobs, but those jobs can be easily filled by uninspired hacks who are in it for the money. If you're reading this, the odds of you being one of those hacks is very low. The job market is smaller, but the workforce of talented functional programmers is much smaller, so the demand is still high.

And Clojure & Scala are even easier because you can get a java job and them worm them in. It's not difficult to make a compelling argument that Clojure & Scala are better at Java than Java is.

Functional programming jobs are scarce, but that's because no-one is a "functional programmer" in the same way that you might be a "PHP programmer". Instead you get lots of jobs where you happen to write a lot of code in a functional programming language but you don't look like a programmer in an organizational sense - you're an "analyst" or an "engineer" or whatever. That's where F# is making inroads.

You're not going to do functional (or any other interesting) programming as an IT programmer in a generic financial services company.

If you work for an actual software company (or perhaps an innovative financial services company) as a software engineer (or even on an operations team in some cases e.g., Sysadmins at Google using Haskell, ops tools at Yahoo once built in OCaml), there's plenty of chances to do functional programming (or something else that interests you).

It's just generally people are programmed to think "it's just a job" and choose their jobs based on salary, name recognition, commute hours etc... (Some also have very specialized skills like systems programming or machine learning and aren't particularly interested in programming languages, although I think they're missing out)

I really don't understand your point. What is the difference between a "programmer" and an "engineer"? Why doesn't "functional programmer" as a category include things like "F#", which you suggest is a valid category.

As for me, I interviewed at several jobs that featured functional programming during my last jobsearch. I actually turned down offers that were not devoted to functional (or at least hybrid object/functional) technologies.

If you are an analyst working for a bank, then your job is to do financial analysis to inform trading decisions. That is what your title is, that is the result you are expected to produce, that is what you will see yourself as. But to actually do that, you might be writing F# 40 hrs a week. You wouldn't consider yourself a programmer tho'. The program is not a product in and of itself; it's just a tool you use that you happen to also make yourself 'cos it's easier than writing a spec document and waiting for "a programmer" to do it.

Similarly if you are an engineer working for Ericcson on switches for telcos then you job is to design and implement switches. The result you are expected to produce is a switch that is better than the current one. You will probably see yourself as an electronic engineer - but you might actually be writing Erlang 40 hrs a week. The code isn't a product either - it's just the means by which you tell your switch hardware how to behave.

Whereas if you are a "PHP programmer" someone has already decided that PHP is what we're doing and your role is to do PHP and your end product is a website built with PHP. Which is not a bad thing mind - but it is why you see "PHP jobs" and you don't see so many "F# jobs".

I don't see how this has any bearing on functional programming jobs.

Great article, bad title. Someone with more kharma mind changing it to Python Infrequently answered Questions?

I agree.

The article actually contains the "if u cn rd ths..." phrase and it's a nice touch. However, it would be better to keep the original title and mention the phrase in the comments.

I don't get it anyway, if I can read this, why can I get a job in functional programming?

I think it is just taken out of the context from the article, where it's just below a code sample with a fair amount of lambdas in it.

Ah ok. I knew from the url that I had read this, so I did not read it this time.

even worse for me, I clicked to find out why employers like citi and BofA in the financial sector were no longer able to afford vowels for their programmers.

Same here.

It was a weird title. I did an an quick poll of two non-programmer, LOL-speak experts, and I got these answers:

- If you can read this, you can get a job in financial program (if there were any)

- If you can read this, you can get a job in functional programs/programming (if there were any)

I don't know what this proves.

Python infrequently asked questions, google cache at

http://webcache.googleusercontent.com/search?q=cache:norvig....

Seems a bit out-of-date (upcoming Python 2.5?), not sure why it's here really.

Is there much benefit to

    fact = lambda n: _if (n <= 1) (1) (lambda: n * fact(n-1))

over

    def fact(n):
        if (n <= 1):
            return 1
        else:
            return n * fact(n-1)

1 line vs 5 lines doesn't seem like an advantage to me when it takes pretty much the same amount of time to read and understand the complicated 1 liner.

Is there more optimisation possible?

Sometimes I put short ifs in one line, just personal taste

    def fact(n):
        if n<=1: return 1
        else:    return n * fact(n-1)

Which I guess can be written like

   def fact(n):
        return 1 if n<=1 else n*fact(n-1)

unfortunately not on python 2.4, which is the version we have on our production servers (2 yr old Linux)

One liner

    def fact(n): return n*fact(n-1) if n>1 else 1

One of those times when I hugely miss languages with pattern matching/guards.

  fact(1) = 1
  fact(n) = n * fact(n-1)

Seems much more readable to me.

     python -c "import _if; fact = lambda n: _if (n <= 1) (1) (lambda: n * fact(n-1)) ; fact(5)"

The main advantage of a 1-liner is that you can compose the whole thing and execute it without having to format anything. That is a nice feature for code that is only ever intended to be used once, such as from the python repl or some other shell. --Or more than once, for the duration of a session. It's a lot easier to use command history to get and modify a 1-liner than to replay a 5-line function definition.

When the code is primarily expressions, it's relatively easy to to this. Trying to do one-liners with regular python syntax can get tricky.

Also, if you have a series of similar relationships to present, it's often easier to line them up next to each other. You might cut 12 lines to 6 lines and the whole thing will be far clearer. Although in those cases, it's probably more effective to use a dictionary to achieve the same thing, with the advantage of data/logic separation.

    fact = lambda n: 1 if n <= 1 else n*fact(n-1)

or, for that matter:

    def fact(n): return 1 if n <= 1 else n*fact(n-1)

The point was to demonstrate that the one-liner fits easily as an argument to 'python -c' from the command-line. You could also point out "import _if;" probably won't let me call "_if()", but again that wasn't really the point.

Also, you'll need to know the version of python:

    $ python
    Python 2.4.3 (#1, Dec 11 2006, 11:39:03)
    [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> fact = lambda n: 1 if n <= 1 else n*fact(n-1)
      File "<stdin>", line 1
        fact = lambda n: 1 if n <= 1 else n*fact(n-1)
                            ^
    SyntaxError: invalid syntax
    >>>

I understand you just copied the same snippet for your example. I'm just pointing out that Python does support that kind of if natively, so that people won't think that it doesn't.

They are of broadly equivalent complexity (if you are used to Python) and you can fit more of the former in an editor window.

I don't like tho' that "lambda" is a keyword in Python, I much prefer Haskell's \ or OCaml's fun.

   from math import factorial

   fact = lambda n: reduce(operator.mul, xrange(1, n+1), 1)

Some of the responses are outdated, here's one of the things that is now part of python:

Python 2.5 introduced defaultdict in the collections module:

   from collections import defaultdict
   d = defaultdict(int)
   d['foo'] +=1 # look ma! no error!

For this application, if you're using Python 2.7 there's now a Counter in collections, you can do the same as above, just call Counter(). You can also do:

   c = Counter(iter) # iter is an iterable. It will count the elements!

It's also worth noting that, in Python 2.6 and higher, we DO have a ternary operator:

    x = 3 if foo() else 6

If u cn rd ths... then you may speak Hebrew or Arabic, which are basically written without vowels.

Regarding the "if thr wr any", and the rise of Haskell and Clojure, I wonder whether such caveat applies any longer.

As for content of the Python IAQ, I've enjoyed learning about two python idioms I had never known possible:

1. The ternary conditional operator:

x = <result> if <test> else <alternative>

2. Using or to assign an alternative value when the first is False or None

x = <option> or <option>

Incidentally, most C-style-syntax languages have a ternary conditional operator, and I use it quite a lot for things like building strings, very small conditionals, etc.... When used correctly, it can improve readability and expressiveness quite a bit.

x = <test> ? <result> : <alternative>

Some times for slightly more complex expressions, I'll put them on separate lines so as to have a very compact if/else structure.

As pointed out in the OP, there are actually quite a lot of ways to simulate the ternary operator in Python. An interesting one is (result, alternative)[test]. If result and alternative are functions you could write it as (result, alternative)[test]().

And for desert: I love this syntax:

  if 0 < x <= 100: pass

For more info see: http://stackoverflow.com/questions/394809/python-ternary-ope...

It's worth noting that Peter himself mentions that most of the ternary tricks he describes are not very readable and wouldn't be considered Pythonic.

   Beautiful is better than ugly.
   Explicit is better than implicit.
   Simple is better than complex.

Personally I'd hate to see something like that in any real-world project.

   (test and [result] or [alternative])[0]

Depending on the language, it could be an idiom.

"..and the rise of Haskell and Clojure.."

Is there any real world evidence of said claim, outside geek-fetish bubbles like HN ?

Reply on news.ycombinator.com