This might be misleading. Germany has something named "mini job" or "400 euro job", where you are paid exactly 400 euro which barely covers the groceries and the rent for a room. A lot of young people have such a job, and this keeps the unemployment rate low.
The amount of people employed in such jobs has actually decreased in recent years and nowadays, more people than ever are employed in full social security jobs in Germany.
That won't solve anything. Let's say that you leave London and 10:00 UTC, and land in another city at 15:00 UTC. Do you go to dinner? Breakfast? Can you schedule the business meeting at 17:30 UTC or this is just after midnight?
I worked in UTC for almost 3 years because it was company policy to have just one timezone for operations. Granted I was in Europe so the impact was minimal on my life, but not having DST and always working in UTC saved a great deal of problems when dealing with clients around the world on a real-time basis. The only organisation I ever had a problem with was the BBC because some of their people would regularly struggle to know which way was up.
I guess that it depends on the ISP (for general area location) or the Wi-Fi SSID and MAC (for exact location). I just ran an HTML5 geolocation demo http://html5demos.com/geo from my wi-fi connected laptop, and the location is less than a couple of meters off. It even shows the correct corner of the building, where my apartment is.
But could Python really take advantage of asm.js? I think that this is more useful for compiling statically typed languages (C/C++/... maybe TypeScript?) to JavaScript.
It's been said elsewhere, but you musn't forget that the python interpreter itself must be compiled. The pypy project is a python interpreter written in a restricted subset of python (rpython), and it would be doable to make the rpython compiler output asm.js.
It is true, though. Money is currency, not a store of value. Buy durable goods or invest in growth projects. Working to accumulate pure money is just piling IOUs on people. If you do that, you are going to face inflation in the future, which you deserve , because your non-spending took away other people's opportunity to create things of value. (Or, if they produced in excess of demand, then prices will drop in the future, and conpensatory inflation is no problem to you.)
What austerity are you talking about? The governments still spend much more money than they have. When you have no money, taking a loan to buy a 60" plasma TV instead of an 80" one does not mean austerity.
That benchmark is for algorithms implemented in pure Python and in pure Go. But for real projects, a Python programmer might use several libraries which are written in C.
>> That benchmark is for algorithms implemented in pure Python and in pure Go <<
Note that papsosouid needed to add the restriction "on benchmarks actually written in python instead of C" to avoid mentioning the 2 tasks where Python is shown as faster than Go ;-)
That would be unusual, but 80% of a program's performance is generally tied up in 20% of its code. If you can replace the 20% with a couple widely-used C libraries, then you get vastly improved performance without actually having to write much C.
In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do the intensive stuff.
Your comment was a non sequitur from what dnu said. Please refrain from attacking arguments with straw men - they add nothing to the discussion
Edited for tone:
s/Quit with the straw man arguments/Please refrain from attacking arguments with straw men/
>80% of a program's performance is generally tied up in 20% of its code
I've never seen any evidence to support this truthy sounding statement. In fact, my experience has been that it only holds true occasionally, and only for the very first initial profiling, seeing that some huge performance no-no was made. Once that is fixed, you have a pretty flat profile, with "the language is just slow" as your explanation, and no recourse.
>Your comment was a non sequitur from what dnu said.
No it wasn't. He responded to what I said. How could re-iterating what I said be a non-sequitur? Read the thread, I said python being only twice as slow as go "for my uses" would indicate some very unusual uses.
>In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do the intensive stuff.
No, in the cases you want to put forth as representative because they support your belief that slow languages are good enough. Most applications don't have a convenient "intensive stuff" to do in C. Most applications are like django, just generally slow all over because they are written in a slow language.
>Quit with the straw man arguments - they add nothing to the discussion.
Neither do unwarranted accusations of straw man arguments.
It was a non sequitur, and a straw man - you said that python was 5 times slower than C at best and 30-50 times slower than C at worst on some benchmarks.
dnu pointed out that the benchmarks did not represent real-world Python code, since real-world code uses C libraries for performance-intensive stuff.
You responded by saying that programs that are 90% C and 10% Python are unrealistic.
Nobody ever suggested using programs that were 90% C and 10% Python, or said that that kind of usage was common. That didn't follow what dnu said at all. You weren't "reiterating" anything - you never said anything about "your uses", coldtea did, much farther up the thread. (If you're coldtea, then I understand your point, but if that's the case, you should have made that clear, as it vastly changes the context of what you were saying). You just brought up some benchmarks, which are not representative of how Python is used in the real world.
I see how you could have intended to imply that this was "your uses" by saying that coldtea must have unusual uses if he got go/2 performance out of Python, but this was hardly clear, if it is the case. Regardless, you totally misrepresented dnu's point.
As for your arguments against my points, the 80/20 rule, while obviously impossible to definitively prove, has far more authoritative supporters than it does detractors. If you haven't experienced that being the case, then that's good and well for you, but the experience of many others suggests that it usually is (in fact, it's usually stated as being closer to 90/10 than 80/20).
Your Django argument falls flat if you look at it more closely. Sure, Django might introduce some slowness, but the vast majority of web performance is in the networking and database layers, not the application layer. Your choice of language has little to no bearing on the networking aspect of things, but what do you think the database drivers are written in? C, or an equivalent. 10% of the code that has 90% of the performance impact - sound familiar? And you interact with database drivers most of the time exactly how I said - by using a Python library that wraps around a C library to run the database.
>>Quit with the straw man arguments - they add nothing to the discussion.
>Neither do unwarranted accusations of straw man arguments.
I apologize if I come across as insulting - it is not my intention. My phrasing in the grandparent comment was overly antagonistic, and I'm about to edit it to fix that. But my accusations of straw man arguments were correct.
It was neither, and repetition is not an argument. Let me paraphrase the conversation in the desperate hope you will at least read this since you refuse to read the thread you are discussing:
Me: if you are seeing 2x slower, then that seems like unusual uses of python.
Him: I think some real world uses of python are 90% C libraries and 10% python
Me: I feel the cases you are referring to are the unusual ones I spoke of.
>You weren't "reiterating" anything - you never said anything about "your uses"
>You must have some very unusual uses for that to be true
Wow, its like I am really saying exactly what I told you I was saying!
>Your Django argument falls flat if you look at it more closely. Sure, Django might introduce some slowness, but the vast majority of web performance is in the networking and database layers, not the application layer
That is completely, and entirely false. Scripting language web frameworks like django, rails, zend, etc are dozens to hundreds of times slower than similar frameworks in compiled languages.
>But my accusations of straw man arguments were correct.
No, they were not. And your continued insistence that your arrogant and pointless accusation was correct is absurd. If you don't wish to read something, don't reply to it.
> Let me paraphrase the conversation in the desperate hope you will at least read this since you refuse to read the thread you are discussing
> ... your continued insistence that your arrogant and pointless accusation was correct is absurd. If you don't wish to read something, don't reply to it.
I'm attempting to keep the conversation civil (I have even gone back and changed some of my more inflammatory phrasings), and I hope you can do the same, without resorting to ad hominems such as these. I have read the entire thread several times over, and have quoted from it at length in my responses.
Prelude aside, my response.
---
> It was neither, and repetition is not an argument.
That's why I followed that statement with an entire page of argument. I didn't expect to convince you with the first sentence, only to state the subject of the argument that followed.
---
> Me: if you are seeing 2x slower, then that seems like unusual uses of python. Him: I think some real world uses of python are 90% C libraries and 10% python Me: I feel the cases you are referring to are the unusual ones I spoke of.
>> You weren't "reiterating" anything - you never said anything about "your uses"
>> You must have some very unusual uses for that to be true
> Wow, its like I am really saying exactly what I told you I was saying!
I actually mentioned what you said here in my previous argument:
> I see how you could have intended to imply that this was "your uses" by saying that coldtea must have unusual uses if he got go/2 performance out of Python, but this was hardly clear, if it is the case.
Your latest response makes it clear that this is, indeed, what you meant, but that wasn't clear from the initial conversation, even after reading it several times over.
---
> Me: if you are seeing 2x slower, then that seems like unusual uses of python. Him: I think some real world uses of python are 90% C libraries and 10% python Me: I feel the cases you are referring to are the unusual ones I spoke of.
Except dnu never said that "some" real world uses of Python are "90%" C libraries. He said, and I quote:
> for real projects, a Python programmer might use several libraries which are written in C.
That is, most real world uses of Python use some C libraries. He never suggested a ridiculous number like 90%. Your comment came across as a mockery of his argument, saying that Python could never achieve reasonable speed unless it was 90% C anyway. If this isn't what you intended, I apologize for insinuating that it was.
It came across that way because almost no real-world Python application uses 90% C, unless you want to count the entire kernel and OS it runs on.
---
>> Your Django argument falls flat if you look at it more closely. Sure, Django might introduce some slowness, but the vast majority of web performance is in the networking and database layers, not the application layer
> That is completely, and entirely false. Scripting language web frameworks like django, rails, zend, etc are dozens to hundreds of times slower than similar frameworks in compiled languages.
I think you misunderstand me. My point was that the parts of a web application that have the biggest impact on performance are the networking and database layers, not the application layer, and that language choice only affects the database and application layers. I was not arguing that Django, Rails, Zend, or other dynamic language based frameworks are as fast as compiled language based frameworks.
It may not seem like the database is that influential to performance at first - but imagine a database driver written in Python. It would be by far the slowest performing part of the application, because the database requires such enormous amounts of computation and is used so much. Thus, database drivers are written in C, so they perform quickly. But that 20% or less of the code, written in C for performance reasons, cuts down an 80% or greater slowdown which would occur if the database drivers were written in Python.
Also, as an aside, Django is hardly representative of Python as a whole. I haven't used it - I've done all my Python web development in Flask, so far, so my opinions on it aren't authoritative, and aren't intended to be so, but it seems to be an overly bloated framework whose performance is much slower than Python in general.
---
Again, I don't intend to be insulting and demeaning, and it is clear that the disagreement is due at least in part to some misunderstandings earlier in the conversation. I am happy to engage in technical discussion, even if it becomes somewhat heated, but I don't want to degrade the forum or make enemies by engaging in personal diatribe. I hope you share my desires on this subject.
Perhaps in the future, rather than accuse people of non-sequiturs and logical fallacies, you might consider alternative explanations like "I misunderstood what was said". I asked several people to read the post you misunderstood, and it was completely clear to them. You are still insisting that your misunderstanding is my fault, and that does not at all indicate that you are interested in engaging in discussion.
