Live data from Hacker News

2019 Python Developer Survey

pyfound.blogspot.com

21–30 of 34 posts

Re: 2019 Python Developer Survey

#21

Even if (or especially if) you are not on the latest and greatest Python version(s), I think it is still valuable to take the survey. We are locked in at 2.6 no matter what on one of our projects. We slowly whittle it away into other services, but making it modern is not feasible.

The reality is that Python2 and Python3 are really two different languages, not unlike C and C++. This is being recognized more as time passes. Should Python2 be consigned to history? Should C have been? I'm not so sure now. Python3 has a lot more to know , but not necessarily a lot more that's useful for what I do.

Try to compile any post C89 code with a C++ compiler to see how far you will go.

And even then there is stuff like implicit conversions or the ?: operator, whose semantics differ between C and C++.

Re: 2019 Python Developer Survey

#22

Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language? I’ve been thinking quite a bit about how it seems that despite how fun Python is to write the dynamic types are really just a determinant with upsides that are essentially anecdotal. Why would one take a performance hit and give up a type system without hard evidence that there would…

> Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language?

You are asking for hard data on a badly defined question. What kind of benefits are you talking about? Does learning curve count? Does speed of development and prototyping count? Does lack of build/compile cycle count?

If I want to run analysis on some data or play around with a machine learning model or actually do any other "I just wanna see what happens" type of experiment, python provides a lot of advantages over a lot of other languages.

If I want to create a simple set of REST style fetch-from-db-and-return-JSON APIs, python is great. There are other options, like Go and Node, but Python is pretty good.

There are other scenarios like this, but these two are the first ones that come to my mind.

I am currently working on a medium sized python project (about 25K LOC or so) and I am starting to think of rewriting some of the key pieces in a compiled, statically typed language for better performance and maintainability. But I feel that at this size and smaller I still have the benefits of quick development cycle.

Re: 2019 Python Developer Survey

#23

Earlier quoted context omitted.

The way they implemented type hinting has been a huge turn off to me. What are your thoughts?

What in particular? Do you have any suggestions on how you would like it to work?

The syntax is what gets me... it's so unpythonic. Like the walrus operator... No thanks!

Re: 2019 Python Developer Survey

#24
post #6

No questions about mypy?

The way they implemented type hinting has been a huge turn off to me. What are your thoughts?

I think overall it is still very immature, I wish there was someone more competent who lead the project. Its not just a lack of resources to blame for its many shortcomings in my opinion.

* the syntax is obtuse and limited on a completely arbitrary restriction of not wanting to extend the parser. (The idea of decoupling type annotations from the type checking implementation is completely insane)

* in most situations you will not know if mypy actually does anything on any given line of code or silently ignores it. There are some options to enable more strict checking but that is almost completely useless because...

* most/all libraries (even standard library) packages have none or very few type annotations (stubs) available and this will likely never actually get better due to its aforementioned incompetent design.

* there is a huge amount of tiny little annoyances and mistakes in the design of the type system you will stumble on when working with it on any large scale

* the mypy type inference (or lack thereof) is terrible, compare it with type inference in C++ (auto) or Rust to see the difference to a competently done type system.

* the mypy software itself has a history of a huge amount of bugs and regressions speaking to its immaturity (1,130 open issues in github at the moment)

I feel most people who will defend mypy no matter what, have probably not had the "pleasure" of using it in a significantly large codebase.

But... I still use it, people should still use it, shitty static code analysis is still better than nothing.

Re: 2019 Python Developer Survey

#25
I think the python ‘developers’ this survey targets is only the tip of the iceberg.

I’ve been using python for 15+ years, writing production tools, yet I’m not a developer and this is not the focus of my job. I expect there are vast numbers of Python coders out there who develop meaningful tools using Python and know the language well, but whose main activity is not software dev.

Clearly, the survey reflects the audience targeted by JetBrains i.e. web and data scientists - whatever the latter really means.

Re: 2019 Python Developer Survey

#26

Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language? I’ve been thinking quite a bit about how it seems that despite how fun Python is to write the dynamic types are really just a determinant with upsides that are essentially anecdotal. Why would one take a performance hit and give up a type system without hard evidence that there would…

As someone who has been working in the _same_ python codebase for near a decade (off and on, it is an ancillary internal service with ~150k lines of code that does not get enough love), I speak from experience when I say that any service being maintained needs to have static typing. `def foo(bar)` - what _is_ bar?! What can I do with it? I either get to dig up and up the stack or pull out a debugger. Additionally, in python, you can iterate over a string or a list, so now you have to protect against both being passed in. Even this simple thing has caused many-o-bug in my experience. Half the tests are type validations.

Re: 2019 Python Developer Survey

#27

Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language? I’ve been thinking quite a bit about how it seems that despite how fun Python is to write the dynamic types are really just a determinant with upsides that are essentially anecdotal. Why would one take a performance hit and give up a type system without hard evidence that there would…

Developper productivity is order of magnitude more important than performance on most software. Dynamic typing is by design more productive at first. Static type systems might allow better productivity on the long term (maintenability, scalability of à big, complex codebase). If this advantage of static typing is a myth, or a truth (and by how much does it increase average productivity, for which project size?) is a…

Having cut my professional teeth on php, perl, ruby, and python, I find no reduced speed working in Go. In fact, I think it is faster to develop in Go. The only time this is not the case is very simple run-once scripts where I don't need tests, and even then I'm not convinced that python is faster.

Re: 2019 Python Developer Survey

#28
post #21

Earlier quoted context omitted.

The reality is that Python2 and Python3 are really two different languages, not unlike C and C++. This is being recognized more as time passes. Should Python2 be consigned to history? Should C have been? I'm not so sure now. Python3 has a lot more to know , but not necessarily a lot more that's useful for what I do.

Try to compile any post C89 code with a C++ compiler to see how far you will go. And even then there is stuff like implicit conversions or the ?: operator, whose semantics differ between C and C++.

Indeed, C and C++ have always been two different languages. Hence the "not unlike".

I still occasionally see people trying to compile or link C++ with 'gcc'. Does that work? Maybe or even most of the time, but doing that is a sin.

Re: 2019 Python Developer Survey

#29
post #18

Earlier quoted context omitted.

The reality is that Python2 and Python3 are really two different languages, not unlike C and C++. This is being recognized more as time passes. Should Python2 be consigned to history? Should C have been? I'm not so sure now. Python3 has a lot more to know , but not necessarily a lot more that's useful for what I do.

It's the paradox of the heap. Should Python 2.6 be considered a different language than Python 2.7? What about Python 1.6 and Python 2.0? Perl 5 and Perl 6? What's the exact amount of changes necessary to switch between "new version of the same language" and "new language"? You might thing that the answer is "breaking changes", but every change breaks someone's workflow ( https://xkcd.com/1172/ ), and even a minor re…

I consider Python 2.latest to be the same language as Python 1.5.2, which was the first I used. They are upward compatible, aside from very small and presumably unavoidable changes.

Python 3 is pretty similar, but nonetheless is very different, thinking of it as the same language will cause you grief. Modern advice is to use the 'python2' and 'python3' commands--never just 'python'.

Re: 2019 Python Developer Survey

#30

Seems like the survey was HEAVILY weighted to learn about how people use python for web / big data / cloud. As an embedded stick-in-the-mud Python2 developer, I'm mildly frustrated. It seems that the python community has been taken over by people trying to compete with NodeJS. Other use cases exist!

I learned Python in 2011 for a Django project.

> embedded stick-in-the-mud Python2 developer

Python (CPython) is also getting crowded out on the low-end thanks to native languages getting easier: Rust, Go, even modern C++.

Post reply on HN