What a wonderful idea. Just FYI, I went to share this on facebook, and the thumbnail was white on white. You might want to put a few metadata tags in there.
Yeah I just installed the firefox version, saw it blocked even google charts, and uninstalled it. If it had adblock like control to whitelist domains it might be ok but as it is, cool idea, but no thanks.
let's please just celebrate our differences rather than tear each other down. This is a real insult to anyone who doesn't consider themselves introverted...
I've used Node.js to power a little "social doodling" pet project I made: http://letsdrawit.com and I find it a useful way to think about concurrency because there are certain types of race conditions you don't have to consider (for example any critical regions in memory)
It's extremely useful for the "evented" part, but I get the sensation of using node for hosting webpages might be overkill and not the appropriate tool. Instead, I've got the node.js core proxied behind an nginx server hosting static files and ruby rack (for when dynamic content is necessary).
Does anyone see an advantage of using Node to host templated webpages?
"- It is compiled into machine code (no interpreter, unlike Python)."
anyone have any kind of measure on how bytecode compares to machine code these days? (most "interpreted" languages have a hidden compile step these days). I understand that this question is largely subjective to the runtime and the task being executed.
Speed? http://shootout.alioth.debian.org/ is an up-to-date, super detailed answer to that question. A rule of thumb simplification I go by is: current Python and Ruby implementations are at least 10x slower than C doing algorithmic work.
A really good bytecode VM can, of course, get much closer to C performance (as shown by Java, C# or even modern JavaScript implementations) especially if JIT is given enough time to profile the app at runtime and generate highly optimized code based on that profile data.
There are of course other aspect you can compare. Bytecode is, inherently, cross-platform and machine code isn't.
Bytecode is usually more compact than equivalent machine code (but then you need the constant overhead of the runtime to interpret that bytecode).
Python is my main language, and I think you underestimate the speed different for a same implementation by an order of magnitude. That is, CPU-boud tasks will most likely be around 100x slower.
The realy argument, of course, is that in a given time frame, with people of similar skills, you will not have the same implementation unless your team contains only vulcans. Several people in the scipy community have reported having gone from C++ to numpy/scipy and went faster at the same time - because C++ is so hard to use correctly, people whose job is not even programming ended up doing things very fast but one millions times because they don't understand their code.
This point is surprisingly not understood by a majority of programmers. Most of the time, you see benchmarks for some trivial or even non trivial algorithms, well specified, and get "look, this language is N times faster". But in my experience, this almost never happens in real life - code specification keeps changing, you need to redesign constantly what you're doing.
I think 10x understates the difference. Python (not familiar with Ruby) eats memory so for a lot of the number crunching I do it turns into a swap disaster. End up with Python using up 10% of the processor waiting around for disk I/O.
Your question is relatively meaningless, since 'bytecode' covers such a wide gamut of possibilities.
Python's bytecode is very high-level and basically just saves the expense of parsing the code. The interpreter is not JIT-ed and thus very slow (compared to machine code).
Java's bytecode is much less dynamic. 'a + b' can execute arbitrary code in python, but in java it is known at compile-time whether it is addition between native types or string concat. Java has a very good JIT compiler and thus can be as fast as 1.5x the speed of c.
Yeah, Python is bytecode compiled and run in a virtual machine. Hell, you can even JIT it into machine code (psyco, Jython with a JIT-enabled JVM, IronPython with a JIT-enabled CLR). Python never had a traditional interpreter.
There were tons of people who were walking around 10 years ago thinking Smalltalk ran on "traditional" bytecode interpreters, when the majority of VM instances used back then running were JIT VM. There was also widespread ignorance about Lisp implementation and performance. The sad part: the degree of misconception is still surprisingly bad. (Much the same held and holds true for Lisp.)
The Interpreter/VM distinction had become hazy and lost its meaning years ago. I think people still hold onto it only as a means of excusing poor language performance.
Specifically: "Please do not reopen a ticket that's been marked "wontfix" by a core developer;"
I'm not sure how the issue jives with the whole Django philosophy, but with that much interest in changing the templating language, I found that a bit harsh...
Someone has to make a decision and since here that person is a django-core developer, I'm not sure there's much to argue with. If they don't want to do that, bug will get marked "won't fix" every time it's created.
What else do you propose developers should do? I may disagree with this decision, but someone has to lead the project.
How else will a core developer let it be known that this feature/issue won't be fixed? The "wontfix" tag/state is there for this very reason. And the core developers are there for this very reason -- to make decisions.
I'm curious though. Why not just fork the project and be more open in terms of getting patches in?
Maybe I missed something, but is this really how Firefox's location services work? By phoning google with the MAC address? I understood google was logging them, but didn't know they were _using_ them...
The location services are pretty creepy actually. I gave a site access and it knew my exact address. I will not be giving another site access, until I can specify that it should only provide my city.
