4 ms·

It is true that console applications would have different constraints. But GUI applications written in Python, like 'Ubuntu Software Center', were also percepti

It is true that console applications would have different constraints. But GUI applications written in Python, like 'Ubuntu Software Center', were also perceptibly slow last time I checked. yum vs apt-get was a quick comparison I could show. I find yum very annoying compared to apt-get/pacman. The author wants more Pythonic GUI apps because s/he thinks it produces more readable code. It has been argued that such code can be slower ( http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/ http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r... ) and maybe it will lead to trading too much developer pleasure for user pleasure.

andybak 10y ago
> maybe it will lead to trading too much developer pleasure for user pleasure. In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing. It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.
- TeMPOraL 10y ago
  > much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option And the world would be much better if that happened. Seriously, the primary driver for the "developer-time offset" is the race-to-the-bottom competition between companies on who releases the app first, driven by the assumption that in this market the winner takes all. Maybe it is the case (though my impression is that people tend to gravitate to better software over time), but then there are markets without such a huge competitive pressure. Like package managers for Linux-based systems. Seriously, there is no reason for not doing them right (except of course the Unix philosophy being that not doing things right is the Right Thing).
  - andybak 10y ago
    > Seriously, the primary driver for the [...] So to summarise - no-one would choose Python for building GUI apps if it wasn't for the obsession modern companies have with being first-to-market? If I've been unfair or misunderstood then can you please explain a bit more clearly how we got from a discussion about using Python for GUI applications to a statement that it's somehow about commercial pressures to release an app. It certainly doesn't match my own reasons for learning and using Python or those of anyone I've met.
    - TeMPOraL 10y ago
      I was addressing your mobile / web vs. native angle. In those markets, in my opinion many of the products, having to choose between being done right or not being done at all would do better if they chose the second option. I don't have anything against Python per se. Sure, it isn't the fastest language out there (even considering the high-level features it provides), but rarely the problem with application performance lies squarely with Python. It's more often about not putting time to "make it good" and "make it fast" after "making it work". Especially with - from what I hear, quite good - FFI capabilities of Python, in the worst case one could always push the most intensive computations down to C.
      - andybak 10y ago
        Ah. I see. I was conflating your reply with the grandfather. With regard to mobile apps - I was thinking more about non-commercial or hobbyist apps - the interesting, quirky or niche.

andybak 10y ago

> maybe it will lead to trading too much developer pleasure for user pleasure. In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing. It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.

TeMPOraL 10y ago
> much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option And the world would be much better if that happened. Seriously, the primary driver for the "developer-time offset" is the race-to-the-bottom competition between companies on who releases the app first, driven by the assumption that in this market the winner takes all. Maybe it is the case (though my impression is that people tend to gravitate to better software over time), but then there are markets without such a huge competitive pressure. Like package managers for Linux-based systems. Seriously, there is no reason for not doing them right (except of course the Unix philosophy being that not doing things right is the Right Thing).
- andybak 10y ago
  > Seriously, the primary driver for the [...] So to summarise - no-one would choose Python for building GUI apps if it wasn't for the obsession modern companies have with being first-to-market? If I've been unfair or misunderstood then can you please explain a bit more clearly how we got from a discussion about using Python for GUI applications to a statement that it's somehow about commercial pressures to release an app. It certainly doesn't match my own reasons for learning and using Python or those of anyone I've met.
  - TeMPOraL 10y ago
    I was addressing your mobile / web vs. native angle. In those markets, in my opinion many of the products, having to choose between being done right or not being done at all would do better if they chose the second option. I don't have anything against Python per se. Sure, it isn't the fastest language out there (even considering the high-level features it provides), but rarely the problem with application performance lies squarely with Python. It's more often about not putting time to "make it good" and "make it fast" after "making it work". Especially with - from what I hear, quite good - FFI capabilities of Python, in the worst case one could always push the most intensive computations down to C.
    - andybak 10y ago
      Ah. I see. I was conflating your reply with the grandfather. With regard to mobile apps - I was thinking more about non-commercial or hobbyist apps - the interesting, quirky or niche.