4 ms·

Opinions on Python aside, I'd never hire somebody saying something like that at an interview, even about a language I don't like. You should really look past pe

Opinions on Python aside, I'd never hire somebody saying something like that at an interview, even about a language I don't like. You should really look past petty details when evaluating any tech and come up with actual arguments.

nnq 14y ago
Really, why? You wouldn't hire someone that has some "language aesthetic preferences", although a bit different that the mainstream ones? He said "preventing me for ever liking Python" not "I'll never touch it because of this".
- pyre 14y ago
  This is really the same as saying, "I won't work for company X because I don't think the brackets in the C++ code should be on the following line[1]!" [1] E.g.: int main() { } vs. int main() { } This is an apt analogy because most companies will have some sort of code style guide that you have to follow, which doesn't make "coding at company X where bracket placement is enforced" much different from "coding in Python where whitespace is enforced." I've yet to come across someone that had a severe hatred of Python due to the significant whitespace that was a programmer I respected. The last person that I knew (who had a visceral hatred of Python whitespace) wrote Perl code like this: sub func1 { shift->func2(shift)->func3(@_) } or sub func1 { grep { $_[0]->func2($_) } $_[0]->func3() } Note: These are literally code samples with the function names changed. I don't know any Perl programmers that would condone this sort of code. It's a maintenance nightmare, especially since these were not one-off instances. Seems to me that the people that have a hatred of Python's handling of whitespace don't like being 'constrained' by their language, and are probably happier with Ruby or Perl.
  - berntb 14y ago
    There are some problems with the whitespace in Python. I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas. List comprehensions is another example -- a kludge coming from that the lack of multi instruction lambdas stop real map functions. (The fun part is that this necessity is touted as something good, instead of admitting that it is unnecessary complexity to learn.)
    - spacemanaki 14y ago
      > There are some problems with the whitespace in Python. > I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas. As nnq points out elsewhere in this thread, this doesn't have anything to do with significant whitespace. Python only allows you to have a single expression in the body of a lambda, and from what I've read the reason it stays this way is to discourage using a lambda as an argument to map, fold, filter & friends. The usual suggestion from Python programmers is to just use a locally defined, named function, which to be honest is often what I do anyway in languages like ML, because it's clearer. And anyway, just because it was hard to port some code from language A to language B due to something different about B doesn't really seem like a valid knock against B.
      - berntb 14y ago
        My argument was that a lack of real anonymous functions (> 1 instruction) is a problem in some quite common and useful scenarios. If you REALLY can give good references that show this is wrong, I'm very interested (like, I would guess, most Ruby users). (It would also be interesting with a link to a PEP or something with, as you claim, arguments that map etc should be discouraged -- and that is why no multi line lambdas exists. For instance, how would the syntax look like??)
        dangerlibrary 14y ago
        For most use cases where you want map/filter/etc, you can chain list comprehensions using generators.
        berntb 14y ago
        You have no relevant comment on what I wrote either, I take it? Here I asked for references about the GP's claims. Also, welcome to HN (or are the prepared troll accounts with a few hundreds of Karma running out? :-) ).
  - alberich 14y ago
    Actually, saying that you'll never like a given detail about a language is not the same as saying that you'll never work for company X because of that specific detail. It is not a logical conclusion, unless you are implying that for one to work for someone else you really need to like everything about the job at hand. I see no reason why you can't do something for money that you wouldn't do for your personal pleasure.
ww520 14y ago
Why won't you hire someone who has a unfavorable opinion on a language? Do you feel the same way if he mentioned Java instead of Python?
- PommeDeTerre 14y ago
  That's clearly not what he said. He just wants actual, technical arguments against a given language, rather than baseless claims that make no sense. I think it's quite reasonable to be suspicious of a interviewee who is against Python solely because it enforces sensible code indentation.
  - alberich 14y ago
    >> I think it's quite reasonable to be suspicious of a interviewee who is against Python solely because it enforces sensible code indentation. Though saying "I don't like python's code indentation" is not the same as "I'm against python". Well, at least I see no relation between the two.
whtspcmttrs 14y ago
The "whitespace matters" business permeates other parts of the language design that contribute to Python's crappyness, like its busted scoping and lack of real lambdas. You can have it, and I don't want to work for you, anyhow.
flogic 14y ago
At least in Haskell, I don't really care for the significant white space when it's re-factoring time. I don't see how it wouldn't become more of an issue for a traditional imperative language and their tendency for large blocks.
wazoox 14y ago
That doesn't make much sense to me. Let's say if I were interviewed at some place using Java, Python, C and Go, why shouldn't I state my personal language preferences? For most things as an hiring manager I'm OK with people working with their favourite language on whatever project I assign them to (as long as it isn't too esoteric; OCaml is OK, but Haskell is probably pushing it a bit too far, for instance), except when they have to work on an existing code base, in which case I wouldn't want to hire someone hating it; they'd be miserable and the resulting code would be awful.
- sylvinus 14y ago
  Personal language preferences are fine if they are justified by actual reasons like tech details, community, librairies, ...
  - wazoox 14y ago
    We'll talk about this Tuesday :) People usually have a very good reason to prefer the language they're more comfortable with, because it makes them more productive. Of course, it could be easy to dispell if some guy insists on writing only assembly, or C++, vs Python. I've known a guy who wrote whole Windows GUIs in assembly, it's pure madness. There are many valid technical reasons to rather choose C than Python, Java than Perl, or PHP than Go, Erlang rather than C++ ... But Perl vs Python vs Ruby? Hardly any difference, extremely similar dynamic languages. It's only a matter of personal taste at this point.

nnq 14y ago

Really, why? You wouldn't hire someone that has some "language aesthetic preferences", although a bit different that the mainstream ones? He said "preventing me for ever liking Python" not "I'll never touch it because of this".

pyre 14y ago
This is really the same as saying, "I won't work for company X because I don't think the brackets in the C++ code should be on the following line[1]!" [1] E.g.: int main() { } vs. int main() { } This is an apt analogy because most companies will have some sort of code style guide that you have to follow, which doesn't make "coding at company X where bracket placement is enforced" much different from "coding in Python where whitespace is enforced." I've yet to come across someone that had a severe hatred of Python due to the significant whitespace that was a programmer I respected. The last person that I knew (who had a visceral hatred of Python whitespace) wrote Perl code like this: sub func1 { shift->func2(shift)->func3(@_) } or sub func1 { grep { $_[0]->func2($_) } $_[0]->func3() } Note: These are literally code samples with the function names changed. I don't know any Perl programmers that would condone this sort of code. It's a maintenance nightmare, especially since these were not one-off instances. Seems to me that the people that have a hatred of Python's handling of whitespace don't like being 'constrained' by their language, and are probably happier with Ruby or Perl.
- berntb 14y ago
  There are some problems with the whitespace in Python. I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas. List comprehensions is another example -- a kludge coming from that the lack of multi instruction lambdas stop real map functions. (The fun part is that this necessity is touted as something good, instead of admitting that it is unnecessary complexity to learn.)
  - spacemanaki 14y ago
    > There are some problems with the whitespace in Python. > I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas. As nnq points out elsewhere in this thread, this doesn't have anything to do with significant whitespace. Python only allows you to have a single expression in the body of a lambda, and from what I've read the reason it stays this way is to discourage using a lambda as an argument to map, fold, filter & friends. The usual suggestion from Python programmers is to just use a locally defined, named function, which to be honest is often what I do anyway in languages like ML, because it's clearer. And anyway, just because it was hard to port some code from language A to language B due to something different about B doesn't really seem like a valid knock against B.
    - berntb 14y ago
      My argument was that a lack of real anonymous functions (> 1 instruction) is a problem in some quite common and useful scenarios. If you REALLY can give good references that show this is wrong, I'm very interested (like, I would guess, most Ruby users). (It would also be interesting with a link to a PEP or something with, as you claim, arguments that map etc should be discouraged -- and that is why no multi line lambdas exists. For instance, how would the syntax look like??)
      - dangerlibrary 14y ago
        For most use cases where you want map/filter/etc, you can chain list comprehensions using generators.
        berntb 14y ago
        You have no relevant comment on what I wrote either, I take it? Here I asked for references about the GP's claims. Also, welcome to HN (or are the prepared troll accounts with a few hundreds of Karma running out? :-) ).
- alberich 14y ago
  Actually, saying that you'll never like a given detail about a language is not the same as saying that you'll never work for company X because of that specific detail. It is not a logical conclusion, unless you are implying that for one to work for someone else you really need to like everything about the job at hand. I see no reason why you can't do something for money that you wouldn't do for your personal pleasure.

ww520 14y ago

Why won't you hire someone who has a unfavorable opinion on a language? Do you feel the same way if he mentioned Java instead of Python?

PommeDeTerre 14y ago
That's clearly not what he said. He just wants actual, technical arguments against a given language, rather than baseless claims that make no sense. I think it's quite reasonable to be suspicious of a interviewee who is against Python solely because it enforces sensible code indentation.
- alberich 14y ago
  >> I think it's quite reasonable to be suspicious of a interviewee who is against Python solely because it enforces sensible code indentation. Though saying "I don't like python's code indentation" is not the same as "I'm against python". Well, at least I see no relation between the two.

whtspcmttrs 14y ago

The "whitespace matters" business permeates other parts of the language design that contribute to Python's crappyness, like its busted scoping and lack of real lambdas. You can have it, and I don't want to work for you, anyhow.

flogic 14y ago

At least in Haskell, I don't really care for the significant white space when it's re-factoring time. I don't see how it wouldn't become more of an issue for a traditional imperative language and their tendency for large blocks.

wazoox 14y ago

That doesn't make much sense to me. Let's say if I were interviewed at some place using Java, Python, C and Go, why shouldn't I state my personal language preferences? For most things as an hiring manager I'm OK with people working with their favourite language on whatever project I assign them to (as long as it isn't too esoteric; OCaml is OK, but Haskell is probably pushing it a bit too far, for instance), except when they have to work on an existing code base, in which case I wouldn't want to hire someone hating it; they'd be miserable and the resulting code would be awful.

sylvinus 14y ago
Personal language preferences are fine if they are justified by actual reasons like tech details, community, librairies, ...
- wazoox 14y ago
  We'll talk about this Tuesday :) People usually have a very good reason to prefer the language they're more comfortable with, because it makes them more productive. Of course, it could be easy to dispell if some guy insists on writing only assembly, or C++, vs Python. I've known a guy who wrote whole Windows GUIs in assembly, it's pure madness. There are many valid technical reasons to rather choose C than Python, Java than Perl, or PHP than Go, Erlang rather than C++ ... But Perl vs Python vs Ruby? Hardly any difference, extremely similar dynamic languages. It's only a matter of personal taste at this point.