91–99 of 99 posts
Earlier quoted context omitted.
Such vulnerabilities still exist in PHP, Python and Ruby, because they are written in C. And they are much easier to exploit because almost every web app uses one of these languages.
Nonsense. Just because the Python interpreter is written in C does not mean that you can overrun Python strings and smash the stack like you can w/ C strings.
Earlier quoted context omitted.
So, serving web pages from an embedded device? Have we finally got to the "your washing machine is on the Internet" era? :)
I can't wait for the RESTful API for my alarm clock, and washer. ;-)
Objc is probably a better candidate because it is so dynamic?
See http://news.ycombinator.com/item?id=1046516 Web apps in Objective C --- the second-least safe programming language on the market. Oh please, oh please, build your next huge application in this. College tuition for my kids is freaking me out.
Earlier quoted context omitted.
I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affec…
> 2x faster at best That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the co…
Earlier quoted context omitted.
Oddly enough I'm back to C++ too, after Ruby. One nice thing is; in a fast language, tests run quickly too. Also, Python and Ruby don't have the equivalent of an ASSERT (you could roll your own but it's not standard practice ). Also, C++ has standard hash lists and complicated data structure are actually going to run quickly. And while memory management can be a pain, you are doing it yourself so you can track down m…
C++ doesn't actually have a standard "hash list" (I assume you meant hash map or hash set?). Depending on your implementation, you either have hash_{map,set}, unordered_{map,set}, both, or something entirely different. tr1 specified unordered_{map,set}, but tr1 is only technically a proposal, not a standard. I think a safe assumption is that tr1::unordered_{map,set} will be available in all implementations by now, bu…
Earlier quoted context omitted.
Such vulnerabilities still exist in PHP, Python and Ruby, because they are written in C. And they are much easier to exploit because almost every web app uses one of these languages.
Nonsense. Just because the Python interpreter is written in C does not mean that you can overrun Python strings and smash the stack like you can w/ C strings.
Earlier quoted context omitted.
"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
I guess my point was that the fast languages are generally not the ones that are good for developing the fast algorithms. It is harder to experiment in a language like C than it is in a language like lisp or perl. The other thing to point out is that there is no reason for memory usage, concurrency or speed to be problems in dynamic languages. These are all issues with the implementations of compilers/interpreters th…
The only way to make dynamic languages as fast as statically typed languages is to selectively remove dynamic features. A few type hints can make a huge difference.
Earlier quoted context omitted.
I can only tell you why _I_ am constantly complaining about the GIL. It's because I would like to use a Python/C combination for in-memory data analysis. C gives me the speed and memory efficiency and Python gives me the ease of use and the web stuff. There is no 50x speedup to be had as it doesn't get any faster than C. The only significant speedup will come from parallelism. 8 cores this year, 16 next year and prob…
Python C extension modules can release the GIL while they're running which allows for true concurrency. See this Google code search http://www.google.com/codesearch?q=python.org+lang%3Ac+Py_BE... for example usage.
But I have to admit that I haven't fully thought this possibility through. Maybe you're right that it can be made to work.