3 ms·

Almost every discussion of programming languages falls into bike-shedding[1] and this is no exception. The only thing he mentions worth talking about is the GIL

Almost every discussion of programming languages falls into bike-shedding[1] and this is no exception. The only thing he mentions worth talking about is the GIL. Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. If whitespace and using the division operator are big problems for you, significant software development probably isn't within your abilities. In addition to the GIL, other problems I'd point out with Python: 1. At one point, Python was "batteries included". This is largely no longer the case any more--most projects are largely dependent on PyPI, and there's been a growing sentiment in the last few years that "the standard library is where modules go to die". PyPI libraries are of inconsistent quality and have a high turnover rate; the "standard" for what to use changes fairly rapidly. And if you manage to make good choices of mature libraries and not have to change them every year or so, you still have to manage dependencies, which complicates deployments. 2. Fracturing community: there are now a bunch of different non-standard ways to install Python and Python dependencies, which conflict with each other, and none of which fit all use cases, so you have to use all of them and deal with conflicts. This exacerbates issues with 1. 3. Increasing dependency on non-pure-Python dependencies which don't build trivially. There are reasons for this: Python often isn't performant enough for certain tasks, and other languages have some very good tools. However, this means you can't just `pip install` a library and expect it to work--even very common libraries like Pillow don't without fiddling. Again, this exacerbates problems with 1. 4. Lack of a good desktop UI framework. It's apparent that not as many people are using Python for native UIs any more. tk is cludgy and doesn't result in pretty UIs, and despite being part of the standard library, it doesn't work out of the box on MacOS. wxWidgets doesn't build on MacOS without significant work, and documentation is for the C++ version of the library. This is sort of the intersection of 1, 2, and 3, but in desktop UIs they combine to form a perfect storm. If you're developing a desktop UI, there are better languages, but I'm not going to post them here because I'd rather keep this as a constructive criticism of Python than a language competition. 5. Introspection being used to change language syntax without solving the problems the language syntax solves. I'm really looking at Django here, but they're not the only guilty ones. When you call a function, i.e. route_on_http_method(GET=get_handler, POST=post_handler), functions can fairly easily check arguments and throw an exception from a logical spot--i.e. route_on_http_method(GIT=get_handler) throws an exception immediately. But when you have `class MyView(GenericView): def git(self, request): ...` you get no exception until you try to call the view, in which case you get a wonderful cornucopia of meaningless line numbers in a useless stack trace. Sure, Django code looks nicer and more organized, but as I said, syntax isn't that important. Debugging IS important. Using the bikeshedding example, this is breaking the nuclear power plant to fix a problem with the bike shed. And this is a generous example: it's fairly simple and Django is one of the libraries that does a better job of this. If you really want configuration-oriented programming, you'd be better off parsing in JSON files and doing explicit error checking when you parse them in, rather than introspecting out a syntax that's not really code and not really configuration. Introspection hasn't played out well as a Python feature. You'll note that all these problems are CULTURAL problems, rather than problems with the language itself. And that's my point, because those are the problems you can't easily work around, and it's the problems you can't easily work around that make or break the language. I say all this because I love Python. I've worked in Python for the last 6ish years, and don't see that changing any time soon. [1] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding

saagarjha 7y ago
> Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. I agree with the first part but not the second. One can only write arraylist.add(arraylist.size() - 1, arraylist.get(arraylist.size() - 1) + 1) before wondering if there’s a better way to do this.
- kerkeslager 7y ago
  Even if your language doesn't support a better syntax, it probably supports functions, so you don't have to write this over and over again. Just pull out into `appendLastIncremented(ArrayList a)` and call that. You'll have forgotten the pain of writing that function within an hour. I'll never forget the pain of debugging a {bar: 1}.baz returning undefined (failing silently) and then going into a future inside a minified 0.0.2 versioned library that doesn't do any constraint checking before finally throwing an exception. Nor will I forgive JavaScript for this.
  - saagarjha 7y ago
    I don’t want to write a random free function for one line of code. I want nice syntax: list[-1] += 1 array.last += 1 *(vector.end() - 1)++; Having reasonable syntax and a strong type system are not mutually exclusive.
    - kerkeslager 7y ago
      > I don’t want to write a random free function for one line of code. I want nice syntax shrug Sure, me too, everybody wants nice syntax. What I'm saying is that syntax is never the most important problem with a language. People talk about problems with syntax because they're easy to understand, and the more important problems with a language are much harder to understand and talk about. If a genie told me I could wish for three problems with Python to be instantly fixed, none of them would be syntax. I can't think of a language I've used where syntax would be on the list.

saagarjha 7y ago

> Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. I agree with the first part but not the second. One can only write arraylist.add(arraylist.size() - 1, arraylist.get(arraylist.size() - 1) + 1) before wondering if there’s a better way to do this.

kerkeslager 7y ago
Even if your language doesn't support a better syntax, it probably supports functions, so you don't have to write this over and over again. Just pull out into `appendLastIncremented(ArrayList a)` and call that. You'll have forgotten the pain of writing that function within an hour. I'll never forget the pain of debugging a {bar: 1}.baz returning undefined (failing silently) and then going into a future inside a minified 0.0.2 versioned library that doesn't do any constraint checking before finally throwing an exception. Nor will I forgive JavaScript for this.
- saagarjha 7y ago
  I don’t want to write a random free function for one line of code. I want nice syntax: list[-1] += 1 array.last += 1 *(vector.end() - 1)++; Having reasonable syntax and a strong type system are not mutually exclusive.
  - kerkeslager 7y ago
    > I don’t want to write a random free function for one line of code. I want nice syntax shrug Sure, me too, everybody wants nice syntax. What I'm saying is that syntax is never the most important problem with a language. People talk about problems with syntax because they're easy to understand, and the more important problems with a language are much harder to understand and talk about. If a genie told me I could wish for three problems with Python to be instantly fixed, none of them would be syntax. I can't think of a language I've used where syntax would be on the list.