Are people in third world countries more likely to endager their lives because their life expectancy is only half that of the first world?
Yes, I have observed that people in the third world do in fact take many chances (driving without seatbelts, driving drunk, smoking like chimneys, unprotected sex, eating food without worrying about its nutrition, flying dangerous airlines) that are frowned upon in the rich world. I do think it is quite rational to realize that if you have a pretty decent chance of dieing of malaria, seatbelts are sort of non-essential. Plus, safety and health costs money.
With regular expressions you have to either write a complex regexp (a true regular expression can take only polynomial time in the string length, I think) or allow the user to provide both the regexp and the string to be matched, so that attack is less likely to take you by surprise.
Perl and Python programmers hardly ever write "true" regular expressions in the Chomsky/CS sense. It doesn't matter whether you are doing something complex or not, you are unlikely to restrict yourself to that subset.
In what sense is the XML only readable in Word? You don't need an XSD to read XML. If you spend an hour eyeballing that XML you will get the gist of it and if you download the CDK you will get the precise definition of it. There is no need to redistribute the schemas!
Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.
I have to weigh in here... it is my sincere belief that it is a huge mistake to start students in on high-level languages. If you start by learning that the JVM or the interpreter will "take care of it for you", it gives poor incentive to write carefully, with the real machine limits in mind.
Probably the right way to learn is to learn a high level language to get the basic concepts of programming, logic, abstraction, control flow, data structures etc. Then drill down through C to assembly. Then go back up to get useful work done. If you start with the low-level language you give people an inaccurate impression of how boring and nit-picky computer programming is. "Hundreds of lines of code to do some simple graphics? Computers suck!" Better to start them out with pygame and let them see the fun and easy side before hitting them over the head with the details.
First, compare the ease of implementation to Python...especially when it comes to garbage collection and threading. Second, Python folks won't look down on you for using C where it is appropriate. Sun has this big marketing campaign about how code should be "100% Java". Third, Python people have worked much harder on tools to make integrating C easy: Pyrex, Distutils, SWIG, CTypes, win32com and pyxpcom.
There is absolutely no chance that either time or vtime would be keywords in any version of C. C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny. Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.
I've found other languages have the same advantage.
vtime = time()
vlocaltime = localtime()
print "UNIX timestamp " + time + " is " + localtime
This isn't any language's syntax in particular...but you get the idea.
I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.
If the code is not time-critical then why optimize for average case performance?
They only need dedicated static IP addresses if they are going to accept incoming IP connections from other networks without some kind of port forwarding. I do kind of like accepting incoming calls on my cell phone and I would kind of like the Internet protocols to be at least as flexible as the phone network. We should not rely on the wirleless telcoms to say who we can connect to and for what services. They will find ways to make it expensive. It is better that they provide the pipes and get the hell out of the way.
Canned response 1: There is no problem. Use NAT.
Canned response 2: NAT is only good for outgoing.
Canned response 3: NAT is an easy way to secure machines.
Canned response 4: NAT is an abomination in the eyes of the Internet gods.
Canned response 5: Even when we have IPv6, ISPs will charge huge amounts for IP addresses.
If you write P2P software you will know that NAT is a major pain in the ass and requires very bizarre architectures involving reflectors owned and run by third parties (or at least port forwarding). More IP addresses cannot be a bad thing and we have to move sooner or later.
No, it includes a subset of SMIL. SMIL is more than just an animation format.
Okay, so what parts of SMIL are missing that make SMIL "like Flash" and SVG "just vector graphics"?
Well animation isn't exactly a novel thing for a graphics format, which just leaves scripting.
Any vector graphics format that has animation isn't about "just simple vector graphics." WMF, EPS, CGM, PICT are examples of simple vector graphics formats and I do not believe that they have animation. I'm curious what vector graphics format you are thinking of.
SVG is obviously scriptable, as it is accessible via the DOM, but I wouldn't go so far as to say that this puts it on the same level as Flash.
We could debate all day whether it is competitive with Flash or not. But a language with animation, scripting, video and audio is not "just vector graphics." I call bullshit.
Re:Parrot started out as a joke, and is still a jo
on
Perl 6 Essentials
·
· Score: 1
Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them.
How will you write the interpreter for a language that is still being designed? This may be part of why Parrot is going nowhere...there is nowhere well-defined to go!
The government's job is to look out for it's own citizens, not it's own corporations. They need to make policies (tarriffs, taxes, etc) that encourage companies to make it worthwhile to hire over-priced US workers. These companies are more than happy to exploit the standard of living in the US by selling their overpriced crap here for huge profits that they can't really get anywhere else.
So...IBM is taxed for hiring offshore. Then SAP has a tarriff applied against them for hiring offshore. So business software is more expensive in the US both because of the taxes/tarriffs and because wages have been held artificially high by them. So software consumers in the UK or France or Japan get their software at a steep discount from vendors located in India and the Philipines. So their software consuming companies (e.g. telecoms, manufacturing, biotech, call centers) have an advantage over American software consuming companies. And guess what...the programmer is sitting pretty but he's just screwed over a bunch of other Americans who are no longer competitive and are paying inflated prices for their consumer software to boot!
The reason that I cannot compete on price with that Indian developer has nothing to do with my willingness to work and everything to do with the fact that I will always pay more for real estate in America. Even Arkansas farmland is going to be more expensive than a good place in India.
I'm betting you live somewhere a little bit more pricey than Arkansas farmland. But either way, if real estate in the US is pricey it is because people with money want to live in the US. In other words, it is a rich society. Why not be happy you live in a rich society rather than begrudging those trying to enrich their societies? Maybe you can't compete in programming. Oh well. You are probably not so stupid that you can only ever do one job in your life. All of the travel agents obsoleted by Expedia found new work. So did the secretaries obsoleted by email. So will we. Surely all of our relatively rich neighbours driving up the real estate prices have some service they need performed. The millions of foreigners trying to move to the US certainly seem to think so! Let's figure out what the next boom industry is and make a good living at it.
If this was the way capitalism worked then nobody would get paid more than the minimum wage because we would have competed ourselves down so much. But the truth is that working is a voluntary exchange of time for money. If the terms are poor enough, people won't make the exchange and the work never gets done. There are millions of potential jobs that "could be done" that are not done because nobody is willing to work cheaply enough (or they are legally prevented from working cheaply enough).
If my cable modem provider would give me access without charging extra for every computer I attach, I would be happy to do without NAT. I don't see that happening, even if they have 50 bazillion addresses available, not when they can make another 5 bux a month per machine.
If McDonald's had their way, they would charge you $30.00 (or at least $10.00) per hamburger. But they don't. Why do you think that is? Perhaps: competition.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs.
First, these programs cannot find all or even most such errors. Second, these programs cannot help you with the fundamental problem that you have written more code and on average the number of bugs is proportional to the amount of code.
Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
C programs have also been known to break with components of the underlying runtime are upgraded. Type checking tools only catch the most obvious and blatant problems that would have been caught with unit testing anyhow. Subtle problems are as hard to find in either case except that when the script fails it typically gives a very clear traceback whereas the C may merely corrupt memory and then crash at an arbitrary time later. The behaviour of the script is determinstic but the behaviour of the C program could depends on what random crap happened to be in a memory location that you accidentally dereferenced.
Scripts are fragile.
I'm sorry, this is just false. Slashdot is widely acknowledged to be written in piss-poor Perl and is no more fragile than sites written in Java and is probably more reliable than those few sites written in C. Yahoo and Amazon are also substantially written in script (PHP and Perl respectively). If scripts are robust enough for them, they are robust enough for me. But then again, some people still claim assembly and FORTRAN are the one try way of writing large-scale software. Every layer will have adherents long past the time when they should have moved on to take advantage of the fruits of Moore's law.
Truly the last thing operating systems need is more fragility.
He's adding a few tools for doing numerical computations. This is hardly a core part of the operating system kernel.
By adhering strictly to a formalized development process which includes unit tests as well as rigorous system tests it is possible to overcome some of this fragility, but then you also lose many of the benefits that scripting is supposed to provide, viz. rapid development and turnaround.
Let me see if I've got this right. I can spend five days scripting plus five days testing or ten days coding in C and zero days testing. Which code will be more fragile? Or lets try this this way: five days scripting plus five days testing versus ten days coding and five days testing. Seems like I'm still geting "rapid development and turnaround". It is totally, empirically false to say that C-coded programs require less testing than scripts. In general they require more because there is just more code to test.
I am not going to claim that scirpts are always better than C code (and we've hardly touched on middle grounds like Java, C#, Eiffel etc.). But I strongly dispute the assertion that scripted code is in general more fragile than C code or requires more testing. The secret to reliable software is testing, testing and testing. Programming language is a distant second place but even there, C tends towards the less reliable side of the spectrum. Of course with proper testing you can make rock-solid C code just as you can make rock-solid code in any language.
PDF is undoubtedly a convenient format, but Adobe's position on the format is highly restrictive and very unfriendly to developers. PDF has enormous potential which is mostly untapped because of this. Their history with PDF has made me (and many others) regard SVG with a great deal of suspicion. I personally believe they're hoping it'll displace Flash some day, at which time they'll take the same developer-unfriendly approach to SVG that they currently maintain with PDF.
There is a big difference. Adobe owns the PDF specification. They do not own the SVG specification. Microsoft has products that read and write SVG so there is no hope of Adobe controlling SVG's future.
Slashdot Mirror
SVG can do overlaying, scaling, tiling, cropping and so on!
Are people in third world countries more likely to endager their lives because their life expectancy is only half that of the first world?
Yes, I have observed that people in the third world do in fact take many chances (driving without seatbelts, driving drunk, smoking like chimneys, unprotected sex, eating food without worrying about its nutrition, flying dangerous airlines) that are frowned upon in the rich world. I do think it is quite rational to realize that if you have a pretty decent chance of dieing of malaria, seatbelts are sort of non-essential. Plus, safety and health costs money.
With regular expressions you have to either write a complex regexp (a true regular expression can take only polynomial time in the string length, I think) or allow the user to provide both the regexp and the string to be matched, so that attack is less likely to take you by surprise.
Perl and Python programmers hardly ever write "true" regular expressions in the Chomsky/CS sense. It doesn't matter whether you are doing something complex or not, you are unlikely to restrict yourself to that subset.
Or (more likely) a volunteer.
In what sense is the XML only readable in Word? You don't need an XSD to read XML. If you spend an hour eyeballing that XML you will get the gist of it and if you download the CDK you will get the precise definition of it. There is no need to redistribute the schemas!
Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.
I have to weigh in here... it is my sincere belief that it is a huge mistake to start students in on high-level languages. If you start by learning that the JVM or the interpreter will "take care of it for you", it gives poor incentive to write carefully, with the real machine limits in mind.
Probably the right way to learn is to learn a high level language to get the basic concepts of programming, logic, abstraction, control flow, data structures etc. Then drill down through C to assembly. Then go back up to get useful work done. If you start with the low-level language you give people an inaccurate impression of how boring and nit-picky computer programming is. "Hundreds of lines of code to do some simple graphics? Computers suck!" Better to start them out with pygame and let them see the fun and easy side before hitting them over the head with the details.
First, compare the ease of implementation to Python...especially when it comes to garbage collection and threading. Second, Python folks won't look down on you for using C where it is appropriate. Sun has this big marketing campaign about how code should be "100% Java". Third, Python people have worked much harder on tools to make integrating C easy: Pyrex, Distutils, SWIG, CTypes, win32com and pyxpcom.
Remember though folks, if you don't want to deal with this complexity, you don't need to.
Sure, as long as you never need to maintain code that deals with it.
There is absolutely no chance that either time or vtime would be keywords in any version of C. C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny. Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.
I've found other languages have the same advantage. vtime = time() vlocaltime = localtime() print "UNIX timestamp " + time + " is " + localtime This isn't any language's syntax in particular...but you get the idea.
Do you have a reference?
I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.
If the code is not time-critical then why optimize for average case performance?
They only need dedicated static IP addresses if they are going to accept incoming IP connections from other networks without some kind of port forwarding. I do kind of like accepting incoming calls on my cell phone and I would kind of like the Internet protocols to be at least as flexible as the phone network. We should not rely on the wirleless telcoms to say who we can connect to and for what services. They will find ways to make it expensive. It is better that they provide the pipes and get the hell out of the way.
Canned response 2: NAT is only good for outgoing.
Canned response 3: NAT is an easy way to secure machines.
Canned response 4: NAT is an abomination in the eyes of the Internet gods.
Canned response 5: Even when we have IPv6, ISPs will charge huge amounts for IP addresses.
If you write P2P software you will know that NAT is a major pain in the ass and requires very bizarre architectures involving reflectors owned and run by third parties (or at least port forwarding). More IP addresses cannot be a bad thing and we have to move sooner or later.
What of ActionScript is not available in JavaScript+SMIL?
No, it includes a subset of SMIL. SMIL is more than just an animation format.
Okay, so what parts of SMIL are missing that make SMIL "like Flash" and SVG "just vector graphics"?
Well animation isn't exactly a novel thing for a graphics format, which just leaves scripting.
Any vector graphics format that has animation isn't about "just simple vector graphics." WMF, EPS, CGM, PICT are examples of simple vector graphics formats and I do not believe that they have animation. I'm curious what vector graphics format you are thinking of.
SVG is obviously scriptable, as it is accessible via the DOM, but I wouldn't go so far as to say that this puts it on the same level as Flash.
We could debate all day whether it is competitive with Flash or not. But a language with animation, scripting, video and audio is not "just vector graphics." I call bullshit.
Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them.
How will you write the interpreter for a language that is still being designed? This may be part of why Parrot is going nowhere...there is nowhere well-defined to go!
It's the same idea that many liberal politicians have. If one man gets rich, it's because another man has become poor.
Ummm. What about the conservative politicians who believe that if a Mexican or Indian gets a job an American must be out of a job?
The government's job is to look out for it's own citizens, not it's own corporations. They need to make policies (tarriffs, taxes, etc) that encourage companies to make it worthwhile to hire over-priced US workers. These companies are more than happy to exploit the standard of living in the US by selling their overpriced crap here for huge profits that they can't really get anywhere else.
So...IBM is taxed for hiring offshore. Then SAP has a tarriff applied against them for hiring offshore. So business software is more expensive in the US both because of the taxes/tarriffs and because wages have been held artificially high by them. So software consumers in the UK or France or Japan get their software at a steep discount from vendors located in India and the Philipines. So their software consuming companies (e.g. telecoms, manufacturing, biotech, call centers) have an advantage over American software consuming companies. And guess what...the programmer is sitting pretty but he's just screwed over a bunch of other Americans who are no longer competitive and are paying inflated prices for their consumer software to boot!
The reason that I cannot compete on price with that Indian developer has nothing to do with my willingness to work and everything to do with the fact that I will always pay more for real estate in America. Even Arkansas farmland is going to be more expensive than a good place in India.
I'm betting you live somewhere a little bit more pricey than Arkansas farmland. But either way, if real estate in the US is pricey it is because people with money want to live in the US. In other words, it is a rich society. Why not be happy you live in a rich society rather than begrudging those trying to enrich their societies? Maybe you can't compete in programming. Oh well. You are probably not so stupid that you can only ever do one job in your life. All of the travel agents obsoleted by Expedia found new work. So did the secretaries obsoleted by email. So will we. Surely all of our relatively rich neighbours driving up the real estate prices have some service they need performed. The millions of foreigners trying to move to the US certainly seem to think so! Let's figure out what the next boom industry is and make a good living at it.
If this was the way capitalism worked then nobody would get paid more than the minimum wage because we would have competed ourselves down so much. But the truth is that working is a voluntary exchange of time for money. If the terms are poor enough, people won't make the exchange and the work never gets done. There are millions of potential jobs that "could be done" that are not done because nobody is willing to work cheaply enough (or they are legally prevented from working cheaply enough).
If my cable modem provider would give me access without charging extra for every computer I attach, I would be happy to do without NAT. I don't see that happening, even if they have 50 bazillion addresses available, not when they can make another 5 bux a month per machine.
If McDonald's had their way, they would charge you $30.00 (or at least $10.00) per hamburger. But they don't. Why do you think that is? Perhaps: competition.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs.
First, these programs cannot find all or even most such errors. Second, these programs cannot help you with the fundamental problem that you have written more code and on average the number of bugs is proportional to the amount of code.
Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
C programs have also been known to break with components of the underlying runtime are upgraded. Type checking tools only catch the most obvious and blatant problems that would have been caught with unit testing anyhow. Subtle problems are as hard to find in either case except that when the script fails it typically gives a very clear traceback whereas the C may merely corrupt memory and then crash at an arbitrary time later. The behaviour of the script is determinstic but the behaviour of the C program could depends on what random crap happened to be in a memory location that you accidentally dereferenced.
Scripts are fragile.
I'm sorry, this is just false. Slashdot is widely acknowledged to be written in piss-poor Perl and is no more fragile than sites written in Java and is probably more reliable than those few sites written in C. Yahoo and Amazon are also substantially written in script (PHP and Perl respectively). If scripts are robust enough for them, they are robust enough for me. But then again, some people still claim assembly and FORTRAN are the one try way of writing large-scale software. Every layer will have adherents long past the time when they should have moved on to take advantage of the fruits of Moore's law.
Truly the last thing operating systems need is more fragility.
He's adding a few tools for doing numerical computations. This is hardly a core part of the operating system kernel.
By adhering strictly to a formalized development process which includes unit tests as well as rigorous system tests it is possible to overcome some of this fragility, but then you also lose many of the benefits that scripting is supposed to provide, viz. rapid development and turnaround.
Let me see if I've got this right. I can spend five days scripting plus five days testing or ten days coding in C and zero days testing. Which code will be more fragile? Or lets try this this way: five days scripting plus five days testing versus ten days coding and five days testing. Seems like I'm still geting "rapid development and turnaround". It is totally, empirically false to say that C-coded programs require less testing than scripts. In general they require more because there is just more code to test.
I am not going to claim that scirpts are always better than C code (and we've hardly touched on middle grounds like Java, C#, Eiffel etc.). But I strongly dispute the assertion that scripted code is in general more fragile than C code or requires more testing. The secret to reliable software is testing, testing and testing. Programming language is a distant second place but even there, C tends towards the less reliable side of the spectrum. Of course with proper testing you can make rock-solid C code just as you can make rock-solid code in any language.
PDF is undoubtedly a convenient format, but Adobe's position on the format is highly restrictive and very unfriendly to developers. PDF has enormous potential which is mostly untapped because of this. Their history with PDF has made me (and many others) regard SVG with a great deal of suspicion. I personally believe they're hoping it'll displace Flash some day, at which time they'll take the same developer-unfriendly approach to SVG that they currently maintain with PDF.
There is a big difference. Adobe owns the PDF specification. They do not own the SVG specification. Microsoft has products that read and write SVG so there is no hope of Adobe controlling SVG's future.