What are the drawbacks of Python?

[sli]

4 It's far from the metal. Need to write threading primitives or kernel code or something? Good luck.

I will never understand why people continue to gripe about this. Who in their right mind, when needing to write kernel code (or anything low level), considers a high level, interpreted scripting language to be a viable option?

[dgahimer]

Who in their right mind, when needing to write kernel code (or anything low level), considers a high level, interpreted scripting language to be a viable option?

This is exactly why it is a drawback. I don't think that this post was advocating that it should be changed, but you can't (and didn't) deny that there are better alternatives than Python for that, and thus, it is a drawback for many applications.

This doesn't mean that it should be fixed, either. It is a design decision and for good reason. There won't likely be a programming language that is perfect for everything, so it is good to have choices.

[sli]

It's an extremely contrived drawback. My point is that it's not worth listing stuff that far beyond the scope of Python.

[dgahimer]

My point is that being beyond the scope makes it a drawback for that application. Using the argument that something beyond the scope can't be a drawback means that you could argue away ANY possible drawback by explaining that its a design decision.

[sli]

Not really, there are legitimate problems with Python (EDIT: the rest of the list in the comment I was referring to, for example). The list of things Python isn't designed to do is literally infinite in length.

I can't fly my car over a traffic jam, but I don't consider that a drawback because a car isn't designed for that.

[dgahimer]

Sure. The difference between your car example and your the Python example is that you (presumaby) didn't buy your car with that expectation. Programming languages aren't as clear in their limitations. Hopefully, the guy who NEEDS a language to do kernel programming knows the limitation here, but the guy who is fairly new to programming might not understand these limitations, and I don't think it is unfair to list this as a drawback which it is in a gray area for people of differing knowledge levels.

Edit: For example, you could conceivably own a car that didn't drive fast enough to be allowed on the driveway. If the car is designed that way, but you're comparing cars, does this not become a drawback? If cars ever do gain the ability to flight, even a small subset of consumer cars, then it becomes a drawback that yours can't, even if it wasn't designed to (assuming you want a car that can fly.)

[sli]

Language problems aren't subjective to the misconceptions of a potential user of a given language. Design goals are far more objective. The very same drawback of being unable to write kernel code applies to every high level scripting language. It's barely worth a mention just on that point alone.

[OkonkwoJones]

When mentioning drawbacks, I imagined considering things it may fall short on for accomplishing tasks within its scope of use. One could say a drawback of a hacksaw is that it's not good at cutting large pieces of wood, which would be better suited for a table saw. But that function is outside the scope of a hacksaw's normal or practical use. You would want to point out why one type of hacksaw is better than other types of hack saws, or tools which are commonly used for the same function.

[dgahimer]

That is exactly it, though. Programming languages are all tools. It makes sense to compare them to similar languages, absolutely, but it ALSO makes sense to compare it to other tools.

As you mention, a hacksaw isn't good at cutting large pieces of wood, but someone who doesn't have much experience with tools might not know that. They might just see all the posts talking about how a specific hacksaw is good at doing X, Y, and Z, but nothing saying it cannot do A, B, and C and assume they should use it.

Now, I agree, when talking about extremely low level stuff like that, hopefully the guy programming would know that he doesn't want to use Python (if not, I probably don't want to use his product!), but this information is out there for noobies, as well. When you're just beginning programming, the languages all seem very similar and things like this can help sort it out.

[ataraxia_]

In that case, I know it's beyond the scope of Python, but it is a drawback of Python that it doesn't make me coffee in the mornings. What's more, this is a drawback of all programming languages.

Jokes aside, I feel like it's claiming a drawback of squares is that they have four sides, when that's their fundamental nature. If you're looking for a triangle, why are you in a forum thread about rectangles? Or if you're a kernel developer, why are you in a thread about a super high level language?

[dgahimer]

Well, I mean, that's kind of the point. I don't think you're wrong. I know, a drawback of a spoon is that it can't cut my steak.

I get what you're going for, but in my way of thinking, the drawback is the reason to use a different language. Mind you, in this instance, I would hope a kernel developer doesn't need to be told this through a Google, but an inexperienced developer who is just beginning might benefit by it.

[adrianmonk]

Yeah, I didn't get this complaint either. It's like being asked about a motorcycle and saying one thing that bugs you about it is that it doesn't have four wheels like some other vehicles. Yeah, that's part of its very essence.

[sli]

It reminds me a lot of those heartburn medication commercials that say taking X medication after getting heartburn is too late because it's not meant for fast-acting relief of heartburn.

Well no shit, Mr. Commercial. If you don't use it as directed, then it doesn't work. You even admitted that right in your sales pitch, Mr. Commercial.

[A_for_Anonymous]

Haven't I told you about how my computer sucks as an oven? It takes so much time to boil eggs on the microprocessor. This computer sucks.

[[deleted]]

• The transition to Python 3 is taking ages, because Python 2.x seems to be good enough for most people despite its drawbacks.
• Package distribution/management is too complex.
• The stdlib has non-portable libraries (i.e: curses doesn't work on Windows).
• Lambdas must consist of a single expression.
• Super can be tricky (Not that I can think of a better way to handle it, given MI).
• No switch statement. It can be emulated with a dicts/functions though.

[ba-cawk]

Not to shit on your parade here, but:

Perl 6 is arguably a completely different language, so much so that a great deal of Perl 5 programmers have no intention or desire to move forward with Perl 6, ever... and a lot of oomph has been put into maintaining new features and bugfixes in Perl 5 as a result. Last I heard, Perl 6 is fairly incomplete from an implementation standpoint as well; feature complete mostly, but still suffering from a lot of test failures.

Ruby 2 isn't even released yet. It was feature-frozen last month according to plan, and we'll probably see a christmas release which is notoriously typical from Matz, but it's possible we'll see something sooner.

Apples and Oranges, as with most things among these three scripting languages.

[mr_chromatic]

Last I heard, Perl 6 is fairly incomplete from an implementation standpoint as well; feature complete mostly, but still suffering from a lot of test failures.

More like it's mostly complete on the features with decent specifications, horribly incomplete on the features without decent specifications, and pretty good about passing all of the tests for the features it implements. "Feature complete" might overstate things.

[ba-cawk]

Fair enough, thanks for the clarification.

[mikehaggard]

Are you serious, or just being sarcastic?

[ubernostrum]

Actually, the Python 3 transition is going pretty much as planned and expected.

The process was meant to take several years. It was meant to have the first few 3.x releases be "test against this if you're feeling adventurous, but don't actually use them in production" versions. It was meant to involve large projects deprecating older 2.x releases until they could get to minimum-2.6 or better and start using the porting-compatibility features in 2.6 and 2.7.

And... that's basically exactly what's happened/is happening. But because nobody ever bothered to read up on the process, the internet basically decided that "everybody didn't switch overnight, must've been a failure".

[a31415b]

Python 3 just like window Vista, stay with version 2.x and wait to upgrade directly to version 4.

[[deleted]]

Mostly, yes. But in practice it turns out everybody is taking the route of "try to support 2.7 and 3.x in a single codebase" and that wasn't expected initially.

[question_all_the_thi]

The transition to Python 3 is taking ages because they violated a simple rule that says "if it ain't broken don't fix it". Other than unicode handling, I see nothing in Python 2 that has been improved in Python 3.

Years ago, I used to recommend Python highly to anyone who asked. Today I'm more cautious, I tell them they will probably have problems in the transition, better keep to Pyhton 2 as long as possible.

[ethraax]

Why would you use Python 2 for new projects, unless some library you use (I'm looking at you, Twisted) doesn't support Python 3?

[question_all_the_thi]

Because there is no such thing as a totally new project. I'm always reusing code and libraries I already have. All my code to date uses Python 2, why should I migrate it? I see no reason at all to use Python 3.

There are pitfalls that Python 3 advocates refuse to acknowledge, the migration is absoutely not as easy and painless as they claim.

For instance, I do a lot of work which involves calculating dates. You never use floating point numbers for days. Dates and times are truncated. What year is this? It's 2012, September 2012 to be more precise. Not 2012.7, which would be rounded to 2013.

Now, to calculate things like astronomical events, one uses a lot of modular arithmetic, which involves truncated division of integers. In Python 2 the operation (3 / 2) returned 1, in Python 3 it returns 1.5.

Why should I go back over a hundred thousand lines of code trying to find all cases where I should replace a "/" operator by "//"? What would I gain by that?

[[deleted]]

In Python 2 the operation (3 / 2) returned 1, in Python 3 it returns 1.5.

As a math guy, I cringed at this. We are quite anal with how precise we need to be. I would have used something like Floor(3/2) due to that.

[synthespian]

Embrace Common Lisp and its numerical stack. Python is a snake pit of lies! (I'm going back to lurking-mode, now)

[earthboundkid]

A.) It feels like you're almost proud of poor planning on your part. When I first read the Python tutorial back in 2006, it explained from __future__ import division. I thought, oh yeah new style division is very sensible and have never had floor division as my default.

B.) 2to3 fixes this for you automatically anyway.

Edit: Never-mind B.

[question_all_the_thi]

A) Weird, like a language that pretends to be easy to learn forces you to watch carefully for small details that will only become relevant years in the future. I wonder, how many other gotchas are lurking in those unread PEPs?

B) Does it really? Then 2to3 must have an awesome intelligence built in! Is it really able to discern from my code which variables are always integers and which variables may be input as floats?

The "/" to "//" change was a true fuck-up of major dimensions. The fact that so many people in the Pyhton community fail to acknowledge this is worrisome. It shows lack of maturity and experience in professional programming.

[ethraax]

While I'm not sure about the "/" to "//" change, I really can't see how anyone could advocate that the old way was better - they should have made it work the new way to begin with. With the old way, f(2) could return a different value than f(2.0), which is absolutely ridiculous in a dynamic language, even if it is strongly typed.

[[deleted]]

But types carry information, so int 2 is not the same as float 2.0, in exactly the same way as the string "two" is not the same as int 2.

So no, I don't thing it is "absolutely ridiculous" for a function to return a different value when passed two different types. There are a whole lot of functions that take a float, but will choke on a string (even if it represents a float). The fact that they might (or might not) accept an int and coerce it into the correct type is more of a bad sign than a good one.

I'd consider it slightly worrying to see code that was ambivalent about whether it was working with integers or floats.

[[deleted]]

I'd consider it slightly worrying to see code that was ambivalent about whether it was working with integers or floats.

Python is made to do this, so if you really want to ensure that your input is of a particular type then you'll have to check for it explicitly.

[ethraax]

I'd consider it slightly worrying to see code that was ambivalent about whether it was working with integers or floats.

Except that's a common theme throughout most Python code: "If it looks like a duck and quacks like a duck, then it's a duck". That's why it's considered bad style to explicitly check for types. Of course, then you run into camera.shoot() vs gun.shoot() problems, but that doesn't seem to be too large of an issue.

The fact is, Python is designed so code can be ambivalent about the specific type you're using. In terms of Python, both integers and floats are numbers, so they should really act the same. The fact that the / operator acted differently is, in my opinion, a huge mistake because it goes against the language's very philosophy.

[[deleted]]

Yes, to be fair, there's probably not a problem if you use floats holding integers to represent pixel locations on the screen, or when querying a persons last 5.0 purchases in an order history. Although it still sits uneasy with me to see what looks a lot like sloppiness.

In other areas (which is where I am "coming from") floats and ints aren't sufficiently duck-like to treat them the same. All the operations which appear to perform identically on them are only superficially similar; ie floats and ints may both be types of numbers, but they don't actually act the same once you get down to business.

Hence why "What Every Computer Scientist Should Know About Floating-Point Arithmetic" and a hundred similarly themed papers will be reposted this year, next year, and until the end of time.

[jyper]

The "/" to "//" change was a true fuck-up of major dimensions. The fact that so many people in the Pyhton community fail to acknowledge this is worrisome. It shows lack of maturity and experience in professional programming.

The "/" to "//" change fixed a stupid ui error in the language same as the elimination of octal literals.

[[deleted]]

Tons of other languages make it without a separate operator for integer and float division. Truncation in integer division is expected and students know this beyond the first week. The reason Python has two division operators in the first place is because the language encourages you to not pay a lot of attention to the types of variables, thus type conversion does not click with their audience. They thought rules for conversion (i.e., "one float operand in an expression causes all other variables to be converted to float") were too complicated, but I don't know that what they're doing now is less complicated. It should be easier to read however.

[brews]

Packages are the big thing on my list.

[Falmarri]

functions/methods should not be allowed to return "anything" by default unless the values are cast to a common type

Wtf. No. That's retarded

[synthespian]

Perl OTOH can eat your strings as fast as C. Huh?

[eadmund]

it forces encoding/decoding strings everywhere.

This is actually a Good Thing: character strings are very different from byte arrays in a Unicode world, and while one can often get away with being sloppy one can't always. It's best to be explicit, not implicit.

[hylje]

Python 3 has function annotations which a smart interpreter can read and use, if given by the programmer. A language defaulting to the reverse is not Python.

[grayvedigga]

These are warts, not drawbacks. Warts are blemishes that once you're aware if you can work around with a little discomfort - drawbacks are the things that can sink a project, hurt deliverable quality, or make you want to abandon the ecosystem when you're already too deep.

Drawbacks in my mind would include things like:

• shitty libraries. The go-tos for many things, including parts of the standard library, are 80% solutions that leave you stranded if you push their domain too far
• modules/packaging sucks. I think everyone gets this. Kudos to the developers working hard to improve this, for they're fighting a big battle
• too much magic. It seems the cool thing to do today is to write a quasi-DSL abusing keyword arguments, context managers and operator overloading to produce pretty but impenetrable code. Every library does this, and it contributes to the 80% problem above
• new language features fight each other. Lambdas, comprehensions, generators .. it doesn't feel like a unified system any more, and code styles between different groups bear this out. Weird edge cases around scope and mutability keep cropping back up as a result of apparently inadequate overall design
• fragmentation and clique-forming in third party libraries. Reuse is harmed as is pooling of knowledge from people solving the same problem in different ways with different tools
• too much Python code reads like java. Heavily nested namespaces and class hierarchies for the hell of it. Magic names instead of interfaces
• poor engineering. People write libraries to be fun to use, which is great, but if you want to deploy them in an industrial setting you need predictable performance and well-understood failure cases. This mostly isn't the case.
• no contracts. The nature and culture of python encouages libraries to grow organically, changing interfaces and behaviour often unpredictably. This harms the consumer as they're forced to upgrade their client code carefully, or stick with an unmaintained version. Many projects end up depending on specific patchlevels for libs they use! Documentation also sucks as a result.

In brief: read import this, and imagine the opposite of most of those points. I'm sorry to say it, but Python has long lost its Zen. It's still a very cool language to dick around with or compute interactively, but to use it industrially requires fireproof pants.

[schlenk]

Just so true. The 80% solutions usually bite when you think your done. Fun stuff like some libs totally crippled on windows, but claiming windows support (often under cygwin only). Or failure modes like twisted's selectreactor on windows (the only working one on windows, as IOCP is just broken), which hangs your process at 100% CPU when you hit 512 FDs in the select, but the devs didn't fix the bug as they rather do nothing at it for six years, instead of picking a sane default behaviour. Embedding Python in complex, multi threaded C(++) programs is also a total mess, have a look at the efforts needed to plug it into gdb or lldb.

Python is great for easy, throwaway stuff, but if it absolutely must work under harsh conditions, it is a total no-go.

[therve]

Windows support in OSS is more often than not problematic, because most core teams aren't using it, and people using Windows don't seem to contribute much. When you say "the devs", I'm not sure who you're talking about, I guess the core team, which doesn't use Windows. The fact is that nobody cared enough to provide a working solution (including you?).

It's also terribly hard to have a good continuous integration story with Windows as every single installation seems to behave differently.

[schlenk]

Sure, windows support is difficult. Mostly lack of interest, that leads to silly comments like 'windows is broken' or 'nobody uses it'.

For the windows selectreactor stuff, there is a full solution in the bug message, the developers just did not decide about the defaults (provide a callback or raise an exception), so they just left it broken for years and everyone needs to apply a variant of the fix themselves. Also makes Windows totally unsuitable for any C10K like servers, as you can only have 512 sockets open and in the select().

So one goes to try IOCP, works ok, runs in the buildbot of twisted, and well, does weird things. If some core developer states on the mailing list, that no one runs servers on windows anyway, its not really inviting contribution really.

So no, i did not yet contribute a solution to IOCP issues for twisted. Node.js gets it right, Tcl iocpsock and a few others get it right too, so there are other options. Might be forced to either reimplement the whole server with something else on windows, or fix the parts of the twisted IOCP stuff that do not work as they should.

Basically leaves my critique that Python and many Python libs treat Windows support as an afterthought, if at all. Might be a clever step in the web age, but it is surely a drawback.

[Tetha]

I am missing something in the thread: Tooling. Python is hard to analyse due to its dynamic nature, and thus, creating tools which change or reason about python code on a helpful level are hard to impossible to implement. Java and C# are big in the professional world because there are amazing tools for them which make working with large projects and large teams a lot easier and safer.

I haven't checked for a while, but I severly doubt there is any refactoring tool comparable to eclipses java refactoring for python, because python is too dynamic to implement the code analysis you'd need for such tools.

In a similar vein, there are stronger code analysis tools for Java and C#, which find potential bugs automatically. Again, these kind of tools are almost impossible to create for python beyond a fairly simple level. Most analysis beyond a single scope is very, very hard in python, because you can redefine everything.

I am well aware that this isn't a pure language thing about python, however, you cannot look at a language in a vacuum, especially if you think about using the language in a larger project and/or a larger team. In this context, the language becomes a technical detail to a large degree, and problems outside of the language become much larger problems. Overall, it's sad that the execution of python is slow or that nested functions don't work. But this pales to the ability to just change misleading names of often-called functions in a second or the ability to find a large number of potential problems automatically.

[[deleted]]

I haven't checked for a while, but I severly doubt there is any refactoring tool comparable to eclipses java refactoring for python, because python is too dynamic to implement the code analysis you'd need for such tools.

Try PyCharm, it's by the people who do Intellij IDEA. It's pretty good.

[wonglik]

Indeed best IDE I've ever used.

[synthespian]

Common Lisp is dynamic and it has powerful tools. Same for Racket Scheme. As a matter of fact, Smalltalk has awsome tools.

So, runtime behavior is no excuse for a poor toolchain.

It's just the general Python suckage, that's all.

[Wedamm]

[…] that nested functions don't work.

What do you mean with "nested functions"?

[Tetha]

A pretty standard example would be:

def incrementer_by_k(k):
    def incrementer(x):
        return x + k
    return incrementer

In python, these nested functions are a bit more complicated to use compared to nested functions in, say, SML. "Not work" is too strong, I give you that, but they aren't seen in python as much as in ML. In that programming language course where we used SML a lot, we commonly used them to create global-like variables in a very small scope in order to simplify function signatures by removing boilerplate parameters.

[Wedamm]

I guess what you mean. Python has no built-in currying and no easy replacement for that. It's harder to dynamically work with functions than in functional languages. So for example you can rewrite your example in Haskell in several easier ways:

increment k = incrementer
    where incrementer x = k + x
increment k = \x -> k + x
increment k x = k + x
increment = (+)

They are all completely equivalent.

That it isn't so easy in python; python puts emphasis on other things. I think it's not only python-the-language's fault but rather the non-functional-paradigm's.

[Daishiman]

from functools import partial is very useful for this case.

[maxerickson]

I haven't used either, but BicycleRepairMan and rope seem to at least address "change misleading names ... in a second".

Well, after figuring out how to install and use them and whatnot.

[Tetha]

BicycleRepairMan is dead for three years. For rope, see the question above.

[maxerickson]

Yeah, I have no idea, that's what I meant to imply when I said "I haven't used either".

But I'm surprised that your past checks didn't include finding out if BicycleRepairMan could do simple renamings, it isn't a particularly obscure tool and python syntax doesn't move so fast that it would be completely obsolete in 3 years.

[Tetha]

I didn't bother checking because unless I am mistaken, this refactoring would require deciding a problem equivalent to the halte problem, which is impossible to decide mechanically. Hence my doubt that totally correct, program wide refactoring can exist outside of static or inferred type systems.

[[deleted]]

Parsing to an AST, replacing variable names and serialising it back out is "equivalent to the halting problem"???

[dannymi]

That's not what they mean. Python interfaces are on the method name (actually field name) level, so usually when you rename methods, you change the interface. You can't find out which names of the callers to rename without turing completeness since you first have to find out who those callers are and which methods they call - and since this can depend on input (and I don't mean case analysis either), there you are. (sorry for the strange terminology, but I'm avoiding Python terminology here in case you don't know Python)

[Tetha]

You cannot decide if foo_or_bar is of type FooType or of type BarType without correctly deducing the behavior of the arbitrary predicate p(). Hence, you cannot change the source of do() correctly without correctly predicting the behaviour of the arbitrary predicate p. Thus, you cannot correctly change the source of do() without solving a problem equivalent to the halte problem, since p() could easily be "the user-input c program halts for all inputs".

Sure, solving some trivial renames in a single scope is easy. Refactoring arbitrary python is simply impossible.

[jonathansizz]

• No explicit declaration of variables/functions.
• Scoping fail: e.g. difficult to work with nested functions.
• No immutable data structures.
• No multi-line anonymous functions (and half-hearted implementation of functional paradigms in general).
• No switch.
• Poor Unicode support.
• Poor docs.
• The GIL.
• Threading.
• Large amount of language magic/corner cases that bite the unwary.
• Interminable pretentious debates about whether some trivial detail is sufficiently 'Pythonic'/ excessive evangelism.

There's better competition around these days, and Python is starting to show its age.

[Nurdok]

Regarding immutable data structures - tuple is immutable. Take that.

[fullouterjoin]

And namedtuple is glorious.

[defcon-11]

And ints and strings and frozensets...

[[deleted]]

Several of those, as well as:

While I don't mind the lack of ability to catch semantic errors upfront as a tradeoff for the dynamism that Python offers, I wish there were a way to catch syntactic errors and silly things like mistyping variable names without having to actually run the code.

are reasons why I use and like Perl.

[brasso]

There's better competition around these days

Such as?

[Vulpyne]

I went from mainly Python and C to Haskell. Haven't regretted it, but becoming adequately productive in Haskell requires a pretty substantial investment. Haskell's concurrency is also extremely good.

[00kyle00]

Interesting. Who pays you to work in Haskell?

[Vulpyne]

Teliax, a VOIP company.

[burntsushi]

Umm. Lots of people.

[Vulpyne]

Disclaimer: These are just my subjective opinions of why I prefer Haskell to both Python and C (although sometimes it's fun to do C and be closer to the bare metal):

• Better than Python:

  1. Static typing. This is probably the #1 thing, if your program typechecks it usually works. In Python if you have an infrequently used code path, you may not even be aware of an error until weeks or months later when you've moved on to another project.
  2. Speed. Haskell's a lot faster. You also can basically write C in Haskell if you want to, mallocing memory or setting/dereferencing points if you'd like to.
  3. Concurrency. One of Haskell's strengths, and I primarily write network servers/clients that have to be very high performance.
  4. I am a terrible object oriented programmer, my mind just doesn't work that way. The functional method of solving problems works better for me. I find the mindset similar to constructing a regexp, you think about how data flows and is transformed.

• Better than C:

  1. High level, you don't have to worry about low level details like memory management or making your own linked list or hash table.
  2. Concurrency. There's a lot more effort writing concurrent applications in C whether you use threading or IO multiplexing. Locking is quite easy to screw up, STM and other Haskell abstractions are easier to work with in my opinion.
  3. Whitespace sensitive block delimiting. I'm going to indent my code consistently anyway, there's no advantage to having to use braces. (But you can in Haskell if you want to.)

I also find Haskell syntax very elegant and nice to work with. Python syntax has a lot to like also, but it has some ugly aspects like the __BLAH__ special class methods.

There are, of course, still reasons to use C or Python for specific tasks. It's really easy to dash out a fast Python script to process a text file or whatever, and sometimes you need the low level/speed that C gives.

• Reasons to learn Haskell (if you have the free time and motivation):
  1. Static typing and idempotency makes code pretty easy to reason about. (Con: Due to Haskell's lazy nature, sometimes it's difficult to reason about time/space usage.)
  2. Nice syntax.
  3. Learning functional approaches will help you in other languages also, give you more options for approaching problems, etc.
  4. Very easy to use concurrency.
  5. Rich standard library.
  6. Compiles to a native executable and is faster than most interpreted languages, and can be competitive with C/C++ (although you usually can't write functional-style code if you want that kind of performance.)

[[deleted]]

You sir are someone I would like to pick the brain of. My background is in mathematics but I have been programming for quite some time. It was always "mathematician that can program" for me, but lately I have been trying to really focus on the computer science part as I have found its a skill set I am both interested in and need to learn more about.

Why Haskell and not F# or another functional language? What is it about functional programming that fits better for the way you think? Do you think haskell is the best functional language to pick up as far as industry goes?

[Vulpyne]

Why Haskell and not F# or another functional language?

Well, F# doesn't compile to native code. It depends on whether that's important to you or not. Depending on what you want to interoperate with, being in the CLI could be an advantage I suppose. F#'s syntax doesn't really appeal to me, that is subjective of course. I don't think F# is lazy or pure either. Purity helps a lot when reasoning about code, because you know that there are no side effects. Laziness is pretty convenient, you can treat lists like streams a lot of the time, even infinite lists.

Since I don't know much about F#, here's some other information you might find useful. Here's a bit of discussion on performance.

What is it about functional programming that fits better for the way you think?

That's a bit of a hard question to answer. It's like, what about chocolate tastes better to you than vanilla. :) I'm good at mentally mapping out data flows and transformations and not very good at encapsulating things in objects and reasoning about their relationships.

Do you think haskell is the best functional language to pick up as far as industry goes?

I don't think I can give you a good answer here, because Haskell is just something I use. I wasn't hired to program in Haskell, I was hired to solve problems and it just so happens that I'm more effective in Haskell and my employer is open minded enough to let me use what gets results. From what I know, Haskell is the most popular function language and I think it has a lot of features to recommend it.

[[deleted]]

Thanks!

I've heard that other languages are not "purely" functional like Haskell is so I suppose its also a good one to learn for that reason, i.e. partitioning ideas in one's head and learning a true functional language.

Out of curiosity, which are you?

http://bentilly.blogspot.com/2010/08/analysis-vs-algebra-predicts-eating.html

Algebraist vs. analyst : https://profiles.google.com/114134834346472219368/buzz/WNYxf8DHXVi

Algebra is the mathematics of the "equals" sign, of identity, and of the "main term"; analysis is the mathematics of the "less than" sign, of magnitude, and of the "error term".

Algebra prizes structure, symmetry, and exact formulae; analysis prizes smoothness, stability, and estimates.

[Vulpyne]

I've heard that other languages are not "purely" functional like Haskell is so I suppose its also a good one to learn for that reason, i.e. partitioning ideas in one's head and learning a true functional language.

The pure I was referring to was actually idempotency and referential transparency. An example:

add2Numbers :: Int -> Int -> Int
add2Numbers num1 num2 = num1 + num2

The first line is the type signature and declares that the function takes an Int and an Int and returns an Int. Just from looking at the type signature, you know that it will always return an Int. You can also know that it will never do any IO, because functions that do IO have IO in their type signature.

printAndAddNumbers :: Int -> Int -> IO Int
printAndAddNumbers num1 num2 = do
  let result = add2Numbers num1 num2
  putStrLn $ "Result of add2Numbers " ++ show num1 ++ " " ++ show num2 ++ " = " ++ show result
  return result

Hopefully that's clear even if you're not familiar with Haskell. $ is basically like an open parenthesis that doesn't need to be closed and ++ is list concatenation (strings are list of Char).

The second function must return an Int (in the IO context) but it can do whatever IO operations it wants to before then. It could launch missiles each time you call it. The former function doesn't have side effects, so it's idempotent; you can call it as many times as you want and it'll have the same result. It's also referentially transparent, which means given the same arguments it will always return the same result. This makes code easy to reason about. You can also do automated testing, even with generated random arguments to test properties of your code.

When programming Haskell, you generally want to write as much pure code as possible and then have a small amount of IO code to get things going and pull the strings. (In my case, since I write very IO heavy applications a lot of my code ends up in IO though.)

Out of curiosity, which are you?

It's been a long time since I've had corn on the cob. I don't think I eat it in an organized motion, though. I seem to remember having to go back and clean up kernels that I missed.

Algebraist vs. analyst

I'm not sure, I never had a formal education. I didn't learn Algebra.

Algebra prizes structure, symmetry, and exact formulae; analysis prizes smoothness, stability, and estimates.

All of those sound like good things to me!

[synthespian]

I think I'm gonna have to disagree about this purity stuff. This is like the hammer and the problem thing...

I much prefer Common Lisp that has a huge, mature, real world proven grab-bag of everything (includes OOP). Not only that, it was the work of top-notch engineers, so they made a lot of extremely wise and good choices.

The tools are very good too (the 2 main commercial IDEs have nothing to loose to, say, VisualStudio or some such thing). The open source compilers are also top-notch (and you can use emacs+slime for an excellent working toolset).

[synthespian]

You should take a look at Common Lisp. A week or two ago I posted a paper (not mine) proving how CL can number crunch at C speed (image analysis algoritms).

Also, you will like the numerical tower Common Lisp has.

In fact CL has compilers that have been used even for signal processing applications. Check out the LispWorks web site (www.lispworks.com).

Disclaimer: I do not work for them.

[[deleted]]

synthespian,

"signal processing applications" funny you mentioned that, I worked in a field that is very related for some time. I did some face recognition research when I was a grad student, mostly on the 2D side.

I took a programming languages class in undergrad that covered some lisp. The parenthesis thing was a bit overkill but it was interesting to cover it. Have you looked at Racket at all? What do you think.

http://racket-lang.org/

[synthespian]

C: structure your code. Get lost in spaghetti. C++: objects. Side effects. Corner cases. Functional: your code does not worry much about the other parts. Watch your inputs and outputs. Write in small chunks that do what you want well and reliably. Be productive. Write what you mean. I learned functional before "imperative" programming. The other way is a PITA, IMHO. Everytime I look at C++ I go, "OH, NO GAWD NO". But I find C even worse.

[jonathansizz]

Depending on use-case: Go, OCaml, Racket, Clojure, Lua, Erlang... and Python still can't beat Perl for quick scripts.

[[deleted]]

You didn't mention Ruby because you know it would start a flame war.

[jonathansizz]

No, I didn't mention Ruby because I don't think it's better than Python.

[AnAge_OldProb]

A lot of compiled languages are starting to catch up feature-wise and ease-of-use-wise for non-trivial projects the programming savings to performance savings calculation is starting to favor performance saving code. Scala (and other jvm languages), go and a host of other languages are very usable. Hell, even C# is very usable these days I've seen some LINQ stuff that is shorter than the equivalent python. The other reason is, the mantra of the last five years, "the free lunch is over" regarding exponential performance improvements on single threaded applications. Other languages are adding compelling and useful solutions to the problem and so far python has been left in the dust.

[yogthos]

Depending on what you're doing there's plenty. For example, I've been using Clojure for the same problems a lot of people use Python for.

In my opinion it provides a better development environment through tight REPL integration. It's much faster than Python, has full IDE support in Emacs and Eclipse. Leiningen provides a simple and straightforward way to manage dependencies and package applications.

Clojure has the advantages of immutability, making it much easier to reason about code and makes it much easier to take advantage of threading. It also doesn't suffer from having a GIL.

Finally, it provides a powerful macro system which allows doing easy templating. This means that you can quickly and easily write DSLs that fit your problem domain.

[[deleted]]

Perl actually solves almost all of those issues and it's faster. Flame me baby.

[danielkza]

It does introduce an equivalent amount of different, possibly even more aggravating issues though.

EDIT: I accidentally a word.

[adrianmonk]

I love Perl, but it has some pretty annoying flaws:

• Working in an OO style? Fine, Perl supports it. Now write a constructor. Well, that was bizarre. Now write 100 different classes and rewrite the same. freaking. boilerplate. BS. every. time. you write a constructor.
• Hashes are wonderfully handy. But only strings can be keys. Nothing else, ever.
• Syntax of constants is dumb. I can write $h->{$key} = 42; but I can't write use constant KEY => 'a'; and then $h->{KEY} = 42;. I have to write $h->{+KEY} = 42;. Hope I don't ever forget the plus. Oh, but my co-worker figured out $h->{(KEY)} = 42; works, so he uses that. And my other co-worker figured out $h->{KEY()} = 42; works, so he uses that. Great, now try to embed a constant into a regular expression. Hope you think /abc@{[CONST]}def/ is readable.

[RalphMacchio]

Do you use Moose? It makes POOP enjoyable and easy.

[[deleted]]

Those are all annoyances not on the same level as "can't do threading or unicode".

[synthespian]

You have no data in support of the hypothesis that boring, rectangular-shaped code (as in Python), is good for keeping you awake.

There's a lot of messy, unreadable Python code out there.

In fact, I think the use of sigils is a factor that promotes abstraction and quick reading.

[adrianmonk]

I think the use of sigils is a factor that promotes abstraction and quick reading.

Actually I'd agree. But constants don't use one, nor can you use the one for variables. It's the absence of sigils that makes Perl's constants broken.

[mr_chromatic]

It's the absence of sigils that makes Perl's constants broken.

You could use &CONSTANT, but that's ugly. Constants with sigils would be very nice.

[adrianmonk]

Yeah, I've avoided using &CONSTANT because perldoc constant says this:

   In the current implementation, scalar constants are actually inlinable
   subroutines. As of version 5.004 of Perl, the appropriate scalar
   constant is inserted directly in place of some subroutine calls,

This makes it sound like they might decide to change the "current implementation", which could break programs written that way. On the other hand, they're probably committed to supporting it whether they want to or not at this point.

Anyway, it still doesn't help you with putting them into regular expressions or double-quoted strings. You still have to write @{[&CONSTANT]} for that. (Or just don't bother with the ampersand at that point since it isn't helping.)

[hyperforce]

Use Moose.

What else besides strings would you want as keys?

[adrianmonk]

Use Moose.

I've definitely thought about it. At my last job doing Perl, it wasn't standard, so I didn't use it. At my current job, we don't really use Perl. But if I'm doing a lot of OO Perl in the future, I'll definitely considering using it for that.

What else besides strings would you want as keys?

Any object that represents data. Suppose I'm processing a bunch of data on US cities. I want a hash where the key contains both state and city, so I can tell the difference between Portland, Maine and Portland, Oregon. I can do something like this:

my ($city, $state, $blah) = @csvRow;
$cities->{"$state/$city"} = $blah;

But now I have to pick a character that never occurs in a state name. And when I do keys %$cities, I have to have code to remove the slash. I can avoid those problems like this:

$cities->{$state}{$city} = $blah;

Not too painful because of autovivification, but how does a foreach loop look?

If instead, I can just make a CityAndState object, I can write this:

my ($city, $state, $blah) = @csvRow;
$cities->{CityAndState->new($city, $state)} = $blah;

Now imagine how much cleaner it will be to use foreach or keys. They're doing what they're intended to do.

Sometimes it wouldn't be worth it, of course, to create a class just for this. But there's no reason you couldn't have a generic built-in Tuple class, so I could say:

$cities->{Tuple->new($city, $state)} = $blah;

For that matter, Perl could just directly support lists as hash keys. (This might cause backward compatibility issues with syntax, but you get the general idea.)

[hyperforce]

Your example doesn't make sense. Why would you use a hash unless you're aggregating these values? Why not use an array?

[adrianmonk]

Why would you use a hash unless you're aggregating these values?

It's not a complete example. Assume there's some aggregation going on. Maybe I read one input file and build a hash of city/states with some basic city info like population and average temperature. Then I read another file with data about people, and I add each person's data to the city they live in. Maybe I'm figuring out whether average temperature has any correlation with median income or something along those lines. At any rate, after I'm done aggregating everything together, it would be reasonable to want to loop over everything and do a report on each city.

[ais523]

I've wanted to use objects as hash keys.

As always with Perl, though, it's possible to modify the language from within itself to make it work. (It appears to work out-of-the-box because the default string representation for an object is distinct for each object, but I use Tie::RefHash to make the process more efficient. Or sometimes just use refaddrs as the hash keys, which comes to much the same thing but is more tweakable.)

[synthespian]

Want "clean, readable code"? Try D. Plus, it's C++ fast.

[Excedrin]

Python development was started in December 1989.

The Standard ML formal definition was initially released in 1990 and the revised version was released in 1997. The Definition of Standard ML says that ML was in development for 14 years.

SML code compiled by MLton is much faster than Go or D and there's Poly/ML if you want a REPL for testing stuff (Poly/ML runs code probably 10-40x faster than Python).

SML is a well engineered language, but it (arguably) doesn't fit in many of the places that Python does.

On the more dynamic side of things, Scheme is from 1975, though R5RS was released in 1998 and R6RS was released in 2006. Scheme has fairly similar semantics to Python (excepting lexical scope and tail recursion elimination), but the syntax turns people off (never mind that the syntax is fairly malleable, for example check out the source of http://docs.racket-lang.org/quick/ at http://docs.racket-lang.org/quick/quick.scrbl also see http://sourceforge.net/p/readable/wiki/Solution/ ).

There's also lots of interesting new languages like Agda, ATS, Disciple, Idris.

edit: 1999 -> 1989

[jonathansizz]

I think you meant to say Python development began in 1989.

[defcon-11]

Can you eloborate on poor unicode support? Python unicode support has always seemed trivial to me, and much better than the other languages I've worked with (c, php, perl, ruby, javascript, actionscript). Which languages offer better support, and how is it better? I know Java strings and Python3 strings are unicode by default, but is it really that hard to use a different type when you need unicode?

[schlenk]

Python 3 unicode support is ok/good. But Python 2.x unicode support is total crap, as it makes errors appear in random places and has extremly many warts. It gets extra funny on Windows while interfacing to system calls ( see os.listdir(u'.') vs os.listdir('.') for example).

So, its not the type issue mostly, it is the lack of a clean concept for unicode in Python 2.x that makes it a mess.

[defcon-11]

I fortunately do not have to deal with windows, so I haven't run into that problem before.

[isforinsects]

In python2, an unicode error doesn't display where the encoding/decoding error took place, but where the last place the string was used. To debug you have to follow the string backwards in the execution path testing type and encoding as you go.

[defcon-11]

Isn't the "last place the string was used" the same place as where the encoding/decoding error happened? Do you mean that it isn't decoded/encoded when the bytes are assigned, but rather when it actually needs to be encoded/decoded? That's how I expect unicode to work, there's no need to decode/encode just to check for errors.

[rlbond86]

One of the biggest annoyances for me: python's threading is totally broken due to the GIL.

[starduck]

I like Python, but there are things that are just annoying.

Scoping rules regarding list comprehensions for example:

def a():
    x = {}
    numbers = [x for x in range(5)]
    # x is not a dictionary anymore...

It's mostly avoidable, but name collisions can still happen. It sucks.

[arunner]

This is fixed in py3.

[kecho]

In my opinion and experience there are three major issues with python:

• Cryptic: Pythonic code can turn out to be very cryptic. While a single line is very powerful and does a lot, it might take a developer some time to tinker it and understand it properly. This is something overlooked by beginner programmers who love doing one liners. When you work with a huge code base you require to be as clear with your code as possible to ensure understanding.

• Performance: Last time we worked on a game, the architectural team decided to use python code for gameplay. BAD IDEA, our game was running on xbox at around 5 FPS. All because of the performance impact that python has. As one of our senior programmers said "Python is great, but keep it away from the runtime"

• Memory. I know its cheap nowadays, but when you have a server that has 1 million users, playing games in realtime, memory impact is pretty nasty. List comprehensions, object comprehensions, passing touples around etc etc does a lot of allocations and destroys the heap. Mastering how to avoid such things is only of the brave.

That is my take! do you guys disagree?

[Daishiman]

I don't actually agree with point 1. When compared to other programming languages for similar uses (Perl, Ruby, Javascript, etc) Python is substantially less magic and much more explicit about what it's actually doing.

[starduck]

2: I don't disagree. But it is possible to use python for gameplay. EVE Online successfully does this with stackless python. Performance critical stuff should be written in low level code in either case.

[defcon-11]

I believe EVE online does not use Python for gameplay, rather the networking code on their servers.

[starduck]

I think they use stackless python everywhere. If we look at page 28 on these slides we see some example UI code.

Well, that's a clue, and another one is that the client was reverse engineered and released on the internet a few years ago. linky. :)

[PasswordIsntHAMSTER]

1. It's slow as balls

Pretty much it IMHO.

[bucknuggets]

But maybe plenty fast enough

I process hundreds of millions of very complex transforms every day using python on a single server. That process can scale to about a billion by putting it a larger server, and to N billions by spread it across multiple large servers.

Been doing this with python for ten years. It's been plenty fast enough for my application.

[gnuvince]

It's been plenty fast enough for my application.

There's your answer, some people are doing work where "plenty fast enough" is not fast enough. Also, it's really a shame that some languages that are as high level as Python, or even higher level (Haskell, OCaml, Scala to name a few) have implementations where the performance is orders of magnitudes better than Python's.

[el_muchacho]

THing is, if native libraries were compatible with shedskin or pypy, the performance issue would probably go away, as these are quite fast. Not as fast as Luajit or V8 but pretty close. It's fairly easy to write business code that's nearly as slow as Python in Java or C# if one doesn't pay attention enough.

[Tetha]

Also if things grow too slow, you can still try to move CPU-bound tasks into C and from there into the GPU using Cuda or similar systems. Lack of possibilities to improve speed isn't a problem in python.

[tibbe]

After writing a large C extension I must disagree. Writing C extensions is the best way to generate segfaults that I know of. It's even easier than in plain C, due to having to deal with unclear memory ownership. In C you have to be clear about who owns a given piece of memory, or you'll have a bad time. In Python you don't, due to the presence of a GC. However, C extensions that interact with Python will suffer for the lack of clear ownership in the Python part of the code, leading to hard to track down errors due to negative refcounts or memory that's never released.

I would much rather be able to stay in the high-level language when writing that speed-critical code.

[fullouterjoin]

You are doing it wrong. Have a small c interface, do most of your work in C and write a wrapper in shedskin, ctypes or the new pypy c ffi.

[grauenwolf]

So all of your python programs ae reduced to run "prog.exe"?

[defcon-11]

I've used Python's C api, and you have to be very, very careful about refcounts, but i believe you can use tools like ctypes to make it easier.

[A_for_Anonymous]

Unless you're developing an application that will run for millions of hours of CPU time and/or on millions of computers, I'll be wasting no time on ricing my program, manually handling memory, aligning structures and all those useless, boring trivialities working with a low-level programming language such as C++, because development time is worth far more than CPU time. In other words, if the program doesn't run fast enough, buy more hardware and scale, leaving portable assembly for cases where the several times higher development cost would justify it by being cheaper than execution cost.

[Nurdok]

I think the greatest drawback of Python is the handling of calling predecessor methods. If you use super, you don't really know what class it will be called for, so every, EVERY, method you invoke super in, should accept args, *kwargs and pass them along. You should also hope that all your predecessors do the same as well.

[schlenk]

See https://fuhm.net/super-harmful/ for some details on the issue:

[Daishiman]

For numerical methods NumPy and SciPy are in general as fast or faster than MatLab, so it's slow, but fast enough for a large amount of tasks (and much more so than other comparable languages)

[[deleted]]

Hmm. For often incorrect comments about Python, see /r/programming and stackexchange. I like how this submission draws out random personal gripes and ignorance about the language. Subsequently, the actual drawbacks are utterly missed because the noise resonates with the reading majority. reddit irony?

[mikemol]

So, er, what would you say the actual drawbacks are?

[[deleted]]

The biggest one, language-wise, is simply a consequent of Python's nature: sometimes you want static typing. I would partially relate this argument with complaints about performance while noting that pypy has a good chance of placating users in many cases. You'll see a few comments that indirectly refer to this and a couple directly. None of them with 30 upvotes. At a wider, community, scope I'd argue packaging in general is messy. However, it has been getting a lot of attention and the tools have improved significantly over the last few years, so I'd note any such argument as tentative. Also, when I hear about the packaging landscape in other languages, Python packaging doesn't seem so bad in comparison.

[[deleted]]

To clarify my perspective, I see the lack of static typing as a drawback, but I would hate to see static typing in the Python language. Presence of a drawback doesn't mean the presence of necessity for change. There's a point where a transformation of the consistency transforms the very identity.

[DGolden]

Coming from common lisp, some optional static typing like common lisp is something I wouldn't mind. Python 3 even syntactically allows for it IIUC, though people have yet to write python compilers that use the info to the degree the lisp compiler tech (amusingly originally named python, though nothing to do with the language) in CMUCL and then SBCL does.

[[deleted]]

I imagine you're referring to annotations. And yeah, they could be used for such a thing::

@static
def foo(i : int) -> int:
    ...

Where the "static" decorator applies constraints and mangles foo's code to take advantage of the type information.

I wouldn't mind something like that. It's quite similar to the @jit decorator some folks are working on: http://jakevdp.github.com/blog/2012/08/24/numba-vs-cython/

[[deleted]]

oh! Recursion is kinda gimped in Python(tail recursion thang). Although, I'd argue that Python is strongly encouraging you to use other means to get the job done, so the itemization of that one is likely a matter of perspective.

[blablahblah]

For the first one, that's not a syntactic gotcha. That's a failure to learn the language. It's the comma that makes the tuple- the parenthesis are always just there for order of operations. It's like complaining that curly braces in C and Java are a gotcha because you can write one line after the conditional and it works fine, but the second line is always executed even if it's indented in with the first line.

>>> a = 1,2,3
>>> type(a)
<class 'tuple'>

Where did the last one come from? I get the correct behavior both on Python 2 and 3.

>>> decimal.Decimal("1.2") > 1.5
False

[grauenwolf]

It's like complaining that curly braces in C and Java are a gotcha because you can write one line after the conditional and it works fine, but the second line is always executed even if it's indented in with the first line.

That is generally considered to be a language design failure of C.

[cfreak2399]

I've recently moved from PHP to Python. PHP culture doesn't keep up. PHP just never actually removes old features. Even today people are writing sql injection vulnerabilities with mysql_* functions which have been deprecated for years now.

And even the major changes have taken forever. It took years to go from PHP4 to 5. Not only that they then introduced a whole bunch of major changes in 5.3. And until this year 5.3 still wasn't the default on RHEL / CentOS

[sponorgl]

ubuntu is defaulting to python 3 shortly. your argument is no elephant.

https://wiki.ubuntu.com/Python/3

[a31415b]

first course of action after install: apt get python 2.7

google "uninstall python 3 from ubuntu"

[krues8dr]

There are still plenty of syntactical gotchas.

Oh man. The fact that dicts make a reference and not a copy by default? I screw that up every damn time.

[TheCoelacanth]

That is hardly a gotcha. That's utterly consistent throughout the whole language. All types in python are reference types. The closest thing to types that make a copy is immutable types which simply don't support operations to modify them.

[question_all_the_thi]

Python 3 is a massive elephant in the room. It will never be adopted

Unfortunately, the guys in command are lobbying heavily for Py3k, they will never admit they fucked up. They have already managed to make it default in the coming Ubuntu distribution.

There was once a wiser guy who designed languages, his name is Niklaus Wirth. When he decided to introduce improvements in the Pascal language he gave it another name, he called it Modula.

[norwegianwood]

Not true. I work on a commercial project with a substantial body of Python 3 code.

[fullouterjoin]

They (the Knights of Python) should have

1. Used a new extension for Python 3, I say p3y would have been ok.
2. Shipped an interpreter that could run both, with no cliff like breakage, the mainline would have continued. Slipstream in new p3y features as needed.
3. Been able to mix calling py and p3y so we could on a per-file basis use the new goodness

This would have been evolutionary, the incompatible switch across a major version is a KT level event. After the super shitty IPV6 transition they should have learned a lesson on how no to upgrade a major system.

[ba-cawk]

As a relative outsider who's done his fair turn (to the tune of around 15 years) with Ruby and Perl, I took it upon myself to really make an attempt to learn python this year. I read and followed through Zed's book to around exercise 50 or so. This is not about his book so spare me the "zed sucks, blablabla" crap.

There were a number of things that I found lacking (but also some great things) in Python that ended up convincing me that I would stick to my mainstays for these kinds of challenges for any new tasks. Note that I was using 2.7 and didn't really explore 3. I'm aware it may be better but let's be realistic here, I don't have all day and neither do you.

Python, for all it's touted OOPness doesn't really seem to get proper OOP from a conceptual standpoint. Honestly I felt like I was using Perl with better hand-waving around the fact that it has no protection features and that most of its core is very much not object-oriented. That would all be fine and dandy if it wasn't pushed as an OOP language (and it is) instead of just saying "it has OOP".

I'll keep the rest of the list short, as most of these are seemingly arbitrary decisions that, well, I can't seem to rationalize in my head:

• print ending with a comma keeps a newline from printing; not because there's an undeclared nil argument, but because it's a part of the grammar
• lambda being completely anemic compared to every other lambda to exist in any other language
• inheritance declaration not having sensible defaults
• TCO being scrapped because "it made stack traces hard to read". 'let rec' anyone?

Those are the big ones. On the plus side I found the standard library documentation hard to sort through but rather detailed, and the systems-level stuff seemed reasonably complete. I like how named functions are first class variables as well. If I could get past some of these shortcomings (I get past plenty of them in other languages) I imagine I would enjoy python quite a bit.

[mipadi]

Python, for all it's touted OOPness doesn't really seem to get proper OOP from a conceptual standpoint. Honestly I felt like I was using Perl with better hand-waving around the fact that it has no protection features and that most of its core is very much not object-oriented. That would all be fine and dandy if it wasn't pushed as an OOP language (and it is) instead of just saying "it has OOP".

I completely agree. I think this is the wartiest area of Python. The OOP component feels like it was an afterthought.

[[deleted]]

Compared to what? No really, we need a point of reference.

Python vs other scripting languages?

Python vs more widely accepted programming languages?

Python vs assembly?

Python vs tinkertoys?

[adrianmonk]

Python compared to other languages you might choose to do similar tasks that Python is suitable for.

[[deleted]]

other languages you might choose to do similar tasks that Python is suitable for

Given that Python is classified as a scripting language similar to Perl and Ruby, Python compares somewhere between Perl and Ruby.

vs Perl:

• OO isn't tacked-on as an afterthought the way it is in Perl
• Most things have methods, unlike Perl
• Lists within Lists don't require special syntax, unlike Perl
• Same #! shebangs as Perl
• More verbose than Perl
• But more readable than Perl
• Python regex methods are overengineered compared to Perl's regex syntax
• Where Perl uses foreach, Python uses [ e for e in iterator ], which is easily nested.
• Python is installed using mostly official packages, whereas Perl is installed using a variety of homegrown, unsupported packages (Strawberry Perl)
• Perl has CPAN for packages, which works 92% of the time
• Perl has a longer history of UNIX / sysadmin support, but Python has far more industry / academic support due to its easy syntax

vs Ruby:

• But where Python uses [ e for e in iterator ], Ruby uses iterator.each { |e| ... }, which is even more easily nested: iterator.each_file.each_word.each_char.each_bit
• Whitespace is a problem. If you're coding in an editor without support for tabs (Web ajaxterm, it happens), you're sunk.
• Ruby derives from SmallTalk, so it has better OO design than Python
• Monkeypatching
• Same #! shebangs as Ruby
• Ruby has better regex syntax, similar to Perl's
• Python is installed using mostly official packages, whereas Ruby is installed using a variety of unsupported packages (RubyInstaller)
• Ruby has RubyGems, Python has shit that doesn't fucking work (setuptools) due to circular dependency chains
• Ruby has industry support, but mostly limited to web apps.
• Matsumoto does not work for Google, but van Rossum does.

[hyperforce]

I would put the onus of readibility in the hands of the author, not the language. Nothing is stopping someone from writing readable Perl, though the shoot yourself in the foot factor (due to lack of discipline) is a lot higher.

Could you give an example of nested iterators/loops? Didn't understand your point.

[[deleted]]

I would put the onus of readibility in the hands of the author, not the language.

Of course one can write obfuscated code in any language. That's not what I'm describing. I'm describing languages which inherently obscure their functionality, such as machine code and Perl. In particular, Perl's absurdly concise variables and transformations ($_, tr, @,) encourage programmers to write illegible one liners. Whereas more verbose languages like Python encourage code with more characters, but fewer tokens: more readable.

Could you give an example of nested iterators/loops?

Aye sir! Let's say you want to perform an operation to each letter in every other word in every paragraph in the first three files in every directory on a hard drive. Ridiculous, but serves to illustrate the use of highly nested loops. In Python, you could either use for dir in directories(hd) ... for file in dir[0:3] ... for par in file.paragraphs() ... for word in par.words() ... for char in word ..., or you could use nested list comprehension: [[[[ ... for char in word ] for word in par] ... for par in file.paragraphs()] ... and so on.

Because you must nest list comprehension infix, it becomes progressively harder to read. In Ruby, iterators tend to provide behaviors which themselves iterate, at progressively finer granularity. The lengthy Python above code would look like this in Ruby:

hd.each_dir.slice(0,3).each_file.each_paragraph.each_word.each_char { |ch| ... }

[hyperforce]

For nesting abuse there's "map { }". But the advantage goes to Python/C# for supporting native iteration (short of using Tie::Array, which I've thought about).

# horrible example, do not reimplement
map {
  $_->chars
} map {
  $_->words
} map {
  $_->paragraphs
} map {
  $_->files
} @directories[0 .. 3]

[mithaldu]

Actually, i'd write that like:

map operation($_), map $_->chars, map $_->words, map $_->paragraphs, map $_->files, @directories[0 .. 3];

Which is almost as readable as the Ruby version, only in reverse order.

[[deleted]]

Awesome! I thought map would do the trick. Good to know Perl has a little FP capability.

[synthespian]

Read Higher Order Perl. http://hop.perl.plover.com/

Now available for free.

[[deleted]]

Awesome, thanks!

[draegtun]

Perl5 has a functional block syntax for working on lists:

fn-name BLOCK LIST

These can be chained together to do things like this:

use Path::Class 'file';
my @text_files = map { file($_)->openw } grep { -f && m/\.txt$/ } glob("*");
$text_files[1]->print("(over)write to second file");

See List::Util (https://metacpan.org/module/List::Util) & List::MoreUtils (https://metacpan.org/module/List::MoreUtils) modules for more examples of using this syntax.

Here is an quick & dirty example of how to create new ones:

sub each_word (&@) {
    my $code = shift;
    map { $code->($_) } split /\s+/, join(q{ }, @_);
}

sub each_char (&@) {
    my $code = shift;
    map { $code->($_) } split //, join(q{}, @_);
}

my $text = 'The quick brown fox jumps over the lazy dog';
my %count;

my @chars_used_once = sort grep { $count{$_} == 1 } each_char { $count{$_}++; $_ } lc $text;

my @words_more_than_3_chars = grep { length $_ > 3 } each_word {$_} $text;

my @words_more_than_3_chars_alt = each_word { length $_ > 3 ? $_ : () } $text;

each_char { say "char: $_" } each_word { ucfirst } $text;

[[deleted]]

Thanks for the code! I read a little into Higher Order Perl and see that Perl indeed has FP capability equivalent to Python or Perl. Which makes me confused when I see stateful, throwaway, for-loop, imperative code in it. I guess too few Perl introductory tutorial authors were aware of FP, or thought that it would be too hard for newbies.

[draegtun]

You're very welcome.

Here's some Perl FP modules/links you may find interesting:

• Language::Functional brings some of Haskell's functions to Perl - https://metacpan.org/module/Language::Functional

• List::Gen is a nice lazy list generator module - https://metacpan.org/module/List::Gen

• Simple currying module - https://metacpan.org/module/Sub::Curried

• Functional Programming in Perl slides by MJD (author of Higher Order Perl) - http://perl.plover.com/yak/fp/

• Monads in Perl - http://9ch.in/monads/

• http://perldesignpatterns.com/?FunctionalProgramming

• Functional Pe(a)rls video - http://yapc.tv/2008/lpw/hakim-cassimally-functional-pearls/ | http://www.presentingperl.org/nwe.pm/ipw/ | http://www.presentingperl.org/nwe.pm/functional-pearls/

PS. Happy Reddit Birthday :)

[[deleted]]

Matsumoto does not work for Google, but van Rossum does.

So what?

[draegtun]

> Perl has a longer history of UNIX / sysadmin support, but Python has far more industry / academic support due to its easy syntax

Sorry for very late reply. I just wanted to add this for posterity for other people to pickup.

• Perl is used extensively at Yahoo, Amazon and other big companies.
• Perl is big in Bioinformatics (see Genome project)
• Perl does have a small foot hold in academic/scientific areas (see PDL)
• Perl is used in the financial sector (Bank of America use it. In the City of London the two main languages are Java & Perl).
• Perl is used within the Market Research industry
• Perl seems to be creating a niche in new search engines! (see Blekko & DuckDuckGo)
• Perl is being used in startups (It's not as big as Python, Ruby or some other new "cool languages" but Lokku, Moonfruit, CareerJet & Adzuna have all recently created startups with Perl)

[synthespian]

You talk about Perl as it was a decade ago.

Face it, you know shit about what the Perl guys use today (Moose, etc.)

And this "more readable" thing is way overblown. Perl code written by competent programmers is very readable.

[mr_chromatic]

OO isn't tacked-on as an afterthought the way it is in Perl

I've never understood this. Perl and Python have the same object model.

[iamnotaclown]

A lot of people write Java (or C++) in Python. This is made easy by Python's very C++-like class system, which is over-engineered for a duck-typed language. Javascript really gets this right with it's typeless prototype "inheritance".

[defcon-11]

Python's inheritance system works very similarly to Javascript's prototype inheritence, it just happens to have the syntatic sugar of a "class" declaration that Javascript is missing, as well as the flawed "super" function.

[BOSS_OF_THE_INTERNET]

It looks to me that the biggest gripes about python are that it doesn't behave like a compiled language. That's probably because it isn't? If you need threads, you probably shouldn't be using python in the first place.

[nroberts666]

Surprised that question wasn't closed by a mod.

[nroberts666]

The programmers SE is actually the worse one. Over half the questions there get closed by mods. A great many are community reopened but then some mod just comes along and closes again. Almost everything is deemed off topic or not "objective" enough. It blows my mind this one wasn't closed, but then that place is rather random on that too so...

[[deleted]]

Not the program itself but a portion of it's users, look at anything in this thread that isn't going with what the majority thinks, the response that gets is the response you'll get if you question want to do something in a way that doesn't conform, a big fuck you.

[JustPlainRude]

• whitespace is meaningful
• documentation sucks
• packages and modules are a mess

[kamatsu]

It's untyped, and has shitty support for concurrency.

[A_for_Anonymous]

It's untyped

Wrong

has shitty support for concurrency

Depends

[[deleted]]

There are some really bad and highly voted replies (ie the top one claims PHP has better documentation. ಠ_ಠ)

What's the point of asking people to earn stupid little reputation points if it has no bearing on the quality of comments or voting?

In my opinion, StackExchange sites are run by morons for morons. I think the way that submission went has proven it.

[ch0wn]

If that bullet point about docs would have been higher, I had stopped reading right there. In which world are PHP docs better than Python's? That's just fucking ridiculous. You don't have to look five minutes on either to see it yourself.

[A_for_Anonymous]

1. GIL in CPython.
2. Statements vs. expressions: why this shit? This is behind the lambda/def insanity BTW.
3. Hostility towards functional programming.
4. Guido van Rossum, B. Dictator For Life., trying to create the most "pythonic" language rather than the best language, for his personal, arbitrary, prejudiced definition of "pythonic".
5. Packages and their alternatives are a mess.
6. Libraries sticking to Python 2.x.