I've been programming in C for ten years and I rarely spend more than thirty minutes on memory management errors over the course of an entire release cycle, if at all.
First, your experience does not strike me as typical. If it were, there would not be so much anecdotal evidence about huge productivity gains from shifting to Java. (which is actually less productive in many ways, but does memory management right).
Second, is your code secure? Is anyone actively poking it for buffer overflows etc.? Recall that the overall thread is about security.
I haven't done much OOP -- mostly just Objective-C stuff on NeXTSTEP and OS X -- but I can say that memory management is a relevant concern in high-level languages too. It's just a different flavor of memory management, with reference counts and retain/release messages instead of handle locking. Both levels have a "null" concept and its associated dangers.
Objective-C is C. Yes, it is OOP. But that doesn't make it a high level language. It is exceedingly rare to worry about "reference counts" or "retain/release messages" in (e.g.) Python, Java, C# or Python.
And the realities are that unless I'm working on a pet project, I don't have the time to learn something new or try to come back up to speed on a language I last used two years ago.
The author is talking about significant applications, not little toy scripts. You are going to be very familiar with (and maybe even expert in) the language used to build a significant application by the time you are done programming it. But another point the author is making is that once you learn a high level language you'll find you can use it for a lot more than you thought. Many programmers get away with using high level languages for 95% of their jobs. And those jobs can involve writing significant (e.g.) ecommerce, content management or client side apps.
Don't get me wrong. Linux is not going to use Python as his major day to day programming language. But I wouldn't be surprised if even he finds the need to program something other than the Linux kernel often enough to justify skill in a higher level language.
Perhaps part of the dullness is that mainframe work will seldom be working with exciting new technologies that you can chat with your friends about. That's what would make me avoid these jobs. I would expect to get new ports of programming languages and tools years after everyone else has moved on to the next big thing.
Why would the upswing happen in the USA? Theres no real reason to hire an American programmer over a Chinese or Indian programmer,
Except that the American programmer can meet with the customer. And the American programmer can talk to the product manager every day. And the American programmer can attend conferences to pick up cutting edge skills. Some areas of programming don't require any of that stuff. Okay, they'll go offshore. But that isn't all programming jobs by a long stretch.
A tribal dialect of swahili used by a tribal village of canabals that died off by eating themselves and never had any texts, OTOH, should not be something worth keeping and studying...
This language has embedded in it a history of its own evolution and the evolution of its neighbouring languages. It could be a wealth of information about how humans acquire language and how language evolves.
It would have only taken two minutes of research for you to find it yourself:
There are several unique benefits of the Java Card technology, such as: Dynamic- New applications can be installed securely after a card has been issued, providing card issuers with the ability to dynamically respond to their customer's changing needs.
That's how Sun is advertising Java Smart Cards. Personally, I'm glad somebody is investigating their claims.
Well, there are already many error-induction attacks agains smart cards (some references in the article), that don't involve JVM running untrusted code.
Great. How do you take advantage of them? The published hack allows you to take over the security manager of the VM and become essentially "god" on the smartcard. So on the one hand you could induce an error on the card to invalidate the money on it (useless) or on the other hand you could induce an error that allows you to do anything you want, including duplicating or precisely mutating the data on the card. I know which ability I would rather have.
So if I can break smart card event if is does not run any my [untrusted] code, who cares about attack to smart card that allows to run untrusted code?
"Break" is one thing. "Use" is another.
Besides, I've never seen any smartcard that actually does this stupid thing.
Good for you. If they exist (they do) and they are being promoted/advertised (they are) then their security considerations are relevant.
A better target for attack may be a server at a nuclear reactor facility that has natural high rate of memory failures:)
For instance, let's say that copyright renewal costs $100 every 20 years, and there's 4 renewal periods. (80 year max) I could easily go into the business of submitting copyright renewals, and I could do it for $100 per copyright for the duration of the copyright (plus my up-front fee)
This is actually a very risky business to be in. Presumably there will be competition in this business so profits will be moderate or slim. The problem is that if a future congress increases the fees, either the copyright holder or the copyright middleman gets screwed. If the middleman lives up to his side of the bargain, he could find himself losing money year after year on twenty year old contracts. If he doesn't renew the copyright then it expires and his whole business concept is useless. Neither party can predict the rates that some future congress will charge...and why wouldn't congress notice the millions or billions of dollars piling up in these services and get a little greedy?
This all leads to another problem: if you really, really care about your copyright, you would need to really, really trust the company maintaining its copyright. By definition, you would need to trust them more then you trust yourself. It would need to be basically an insurance company or a bank (and even those go out of business sometimes).
And anyhow, an easy way to prevent the business model you've described from developing is to require the signature of the copyright holder on the copyright renewel.
The folks I worry about with copyright are small artists who either themselves make a living off of their work, or who have living relatives who do so.
If they make a living off of the work, why wouldn't they be able to pay the nominal fee required to maintain its copyright status? Its like saying that people shouldn't have to pay for driver's licenses because this prevents poor people from driving to their jobs. Well, if they are getting paid at their jobs then the driver's license is a small price to pay to keep getting that paycheck!
Reports are sketchy at present, but we're being led to believe that it's easy to compromise a machine to which you have physical access!
Bet you didn't even read the abstract. Here's the relevant bit:
Our attack is particularly relevant against smart cards or tamper-resistant computers, where the user has physical access (to the outside of the computer) and can use various means to induce faults; we have successfully used heat.
Maybe Virtual PC is better for Windows development than just Windows (for repeatibility reasons) but it is a hell of a lot slower than running Windows under VMWare under Windows (or Linux).
They have a 70-80% market share that isn't going anywhere quickly so why bother?
The velocity of the shift to Mozilla and other alternative browsers will be directrly proportional to the distance in functionality between them and Internet Explorer. You yourself said that Microsoft will probably have to add tabbed browsing "to stop people saying it is behind for features." Well, this will apply to many other features too. If Mozilla keeps adding "killer" features, Microsoft will eventually have to respond or lose. It's that simple. Yes, they can coast on their monopoly for a while. But not forever. Technology doesn't work like that.
SmallPaul said:I find it kind of odd that you think that a language with regular expressions in the syntax and one without cannot in general be used to solve the same kinds of problems.
Mattdm responded:Wow, I sure didn't say anything like that.
You said that Perl and Python do not really compete at all. That's simply not true. There are tens of thousands of projects out there that could be done in either Perl or Python. At the beginning of the project, someone chose between the languages. Often this is a very explicit process involving a bunch of argumentation and sometimes rancour. If that isn't competition, what is it?
At least on the second of these points, Python isn't even in the same *business* as Perl. There's just flat out no meaningful comparision.
I find it kind of odd that you think that a language with regular expressions in the syntax and one without cannot in general be used to solve the same kinds of problems. Does typing the parens change the nature of the problem that much?
But more to the point, if Perl's raison d'etre is built-in regular expressions (as you claim) then why is it used for (e.g.) SlashCode. What about building a large weblog community is regular-expression-centric? The vast majority of sizable Perl programs have very little to do with regular expressions.
Python has *a lot* of strengths, but they're totally different from Perl's. So why do Python advocates get so worked up about something their preferred language fundamentally isn't designed to do?
There was a period in the mid-90s when it was very common to be forced to write Perl because there was just some Perl code around that had to be maintained. The liklihood of this happening to an individual is proportional to the popularity of Perl. If Perl ceases to be popular then there won't be that much Perl code laying around to be maintained. Just today I was scrounging around in some open source scruffy Perl code that could have been better written in Python. That's the argument from self-interest.
The argument from emotion is that the popularity of Perl rather offends people's sense of competition between technologies being on the basis of quality rather than luck or marketing...in somewhat of the same way that it is typical to be annoyed at the popularity of IIS on Windows 2000 Server. In a sense, Perl is symbolimatic for some people of the less admirable qualities of our industry. What if the "Perl Aesthetic" (which discounts the importance of cleanliness and orthogonality) was to become the norm in other areas of our business?
Why don't they raise a big stink every time someone mentions Java? That seems like a more usefully-comparible application space. Or C++, for that matter.
Well for one thing, Python interoperates really well with Java and C++. So every line of Java and C++ out there can be construed as bolstering the argument for adding Python to the mix a a glue language. Whereas it is very rare to take a large Perl system and say: "let's bolt on some Python to provide a high level interface to this thing." For another thing, the liklihood of Python replacing Java and C++ in the hearts and minds of corporate application developers is quite slim. (especially considering the performance issues) But Python really could replace Perl for everything but 1-liners.
But the most important reason Python users trash Perl is because the first question a newbie asks on hearing about Python, an object oriented scripting language is: "How is it different than Perl?" It is rare for people to ask how it compares to Java or C++ because typically they are expecting Python to complement or extend systems built in Java or C++. If there were a clear consensus out there about when to use Python and when to use Perl then there would be little anti-Perl sentiment in the Python community. But saying that "Perl has built-in regular expressions" is not the same as providing a guideline for when it is better to use Perl than Python or vice versa.
The overall point is that the idea that the "Bible is quite clear" is merely wishful thinking. The Bible is massively open to interpreration. EVEN if you believe that it is literally true AND written by the people it claims it was written by (both of which are questionable).
in nearly all areas, the Bible is quite clear. Like it or not, the Bible provides an excellent moral standard.
Dear Dr. Laura:
Thank you for doing so much to educate people regarding God's Law. I have learned a great deal from your show, and I try to share that knowledge with as many people as I can. When people try to defend the homosexual lifestyle, for example, I simply remind them that Leviticus 18:22 clearly states it to be an abomination. End of debate.
I do need some advice from you, however, regarding some of the specific laws and how to follow them:
a) When I burn a bull on the altar as a sacrifice, I know it creates a pleasing odor for the Lord (Lev.1:9).The problem is my neighbors. They claim the odor is not pleasing to them. Should I smite them?
b) I would like to sell my daughter into slavery, as sanctioned in Exodus 21:7.In this day and age, what do you think would be a fair price for her?
c) I know that I am allowed no contact with a woman while she is in her period of menstrual uncleanness (Lev.15:19-24).The problem is, how do I tell? I have tried asking, but most women take offense.
d) Lev.25:44 states that I may indeed possess slaves, both male and female, provided they are purchased from neighboring nations. A friend of mine claims that this applies to Mexicans, but not Canadians. Can you clarify? Why can't I own Canadians?
e) I have a neighbor who insists on working on the Sabbath. Exodus 35:2 clearly states he should be put to death. Am I morally obligated to kill him myself?
f) A friend of mine feels that even though eating shellfish is an abomination (Lev.11:10), it is a lesser abomination than homosexuality. I don't agree. Can you settle this?
g) Lev.21:20 states that I may not approach the altar of God if I have a defect in my sight. I have to admit that I wear reading glasses. Does my vision have to be 20/20, or is there some wiggle room here?
h) Most of my male friends get their hair trimmed, including the hair around their temples, even though this is expressly forbidden by Lev. 19:27. How should they die?
i) I know from Lev.11:6-8 that touching the skin of a dead pig makes me unclean, but may I still play football if I wear gloves?
j) My uncle has a farm. He violates Lev.19:19 by planting two different crops in the same field, as does his wife by wearing garments made of two different kinds of thread cotton/polyester blend. He also tends to curse and blaspheme a lot. Is it really necessary that we go to all the trouble of getting the whole town together to stone them (Lev.24:10-16)? Couldn't we just burn them to death at a private family affair like we do with people who sleep with their in-laws? (Lev.20:14)
I know you have studied these things extensively, so I am confident you can help. Thank you again for reminding us that God's word is eternal and unchanging.
What "innovations" can you put in mature software, other than small details?
Browser technology is far from mature. Ten years from now we will look back and see today's browsers as incredibly primitive. For instance, SVG, SMIL and that family of specifications will lead to a much more integrated, interactive Web. RSS, iCal, RDF an so forth will lead to a Web where the browser can help us understand what is going on much better. XUL and XForms will lead to much better Web user interfaces. etc.
So what? An increase in heat and wear and tear on components, for what theroy says is ~25% speed increase. This drive doesn't even come close to that.
I would think that for most apps that need this, a SCSI or RAID (or both) solution would be better.
Why would SCSI be less prone to heat and wear than IDE?
It's bad programming habits and the lack of tools that catch those program time errors.
A high level language compiler/interpreter is a tool. ;) And there are lots of them out there. Even open source ones!
I've been programming in C for ten years and I rarely spend more than thirty minutes on memory management errors over the course of an entire release cycle, if at all.
First, your experience does not strike me as typical. If it were, there would not be so much anecdotal evidence about huge productivity gains from shifting to Java. (which is actually less productive in many ways, but does memory management right).
Second, is your code secure? Is anyone actively poking it for buffer overflows etc.? Recall that the overall thread is about security.
I haven't done much OOP -- mostly just Objective-C stuff on NeXTSTEP and OS X -- but I can say that memory management is a relevant concern in high-level languages too. It's just a different flavor of memory management, with reference counts and retain/release messages instead of handle locking. Both levels have a "null" concept and its associated dangers.
Objective-C is C. Yes, it is OOP. But that doesn't make it a high level language. It is exceedingly rare to worry about "reference counts" or "retain/release messages" in (e.g.) Python, Java, C# or Python.
And the realities are that unless I'm working on a pet project, I don't have the time to learn something new or try to come back up to speed on a language I last used two years ago.
The author is talking about significant applications, not little toy scripts. You are going to be very familiar with (and maybe even expert in) the language used to build a significant application by the time you are done programming it. But another point the author is making is that once you learn a high level language you'll find you can use it for a lot more than you thought. Many programmers get away with using high level languages for 95% of their jobs. And those jobs can involve writing significant (e.g.) ecommerce, content management or client side apps.
Don't get me wrong. Linux is not going to use Python as his major day to day programming language. But I wouldn't be surprised if even he finds the need to program something other than the Linux kernel often enough to justify skill in a higher level language.
Piers Anthony wrote the book based upon the movie based upon the Philip K. Dick short story. http://www.piers-anthony.com/totalrecall.html
Perhaps part of the dullness is that mainframe work will seldom be working with exciting new technologies that you can chat with your friends about. That's what would make me avoid these jobs. I would expect to get new ports of programming languages and tools years after everyone else has moved on to the next big thing.
Don't forget Leisure Suit Larry!
Pink? Nah, Apple already tried that.
Why would the upswing happen in the USA? Theres no real reason to hire an American programmer over a Chinese or Indian programmer,
Except that the American programmer can meet with the customer. And the American programmer can talk to the product manager every day. And the American programmer can attend conferences to pick up cutting edge skills. Some areas of programming don't require any of that stuff. Okay, they'll go offshore. But that isn't all programming jobs by a long stretch.
A tribal dialect of swahili used by a tribal village of canabals that died off by eating themselves and never had any texts, OTOH, should not be something worth keeping and studying...
This language has embedded in it a history of its own evolution and the evolution of its neighbouring languages. It could be a wealth of information about how humans acquire language and how language evolves.
It would have only taken two minutes of research for you to find it yourself: There are several unique benefits of the Java Card technology, such as: Dynamic- New applications can be installed securely after a card has been issued, providing card issuers with the ability to dynamically respond to their customer's changing needs.
That's how Sun is advertising Java Smart Cards. Personally, I'm glad somebody is investigating their claims.
Well, there are already many error-induction attacks agains smart cards (some references in the article), that don't involve JVM running untrusted code.
Great. How do you take advantage of them? The published hack allows you to take over the security manager of the VM and become essentially "god" on the smartcard. So on the one hand you could induce an error on the card to invalidate the money on it (useless) or on the other hand you could induce an error that allows you to do anything you want, including duplicating or precisely mutating the data on the card. I know which ability I would rather have.
So if I can break smart card event if is does not run any my [untrusted] code, who cares about attack to smart card that allows to run untrusted code?
"Break" is one thing. "Use" is another.
Besides, I've never seen any smartcard that actually does this stupid thing.
Good for you. If they exist (they do) and they are being promoted/advertised (they are) then their security considerations are relevant.
A better target for attack may be a server at a nuclear reactor facility that has natural high rate of memory failures :)
A paper on that might also be interesting.
Is there something in the current policy that would prevent open source from being considered?
Open source projects do not tend to be represented by salespeople.
For instance, let's say that copyright renewal costs $100 every 20 years, and there's 4 renewal periods. (80 year max) I could easily go into the business of submitting copyright renewals, and I could do it for $100 per copyright for the duration of the copyright (plus my up-front fee)
This is actually a very risky business to be in. Presumably there will be competition in this business so profits will be moderate or slim. The problem is that if a future congress increases the fees, either the copyright holder or the copyright middleman gets screwed. If the middleman lives up to his side of the bargain, he could find himself losing money year after year on twenty year old contracts. If he doesn't renew the copyright then it expires and his whole business concept is useless. Neither party can predict the rates that some future congress will charge...and why wouldn't congress notice the millions or billions of dollars piling up in these services and get a little greedy?
This all leads to another problem: if you really, really care about your copyright, you would need to really, really trust the company maintaining its copyright. By definition, you would need to trust them more then you trust yourself. It would need to be basically an insurance company or a bank (and even those go out of business sometimes).
And anyhow, an easy way to prevent the business model you've described from developing is to require the signature of the copyright holder on the copyright renewel.
The folks I worry about with copyright are small artists who either themselves make a living off of their work, or who have living relatives who do so.
If they make a living off of the work, why wouldn't they be able to pay the nominal fee required to maintain its copyright status? Its like saying that people shouldn't have to pay for driver's licenses because this prevents poor people from driving to their jobs. Well, if they are getting paid at their jobs then the driver's license is a small price to pay to keep getting that paycheck!
Reports are sketchy at present, but we're being led to believe that it's easy to compromise a machine to which you have physical access!
Bet you didn't even read the abstract. Here's the relevant bit:
Our attack is particularly relevant against smart cards or tamper-resistant computers, where the user has physical access (to the outside of the computer) and can use various means to induce faults; we have successfully used heat.
Maybe Virtual PC is better for Windows development than just Windows (for repeatibility reasons) but it is a hell of a lot slower than running Windows under VMWare under Windows (or Linux).
They have a 70-80% market share that isn't going anywhere quickly so why bother?
The velocity of the shift to Mozilla and other alternative browsers will be directrly proportional to the distance in functionality between them and Internet Explorer. You yourself said that Microsoft will probably have to add tabbed browsing "to stop people saying it is behind for features." Well, this will apply to many other features too. If Mozilla keeps adding "killer" features, Microsoft will eventually have to respond or lose. It's that simple. Yes, they can coast on their monopoly for a while. But not forever. Technology doesn't work like that.
SmallPaul said:I find it kind of odd that you think that a language with regular expressions in the syntax and one without cannot in general be used to solve the same kinds of problems.
Mattdm responded:Wow, I sure didn't say anything like that.
You said that Perl and Python do not really compete at all. That's simply not true. There are tens of thousands of projects out there that could be done in either Perl or Python. At the beginning of the project, someone chose between the languages. Often this is a very explicit process involving a bunch of argumentation and sometimes rancour. If that isn't competition, what is it?
At least on the second of these points, Python isn't even in the same *business* as Perl. There's just flat out no meaningful comparision.
I find it kind of odd that you think that a language with regular expressions in the syntax and one without cannot in general be used to solve the same kinds of problems. Does typing the parens change the nature of the problem that much?
But more to the point, if Perl's raison d'etre is built-in regular expressions (as you claim) then why is it used for (e.g.) SlashCode. What about building a large weblog community is regular-expression-centric? The vast majority of sizable Perl programs have very little to do with regular expressions.
Python has *a lot* of strengths, but they're totally different from Perl's. So why do Python advocates get so worked up about something their preferred language fundamentally isn't designed to do?
There was a period in the mid-90s when it was very common to be forced to write Perl because there was just some Perl code around that had to be maintained. The liklihood of this happening to an individual is proportional to the popularity of Perl. If Perl ceases to be popular then there won't be that much Perl code laying around to be maintained. Just today I was scrounging around in some open source scruffy Perl code that could have been better written in Python. That's the argument from self-interest.
The argument from emotion is that the popularity of Perl rather offends people's sense of competition between technologies being on the basis of quality rather than luck or marketing...in somewhat of the same way that it is typical to be annoyed at the popularity of IIS on Windows 2000 Server. In a sense, Perl is symbolimatic for some people of the less admirable qualities of our industry. What if the "Perl Aesthetic" (which discounts the importance of cleanliness and orthogonality) was to become the norm in other areas of our business?
Why don't they raise a big stink every time someone mentions Java? That seems like a more usefully-comparible application space. Or C++, for that matter.
Well for one thing, Python interoperates really well with Java and C++. So every line of Java and C++ out there can be construed as bolstering the argument for adding Python to the mix a a glue language. Whereas it is very rare to take a large Perl system and say: "let's bolt on some Python to provide a high level interface to this thing." For another thing, the liklihood of Python replacing Java and C++ in the hearts and minds of corporate application developers is quite slim. (especially considering the performance issues) But Python really could replace Perl for everything but 1-liners.
But the most important reason Python users trash Perl is because the first question a newbie asks on hearing about Python, an object oriented scripting language is: "How is it different than Perl?" It is rare for people to ask how it compares to Java or C++ because typically they are expecting Python to complement or extend systems built in Java or C++. If there were a clear consensus out there about when to use Python and when to use Perl then there would be little anti-Perl sentiment in the Python community. But saying that "Perl has built-in regular expressions" is not the same as providing a guideline for when it is better to use Perl than Python or vice versa.
The overall point is that the idea that the "Bible is quite clear" is merely wishful thinking. The Bible is massively open to interpreration. EVEN if you believe that it is literally true AND written by the people it claims it was written by (both of which are questionable).
I didn't write it. I think the attribution is lost in the mists of time.
in nearly all areas, the Bible is quite clear. Like it or not, the Bible provides an excellent moral standard.
Dear Dr. Laura:
Thank you for doing so much to educate people regarding God's Law. I have learned a great deal from your show, and I try to share that knowledge with as many people as I can. When people try to defend the homosexual lifestyle, for example, I simply remind them that Leviticus 18:22 clearly states it to be an abomination. End of debate.
I do need some advice from you, however, regarding some of the specific laws and how to follow them:
a) When I burn a bull on the altar as a sacrifice, I know it creates a pleasing odor for the Lord (Lev.1:9).The problem is my neighbors. They claim the odor is not pleasing to them. Should I smite them?
b) I would like to sell my daughter into slavery, as sanctioned in Exodus 21:7.In this day and age, what do you think would be a fair price for her?
c) I know that I am allowed no contact with a woman while she is in her period of menstrual uncleanness (Lev.15:19-24).The problem is, how do I tell? I have tried asking, but most women take offense.
d) Lev.25:44 states that I may indeed possess slaves, both male and female, provided they are purchased from neighboring nations. A friend of mine claims that this applies to Mexicans, but not Canadians. Can you clarify? Why can't I own Canadians?
e) I have a neighbor who insists on working on the Sabbath. Exodus 35:2 clearly states he should be put to death. Am I morally obligated to kill him myself?
f) A friend of mine feels that even though eating shellfish is an abomination (Lev.11:10), it is a lesser abomination than homosexuality. I don't agree. Can you settle this?
g) Lev.21:20 states that I may not approach the altar of God if I have a defect in my sight. I have to admit that I wear reading glasses. Does my vision have to be 20/20, or is there some wiggle room here?
h) Most of my male friends get their hair trimmed, including the hair around their temples, even though this is expressly forbidden by Lev. 19:27. How should they die?
i) I know from Lev.11:6-8 that touching the skin of a dead pig makes me unclean, but may I still play football if I wear gloves?
j) My uncle has a farm. He violates Lev.19:19 by planting two different crops in the same field, as does his wife by wearing garments made of two different kinds of thread cotton/polyester blend. He also tends to curse and blaspheme a lot. Is it really necessary that we go to all the trouble of getting the whole town together to stone them (Lev.24:10-16)? Couldn't we just burn them to death at a private family affair like we do with people who sleep with their in-laws? (Lev.20:14)
I know you have studied these things extensively, so I am confident you can help. Thank you again for reminding us that God's word is eternal and unchanging.
The Python you gave doesn't solve the problem illustrated. Here's the real solution. It's a new Python 2.3 feature.
What "innovations" can you put in mature software, other than small details?
Browser technology is far from mature. Ten years from now we will look back and see today's browsers as incredibly primitive. For instance, SVG, SMIL and that family of specifications will lead to a much more integrated, interactive Web. RSS, iCal, RDF an so forth will lead to a Web where the browser can help us understand what is going on much better. XUL and XForms will lead to much better Web user interfaces. etc.
So what? An increase in heat and wear and tear on components, for what theroy says is ~25% speed increase. This drive doesn't even come close to that. I would think that for most apps that need this, a SCSI or RAID (or both) solution would be better.
Why would SCSI be less prone to heat and wear than IDE?