4 ms·

With regard to your first link, I really have to take issue with code like the following as a measure of Java and Python's relative verbosity: class Artist

by Niten 14y ago

With regard to your first link, I really have to take issue with code like the following as a measure of Java and Python's relative verbosity: class Artist: def __init__(self, name): self.name = name def __str__(self): return self.name There may be an argument to, as you say, "Never, never, never use String in Java" (or other statically typed languages), but a class like this in a duck-typed language such as Python is nonsensical. I'm not even arguing that Python's dynamically typed approach is necessarily better overall than Java, but if you're going to evaluate the two in terms of verbosity then you really have to compare idiomatic code in both languages. Whereas if you continue writing Java in Python, of course you'll only see a 2x improvement.

Uchikoma 14y ago
Sorry, my Python was in the 90s, I dropped it for Java back than so my skills - even in 2008 - were not the best, as I've said in the post "Sorry that my Python is rusty, all correcting comments or comments on how to do it better are welcome." Not sure what your argument has to do with dynamically typed references? How would one create a constructor for an object that takes an argument (name)? " but a class like this in a duck-typed language such as Python is nonsensical." Does this mean people do not use classes in Python (e.g. for DDD)?
- masklinn 14y ago
  No, it means people don't usually create completely useless data-holder classes in Python. Instead they use standard collections, depending on their hierarchy of needs: tuples, dicts or namedtuples. All three of the classes in the example are basically worthless. Including SongList, which is the one with the most logic (a single line) and which you didn't even use at the end. Here's the three classes, at their most future-proof: from collections import namedtuple Song = namedtuple('Song', 'name duration artist') Artist = namedtuple('Artist', 'name') class SongList(list): pass and as a side-note, this: for song in (song for song in songList if song.duration < 10): print "%s by %s (%d)" % (song.name, song.artist, song.duration) is needlessly complex, why the comprehension? Just write a loop and a conditional: for song in songList: if song.duration < 10: print "{0.name} by {0.artist.name} ({0.duration})".format(song)
  - Uchikoma 14y ago
    Ah I see the problem, the example would need to be larger for the classes to be more than data holder classes. Do you think when the classes are larger with some logic, the ratio of Java/Python LOC would change?
    - masklinn 14y ago
      It probably depends on the work being done — matrix computations likely wouldn't be significantly shorter in Python, even with numpy — but considering the java styles I know of (rather defensive and comparatively low-level) and the Python styles I also know of, as long as your python isn't java I'd say it should remain significantly shorter. Not as short as replacing 20 LOC by a single namedtuple, that's a bit extreme, but 2x is what I expect of (mostly) translating java code into python, that's the rough overhead of the language itself when saying the same thing the same way.
      - Uchikoma 14y ago
        "[..] as long as your python isn't java I'd say it should remain significantly shorter." My intent with the post was to create empiric knowledge, I'm not a follower of the idea anecdotal 'evidence' trumps all that is pervasive in our industry. So thanks for your opinion, but I'm not interested in the least in anecdotes when comparing languages.
    - Niten 14y ago
      In truth, I wouldn't use anything other than a plain Python string to represent an artist's name, if that's the only thing about the artist you're interested in. But it's hard to have a meaningful conversation about such a contrived example as in that link. To answer your question, though, yes: all other arguments about Python vs. Java aside, the LOC ratio would change dramatically in Python's favor once you start to add actual program logic. (Unless you're stuck with an architecture astronaut for a Python programmer.)

by Niten 14y ago

Uchikoma 14y ago

Sorry, my Python was in the 90s, I dropped it for Java back than so my skills - even in 2008 - were not the best, as I've said in the post "Sorry that my Python is rusty, all correcting comments or comments on how to do it better are welcome." Not sure what your argument has to do with dynamically typed references? How would one create a constructor for an object that takes an argument (name)? " but a class like this in a duck-typed language such as Python is nonsensical." Does this mean people do not use classes in Python (e.g. for DDD)?

masklinn 14y ago
No, it means people don't usually create completely useless data-holder classes in Python. Instead they use standard collections, depending on their hierarchy of needs: tuples, dicts or namedtuples. All three of the classes in the example are basically worthless. Including SongList, which is the one with the most logic (a single line) and which you didn't even use at the end. Here's the three classes, at their most future-proof: from collections import namedtuple Song = namedtuple('Song', 'name duration artist') Artist = namedtuple('Artist', 'name') class SongList(list): pass and as a side-note, this: for song in (song for song in songList if song.duration < 10): print "%s by %s (%d)" % (song.name, song.artist, song.duration) is needlessly complex, why the comprehension? Just write a loop and a conditional: for song in songList: if song.duration < 10: print "{0.name} by {0.artist.name} ({0.duration})".format(song)
- Uchikoma 14y ago
  Ah I see the problem, the example would need to be larger for the classes to be more than data holder classes. Do you think when the classes are larger with some logic, the ratio of Java/Python LOC would change?
  - masklinn 14y ago
    It probably depends on the work being done — matrix computations likely wouldn't be significantly shorter in Python, even with numpy — but considering the java styles I know of (rather defensive and comparatively low-level) and the Python styles I also know of, as long as your python isn't java I'd say it should remain significantly shorter. Not as short as replacing 20 LOC by a single namedtuple, that's a bit extreme, but 2x is what I expect of (mostly) translating java code into python, that's the rough overhead of the language itself when saying the same thing the same way.
    - Uchikoma 14y ago
      "[..] as long as your python isn't java I'd say it should remain significantly shorter." My intent with the post was to create empiric knowledge, I'm not a follower of the idea anecdotal 'evidence' trumps all that is pervasive in our industry. So thanks for your opinion, but I'm not interested in the least in anecdotes when comparing languages.
  - Niten 14y ago
    In truth, I wouldn't use anything other than a plain Python string to represent an artist's name, if that's the only thing about the artist you're interested in. But it's hard to have a meaningful conversation about such a contrived example as in that link. To answer your question, though, yes: all other arguments about Python vs. Java aside, the LOC ratio would change dramatically in Python's favor once you start to add actual program logic. (Unless you're stuck with an architecture astronaut for a Python programmer.)