Hacker News Reader

Comment by mapgrep | Hacker News Reader

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.

View on HN

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.)

>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.

>> 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.

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?

Also numba. It is a multithreaded JIT compiler for a subset of python code. Just need a decorator.

PyPy also has a GIL. Their proposal to get rid of it (PyPy STM) is far from being ready for production and comes with a pretty important overhead: http://pypy.readthedocs.org/en/latest/stm.html#introduction

(but it's a really promising project that all Python developers should follow!)

You can deal with the GIL, it's not the death sentance some people think it is, I agree.

But this guy actually DOES try to argue it's a _positive_ somehow! He really is claiming it's all unicorns and rainbows, he doesn't mention _any_ negative to it, he says it doesn't effect concurrency at all, look at generators and deferreds that proves it (not true, a misdirection), he even tries to say it's a positive, the "GIL is a performance optimization for most use cases of Python, and a development ease optimization for virtually all CPython code. The GIL makes it much easier to use OS threads"

I think either this is an intellectually dishonest argument meant to confuse less-technical people, or the guy doesn't understand what he's talking about.

And I still think python is probably fine for 'enterprise', although as always it depends on what you're doing with it!

The GIL absolutely makes it easier to use OS threads in terms of development ease, but the "performance optimization" piece I can't really see, except insofar as the development ease aspect means that developers are less likely to avoid using threads where they would provide a performance benefit.

"The GIL absolutely makes it easier to use OS threads in terms of development ease"

Yes, but pretending that you can have the ease of not worrying about thread safety while still having the performance benefits of multi-threading (real OS threads, mind you) is ridiculous. You can't have your cake and eat it too.

You can have the ease with some of the performance benefits with the GIL (since the GIL is released in certain low level operations) -- because, for the things where you get the performance benefits, someone else has dealt with the pain of not having the ease.

I think the performance comment is in regard to the single-threaded common case. The reason the GIL is still around is that Guido has said that a replacement is only acceptable if it avoids performance regressions for single-threaded code. Most of the Python world seems to have concluded that that's not possible in practice.

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.

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?"

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.

For what it's worth:

https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

Optionals are part of Java 8.

It's in Java 8. java.util.Optional<T>

Still a library but at least it's part of the standard library.

> If you remove the cons you would probably also lose some of the pros.

Especially true of Lisps, of course.

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.

Reply on news.ycombinator.com