Given that you're in the Bay Area, you might have a chance of landing some kind of summer work at a start up. Startups, especially rapidly growing and/or early stage ones, typically have huge backlogs of work that needed to be done yesterday. With no experience, no one is going to risk their business by putting you on the critical path of key projects. But if you're smart, have a lot of initiative (and I presume that you do given that you're asking this question on Slashdot), I bet you could get someone to take a chance on you in a way that would give you interesting work and some experience you won't get at school. You risk nothing by sending your resume and cover letter out to places you find interesting.
Check out Project 7. Microsoft is funding development of a variety of functional language front-ends for.NET including Scheme, SML, Mercury, and Haskell. Dan's work has been to provide a higher-level IL than MSIL (CIL) that may make writing a front-end for functional (or some object oriented) languages easier. AFAIK the Haskell front-end is the only one using Dan's higher-level IL.
I whole-heartedly agree with you that C#'s use of implicit boxing for value types is a really good idea. However, C# is not the first language that automatically converts between boxed and unboxed data representations. Functional languages (both dynamically typed and polymorphic statically typed) have been using similar techniques for decades. This is probably just semantic nitpicking, but your use of the word introduce might lead some folks to believe that Microsoft invented this technique.
The new administration's Department of Justice doesn't have the power to unilaterally drop or settle the Microsoft antitrust case. To do either would require the consent of the state attorneys general participating in the case. As long as just one of those state attorneys general chooses to pursue the case, it will have to work its way through the entire appeals process. And there is every indication that several state AGs are ready, willing, and able to see the case through to its bitter end.
The decision that Judge Kaplan handed down strikes a disturbing blow against source code as a protected form of free expression. Dave Touretzky has constructed a gallery of CSS descramblers which demonstrates the difficulty of establishing when a piece of code is more expression than it is mechanism. Kaplan's decision even suggests that his finding might have been different if the CSS descrambler in question (DeCSS) was not trivially translatable to an executable device.
But where do we draw the line. When a judge deems that pseudo-code, or a precisely worded prose description of a circumvention algorithm is too easy to turn into an executable circumvention device, are we going to see those forms of expression restricted as well?
The DMCA's provision against bypassing copy protection mechanisms probably precludes the commercialization of hardware that plays back cracked SDMI streams.
On the contrary, I think that there is need for much worry. Windows Media Player is available on MacOS and Windows platforms which account for the vast majority of desktop systems. If Microsoft's licensing terms for the WMP server are more attractive (i.e. cheaper per stream) than its competitors, then that -- combined with an enormous installed base -- has to be extremely appealing to content providers. Content providers, especially those running on a shoestring budget, may not mind that they're excluding a few million potential Linux users; especially when they could reach a few hundred million Mac and Wintel users.
And don't forget that Microsoft has a vested interest in gaining a share of the streaming media market -- it is yet another reason for people to buy Microsoft server operating systems.
Some programmers already are compelled to abide by a professional code of ethics as terms of membership in either the ACM or the IEEE. Admittedly there is no substantive penalty for breaking these codes. But the codes are there and most members (that I know) take them seriously. Codes of ethics are good.
What I'm wondering is how many programmers welcome training in and practice of software development processes? Many programmers that I know believe that what they do is create software -- that they are software craftspeople. They perceive software engineers as people who do more paperwork than programming, and who value process over ingenuity in programming. Now I'm not endorsing this view, but what do you guys think?
It has been my experience that flamers don't just choose to flame people at random. A person persitently inspiring large numbers of flames is probably saying something that is outside the boundaries of the community. Or at least what the flamers perceive the boundaries to be.
When a community is organized around a very specific theme or idea, and someone just barges in and tries to change the dialogue to something totally unrelated, people are likely to be dismissive. If the person persists, members of the community will probably get upset. And some people are likely to voice their discontent. Loudly. With expletives. The flamers just skip the dismissive part and go straight to the expletives.
The problem is knowing where the boundaries are and when they've changed. Flamers can actually help delineate boundaries. If the majority of the responses to a posting are flames, then you're out of bounds. There is probably a kinder, gentler way. But flaming is the longstanding tradition.
Well the compiler guys certainly shouldn't give up. You've touched on a good point though. Many potentially profitable code transformations cannot be performed statically because it is impossible to prove they won't alter a program's semantics. Often, the transformation is prevented because the value of some variable at a given point in the program can't be determined. Think aliases.
The Crusoe code morpher has an entirely different problem. It must make optimization decisions based solely on a local set of machine instructions. It doesn't have any of the high level information about the program's structure -- and some of this potentially useful information can't be inferred directly from the instruction stream. So, yes, the Crusoe code morpher has more information (values of variables, etc.) and less information (types, etc.) than the static compiler.
So it makes sense that static and dynamic optimization should benefit from one another and each exploit its own strengths.
- Good static optimization can reduce the amount of work that the dynamic optimizer has to do, thus yielding better performance (through lower translation latency) and reduced power consumption.
- Static optimizations can perform translations on larger chunks of code than the Crusoe code morpher. For instance, through analysis it may be possible to show that a loop can be reordered to improve cache performance w/o altering the original program semantics.
- Static optimizations can be more agressive since their cost is amortized across all program executions.
And there are many other arguments for good static optimization technology.
Now, I imagine that Transmeta has arranged it so that codes optimized for Intel processors run well on Crusoe under morphing. But I also imagine that Transmeta might publish a set of guidelines for compiler writers that suggest how one might generate better code for Crusoe targets. The trick will be doing so w/o exposing too much information about their top secret morphing technology.
Just paranoid speculation, but might RIAA's blind eye towards Phillips and Sony be because they both own huge recording companies and are thus represented by RIAA?
I was experiencing similar symptoms a few months ago. On the recommendation of two colleagues, I bought a Kinesis keyboard; a refurbished Essential model. They're sort of pricey and take a week or so to get used to, but they're definitely worth it. Just a thought.
There is a school of thought that says compilers and interpreters are systems programs and hence should be written in systems programming languages like C.
There is another school of thought that says the language being implemented is clearly the best in the world for almost all purposes, therefore its compiler/interpreter should be bootstrapped.
In general, I don't think that either of these attitudes is entirely appropriate. It strikes me that when implementing a translator for a programming language, that one would want to use a language that had:
1) Automatic lexer and parser generator tools. I suspect that the lack of these tools is not a real barrier though, since most compiler jocks know enough to rattle both off in a weekend.
2) Reasonable linguistic facilities for manipulating strings.
3) Reasonable linguistic facilities for specifying and manipulating user defined data structures -- particularly trees.
4) Some way to do information hiding and separate compilation. And perhaps other facilities for programming in the large.
5) A reasonably speedy implementation, so the translator that you're writing isn't hideously slow.
Now, does Perl have all of these attributes? Mostly. The thing that I would think you wouldn't want to do, is write a bytecode interpreter in Perl. This, you definitely want to do in C (if you're concerned with portability) or C/assembler (if performance matters more than anything else).
Being a graduate student in computer science is an ascetic experience. In order to succeed, you will be called upon by the elders of your order (professors) to forsake the temptations of big IT salaries and stock options, to labor and toil as a peon with virtually no status whatsoever. In the end, you are supposed to emerge as an enwizened practitioner. That's the theory at least.
Seriously though, if you decide to go to graduate school, you will help yourself greatly by doing the following:
1) Talk to graduate students from any of the schools that you are considering attending. They will be able to tell you the real deal about their school. You might also be able to judge how bright a department's grads are when you talk to them. A lot of smart grads is usually a good sign.
2) Find out something about the school's location. Even though you will be involved with classes and research most of the time, you want to make sure that when you actually have free time, that there's something to do.
3) Make sure that the school's aid package is enough to pay the rent and eat. That is, unless you are your parents are rich. Make sure that you know exactly what your expenses are, e.g., tuition, fees and health insurance. Any good Ph.D. program will pay most of these for you. Don't be shy asking about the size of stipends or fellowships. And make sure that you'll be funded throughout your tenure as a student.
4) Know exactly why you're going to graduate school. You will get depressed and start doubting your decision to go to graduate school. Especially when your friend's make $10,000,000 when their stock vests. It's good to be able to reassure yourself that you made the right choice when this happens.
I don't believe that any of last year's entries were straight out pre-written. Even the guys who had code written to play games like chess had to make non-trivial changes to get their programs to play Pousse well enough to be competitive.
For this year's contest, we have again tried our best to come up with a problem that won't give some teams a competitive advantage over others.
Slashdot Mirror
Given that you're in the Bay Area, you might have a chance of landing some kind of summer work at a start up. Startups, especially rapidly growing and/or early stage ones, typically have huge backlogs of work that needed to be done yesterday. With no experience, no one is going to risk their business by putting you on the critical path of key projects. But if you're smart, have a lot of initiative (and I presume that you do given that you're asking this question on Slashdot), I bet you could get someone to take a chance on you in a way that would give you interesting work and some experience you won't get at school. You risk nothing by sending your resume and cover letter out to places you find interesting.
Yes, we do use this in some of our apps, the most recent of which is described here: http://googlebase.blogspot.com/2006/12/plastic-sur gery.html
Check out Project 7. Microsoft is funding development of a variety of functional language front-ends for .NET including Scheme, SML, Mercury, and Haskell. Dan's work has been to provide a higher-level IL than MSIL (CIL) that may make writing a front-end for functional (or some object oriented) languages easier. AFAIK the Haskell front-end is the only one using Dan's higher-level IL.
> C# introduces some ideas ... such as boxing ...
I whole-heartedly agree with you that C#'s use of implicit boxing for value types is a really good idea. However, C# is not the first language that automatically converts between boxed and unboxed data representations. Functional languages (both dynamically typed and polymorphic statically typed) have been using similar techniques for decades. This is probably just semantic nitpicking, but your use of the word introduce might lead some folks to believe that Microsoft invented this technique.
The new administration's Department of Justice doesn't have the power to unilaterally drop or settle the Microsoft antitrust case. To do either would require the consent of the state attorneys general participating in the case. As long as just one of those state attorneys general chooses to pursue the case, it will have to work its way through the entire appeals process. And there is every indication that several state AGs are ready, willing, and able to see the case through to its bitter end.
Firing up realplay and chunking the following URL into "Open Location" will get you right to the interview:
v ers/09042000/ss00914200.rm?start=00:22:11& end=00:30:23&vidsection=2100114
http://www.zdtv.com/cgi-bin/zdvmod_smi/screensa
Actually Judge Kaplan's opinion says that source code IS a circumvention device.
And another thing...
The decision that Judge Kaplan handed down strikes a disturbing blow against source code as a protected form of free expression. Dave Touretzky has constructed a gallery of CSS descramblers which demonstrates the difficulty of establishing when a piece of code is more expression than it is mechanism. Kaplan's decision even suggests that his finding might have been different if the CSS descrambler in question (DeCSS) was not trivially translatable to an executable device.
But where do we draw the line. When a judge deems that pseudo-code, or a precisely worded prose description of a circumvention algorithm is too easy to turn into an executable circumvention device, are we going to see those forms of expression restricted as well?
This is scary stuff...
The DMCA's provision against bypassing copy protection mechanisms probably precludes the commercialization of hardware that plays back cracked SDMI streams.
On the contrary, I think that there is need for much worry. Windows Media Player is available on MacOS and Windows platforms which account for the vast majority of desktop systems. If Microsoft's licensing terms for the WMP server are more attractive (i.e. cheaper per stream) than its competitors, then that -- combined with an enormous installed base -- has to be extremely appealing to content providers. Content providers, especially those running on a shoestring budget, may not mind that they're excluding a few million potential Linux users; especially when they could reach a few hundred million Mac and Wintel users.
And don't forget that Microsoft has a vested interest in gaining a share of the streaming media market -- it is yet another reason for people to buy Microsoft server operating systems.
I'd say that there's a lot to worry about.
Some programmers already are compelled to abide by a professional code of ethics as terms of membership in either the ACM or the IEEE. Admittedly there is no substantive penalty for breaking these codes. But the codes are there and most members (that I know) take them seriously. Codes of ethics are good.
What I'm wondering is how many programmers welcome training in and practice of software development processes? Many programmers that I know believe that what they do is create software -- that they are software craftspeople. They perceive software engineers as people who do more paperwork than programming, and who value process over ingenuity in programming. Now I'm not endorsing this view, but what do you guys think?
It has been my experience that flamers don't just choose to flame people at random. A person persitently inspiring large numbers of flames is probably saying something that is outside the boundaries of the community. Or at least what the flamers perceive the boundaries to be.
When a community is organized around a very specific theme or idea, and someone just barges in and tries to change the dialogue to something totally unrelated, people are likely to be dismissive. If the person persists, members of the community will probably get upset. And some people are likely to voice their discontent. Loudly. With expletives. The flamers just skip the dismissive part and go straight to the expletives.
The problem is knowing where the boundaries are and when they've changed. Flamers can actually help delineate boundaries. If the majority of the responses to a posting are flames, then you're out of bounds. There is probably a kinder, gentler way. But flaming is the longstanding tradition.
Well the compiler guys certainly shouldn't give up. You've touched on a good point though. Many potentially profitable code transformations cannot be performed statically because it is impossible to prove they won't alter a program's semantics. Often, the transformation is prevented because the value of some variable at a given point in the program can't be determined. Think aliases.
The Crusoe code morpher has an entirely different problem. It must make optimization decisions based solely on a local set of machine instructions. It doesn't have any of the high level information about the program's structure -- and some of this potentially useful information can't be inferred directly from the instruction stream. So, yes, the Crusoe code morpher has more information (values of variables, etc.) and less information (types, etc.) than the static compiler.
So it makes sense that static and dynamic optimization should benefit from one another and each exploit its own strengths.
- Good static optimization can reduce the amount of work that the dynamic optimizer has to do, thus yielding better performance (through lower translation latency) and reduced power consumption.
- Static optimizations can perform translations on larger chunks of code than the Crusoe code morpher. For instance, through analysis it may be possible to show that a loop can be reordered to improve cache performance w/o altering the original program semantics.
- Static optimizations can be more agressive since their cost is amortized across all program executions.
And there are many other arguments for good static optimization technology.
Now, I imagine that Transmeta has arranged it so that codes optimized for Intel processors run well on Crusoe under morphing. But I also imagine that Transmeta might publish a set of guidelines for compiler writers that suggest how one might generate better code for Crusoe targets. The trick will be doing so w/o exposing too much information about their top secret morphing technology.
Just paranoid speculation, but might RIAA's blind eye towards Phillips and Sony be because they both own huge recording companies and are thus represented by RIAA?
I was experiencing similar symptoms a few months ago. On the recommendation of two colleagues, I bought a Kinesis keyboard; a refurbished Essential model. They're sort of pricey and take a week or so to get used to, but they're definitely worth it. Just a thought.
There is a school of thought that says compilers and interpreters are systems programs and hence should be written in systems programming languages like C.
There is another school of thought that says the language being implemented is clearly the best in the world for almost all purposes, therefore its compiler/interpreter should be bootstrapped.
In general, I don't think that either of these attitudes is entirely appropriate. It strikes me that when implementing a translator for a programming language, that one would want to use a language that had:
1) Automatic lexer and parser generator tools. I suspect that the lack of these tools is not a real barrier though, since most compiler jocks know enough to rattle both off in a weekend.
2) Reasonable linguistic facilities for manipulating strings.
3) Reasonable linguistic facilities for specifying and manipulating user defined data structures -- particularly trees.
4) Some way to do information hiding and separate compilation. And perhaps other facilities for programming in the large.
5) A reasonably speedy implementation, so the translator that you're writing isn't hideously slow.
Now, does Perl have all of these attributes? Mostly. The thing that I would think you wouldn't want to do, is write a bytecode interpreter in Perl. This, you definitely want to do in C (if you're concerned with portability) or C/assembler (if performance matters more than anything else).
Being a graduate student in computer science is an ascetic experience. In order to succeed, you will be called upon by the elders of your order (professors) to forsake the temptations of big IT salaries and stock options, to labor and toil as a peon with virtually no status whatsoever. In the end, you are supposed to emerge as an enwizened practitioner. That's the theory at least.
Seriously though, if you decide to go to graduate school, you will help yourself greatly by doing the following:
1) Talk to graduate students from any of the schools that you are considering attending. They will be able to tell you the real deal about their school. You might also be able to judge how bright a department's grads are when you talk to them. A lot of smart grads is usually a good sign.
2) Find out something about the school's location. Even though you will be involved with classes and research most of the time, you want to make sure that when you actually have free time, that there's something to do.
3) Make sure that the school's aid package is enough to pay the rent and eat. That is, unless you are your parents are rich. Make sure that you know exactly what your expenses are, e.g., tuition, fees and health insurance. Any good Ph.D. program will pay most of these for you. Don't be shy asking about the size of stipends or fellowships. And make sure that you'll be funded throughout your tenure as a student.
4) Know exactly why you're going to graduate school. You will get depressed and start doubting your decision to go to graduate school. Especially when your friend's make $10,000,000 when their stock vests. It's good to be able to reassure yourself that you made the right choice when this happens.
5) Visit Ron Azuma's guide to being a PhD student.
Hope this helps.
EvilKevin
I don't believe that any of last year's entries were straight out pre-written. Even the guys who had code written to play games like chess had to make non-trivial changes to get their programs to play Pousse well enough to be competitive.
:)
For this year's contest, we have again tried our best to come up with a problem that won't give some teams a competitive advantage over others.
Hopefully everyone will be equally challenged