61–70 of 231 posts
How is Haskell "weird"?
I've used Python for many years, but only recently have I migrated my last Python niche (simple scripts) from Python to Haskell. I've found that even there, Haskell has become more productive.
I do love Python, but I often wish there was more rigor for some things. I currently work on a large project (>500K LOC) and have started to see it fall apart with a bigger team. Lack of enforced typing in function arguments, inability to create strict interfaces, inconsistency in standard library conventions, and package management would probably be my biggest gripes.
Package management and generally deployment is certainly a pain in python. I think it is one of the main issue in typical "corporate environments"
Earlier quoted context omitted.
Library support. For example, there really is no Ruby equivalent to SciPy, NumPy, Matplotlib or NLTK ( http://news.ycombinator.com/item?id=3179370 ). However, there has been some effort in the Ruby community to begin the process of developing some of these libraries (see SciRuby http://news.ycombinator.com/item?id=3180369 ). but the Python libraries have been in development for years so this will be no easy feat.
>> Library support. Isn't that rather an argument for Java or Perl? What I don't get is the cheerleading for Python? Ruby has/had something similar going with Rails. I mean, the article even notes that it is a middle of the road choice, optimised to not be extreme.
My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier…
I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another property onto an object before sending it to the template-engine saves so much engineering work, it totally overcomes the downsides of not annotating required types. I can see where it may be an issue, but I think the documentation should focus on what functio…
Web-based systems tend toward smallness and/or flatness, with fairly straight execution paths through the system. You're not going to run into the limitations being discussed.
Earlier quoted context omitted.
The downside of Ruby is the third-party packages, especially advanced/industrial-strength stuff (NumPy/SciPy for instance). The main upside of Ruby is blocks, however limited (compared to Smalltalk's) the ability to craft your own control structures is incredibly powerful and empowering (and you can't really do that in Python, you can abuse decorators for it nowadays but it's not exactly sexy or readable, or generall…
I'd also say that ruby has done a better job of moving forward. Compare ruby 1.9 to python 3. I think JRuby is more mature than jpython, and I know this will start the flames, but I think ruby is clearly better for web stuff; not just rails, but the whole ecosystem. Edit: I also think bundler is better than what is going on in python land.
JRuby is clearly more advanced that Jython. I'm guessing that with the advance of PyPy, other Python interpreters just aren't getting that much attention, which is a bit unfortunate.
Earlier quoted context omitted.
Library support. For example, there really is no Ruby equivalent to SciPy, NumPy, Matplotlib or NLTK ( http://news.ycombinator.com/item?id=3179370 ). However, there has been some effort in the Ruby community to begin the process of developing some of these libraries (see SciRuby http://news.ycombinator.com/item?id=3180369 ). but the Python libraries have been in development for years so this will be no easy feat.
>> Library support. Isn't that rather an argument for Java or Perl? What I don't get is the cheerleading for Python? Ruby has/had something similar going with Rails. I mean, the article even notes that it is a middle of the road choice, optimised to not be extreme.
I'm sure there are probably tons of nice alternatives to Python for this kind of work, and there are tasks that other people need to do for which trying to use Python and some readily-available libs just wouldn't be sufficient. I only suggest Python to people whom I know are doing work where it would be helpful; there's no point in pushing it as a one-size-fits-all solution.
My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier…
I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another property onto an object before sending it to the template-engine saves so much engineering work, it totally overcomes the downsides of not annotating required types. I can see where it may be an issue, but I think the documentation should focus on what functio…
I do love Python, but I often wish there was more rigor for some things. I currently work on a large project (>500K LOC) and have started to see it fall apart with a bigger team. Lack of enforced typing in function arguments, inability to create strict interfaces, inconsistency in standard library conventions, and package management would probably be my biggest gripes.
On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that the function is not documented, nor is the function expectations. Typing in C++/java does not replace that (more advanced typing systems do much better, though). Package management and generally deployment is certainly a pain in python. I think it is one of t…
History has shown that programmers are too lazy/busy to write good documentation, and when they do, they don't keep it in sync with what the code does. If it's not checked by the compiler or automated tests, it's probably wrong.
I like to call this cognitive compatibility - the amount of effort required from an uninitiated English-speaking observer to understand what a program does. Most people who are deeply familiar with a language will have a tendency to discount this effort, but really it is essential because it minimizes the translation layer that your brain has to use any time you read code. Python encourages code which is readable in…
Also there is plenty of Python code that is not particularly readable even superficially, particularly convoluted uses of list comprehension come to mind.
And I don't think 'consistency' is one of python's main qualities, when even in the stdlib there are plenty of very different naming styles. (Yes, this is improving in Python 3, but has been a big issue for a very long time.)
Earlier quoted context omitted.
The downside of Ruby is the third-party packages, especially advanced/industrial-strength stuff (NumPy/SciPy for instance). The main upside of Ruby is blocks, however limited (compared to Smalltalk's) the ability to craft your own control structures is incredibly powerful and empowering (and you can't really do that in Python, you can abuse decorators for it nowadays but it's not exactly sexy or readable, or generall…
I'd also say that ruby has done a better job of moving forward. Compare ruby 1.9 to python 3. I think JRuby is more mature than jpython, and I know this will start the flames, but I think ruby is clearly better for web stuff; not just rails, but the whole ecosystem. Edit: I also think bundler is better than what is going on in python land.
They're not comparable, so no.
> I think JRuby is more mature than jpython
Pretty different situations, from 2006 to 2009 two lead JRuby developers were hired specifically for that by Sun (later left for EngineYard) and a third was hired by ThoughtWorks for the same.
For Jython this only happened in 2008, after the project had pretty much gone on freeze due to the original founder leaving to work on the Pypy project.
Compare IronPython to IronRuby instead, and the situation is reversed. Same if you compare Rubinius and Pypy.
> and I know this will start the flames, but I think ruby is clearly better for web stuff
That's your personal judgement, I don't agree.