The key architectural performance issues in large web apps like Facebook are about scalability by clustering and parallelism and caching... usage of proper higher-level languages helps in this (think how pure-functional programming removes shared state and Google's mapreduce for example), while using a lower-level language may give a speedup on single individual machines but makes the architectural problems harder to tackle.
Yes PHP is dynamic and variables are typed at runtime, but the logic analyzer and parser would figure all that out and then the resulting machine code would be type appropriate.
The whole problem is that when typing is dynamic, your variable in your program can have some arbitrary type at runtime, and you can't figure that out in the general case without executing the actual program. Static code analysis goes only so far in this matter.
true, but on the other hand most of what I've seen is that the embedded developers can program the higher level languages with more care anyway
My impression tends to be that the best overall programmers are those with a solid understanding of algorithmics theory, programming language design in general (meaning they have had exposure to all kinds of solutions), and most interestingly, tend to have an understanding of functional programming. The true programmer gods I have come across have always been Lispers, almost without exception.
On the other hand, I never understood what is supposedly so educational and intellectually important in things like assembly. If one only learned that, it wouldn't still mean that one could actually use it for anything... it's just "manipulate state in registers and RAM by making use of extremely rudimentary basic operations". The transformations into machine code from higher-level program solution descriptions are much more consistently handled by a compiler than a human, and as that is manual, automatable work, it may be more important to study compiler construction... (which Lisp is pretty good for)
Calm down and read the other comments regarding population density, network tower density, amount of paying customers, having to provide infrastructure competitively with the paying customers you have... and in particular my comment about us not just throwing excessive amounts of infrastructure at the problem to get the results. These kinds of problems work out mostly the same regardless of scale... and yes, we also do reliably cover the very low-pop-density areas that are comparable to the ones in the USA.
The much more interesting point is that we don't have densities anywhere comparable to the NYC, but with those amounts of customers, providing the infrastructure should be doable.
The GP seems quite vocal in his views about Socialists supposedly pushing some agenda through global warming, and the response to it points out exactly why the political bias appears to be very deeply rooted on the right side of the political aisle in this matter -- IMO it's fair.
On American terms, I am certainly Socialist, but I sure as hell would hope that AGW didn't require countering, as that would help my "Socialist agenda" much much more. Alas, just hoping doesn't make it so. Right-wingers, as usual, turn even this issue to a chance to bash the left, oblivious to any rational evaluation of the evidence, because obviously it's a red conspiracy...
Fair point; in particular price-wise, competition doesn't really work yet in the common market in Europe. Roaming charges can be surprisingly high. When it comes to both competition to push down prices and carrier co-operation in providing reliable infrastructure, I would say it would be probably pretty hard to replicate Europe-wide.
Heh, I am not looking for a "OMG Europe for teh win" pissing contest..;) It's just interesting that robustness of the cellphone network is something we take so totally for granted here, that it feels weird to read about "calls dropped" as some sort of real measure of network performance.
Finland's population density is also actually quite low anywhere north of Tampere -- you don't get 3G in the woods, but basic EDGE/GSM works pretty much always. The interesting measure is the people's data needs served per infrastructure investment euro, and the Helsinki area should serve as your representative (well, ok, smallish:) urban region... it's not as if we're throwing inordinate amounts of money at the infrastructure either, considering I get unlimited data for 10/month and it's quite a popular service.
Then again, we've had a very integrated network here in the entire Northern Europe since the 1980s -- it was the Nordic Mobile Telephone (NMT) network that gave rise to the GSM network, and Ericsson and Nokia just ran with it, with known consequences. I guess we have more experience in phone network reliability, too, than most other regions of the world... we've had engineering people thinking about that stuff for longer than elsewhere, because they are the ones that developed the stuff.
Maybe, but I do hear about this kind of stuff from all over the US. It's the some sort of data transmission per area measure that is relevant, and NYC is a bit of an extreme example... when one hits a relatively unprepared network (you guys did get on the bandwagon just in the past few years) with iPhone data transmission requirements, I guess you could assume problems.
It is, I would suppose, still fundamentally an iPhone issue though...
Funny how in the past couple of decades using Nokia GSM phones on a Finnish carrier, I've never experienced a single "dropped call". It's amazing this happens in the US.
"Trivial"? How exactly? They are actual, real, physical hardware patents that were developed when the industry was in its infancy just so that there is a cellphone to begin with! Nokia and Ericsson pretty much created the technological fundamentals, and now people are willing to take them for granted... most importantly, the engineering stuff that goes into this is actually far more challenging in a lot of ways than anything on the software side (I very much dislike software patents like most here...)
There's the added component of who the enemy actually is considered to be... in a lot of the collateral-damage cases, frankly, it seems like although the demise of the civilians is "regrettable", they still are considered to be part of an enemy population, so it doesn't *really* matter, shit just happens. This is even more so when the whole deal starts to look like collective punishment, which is the case in a lot of what, say, Israel does.
Of course, for the suicide bomber terrorist, everyone in the restaurant is a high-value enemy target as they probably support whatever policies the suicide bomber finds oppressive etc. Perhaps his family died an unfortunate death as collateral damage or something...
Your analogies are intentionally grotesquely flawed. As someone who has lived his entire life with a fairly severe physical disability, I find your casual comparison of these matters to "anything that inconveniences you in the slightest" to be flippant and incredibly ignorant. Of course you will then answer that you aren't really interested in the distinction, as for you it is the same thing... but if this is to be discussed objectively, there should at least be a fair effort at understanding the relative significance.
Mind you, I actually agree that the nut-stuff is probably at least partially hysteria, and the nutcases can be accommodated easily otherwise...
I agree with the sentiment, but the "shell model of electrons" analogy gives too much credit to low-level languages in the programming context. I have debated low-level programmers a lot on this, and the most fanatical of them always leave me with the feeling that they don't actually have any clue as to why higher-level languages have the kinds of entities in them that they do. To them it's just all "dumbed down library calls" to the low level, where the actual pointer-magic makes everything happen. They simply do not see the meaning of the higher-level abstractions that emerge, and understanding of which is IMO the more important part to really grokking computation from the theoretical perspective.
I would actually go as far as say that low-level languages in the sense of asm simply are not present in any meaningful way in a language like Lisp, and/or they are trivially contained, and the value of a supposed bottom-up approach is very suspect...
I have talked about the "programmer's learning path" a lot, and considering my own experiences, I am quite convinced that there is no such thing as a "continuum" towards C or C++... C is minimal and dull and a lot of work for a beginner to get anything done in, C++ is hairy and complex (even from my experienced programmer's perspective) and rigid.
Personally I have started to view programming more and more simply in terms of "formulating problem solutions in a Turing-complete symbolic system". As such, the machine-specifics have receded more and more into the background... I tend to see C for example in terms of a small set of imperative, structured-programming statements instead of "low-level programming"... the machine is just simply not important as long as the specification of the language is correct. What truly has been the most instructive thing for me ever as a programmer was learning Lisp -- I'm mostly a fanatical Lisper these days whenever I can. Of course, C's imperative statements are trivially included as a part of Lisp. It's nothing to write home about.
Python is a nice language because it contains a lot of important high-level programming ideas in a language that is easy to use... that is, it does not even waste an experienced programmer's time. Managing your memory does not make you more of a man... understanding how programming conceptually works is far more crucial.
Fact 3: Human produced CO2 has caused most of that warming. Unfortunately no one has ever been able to convincingly demonstrate that this is true.
How is it not reasonable that if we understand well and agree that CO2 is a greenhouse gas, and that there is a record concentration of it in the air currently, compared to ice core data, and that humans are causing this increase in concentration, that the temperature rise therefore would not, according to the well-known greenhouse mechanism, be linked to human emissions?
To me it seems like insanity to argue that this effect would not exist, or that we should presuppose some unknown mechanism to account for the warming instead of the most obvious explanation, and that it would be perfectly ok to just keep on pumping CO2 into the atmosphere, suggesting that "well, this time the greenhouse gas might work differently!"
Governments are the right organizations to correct any issues, which, if we look at similar historic pollution agreements, they have failed miserably.
Care to elaborate? It is my impression that governments or similar institutions are the only instance that has ever been able to solve these kinds of issues (think CFCs) in the past. It may make use of market-style solutions, but still.
No, but I'm into algorithmics which is mostly language-independent, and in addition like thinking about the "philosophy" of programming languages... so I guess I just am not horribly impressed by constant factors or CPU instruction sets. Whatever that's worth;)
I do recognize that C will be "faster" than other languages... but that's just one metric, and sometimes I wonder why a lot of programmers who seem very married to the low-level consider anything else to be "dumbing down". For parallel programming for example, pure-functional languages are very applicable (think parallel-map etc operations in Haskell) and also intellectually interesting. In the end, there will never be a programming language that will program for you -- they can just take some (or a lot) of the manual drugdery out, and create more interesting language elements that express things a bit differently than in terms of your basic imperative control structures.
And I kind of wish that Java wasn't used as some sort of an example of a high-level language... it is actually rather pedestrian in its ideas.
I have spent a lot of time debating the relative merits of low- vs. high-level programming languages, and I always make the reservation that sometimes technical requirements do dictate implementation language, and then you work with what you must. Otherwise, as a guy who likes CS theory and Lisp, I find Asm and C to be so rudimentary that they're outright uninteresting (and a lot of boring work to use).
Your examples demonstrate quite well what I have suspected for a long time... it seems to be an Engineering vs. CS distinction. When the programming task is specifically a task of programming a device, then the language that fits hardware best also models the problem best. For general purpose one needs a language that models "any" problem domain best.
That said, using English as a base for a programming language sounds like a remarkably bad idea.
What are they doing studying CS if they need to be persuaded that programming can be fun like they were a bunch of kids who need to eat their broccoli?
Slashdot Mirror
The key architectural performance issues in large web apps like Facebook are about scalability by clustering and parallelism and caching... usage of proper higher-level languages helps in this (think how pure-functional programming removes shared state and Google's mapreduce for example), while using a lower-level language may give a speedup on single individual machines but makes the architectural problems harder to tackle.
Yes PHP is dynamic and variables are typed at runtime, but the logic analyzer and parser would figure all that out and then the resulting machine code would be type appropriate.
The whole problem is that when typing is dynamic, your variable in your program can have some arbitrary type at runtime, and you can't figure that out in the general case without executing the actual program. Static code analysis goes only so far in this matter.
My impression tends to be that the best overall programmers are those with a solid understanding of algorithmics theory, programming language design in general (meaning they have had exposure to all kinds of solutions), and most interestingly, tend to have an understanding of functional programming. The true programmer gods I have come across have always been Lispers, almost without exception.
On the other hand, I never understood what is supposedly so educational and intellectually important in things like assembly. If one only learned that, it wouldn't still mean that one could actually use it for anything... it's just "manipulate state in registers and RAM by making use of extremely rudimentary basic operations". The transformations into machine code from higher-level program solution descriptions are much more consistently handled by a compiler than a human, and as that is manual, automatable work, it may be more important to study compiler construction... (which Lisp is pretty good for)
Good to know that about GSM vs. CDMA, thanks. Probably the only relevant comment in this thread to the actual "it's GSM's fault" claim :-)
Calm down and read the other comments regarding population density, network tower density, amount of paying customers, having to provide infrastructure competitively with the paying customers you have... and in particular my comment about us not just throwing excessive amounts of infrastructure at the problem to get the results. These kinds of problems work out mostly the same regardless of scale... and yes, we also do reliably cover the very low-pop-density areas that are comparable to the ones in the USA.
The much more interesting point is that we don't have densities anywhere comparable to the NYC, but with those amounts of customers, providing the infrastructure should be doable.
The GP seems quite vocal in his views about Socialists supposedly pushing some agenda through global warming, and the response to it points out exactly why the political bias appears to be very deeply rooted on the right side of the political aisle in this matter -- IMO it's fair.
On American terms, I am certainly Socialist, but I sure as hell would hope that AGW didn't require countering, as that would help my "Socialist agenda" much much more. Alas, just hoping doesn't make it so. Right-wingers, as usual, turn even this issue to a chance to bash the left, oblivious to any rational evaluation of the evidence, because obviously it's a red conspiracy...
Fair point; in particular price-wise, competition doesn't really work yet in the common market in Europe. Roaming charges can be surprisingly high. When it comes to both competition to push down prices and carrier co-operation in providing reliable infrastructure, I would say it would be probably pretty hard to replicate Europe-wide.
Heh, I am not looking for a "OMG Europe for teh win" pissing contest.. ;) It's just interesting that robustness of the cellphone network is something we take so totally for granted here, that it feels weird to read about "calls dropped" as some sort of real measure of network performance.
Finland's population density is also actually quite low anywhere north of Tampere -- you don't get 3G in the woods, but basic EDGE/GSM works pretty much always. The interesting measure is the people's data needs served per infrastructure investment euro, and the Helsinki area should serve as your representative (well, ok, smallish :) urban region... it's not as if we're throwing inordinate amounts of money at the infrastructure either, considering I get unlimited data for 10/month and it's quite a popular service.
Then again, we've had a very integrated network here in the entire Northern Europe since the 1980s -- it was the Nordic Mobile Telephone (NMT) network that gave rise to the GSM network, and Ericsson and Nokia just ran with it, with known consequences. I guess we have more experience in phone network reliability, too, than most other regions of the world... we've had engineering people thinking about that stuff for longer than elsewhere, because they are the ones that developed the stuff.
Maybe, but I do hear about this kind of stuff from all over the US. It's the some sort of data transmission per area measure that is relevant, and NYC is a bit of an extreme example... when one hits a relatively unprepared network (you guys did get on the bandwagon just in the past few years) with iPhone data transmission requirements, I guess you could assume problems.
It is, I would suppose, still fundamentally an iPhone issue though...
Funny how in the past couple of decades using Nokia GSM phones on a Finnish carrier, I've never experienced a single "dropped call". It's amazing this happens in the US.
This is why I use Netbeans. It just works out of the box most of the time.
Care to explain how these patents are trivial? I would say that they are the most central patents you can imagine in the field...
"Trivial"? How exactly? They are actual, real, physical hardware patents that were developed when the industry was in its infancy just so that there is a cellphone to begin with! Nokia and Ericsson pretty much created the technological fundamentals, and now people are willing to take them for granted... most importantly, the engineering stuff that goes into this is actually far more challenging in a lot of ways than anything on the software side (I very much dislike software patents like most here...)
There's the added component of who the enemy actually is considered to be... in a lot of the collateral-damage cases, frankly, it seems like although the demise of the civilians is "regrettable", they still are considered to be part of an enemy population, so it doesn't *really* matter, shit just happens. This is even more so when the whole deal starts to look like collective punishment, which is the case in a lot of what, say, Israel does.
Of course, for the suicide bomber terrorist, everyone in the restaurant is a high-value enemy target as they probably support whatever policies the suicide bomber finds oppressive etc. Perhaps his family died an unfortunate death as collateral damage or something...
Your analogies are intentionally grotesquely flawed. As someone who has lived his entire life with a fairly severe physical disability, I find your casual comparison of these matters to "anything that inconveniences you in the slightest" to be flippant and incredibly ignorant. Of course you will then answer that you aren't really interested in the distinction, as for you it is the same thing... but if this is to be discussed objectively, there should at least be a fair effort at understanding the relative significance.
Mind you, I actually agree that the nut-stuff is probably at least partially hysteria, and the nutcases can be accommodated easily otherwise...
I agree with the sentiment, but the "shell model of electrons" analogy gives too much credit to low-level languages in the programming context. I have debated low-level programmers a lot on this, and the most fanatical of them always leave me with the feeling that they don't actually have any clue as to why higher-level languages have the kinds of entities in them that they do. To them it's just all "dumbed down library calls" to the low level, where the actual pointer-magic makes everything happen. They simply do not see the meaning of the higher-level abstractions that emerge, and understanding of which is IMO the more important part to really grokking computation from the theoretical perspective.
I would actually go as far as say that low-level languages in the sense of asm simply are not present in any meaningful way in a language like Lisp, and/or they are trivially contained, and the value of a supposed bottom-up approach is very suspect...
I have talked about the "programmer's learning path" a lot, and considering my own experiences, I am quite convinced that there is no such thing as a "continuum" towards C or C++... C is minimal and dull and a lot of work for a beginner to get anything done in, C++ is hairy and complex (even from my experienced programmer's perspective) and rigid.
Personally I have started to view programming more and more simply in terms of "formulating problem solutions in a Turing-complete symbolic system". As such, the machine-specifics have receded more and more into the background... I tend to see C for example in terms of a small set of imperative, structured-programming statements instead of "low-level programming"... the machine is just simply not important as long as the specification of the language is correct. What truly has been the most instructive thing for me ever as a programmer was learning Lisp -- I'm mostly a fanatical Lisper these days whenever I can. Of course, C's imperative statements are trivially included as a part of Lisp. It's nothing to write home about.
Python is a nice language because it contains a lot of important high-level programming ideas in a language that is easy to use... that is, it does not even waste an experienced programmer's time. Managing your memory does not make you more of a man... understanding how programming conceptually works is far more crucial.
How is it not reasonable that if we understand well and agree that CO2 is a greenhouse gas, and that there is a record concentration of it in the air currently, compared to ice core data, and that humans are causing this increase in concentration, that the temperature rise therefore would not, according to the well-known greenhouse mechanism, be linked to human emissions?
To me it seems like insanity to argue that this effect would not exist, or that we should presuppose some unknown mechanism to account for the warming instead of the most obvious explanation, and that it would be perfectly ok to just keep on pumping CO2 into the atmosphere, suggesting that "well, this time the greenhouse gas might work differently!"
Yes, it is.
Here!
You must be new here, it should be obvious. Send the company a picture of goatse, and have your pattern...
Care to elaborate? It is my impression that governments or similar institutions are the only instance that has ever been able to solve these kinds of issues (think CFCs) in the past. It may make use of market-style solutions, but still.
No, but I'm into algorithmics which is mostly language-independent, and in addition like thinking about the "philosophy" of programming languages... so I guess I just am not horribly impressed by constant factors or CPU instruction sets. Whatever that's worth ;)
I do recognize that C will be "faster" than other languages... but that's just one metric, and sometimes I wonder why a lot of programmers who seem very married to the low-level consider anything else to be "dumbing down". For parallel programming for example, pure-functional languages are very applicable (think parallel-map etc operations in Haskell) and also intellectually interesting. In the end, there will never be a programming language that will program for you -- they can just take some (or a lot) of the manual drugdery out, and create more interesting language elements that express things a bit differently than in terms of your basic imperative control structures.
And I kind of wish that Java wasn't used as some sort of an example of a high-level language... it is actually rather pedestrian in its ideas.
I have spent a lot of time debating the relative merits of low- vs. high-level programming languages, and I always make the reservation that sometimes technical requirements do dictate implementation language, and then you work with what you must. Otherwise, as a guy who likes CS theory and Lisp, I find Asm and C to be so rudimentary that they're outright uninteresting (and a lot of boring work to use).
Your examples demonstrate quite well what I have suspected for a long time... it seems to be an Engineering vs. CS distinction. When the programming task is specifically a task of programming a device, then the language that fits hardware best also models the problem best. For general purpose one needs a language that models "any" problem domain best.
That said, using English as a base for a programming language sounds like a remarkably bad idea.
What are they doing studying CS if they need to be persuaded that programming can be fun like they were a bunch of kids who need to eat their broccoli?
No, it does not drop off "exponentially". That would be a much more extreme dropoff than inverse-square.