131–140 of 231 posts
Earlier quoted context omitted.
rapid movement definitely has it's downsides. However, I don't know what you mean when you say that ruby code isn't stable between versions. Do you mean between versions of ruby? If so, again, the transition from ruby 1.8 to ruby 1.9 was much much better than the transition from python 2 to python 3.
Python 2 to Python 3 is a big jump once in a lifetime. what about ruby 1.9 to ruby 2.0?
So I sat down and decided to find a nice general-purpose language that I would focus on learning. I wasn't quite sure what for yet, but I decided I was going to pick one and stick with it. I didn't have the time to learn multiple languages and I didn't have a lot of time to try out different ones, so I just looked around a little bit. Some I ruled out early: C and it's relatives were just too verbose, I didn't want to spend the time writing all the error handling necessary just to read a damn file. I was doing a lot of sysadmin type work at the time and had therefore developed an intense disliking for Java. This was based on too much badly packaged Java software that even if you got it running at all was sluggish, hogging way too much memory and crashed with arcane error messages. I did like the quick & dirty way I could make things work in a shell script, so I looked mostly at scripting languages.
I looked at Perl, which was the standard scripting language at the time and had a huge library (CPAN) of modules, which was great. I hated the syntax though and found the code often unreadable and there being too many ways of doing the same thing.
I looked at Pike, which had the benefit of using a C syntax (which I already knew, so that was a plus), but it seemed not widely supported and nobody was using it (this hasn't changed since, it seems).
I don't remember what else I looked at, but then there was Python. The syntax was a revelation. Here someone had finally made the most of creating a language from scratch and spent the time thinking about syntax and how to do away with largely pointless stuff (brackets), replacing it with things that everyone did anyways (indentation). It also came with a sizeable library of stuff that did almost everything I could dream of at the time. It was love at first sight.
Recently I've spent £35 on a stainless steel mill that grinds salt when you twist it one way and pepper when you twist it the other way, just because I really love well thought out and engineered things that make stuff that's been around forever just a little bit better. That's how I feel about Python. It's not doing anything fantastically new or unique, but it's doing the stuff that others do just a little bit better.
Today I'm doing lots of web stuff, some sysadmin stuff and random hacking of various things on the side. I'm still doing almost everything in Python and whenever Javascript bitches at me about a missed semicolon I do think: "All these fantastic things you can do in a web browser these days and you couldn't figure out that this command in an entirely different line isn't part of the previous line?".
The only thing that I can't do in Python is write software for my iPhone, which bugs me a bit. But every time I try to get into Objective C I just get annoyed by the syntax and amount of cruft I have to write to do anything.
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…
def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
def thing(something: "A string!") -> "does stuff":
I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them. Some Things Wrong With Python * Immutable strings[0] * Everything a reference[1] * Envir…
As a commenter on the article wrote: what about Ruby? I say this as a happy Python user. Ruby seems very similar but I'm reminded of a pg essay on language power: looking up the power curve, you see '$Language plus a bit of weird stuff that is probably irrelevant.' So I don't trust myself. As someone who loves Python and doesn't know any Ruby beyond a few bits of syntax and the obvious bits that are common to most la…
Except...
Every interpreter I've tried is just too slow. I recently ported over a networking library I wrote in python to ruby, and the requests per second (CPU limited in this case, since it was talking over a loopback socket -- this was just a test of how fast data could be serialized/deserialized) dropped from 7000 requests/sec in python to 120 in ruby. And that was just with standard CPython. Under PyPy, I was able to process about 20,000 requests/sec after letting the JIT warm up.
I realize it's sort of silly to choose a dynamically typed interpreted language on the grounds of performance when you're already giving up so much performance regardless, but in my mind python hits the sweet spot of "just fast enough for most things I need to do", and with all other things being roughly equal (which, in my opinion, they roughly are), being an order of a magnitude factor faster wins out.
Many years ago I've decided it was time to pick up a modern programming language. In the past I had written lots of (Turbo) Pascal code, some x86 (and more exotic) Assembler and a bit of C, but then for several years I only did shell/awk scripts and ported C software to IRIX and SINIX/RU. So I sat down and decided to find a nice general-purpose language that I would focus on learning. I wasn't quite sure what for yet…
I hear you about Python, but JavaScript doesn't require semicolons either, as far as I know. The main reason it's advisable to put them is to avoid ambiguity when 2 statements find themselves on the same line, for example, in a minified js file. Python uses semicolons for the same reasons, but minifying Python files is quite uncommon (and would probably serve no real purpose).
I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them. Some Things Wrong With Python * Immutable strings[0] * Everything a reference[1] * Envir…
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…
I want to make what I think is an important qualification which conflicts with a reading of your comment: Python is readable to people who are familiar with conventional Algol-based programming, i.e. every modern programmer. That does not make it readable to an arbitrary English-speaker, which is an assertion I sometimes hear: "Oh, Python is so much like English, people who aren't even programmers can read some of it…
I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them. Some Things Wrong With Python * Immutable strings[0] * Everything a reference[1] * Envir…
You forgot mutable default arguments! def fn(ls=[]): ls += [1] return len(ls) (My syntax might be a little off, but you get the idea.) This will return an ever-increasing number if called repeatedly with no arguments. Also, the reliance on tuples, particularly tuples of one item always gets me because (1) and (1,) are different. Also, the scoping for list comprehensions doesn't make sense: x = 11 [x for x in [1,2,3]]…