Well, I too have anecdotes in the opposite direction, so not sure what to say. I've used Python on very, very large projects that have undergone multiple, massive refactorings and I'm not aware of a single time in a refactor that this was an issue. Honestly, as I've read your message and others' and genuinely tried to imagine the circumstances under which it would happen, I'm really struggling. Like, do you have these 10 page functions or something and large swaths of code are being cut and paste willy nilly?
The "major source of bugs" comment - is that "major source of bugs [in programs I've worked on]" or "major source of bugs [for Python programs generally]"? If it's the latter, I'd love to hear more because, again, my experience and the experience of everyone I've ever worked with who uses Python is the exact opposite.
"nearly impossible to find bugs in" ?? Sorry, but that's at best a wild exaggeration. I have no way of knowing if you've really seen "teams" of programmers spend "weeks" looking for one line being wrong with tabs or spaces, but it strains credulity - if it's true, then that may say more about those developers. Sorry, I'm sure that comes across rude, and that's not my intention, but... wow. So this code passed your unit tests and there was some corner case w/o coverage in which it resulted only in something like a logic error and not something more obvious like throwing an exception? Not saying it can't happen, but the whole scenario sounds a bit fishy, especially if it took multiple teams multiple weeks to find it. Anyway...
On the whole, I haven't found Python any harder to find bugs in, and there are a good chunk of bugs that simply don't occur in it, so that it has been a net gain for me. I guess YMMV, but again, I've used Python along with other languages for literally decades and what you're describing just doesn't occur. Maybe I should go buy a lottery ticket or something because I'm wildly lucky... or maybe this just doesn't happen very often in practice.
I think I get the point you're trying to make, but I'm a bit dubious - it's a syntactically valid change, so there's no reason for the tool to complain. That's in the same class of errors as deleting a digit from a constant, accidentally pressing '+' instead of '-', removing the '=' from a '=' expression, and so on.
I personally don't care if certain people like Python or not - language preference is often fairly subjective. I'm doubtful, however, about claims that the indenting is bad in any objective way - I've seen too many people use it for too many years on too many projects without it being a problem. I mean, don't you think this would be tripping people up constantly if it were a real issue in practice?
I've watched veteran devs pick up Python as well as recent college grads pick it up, and this just isn't an issue. I can maybe/kinda/sorta almost convince myself that I've just been extraordinarily lucky to have never had this be a problem, but for it to not be a common problem for all of those other people, on all of those other projects? Nah, it just doesn't add up. Everything I've seen suggests that this is a problem that could occur in theory, but rarely if ever does in practice.
Indentation is the strongest indicator of block structure to the people reading and writing the code, but the toolchain uses a *different* set of indicators (the braces and semicolons). Any person who is looking at code - especially just quickly scanning code - is going to rely on the indentation to denote blocks first, and then to a lesser degree things like curly braces - the spacing and positioning are simply stronger visual cues.
In most languages, this is what can lead to a few types of subtle bugs, e.g.
if (x y);
doSomething();
Python's stance is that the humans and the tools should use the same block identifiers. Sure there are other ways to solve the problem (like make the tools look for likely errors and warn the user), but Python chose the route of just getting people and tools on the same page - it's not a bad solution.
Personally, I've used Python for many years now, in everything from tiny startups to Fortune 500 companies, for everything from small tools to enormous, distributed systems. Like any language, it has its strengths and its weaknesses, but the indentation is not an issue in practice, but is instead an asset. All of the potential or theoretical problems that people complain about with indentation-based blocks are overblown and simply doesn't occur in practice - at least no more than any other type of problem (I can't even remember the last time we had a bug due to it - probably not in this decade).
If that's not your cup of tea, that's fine. I just find it interesting that (a) it does not actually cause problems in practice and (b) when I hop over to a language like C++ I find that curly braces are just noise and feel wholly unnecessary - just extra stuff to help the tools along, and not there for my benefit as a developer.
Yeah, no disagreement there - I was addressing just the LOC aspect.
FWIW Python's threading model does have concurrent execution of threads, but only for a part of the time - it does support true OS-level threads, but a single, process-wide interpreter lock gets held when running Python bytecode or in a Python API function, so/some/ applications see benefits to using multiple threads (typically cases when you can either do lots of work in a C API or when you are waiting on I/O and just want concurrency but aren't necessarily CPU bound), but often that is not the case and/or the app has trouble using all available CPU. On the upside, it's really great in that you can't corrupt Python's internal state and crash with threads, but that's a pretty minor upside.:)
The multiprocessing library is pretty nifty - at my current job we run a Python request handler process on each CPU core and use pipes to talk to a "controller" process (ends up being message inter-thread communication, so a lot like if you use ZMQ), but it's still a far cry from normal threads. And if you just need concurrency and aren't CPU bound, then gevent is pretty spectacular.
But despite all of this, I think Python's threading model is still one of the big design decisions that can make it a difficult choice in some environments - for our current system, we settled on Python despite this and decided that the cost of dealing with it is offset by the other benefits of Python, but it'd sure be notice to avoid that.
Long term, I'm keeping an eye on pypy+STM (http://doc.pypy.org/en/latest/stm.html) - it's nowhere near ready and may not ever be, but it's cool in that it's taking a radically different approach to the problem.
Yeah, that's a good point. I think an even better example might be low level bit twiddling of a byte stream and conversion back and forth between a struct in memory and a packed binary file format - C rules there and in Python you end up jumping through weird hoops a lot of times. The struct module helps a lot (though to your point it's more verbose than the same task in C), but only to a point.
I'll bite, though I wish you hadn't posted anonymously.:)
1) I don't think Twisted is that relevant because it's judging a language based on a library that some third party wrote. And Twisted was insane in part because of the callback-oriented approach to asynchronous programming it took (these days you can use e.g. gevent, which is awesome).
2) The whole whitespace issue is pretty simple, actually. In all the languages you cited (C, C++, Java, etc.) there's a problem in that in reality there are *two* systems for denoting blocks, and the programmer (and IDE, if used) keeps them in sync. The first is the *actual* system, which are things like the { } tokens in C. The second is the whitespace - you'd be rightfully skewered if you tried to write code without "proper" formatting because it'd be an unreadable mess. The problem is that the language parser cares only about the first one, while the human - intentionally or not - generally leans more heavily on the second one, most of the time.
Instead of removing the redundancy and having both the machine and the human rely on a single means of denoting blocks, we instead went with the bandaid solution of making the tools help point out errors like this:
while (x < 100);
doSomething();
Python took a different approach and made the language use the same code block delimiter that humans use for both pseudocode and real code: the whitespace. Some people simply don't like that, and that's fine, but for me it makes great sense and I'm pretty skeptical of people who are rabidly against it, since they undoubtedly rely on whitespace all the time, even if it's subconscious.
3) I use Python a ton, and it's because it's concise while readable, in part due to the language design and in part due to the rich set of built in data types and standard libraries. For any non-trivial task, an equivalent C program (and I love C, BTW) is often 5x or more LOC. That's totally fine because C is great at what it's for, but it's also really great to write 20% of the code to do stuff in Python. A core part of Python's philosophy is to keep in mind that code is read far more times than it is written, so readability is hugely important (for example, the colon at the end of e.g. an 'if' statement wouldn't really be necessary, but Guido et al actually did some code readability tests and found that it improved readability, so he put it in).
Obviously you can write ugly code in any language, and Python is no exception, but I've found that Python makes it easy to write readable code.
4) Performance is often a bit of a red herring. Yes, Python itself is quite slow, but in day-to-day work there's often very little code that actually needs high performance. I've worked at several companies with large Python systems and for most parts of the system, if something takes 1ms vs 0.05ms, it just doesn't matter, but the cost of building, testing, and maintaining that component does matter. A lot. Further, huge parts of most Python programs are actually running C code because so much happens in libraries. Doing file I/O? Networking? All of that is really in C. Number crunching, image manipulation, crypto, etc. etc. - it's all C routines in a pretty Python interface.
Beyond that, in cases where you really do have some chunk of code that has to be blazingly fast, you can easily write it in C and call it from Python (see ctypes, libffi, cython, and so on). Python is by no means a perfect fit for every problem, and it does have its warts, but it's a really terrific fit for a huge set of problems, and a good fit for many more. (and on the performance front I didn't even touch on pypy, which is a drop-in replacement for a large and growing set of Python programs - basically a no-effort perf boost)
5) The kicker for me actually has to do with your question of "What the heck is the attraction". Developing in Python is just more fun. It's kind of silly, on some level, but you might be surprised by how much that matters. I
The Kernel is written in C - a language designed for brevity, while python is much more verbose.... So the exact same algorithm is likely to use more lines in python than in C
I dunno, YMMV, but to me the opposite seems to pretty much always be the case - for any non-trivial chunk of code, the Python version tends to require far fewer lines than the C equivalent. At several different companies we've ported various C modules to Python and it's common for the Python version to have only 20% (or fewer) LOC vs the C original. The reason is just the usual stuff: Python, being a much higher level language, introduces a lot of overhead but in exchange you get powerful built-in data types and have to do basically zero manual memory management.
This tends to show up in not just large libraries or apps, but even in small chunks of code. For example, below is a function from one of our network monitoring agents; as background, basically there are a bunch of different server clusters and a job monitor spits out an hourly file that lists on each line the IP address of each server and the number of errors it encountered (this is part of some legacy thing we're hoping to replace, it's kind of goofy). Anyway, those files get aggregated to a central monitor, that in turn looks for various conditions and alarms if e.g. the error rates are too high.
Anyway, here's a function that reads those files and tells you which servers are seeing the most errors (it returns a list of server IP address and number of errors encountered, in descending order of number of errors):
def ServerErrorRates(reportFiles):
counts = {} # ip addr --> total errors
for filename in reportFiles:
for line in open(filename):
ip, errors = line.strip().split()
counts[ip] = counts.get(ip, 0) + int(errors)
return sorted(counts.items(), key=lambda x:x[1], reverse=True)
Nothing fancy, but doing that in straight C is likely going to take far more than 7 code statements. There's just no way to perform the same work in C in anything close to 7 statements. It's not a knock on C, the two tools are just optimized for different things.
As another example, I just took a peek at our HTTP server library. The whole thing is a single file of less than 800 LOC, and that handles all HTTP request/response handling including header reading/writing, file uploads, cookies, websocket support, request routing, etc., etc. without using any of the HTTP stuff from the Python standard library. The C equivalent would certainly be several times as many lines of code.
I think you could maybe argue that individual statements in Python are more verbose than C, but it's common for each Python statement to be the equivalent of several C statements (and/or many statements in C are simply not required in Python), so on the whole Python programs end up being way more concise. Occasionally I'll see an exception, but it's just that - an exception.
The summary, especially the title, omitted a really important detail: it's not that they are porting it to VC++, it's that they are making it work with VC++ *2015*.
IOW they apparently already had the build working with an earlier version of VC++, and this is all about them changing things to work with this newer version of VC++.
Are movie theaters in most cities really that terrible, or has it just been a long time since you've been to a movie theater? So many people gripe about having to put up with a theater experience and I just don't get it.
Within 20 miles of my home there are 4-5 "megaplex" theaters where, for a $5 matinee ticket, you can go see the very latest movies on incredibly good screens with terrific audio systems, you stand in no waiting lines, you sit in large, plush semi-reclining chairs with stadium (sloped) seating. The room is clean, the floors are clean. Heck, even the bathrooms are clean. Even if you pay a few bucks more to go at night, you still don't really wait in line and there's never any jostling for seats because you can buy your tickets online and choose your exact seat ahead of time.
At home we have a pretty nice setup for watching movies, but we still occasionally go to the theater not to "put up" with a movie theater, but because of it - it's a fun experience.
FWIW I'm not trying to rip on you, I'm just genuinely curious.:)
Haha, so true. If it had been any more different from the original trilogy then people would be complaining that it departed from the heart and soul of SW, that it was Star Trek rebranded, etc. I took my kids to it, we had a great time too - it was fun and it felt nice and Star Wars-y.
If I was to sit back and pick the movie apart then, sure, I could find problems with it. But what's the point of doing that? I exchanged some amount of money for some amount of entertainment, and in the end I felt it was a good trade. Me looking for flaws in the movie will just decrease the enjoyment I got out of it and will in no way improve the subsequent movies, so why bother?
We like the Star Wars universe, we got to see more of it, and now I'm cautiously optimistic about future installments. WIN!
But she makes more progress in half a movie (and years less time in the story) than Luke AND Anakin did with training by masters, field experience, and a lot of time.
It's not incredible... it's simply not credible.
Hmm... aren't you making an assumption that there is no alternative explanation for this that fits in the story? Yes, given "she makes an incredible amount of progress in a short amount of time", then one conclusion *could* be "therefore, the story is broken", but why assume that's the only possible explanation?
I wondered if her rapid pace at discovering the force wasn't discovering at all, but remembering. i.e. I won't be surprised if in Ep8/9 we find out that she had been a Padawan in training at Luke's school and when things went crazy there, they took some of the promising kids and hid them away on various planets, wiping their memories as a way to protect them. Her vision after finding the lightsaber would seem to suggest this is at least possible.
Anyway, yeah,/maybe/ that part of the story is screwed up. Or maybe, since this act one of a new multi-act story, you're supposed to wonder about some things that eventually get explained.:)
In generally I think you'd be right, but the specific channel they're considering is truTV - a channel that has very little scripted (in the traditional sense) content. Their big focus is on "reality" TV (https://en.wikipedia.org/wiki/TruTV), and next to sports programming, reality shows would be the easiest to lengthen - much of the editing process is whittling down hours and hours of footage into the 22 or 44 minutes of available time.
In other words, Turner is going to just barely dip their toes into the water, a year from now, and they'll do it with some of the easiest content they could try. So... slow...:)
"Time Warner's truTV will cut its ad load in half for prime-time original shows starting late next year"
Wait, so you're gonna react to a problem a year from now?!
I know this is probably driven in part by existing contracts, and while the current state of advertising is definitely a mess, I think it's more a symptom of an underlying problem. And that problem is that in almost every respect, traditional TV broadcasters have been way too slow to keep up. Almost without exception they had to be dragged into the 21st century. They had to be coaxed into alternate viewing devices, allowing time-shifting was a huge battle, etc.
The way they alienate their users via current ad models is bad, but it's just an example from a larger set of ways they alienate their users.
Yes! Also, stop remembering the hashes of my past N passwords.
Forcing you to routinely change passwords, forcing the inclusion of mixed case or numbers or symbols, forcing you to not reuse a past password... net result is less security because most people will just end up writing their weird passwords down somewhere.
All of these restrictions aren't fixing the problem, just shifting elsewhere to be not the site's problem.
To some extent, ya. But DRM formats and streaming/container formats are a bigger issue for them - on the vast majority (nearly all? all?) of their supported platforms, the video is h.264.
A lot of the stuff I've used it for are things I didn't plan on using it for, i.e. it's not until it's an option that you start to find some uses for it. Anyway, I'm not a very good 3d modeler but I've used my printer for:
- a custom laptop stand - replacement knobs for washer, dryer, etc. (not sure why so many broke off, but kinda cool to print replacements) - mods for my kids' toys (e.g. an equipment connector for Nerf guns) - wall mount for a quadcopter so I could get it off my desk - computer speaker mounts - odds and ends for organization of household items - containers, dividers, custom holders of random stuff around the house - a couple of small camp gadgets - simple hooks for flashlight, hanger attachments for stuff on a rope - custom/replacement Lego parts (results are mixed so far) - similar to knobs for washer & dryer, replacement parts for other things around the house like a part that broke in my window blinds
Preface: creationism shouldn't be taught in schools except for in e.g. a World Religions or Comparative Religions class or something. It has no place in a science class.
That said I've been in a *lot* of science classes where, instead of sticking to science, the teacher almost gleefully makes the discussion about religion and tries to use science to disprove religion - I remember that as far back as my middle school days and all through high school - it was very, very frequent. Sometimes it was very overt; many times it was just interjecting needless, snarky anti-religion comments that implied that religion and science had to be at odds with each other (they don't) and that obviously only a moron would be religious to any degree. A little Googling reveals that this isn't all that uncommon (although, unfortunately, many of the accounts are often full of hysteria so it's hard to extract the facts, but the fact that there are so many of them is enough to suggest my experience isn't completely unheard of).
So I have to disagree with the idea that "nobody" is teaching that there is no God - I heard that all the time in what should have been science classes. I have no problem with a teacher being personally religious or atheistic or anything in between. I don't have a problem with them acknowledging their belief. But it's completely wrong for either of them to use a science class as a forum for advocating their position, and I've seen both happen so often that I honestly can't say whether either is more common than the other.
Also, maybe I'm just taking this out of context, but the bit about "Atheists probably value personal choice more than ANY other group of people" doesn't ring true to me at all. I see no reason why an atheist would inherently value personal choice regarding beliefs over any other group, and it's easy to find vitriolic, close-minded people all along the belief spectrum, and some of the staunchest defenders of choice I've come across are people who are themselves very religious.
Slashdot Mirror
Well, I too have anecdotes in the opposite direction, so not sure what to say. I've used Python on very, very large projects that have undergone multiple, massive refactorings and I'm not aware of a single time in a refactor that this was an issue. Honestly, as I've read your message and others' and genuinely tried to imagine the circumstances under which it would happen, I'm really struggling. Like, do you have these 10 page functions or something and large swaths of code are being cut and paste willy nilly?
The "major source of bugs" comment - is that "major source of bugs [in programs I've worked on]" or "major source of bugs [for Python programs generally]"? If it's the latter, I'd love to hear more because, again, my experience and the experience of everyone I've ever worked with who uses Python is the exact opposite.
"nearly impossible to find bugs in" ?? Sorry, but that's at best a wild exaggeration. I have no way of knowing if you've really seen "teams" of programmers spend "weeks" looking for one line being wrong with tabs or spaces, but it strains credulity - if it's true, then that may say more about those developers. Sorry, I'm sure that comes across rude, and that's not my intention, but ... wow. So this code passed your unit tests and there was some corner case w/o coverage in which it resulted only in something like a logic error and not something more obvious like throwing an exception? Not saying it can't happen, but the whole scenario sounds a bit fishy, especially if it took multiple teams multiple weeks to find it. Anyway...
On the whole, I haven't found Python any harder to find bugs in, and there are a good chunk of bugs that simply don't occur in it, so that it has been a net gain for me. I guess YMMV, but again, I've used Python along with other languages for literally decades and what you're describing just doesn't occur. Maybe I should go buy a lottery ticket or something because I'm wildly lucky... or maybe this just doesn't happen very often in practice.
I think I get the point you're trying to make, but I'm a bit dubious - it's a syntactically valid change, so there's no reason for the tool to complain. That's in the same class of errors as deleting a digit from a constant, accidentally pressing '+' instead of '-', removing the '=' from a '=' expression, and so on.
I personally don't care if certain people like Python or not - language preference is often fairly subjective. I'm doubtful, however, about claims that the indenting is bad in any objective way - I've seen too many people use it for too many years on too many projects without it being a problem. I mean, don't you think this would be tripping people up constantly if it were a real issue in practice?
I've watched veteran devs pick up Python as well as recent college grads pick it up, and this just isn't an issue. I can maybe/kinda/sorta almost convince myself that I've just been extraordinarily lucky to have never had this be a problem, but for it to not be a common problem for all of those other people, on all of those other projects? Nah, it just doesn't add up. Everything I've seen suggests that this is a problem that could occur in theory, but rarely if ever does in practice.
Indentation is the strongest indicator of block structure to the people reading and writing the code, but the toolchain uses a *different* set of indicators (the braces and semicolons). Any person who is looking at code - especially just quickly scanning code - is going to rely on the indentation to denote blocks first, and then to a lesser degree things like curly braces - the spacing and positioning are simply stronger visual cues.
In most languages, this is what can lead to a few types of subtle bugs, e.g.
if (x y);
doSomething();
Python's stance is that the humans and the tools should use the same block identifiers. Sure there are other ways to solve the problem (like make the tools look for likely errors and warn the user), but Python chose the route of just getting people and tools on the same page - it's not a bad solution.
Personally, I've used Python for many years now, in everything from tiny startups to Fortune 500 companies, for everything from small tools to enormous, distributed systems. Like any language, it has its strengths and its weaknesses, but the indentation is not an issue in practice, but is instead an asset. All of the potential or theoretical problems that people complain about with indentation-based blocks are overblown and simply doesn't occur in practice - at least no more than any other type of problem (I can't even remember the last time we had a bug due to it - probably not in this decade).
If that's not your cup of tea, that's fine. I just find it interesting that (a) it does not actually cause problems in practice and (b) when I hop over to a language like C++ I find that curly braces are just noise and feel wholly unnecessary - just extra stuff to help the tools along, and not there for my benefit as a developer.
Thank you for not writing "towing the line", it would have driven me crazy. That is all.
Ruby On Rails != Ruby
(the guy being interviewed didn't write Ruby)
Yeah, no disagreement there - I was addressing just the LOC aspect.
FWIW Python's threading model does have concurrent execution of threads, but only for a part of the time - it does support true OS-level threads, but a single, process-wide interpreter lock gets held when running Python bytecode or in a Python API function, so /some/ applications see benefits to using multiple threads (typically cases when you can either do lots of work in a C API or when you are waiting on I/O and just want concurrency but aren't necessarily CPU bound), but often that is not the case and/or the app has trouble using all available CPU. On the upside, it's really great in that you can't corrupt Python's internal state and crash with threads, but that's a pretty minor upside. :)
The multiprocessing library is pretty nifty - at my current job we run a Python request handler process on each CPU core and use pipes to talk to a "controller" process (ends up being message inter-thread communication, so a lot like if you use ZMQ), but it's still a far cry from normal threads. And if you just need concurrency and aren't CPU bound, then gevent is pretty spectacular.
But despite all of this, I think Python's threading model is still one of the big design decisions that can make it a difficult choice in some environments - for our current system, we settled on Python despite this and decided that the cost of dealing with it is offset by the other benefits of Python, but it'd sure be notice to avoid that.
Long term, I'm keeping an eye on pypy+STM (http://doc.pypy.org/en/latest/stm.html) - it's nowhere near ready and may not ever be, but it's cool in that it's taking a radically different approach to the problem.
Yeah, that's a good point. I think an even better example might be low level bit twiddling of a byte stream and conversion back and forth between a struct in memory and a packed binary file format - C rules there and in Python you end up jumping through weird hoops a lot of times. The struct module helps a lot (though to your point it's more verbose than the same task in C), but only to a point.
I'll bite, though I wish you hadn't posted anonymously. :)
1) I don't think Twisted is that relevant because it's judging a language based on a library that some third party wrote. And Twisted was insane in part because of the callback-oriented approach to asynchronous programming it took (these days you can use e.g. gevent, which is awesome).
2) The whole whitespace issue is pretty simple, actually. In all the languages you cited (C, C++, Java, etc.) there's a problem in that in reality there are *two* systems for denoting blocks, and the programmer (and IDE, if used) keeps them in sync. The first is the *actual* system, which are things like the { } tokens in C. The second is the whitespace - you'd be rightfully skewered if you tried to write code without "proper" formatting because it'd be an unreadable mess. The problem is that the language parser cares only about the first one, while the human - intentionally or not - generally leans more heavily on the second one, most of the time.
Instead of removing the redundancy and having both the machine and the human rely on a single means of denoting blocks, we instead went with the bandaid solution of making the tools help point out errors like this:
while (x < 100);
doSomething();
Python took a different approach and made the language use the same code block delimiter that humans use for both pseudocode and real code: the whitespace. Some people simply don't like that, and that's fine, but for me it makes great sense and I'm pretty skeptical of people who are rabidly against it, since they undoubtedly rely on whitespace all the time, even if it's subconscious.
3) I use Python a ton, and it's because it's concise while readable, in part due to the language design and in part due to the rich set of built in data types and standard libraries. For any non-trivial task, an equivalent C program (and I love C, BTW) is often 5x or more LOC. That's totally fine because C is great at what it's for, but it's also really great to write 20% of the code to do stuff in Python. A core part of Python's philosophy is to keep in mind that code is read far more times than it is written, so readability is hugely important (for example, the colon at the end of e.g. an 'if' statement wouldn't really be necessary, but Guido et al actually did some code readability tests and found that it improved readability, so he put it in).
Obviously you can write ugly code in any language, and Python is no exception, but I've found that Python makes it easy to write readable code.
4) Performance is often a bit of a red herring. Yes, Python itself is quite slow, but in day-to-day work there's often very little code that actually needs high performance. I've worked at several companies with large Python systems and for most parts of the system, if something takes 1ms vs 0.05ms, it just doesn't matter, but the cost of building, testing, and maintaining that component does matter. A lot. Further, huge parts of most Python programs are actually running C code because so much happens in libraries. Doing file I/O? Networking? All of that is really in C. Number crunching, image manipulation, crypto, etc. etc. - it's all C routines in a pretty Python interface.
Beyond that, in cases where you really do have some chunk of code that has to be blazingly fast, you can easily write it in C and call it from Python (see ctypes, libffi, cython, and so on). Python is by no means a perfect fit for every problem, and it does have its warts, but it's a really terrific fit for a huge set of problems, and a good fit for many more. (and on the performance front I didn't even touch on pypy, which is a drop-in replacement for a large and growing set of Python programs - basically a no-effort perf boost)
5) The kicker for me actually has to do with your question of "What the heck is the attraction". Developing in Python is just more fun. It's kind of silly, on some level, but you might be surprised by how much that matters. I
The Kernel is written in C - a language designed for brevity, while python is much more verbose. ... So the exact same algorithm is likely to use more lines in python than in C
I dunno, YMMV, but to me the opposite seems to pretty much always be the case - for any non-trivial chunk of code, the Python version tends to require far fewer lines than the C equivalent. At several different companies we've ported various C modules to Python and it's common for the Python version to have only 20% (or fewer) LOC vs the C original. The reason is just the usual stuff: Python, being a much higher level language, introduces a lot of overhead but in exchange you get powerful built-in data types and have to do basically zero manual memory management.
This tends to show up in not just large libraries or apps, but even in small chunks of code. For example, below is a function from one of our network monitoring agents; as background, basically there are a bunch of different server clusters and a job monitor spits out an hourly file that lists on each line the IP address of each server and the number of errors it encountered (this is part of some legacy thing we're hoping to replace, it's kind of goofy). Anyway, those files get aggregated to a central monitor, that in turn looks for various conditions and alarms if e.g. the error rates are too high.
Anyway, here's a function that reads those files and tells you which servers are seeing the most errors (it returns a list of server IP address and number of errors encountered, in descending order of number of errors):
def ServerErrorRates(reportFiles):
counts = {} # ip addr --> total errors
for filename in reportFiles:
for line in open(filename):
ip, errors = line.strip().split()
counts[ip] = counts.get(ip, 0) + int(errors)
return sorted(counts.items(), key=lambda x:x[1], reverse=True)
Nothing fancy, but doing that in straight C is likely going to take far more than 7 code statements. There's just no way to perform the same work in C in anything close to 7 statements. It's not a knock on C, the two tools are just optimized for different things.
As another example, I just took a peek at our HTTP server library. The whole thing is a single file of less than 800 LOC, and that handles all HTTP request/response handling including header reading/writing, file uploads, cookies, websocket support, request routing, etc., etc. without using any of the HTTP stuff from the Python standard library. The C equivalent would certainly be several times as many lines of code.
I think you could maybe argue that individual statements in Python are more verbose than C, but it's common for each Python statement to be the equivalent of several C statements (and/or many statements in C are simply not required in Python), so on the whole Python programs end up being way more concise. Occasionally I'll see an exception, but it's just that - an exception.
The summary, especially the title, omitted a really important detail: it's not that they are porting it to VC++, it's that they are making it work with VC++ *2015*.
IOW they apparently already had the build working with an earlier version of VC++, and this is all about them changing things to work with this newer version of VC++.
Yikes, good call. With all the recent stories about fudging data, we should keep an eye on this guy.
Haha, exactly - it sounds like his model is saying there are zero earths, not one. :)
Are movie theaters in most cities really that terrible, or has it just been a long time since you've been to a movie theater? So many people gripe about having to put up with a theater experience and I just don't get it.
Within 20 miles of my home there are 4-5 "megaplex" theaters where, for a $5 matinee ticket, you can go see the very latest movies on incredibly good screens with terrific audio systems, you stand in no waiting lines, you sit in large, plush semi-reclining chairs with stadium (sloped) seating. The room is clean, the floors are clean. Heck, even the bathrooms are clean. Even if you pay a few bucks more to go at night, you still don't really wait in line and there's never any jostling for seats because you can buy your tickets online and choose your exact seat ahead of time.
At home we have a pretty nice setup for watching movies, but we still occasionally go to the theater not to "put up" with a movie theater, but because of it - it's a fun experience.
FWIW I'm not trying to rip on you, I'm just genuinely curious. :)
Haha, so true. If it had been any more different from the original trilogy then people would be complaining that it departed from the heart and soul of SW, that it was Star Trek rebranded, etc. I took my kids to it, we had a great time too - it was fun and it felt nice and Star Wars-y.
If I was to sit back and pick the movie apart then, sure, I could find problems with it. But what's the point of doing that? I exchanged some amount of money for some amount of entertainment, and in the end I felt it was a good trade. Me looking for flaws in the movie will just decrease the enjoyment I got out of it and will in no way improve the subsequent movies, so why bother?
We like the Star Wars universe, we got to see more of it, and now I'm cautiously optimistic about future installments. WIN!
But she makes more progress in half a movie (and years less time in the story) than Luke AND Anakin did with training by masters, field experience, and a lot of time.
It's not incredible... it's simply not credible.
Hmm... aren't you making an assumption that there is no alternative explanation for this that fits in the story? Yes, given "she makes an incredible amount of progress in a short amount of time", then one conclusion *could* be "therefore, the story is broken", but why assume that's the only possible explanation?
I wondered if her rapid pace at discovering the force wasn't discovering at all, but remembering. i.e. I won't be surprised if in Ep8/9 we find out that she had been a Padawan in training at Luke's school and when things went crazy there, they took some of the promising kids and hid them away on various planets, wiping their memories as a way to protect them. Her vision after finding the lightsaber would seem to suggest this is at least possible.
Anyway, yeah, /maybe/ that part of the story is screwed up. Or maybe, since this act one of a new multi-act story, you're supposed to wonder about some things that eventually get explained. :)
In generally I think you'd be right, but the specific channel they're considering is truTV - a channel that has very little scripted (in the traditional sense) content. Their big focus is on "reality" TV (https://en.wikipedia.org/wiki/TruTV), and next to sports programming, reality shows would be the easiest to lengthen - much of the editing process is whittling down hours and hours of footage into the 22 or 44 minutes of available time.
In other words, Turner is going to just barely dip their toes into the water, a year from now, and they'll do it with some of the easiest content they could try. So... slow... :)
"Time Warner's truTV will cut its ad load in half for prime-time original shows starting late next year"
Wait, so you're gonna react to a problem a year from now?!
I know this is probably driven in part by existing contracts, and while the current state of advertising is definitely a mess, I think it's more a symptom of an underlying problem. And that problem is that in almost every respect, traditional TV broadcasters have been way too slow to keep up. Almost without exception they had to be dragged into the 21st century. They had to be coaxed into alternate viewing devices, allowing time-shifting was a huge battle, etc.
The way they alienate their users via current ad models is bad, but it's just an example from a larger set of ways they alienate their users.
Yes! Also, stop remembering the hashes of my past N passwords.
Forcing you to routinely change passwords, forcing the inclusion of mixed case or numbers or symbols, forcing you to not reuse a past password... net result is less security because most people will just end up writing their weird passwords down somewhere.
All of these restrictions aren't fixing the problem, just shifting elsewhere to be not the site's problem.
Actually, that's the reason I said what I did. :)
(that and my company is smack dab in the middle of the digital media space)
To some extent, ya. But DRM formats and streaming/container formats are a bigger issue for them - on the vast majority (nearly all? all?) of their supported platforms, the video is h.264.
A lot of the stuff I've used it for are things I didn't plan on using it for, i.e. it's not until it's an option that you start to find some uses for it. Anyway, I'm not a very good 3d modeler but I've used my printer for:
- a custom laptop stand
- replacement knobs for washer, dryer, etc. (not sure why so many broke off, but kinda cool to print replacements)
- mods for my kids' toys (e.g. an equipment connector for Nerf guns)
- wall mount for a quadcopter so I could get it off my desk
- computer speaker mounts
- odds and ends for organization of household items - containers, dividers, custom holders of random stuff around the house
- a couple of small camp gadgets - simple hooks for flashlight, hanger attachments for stuff on a rope
- custom/replacement Lego parts (results are mixed so far)
- similar to knobs for washer & dryer, replacement parts for other things around the house like a part that broke in my window blinds
Wow, those are some pretty huge generalizations, of both religious people and atheists.
Preface: creationism shouldn't be taught in schools except for in e.g. a World Religions or Comparative Religions class or something. It has no place in a science class.
That said I've been in a *lot* of science classes where, instead of sticking to science, the teacher almost gleefully makes the discussion about religion and tries to use science to disprove religion - I remember that as far back as my middle school days and all through high school - it was very, very frequent. Sometimes it was very overt; many times it was just interjecting needless, snarky anti-religion comments that implied that religion and science had to be at odds with each other (they don't) and that obviously only a moron would be religious to any degree. A little Googling reveals that this isn't all that uncommon (although, unfortunately, many of the accounts are often full of hysteria so it's hard to extract the facts, but the fact that there are so many of them is enough to suggest my experience isn't completely unheard of).
So I have to disagree with the idea that "nobody" is teaching that there is no God - I heard that all the time in what should have been science classes. I have no problem with a teacher being personally religious or atheistic or anything in between. I don't have a problem with them acknowledging their belief. But it's completely wrong for either of them to use a science class as a forum for advocating their position, and I've seen both happen so often that I honestly can't say whether either is more common than the other.
Also, maybe I'm just taking this out of context, but the bit about "Atheists probably value personal choice more than ANY other group of people" doesn't ring true to me at all. I see no reason why an atheist would inherently value personal choice regarding beliefs over any other group, and it's easy to find vitriolic, close-minded people all along the belief spectrum, and some of the staunchest defenders of choice I've come across are people who are themselves very religious.
Ok... but... why are you replying to me?