5 ms·

If you want me to trust what you say about a language — or any technology, actually — be forthright about its deficiencies. Because I don't believe you really,

by mapgrep 12y ago

If you want me to trust what you say about a language — or any technology, actually — be forthright about its deficiencies. Because I don't believe you really, truly understand a language until you can tell me what sucks about it. It takes significant time (in a reasonably decent language) to discover the corner cases, performance bottlenecks, quirks, big-deficiencies-hidden-in-plain-sight and outright bugs in a language like, say, python. Something as "rah-rah" this, which goes so far as to basically call the GIL a source of unicorns and rainbows, is convincing almost in inverse proportion to its stridency. Suddenly I'm wondering if all these "myths" about python might be smoke pointing toward a fire. That's probably a bit unfair, but it's hard to know what to take seriously when you're listening to a voice that's less than credible.

patrickmay 12y ago
This is one of my favorite questions when interviewing software developers: "What is your favorite language and why?" Followed by: "Tell me what you would change about it if you could." It's a good fanboy filter.
- ravishi 12y ago
  I would just answer "Nothing." Because, really, it isn't just because a language has it's deficiencies that I would want to change that. That would probably result in a new language, which is not desirable. Usually a language is what it is because of it's pros, which unfortunately happens to create the cons. If you remove the cons you would probably also lose some of the pros. So, I think a better question would be: "And what wouldn't you use [language] for? Why?" Or, if you want to sound cool, "What do you hate about it?"
  - krschultz 12y ago
    Not exactly. I use Guava's Optional frequently when writing Java. It really helps take care of the null problem. It doesn't change the language significantly. However, I really wish it was part of the language instead of a library. Other libraries typically don't return Optionals which forces me to add even more lines of code protecting against nulls. edit: s/Java/Android Java/, unfortunately the spat between Oracle & Google has prevented most of Java 7 & all of Java 8 from being incorporated into Android Java, which is what I work with on a daily basis.
    - Niten 12y ago
      For what it's worth: https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
    - rcconf 12y ago
      Optionals are part of Java 8.
    - anthony_d 12y ago
      It's in Java 8. java.util.Optional<T> Still a library but at least it's part of the standard library.
  - JimmyM 12y ago
    > If you remove the cons you would probably also lose some of the pros. Especially true of Lisps, of course.
  - odonnellryan 12y ago
    There are some cases that won't change the language. Python can easily add better support for static analysis without changing the language at all. I shouldn't have to do this: """ :type member_list: list of [string] """ To have that hinting. I know this is getting better, but it isn't to the point of being very useful.
crdoconnor 12y ago
>Something as "rah-rah" this, which goes so far as to basically call the GIL a source of unicorns and rainbows The GIL is definitely no source of unicorns and rainbows, but I think the case against it is usually overstated. There are numerous ways of sidestepping it (multiprocessing, pypy, C extensions, etc.), and it does serve a useful purpose.
- w0utert 12y ago
  >> The GIL is definitely no source of unicorns and rainbows, but I think the case against it is usually overstated. There are numerous ways of sidestepping it (multiprocessing, pypy, C extensions, etc.), and it does serve a useful purpose. That's definitely all true, but the article brushes it's implications for multithreaded Python off as if they don't exist, which is what one of the posters above me was probably referring to. Yes you can do multiprocessing, but if I have lots of shared, volatile state that's not what I want. Yes you can use PyPy, but if that doesn't work for some python framework I use, or if I can't control my deployment environment and it only has CPython I can't use PyPy. Obviously you can write C extensions for about any language, using that as an arguments why the GIL is not a problem for multithreaded Python is disingenuous. Maybe I don't know or don't like to program in C? Green threads are not a substitute for multi-threading either, as they still don't allow full utilization of multiple cores and are really only a solution for I/O bound processing. Of the 'numerous ways to sidestep the GIL' none are satisfactory if you have a CPU bound problem operating on shared state, that lends itself well to parallel execution, which are many. I wouldn't use Python to write a video codec or to do DNA sequence processing for example. It's not a fatal flaw for Python-as-a-language, but it's a flaw of CPython nonetheless, and not an insignificant one.
  - crdoconnor 12y ago
    I wouldn't write a video codec in python either, nor would I write code that requires a huge amount of shared volatile state, but these things are not common coding tasks in general, particularly not in enterprisey-type programming. > Maybe I don't know or don't like to program in C? If you want to write a video codec or highly performant multithreaded code, you should probably give it a go. >Of the 'numerous ways to sidestep the GIL' none are satisfactory if you have a CPU bound problem operating on shared state, that lends itself well to parallel execution, which are many. You mean exactly like the matrix calculations done in the C extensions of numpy?
johan_larson 12y ago
I've had a chance to use Python several times in various projects. The language really excelled at small projects, where the expressiveness of the language and the excellent libraries available really let us get a lot done with little code and time. Avoiding the recompile/redeploy steps also helped. But using the language for larger projects was quite a different thing. Suddenly you could find yourself in code several layers down, being passed an object of God knows what type from unfamiliar code, and having to find out what you were receiving essentially by trial and error. And once the execution times started to climb, it became increasingly frustrating to see trivial problems that would have been caught during compilation in a statically typed language appear in Python only after 30-60 minutes of execution. There are surely ways to alleviate these specific problems -- I can think of some things to try myself -- but my experience suggests that the sweet spot for dynamic languages like Python is in projects that fit between one pair of ears, and stricter statically typed languages become increasingly useful as things scale up. (Hardly a radical position, I know.)

by mapgrep 12y ago

patrickmay 12y ago

This is one of my favorite questions when interviewing software developers: "What is your favorite language and why?" Followed by: "Tell me what you would change about it if you could." It's a good fanboy filter.

ravishi 12y ago
I would just answer "Nothing." Because, really, it isn't just because a language has it's deficiencies that I would want to change that. That would probably result in a new language, which is not desirable. Usually a language is what it is because of it's pros, which unfortunately happens to create the cons. If you remove the cons you would probably also lose some of the pros. So, I think a better question would be: "And what wouldn't you use [language] for? Why?" Or, if you want to sound cool, "What do you hate about it?"
- krschultz 12y ago
  Not exactly. I use Guava's Optional frequently when writing Java. It really helps take care of the null problem. It doesn't change the language significantly. However, I really wish it was part of the language instead of a library. Other libraries typically don't return Optionals which forces me to add even more lines of code protecting against nulls. edit: s/Java/Android Java/, unfortunately the spat between Oracle & Google has prevented most of Java 7 & all of Java 8 from being incorporated into Android Java, which is what I work with on a daily basis.
  - Niten 12y ago
    For what it's worth: https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
  - rcconf 12y ago
    Optionals are part of Java 8.
  - anthony_d 12y ago
    It's in Java 8. java.util.Optional<T> Still a library but at least it's part of the standard library.
- JimmyM 12y ago
  > If you remove the cons you would probably also lose some of the pros. Especially true of Lisps, of course.
- odonnellryan 12y ago
  There are some cases that won't change the language. Python can easily add better support for static analysis without changing the language at all. I shouldn't have to do this: """ :type member_list: list of [string] """ To have that hinting. I know this is getting better, but it isn't to the point of being very useful.

crdoconnor 12y ago

>Something as "rah-rah" this, which goes so far as to basically call the GIL a source of unicorns and rainbows The GIL is definitely no source of unicorns and rainbows, but I think the case against it is usually overstated. There are numerous ways of sidestepping it (multiprocessing, pypy, C extensions, etc.), and it does serve a useful purpose.

w0utert 12y ago
>> The GIL is definitely no source of unicorns and rainbows, but I think the case against it is usually overstated. There are numerous ways of sidestepping it (multiprocessing, pypy, C extensions, etc.), and it does serve a useful purpose. That's definitely all true, but the article brushes it's implications for multithreaded Python off as if they don't exist, which is what one of the posters above me was probably referring to. Yes you can do multiprocessing, but if I have lots of shared, volatile state that's not what I want. Yes you can use PyPy, but if that doesn't work for some python framework I use, or if I can't control my deployment environment and it only has CPython I can't use PyPy. Obviously you can write C extensions for about any language, using that as an arguments why the GIL is not a problem for multithreaded Python is disingenuous. Maybe I don't know or don't like to program in C? Green threads are not a substitute for multi-threading either, as they still don't allow full utilization of multiple cores and are really only a solution for I/O bound processing. Of the 'numerous ways to sidestep the GIL' none are satisfactory if you have a CPU bound problem operating on shared state, that lends itself well to parallel execution, which are many. I wouldn't use Python to write a video codec or to do DNA sequence processing for example. It's not a fatal flaw for Python-as-a-language, but it's a flaw of CPython nonetheless, and not an insignificant one.
- crdoconnor 12y ago
  I wouldn't write a video codec in python either, nor would I write code that requires a huge amount of shared volatile state, but these things are not common coding tasks in general, particularly not in enterprisey-type programming. > Maybe I don't know or don't like to program in C? If you want to write a video codec or highly performant multithreaded code, you should probably give it a go. >Of the 'numerous ways to sidestep the GIL' none are satisfactory if you have a CPU bound problem operating on shared state, that lends itself well to parallel execution, which are many. You mean exactly like the matrix calculations done in the C extensions of numpy?

johan_larson 12y ago

I've had a chance to use Python several times in various projects. The language really excelled at small projects, where the expressiveness of the language and the excellent libraries available really let us get a lot done with little code and time. Avoiding the recompile/redeploy steps also helped. But using the language for larger projects was quite a different thing. Suddenly you could find yourself in code several layers down, being passed an object of God knows what type from unfamiliar code, and having to find out what you were receiving essentially by trial and error. And once the execution times started to climb, it became increasingly frustrating to see trivial problems that would have been caught during compilation in a statically typed language appear in Python only after 30-60 minutes of execution. There are surely ways to alleviate these specific problems -- I can think of some things to try myself -- but my experience suggests that the sweet spot for dynamic languages like Python is in projects that fit between one pair of ears, and stricter statically typed languages become increasingly useful as things scale up. (Hardly a radical position, I know.)