5 ms·

It’s the same feeling I have watching people work in Java; their IDE and whole language development experience is a tier above Python. I am surprised that the w

It’s the same feeling I have watching people work in Java; their IDE and whole language development experience is a tier above Python. I am surprised that the world decided on Python as the informal lingua franca of science.

mafribe 7y ago
It's a short-term vs long-term trade-off. Learning a dynamically typed language like Python is moderately easier than learning a statically typed language, especially old-fashioned languages like Java without type inference. OTOH using a statically typed language, once you've learned how to handle it, makes for a more powerful software engineering experience, but you'll have to climb the hill of typing first.
- ken 7y ago
  How tall is that hill? I wrote C# professionally every day for 3.5 years. The last day was as painful as the first. I can appreciate making an investment in tools that make me more productive in the long run, but at some point it has to start paying off. Programming languages have finite useful lifetimes. Common Lisp took me years to learn well, too, but it started paying big dividends after only a couple weeks.
  - threatofrain 7y ago
    Are you still a Common Lisper, and what do you use it for?
- friedman23 7y ago
  People don't use dynamic typing over static typing because dynamic typing is "easier" to learn. Types are not a difficult concept.
inertiatic 7y ago
It was very surreal moving from a team using idea for java development to a team using vim for python development. A lot of the smartest people are super productive and super considerate of all the possible codepaths when making changes. Bugs still occur due to statically discoverable coding errors. Just how much harder it is to navigate a new codebase is staggering.
- mixmastamyk 7y ago
  There are many tools available outside the editor as well as testing to catch these errors.
sverhagen 7y ago
As a Java developer, I still like Python as a language for small to medium-sized programs, or: scripts, if your will. To me, it's just quick to iterate. The condition is, though, that I need to be able to quickly run the program to validate just all of it to work. In other words, when it comes to test coverage and longevity and reliable refactoring it gets hard. I'm sure these things are possible in Python too (I know there's testing frameworks, although it seems more of an eclectic mess than Java, which seems to have mostly settled on a small set of established testing libraries instead) but somehow the Python projects I stumbled upon have less of a testing and thus maintainability culture than the Java projects I stumbled upon. I have often wondered why that is, and I keep getting back to culture. Maybe that's too simple, and maybe the testing is just fine for business applications, and maybe my general usage of Python is too much command-like scripting, where testing and mocking is just a little harder to do...
- ptx 7y ago
  Python has the unittest module, which is a port of JUnit, in the standard library. (And a mocking library as well.) The other popular testing library is pytest. So that's more choices than in Java but fewer than in C#.
  - jfim 7y ago
    > So that's more choices than in Java but fewer than in C#. There are far more unit testing libraries available on the JVM than just JUnit.
    - sverhagen 7y ago
      For the combination of JUnit, Mockito, Hamcrest, Rest Assured and Spring Test (each of which playing its own role in testing) I am able to more-reliably find answers than for the combinations of Python libraries that I seem to run into. They may be less in absolute numbers, but if (my perception) they appear in too many permutations, it's often hard to find the right answers.
      - 7y ago
discreteevent 7y ago
I think it may be partly to do with the fact that a lot of people do not like using an IDE. Then they don't get as much of the benefit. (Particularly a few years ago there was a lot of negativity about IDEs on forums like this)
smitty1e 7y ago
Petzold offered the canonical IDE rant => http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...
mixmastamyk 7y ago
Unfortunately to get that tier you have to put up with a gargantuan high-latency IDE that thinks a lot. Helpful yes, but not a clear win on non-huge projects.
coldtea 7y ago
>their IDE and whole language development experience is a tier above Python. I am surprised that the world decided on Python as the informal lingua franca of science. That's because that however good the IDEs are, their language is full of ceremony and stiff-OO abstractions, and Python can achieve in 10 lines what takes Java 100. Plus it interfaces much better with C/C++/Fortran/etc code, which serious data science libraries are written in. This makes it much better fit for science than Java. Plus a lot if not most of science code is short scripts and one-off. So the benefits of types for larger projects etc don't come in at all. Unlike enterprise users, scientists wanting to write a program don't have no time for 100 lines of ceremonial crap to make it look "enterprisy" or have much tolerance for a language with much less expressive power.

mafribe 7y ago

It's a short-term vs long-term trade-off. Learning a dynamically typed language like Python is moderately easier than learning a statically typed language, especially old-fashioned languages like Java without type inference. OTOH using a statically typed language, once you've learned how to handle it, makes for a more powerful software engineering experience, but you'll have to climb the hill of typing first.

ken 7y ago
How tall is that hill? I wrote C# professionally every day for 3.5 years. The last day was as painful as the first. I can appreciate making an investment in tools that make me more productive in the long run, but at some point it has to start paying off. Programming languages have finite useful lifetimes. Common Lisp took me years to learn well, too, but it started paying big dividends after only a couple weeks.
- threatofrain 7y ago
  Are you still a Common Lisper, and what do you use it for?
friedman23 7y ago
People don't use dynamic typing over static typing because dynamic typing is "easier" to learn. Types are not a difficult concept.

inertiatic 7y ago

It was very surreal moving from a team using idea for java development to a team using vim for python development. A lot of the smartest people are super productive and super considerate of all the possible codepaths when making changes. Bugs still occur due to statically discoverable coding errors. Just how much harder it is to navigate a new codebase is staggering.

mixmastamyk 7y ago
There are many tools available outside the editor as well as testing to catch these errors.

sverhagen 7y ago

As a Java developer, I still like Python as a language for small to medium-sized programs, or: scripts, if your will. To me, it's just quick to iterate. The condition is, though, that I need to be able to quickly run the program to validate just all of it to work. In other words, when it comes to test coverage and longevity and reliable refactoring it gets hard. I'm sure these things are possible in Python too (I know there's testing frameworks, although it seems more of an eclectic mess than Java, which seems to have mostly settled on a small set of established testing libraries instead) but somehow the Python projects I stumbled upon have less of a testing and thus maintainability culture than the Java projects I stumbled upon. I have often wondered why that is, and I keep getting back to culture. Maybe that's too simple, and maybe the testing is just fine for business applications, and maybe my general usage of Python is too much command-like scripting, where testing and mocking is just a little harder to do...

ptx 7y ago
Python has the unittest module, which is a port of JUnit, in the standard library. (And a mocking library as well.) The other popular testing library is pytest. So that's more choices than in Java but fewer than in C#.
- jfim 7y ago
  > So that's more choices than in Java but fewer than in C#. There are far more unit testing libraries available on the JVM than just JUnit.
  - sverhagen 7y ago
    For the combination of JUnit, Mockito, Hamcrest, Rest Assured and Spring Test (each of which playing its own role in testing) I am able to more-reliably find answers than for the combinations of Python libraries that I seem to run into. They may be less in absolute numbers, but if (my perception) they appear in too many permutations, it's often hard to find the right answers.
    - 7y ago

discreteevent 7y ago

I think it may be partly to do with the fact that a lot of people do not like using an IDE. Then they don't get as much of the benefit. (Particularly a few years ago there was a lot of negativity about IDEs on forums like this)

smitty1e 7y ago

Petzold offered the canonical IDE rant => http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...

mixmastamyk 7y ago

Unfortunately to get that tier you have to put up with a gargantuan high-latency IDE that thinks a lot. Helpful yes, but not a clear win on non-huge projects.

coldtea 7y ago

>their IDE and whole language development experience is a tier above Python. I am surprised that the world decided on Python as the informal lingua franca of science. That's because that however good the IDEs are, their language is full of ceremony and stiff-OO abstractions, and Python can achieve in 10 lines what takes Java 100. Plus it interfaces much better with C/C++/Fortran/etc code, which serious data science libraries are written in. This makes it much better fit for science than Java. Plus a lot if not most of science code is short scripts and one-off. So the benefits of types for larger projects etc don't come in at all. Unlike enterprise users, scientists wanting to write a program don't have no time for 100 lines of ceremonial crap to make it look "enterprisy" or have much tolerance for a language with much less expressive power.