I'm not aware of any static analysis that can factor in unit tests (as this work does) to decide what does and what does not make a suitable patch. Note that these patches are about dynamic semantics, not just about name or type analysis failures (which might indeed be easy to fix purely by using static analysis).
The reason for not attaching his name (or the name of the students working on the project) is to minimise bias. A patch coming in from a widely-published and highly experienced formerly-INRIA-now-KTH researcher might be viewed very differently than a patch coming in from a noob.
The reason for `not just checking the patches themselves' is again to reduce bias, though you'll note that they did a manual sanity check every time before they submitted the patch. That is, they only submitted patches that they hoped wouldn't waste the devleopers' time after submission. Evaluating purely by manual validation means that the judgment of whether the result is useful relies purely on the honesty of the researcher, since most publication venues don't leave enough space for researchers to submit source code (nor sufficient time for the reviewers to analyse the source code and patches in detail, unless it's all pretty small and can be squeezed in with the rest of what one must describe in the typical 6-12 pages (double-column) or up-to-25 pages (single-column).
See, I've heard this argument many times, but I've never been able to wrap my head around it. If you tell me that a social system (such as a system of government) has trouble scaling from 1 to 10 people, or from 10 to 100, or from 100 to 1000, then yes, I can see that. If you tell me that it scales fine up to 1000, but has trouble scaling to 10,000, then that's a bit odd (unless we have time/storage constraints and superlinear factors, of course, but that's not really an issue here). My line of thinking is that if you can scale fine to 10 million, then why wouldn't you be able to scale to 400 million or however many people live in the US these days?
In other words, there must be other reasons, and `we could never do that in the US / in Germany / in France / in Japan' is not something that I'm willing to buy.
I haven't tested this link yet (hesitant to update my Skype for that very reason), but here's a list of DNS names that supposedly cover all that Skype uses for ad lookup:
Now, Skype could circumvent such a mechanism (hard-code the IPs-- which could be circumvented with custom routing tables-- or inline the ads into the regular data stream, which would be very hard to circumvent, or just refuse to run if it can't access any ads (or `signed ads')), so even if it works now, it may not be forever....and now I'll shut up and stop giving Microsoft ideas...
From that perspective, you might as well argue that the market distortion here is that the government doesn't permit foreign workers to work in the US under the same conditions as US nationals, since that `unnaturally' restricts the job market (i.e., `national borders distort the job market').
OP pointed out that the situation is more similar to the French Revolution than to the Kristallnacht/disenfranchisement of Jews in 30s Germany. I agree with you that most of the tech workers are scape-goats (I have been part of this very group in the past, for the record), but I agree with OP that the situation is closer to that in the French revolution:
(a) The targetted group holds considerable power and is connected to an apparatus that is seen with approval and benevolence `all the way up' (b) The targetted group lives in a `bubble' that separates its concerns from those of the `lower' classes (c) Targetting is driven by public disapproval, rather than by governmental machinations (sort of a fall-out of (a)).
Now, are the Googlers etc. to blame for the situation? Most of them aren't of course, they're just innocent participants `in the system' and can't be blamed for not wanting to not participate. But I'm confident that most of the French aristocracy had little intent of stomping on the common man either-- they just didn't deal with them much. Didn't do their necks much good, in the end.
So yes. This looks way more French revolution, `to the barricades, comrades! We shall throw off our shackles, and then guilloutine everyone who was or might have been sympathetic to these oppressors!' than Nazi `you really want to be there tonight to throw stones at the Jews, dude, or the Gauleiter will want to have a word with you, and you do remember that you have a wife and kids to feed, right?' Reichskristallnacht.
Based on his description, he is using a very synthetic benchmark:
The code I’m testing contains no #include directives, and makes use of only standard C++ code. It starts with one class, and then is followed by 6084 small classes derived from various instantiations of the template classes. (So these 6084 classes are technically not templates themselves.) Then I create 6084 instantiations of the original template class, using each of the 6084 classes. The end result is 6084 different template instantiations. Now, obviously in real life we wouldn’t write like that (at least I hope you don’t).
So in his own words, the code does not reflect realistic compiles. There is no reason to assume that the result generalise to any programs that anyone actually cares about.
Also, there are no error bars of any kind listed.
In other words, I have no reason to assign any meaning to these numbers.
There's one big change that you are not considering there: the _rate of change_ is greater than ever before. In the past, if someone invented a loom, then a bunch of workers unable to learn the new skills would be out of work and replaced by (mostly younger) people who had grown up with the new technology. This was a problem for about half a generation, during which the younger people could support their out-of-work relatives.
Nowadays, the new skills come and go at a much faster rate. The 16 bit assembly programming skills I learned as a kid about a generation ago are almost useless to me today (in the sense that everything I _need_ to know about low-level programming I could have learned from C). Imperative programming, the way I learned it, is considered largely obsolete by today's vocal OO majority. The APIs I developed against in the late 90s are dead and buried, subsumed in wrapper APIs that one should use instead (who programs directly against xlib these days?) or evolved into entirely new forms (such as OpenGL). Sure, the core Unix APIs are still alive (and so is XML, sadly), but the vast majority of APIs, languages, tools, and hardware from the last few decades have gone the way of the dodo. Compare that to the small number of technological advances we saw in centuries past.
Now, I'm not complaining-- many of these changes were for the better, and even the ones that weren't are likely to be superceded by better ideas within the next couple of years. But note that at the same time at which we see this unprecedented rate of change, poverty statistics show that the gap between rich and poor is growing at similarly unprecedented rates. Yes, this is merely correlation, and it shows nothing. For all I know it might just be that TPTB have become more effective at making people docile and exploitable, or that laws and legal practice have gradually become so complex and expensive that the privilege of freedom has become even more exclusive than it used to be.
But I'd like to think that the increased rate of change is a strong contributor to that change in poverty rates, if only because that is one thing that I see some hope for, via improved education and better tools.
No, there is no assumption that an H-1B holder `will return to their home country.' The H-1B is a dual-intent visa, meaning that you can apply for a permanent resident card while in the US and then legally stay as long as you want.
Incidentally, I'm currently on that very route. I still don't expect to ever see any benefits from the near-decade social security and taxes I've already paid while working on F-1 and J-1 non-immigrant visas.
That was helpful information, thank you! (Unfortunately I can't mod you up.) So they are useful in the grand scheme of things for reducing the amount of `please explain X to me' or `please fix Y on my computer' incidents.
Can someone explain the use cases IPad-like finger-only tablets are intended for to me?
Laptops I understand: you can use them to code, do your e-mail, ssh into machines to get stuff done etc. Phones I get: you can use them to read your e-mail `on the go' and perhaps even send quick replies to important things, read maps, and do skype if you're the adventurous kind who likes voice communication. Tablets with pens I also get: you can read and annotate papers/books with them or draw.
But I don't understand the use cases for finger-only tablets. They seem to be selling well, so my guess is that it's games or porn. Does anyone have experiences with these fingery tablets?
Yes, there has been much progress in module systems. The very Bob Harper mentioned there was involved in the design of the SML module system, which is often cited in the CS literature as `the' reference module system. SML achieves a level of isolation that is simply impossible to achieve in a language like Java or Smalltalk. in Java, any object you can still call `hashcode()' and `toString()' etc. on, and it's often possible for someone to subclass one of your internal classes and thereby break your intended module structure.
In SML, you can confine types through (e.g.) the following signature:
(* this is imperative code; a typical SML program focuses on functional code, but it's good enough for illustration purposes. *) signature STACK = sig
type 'a stack (* 'a is a type parameter, so "'a stack" is what OO-land calls a `generic type' *)
empty : unit -> 'a stack (* create fresh stack *)
push : 'a stack -> 'a -> unit (* take a stack of 'a elements, take an element of type 'a, and plug them together *)
pop : 'a stack -> 'a option (* "'a option" means that the operation may fail *) end
You can then implement this stack in various structures that match this signature, and confine it in such a way that only the operations listed above are available. That is, you can't stringify stacks (there is no such operation listed there, though you can choose to add one), you can't compare them (again, no such operation), you can't `reflect' on them and you can't access their `protected' functionality by subclassing them, unless the stack implementer put a separate view of the structure into place for that particular purpose.
Why is this good? Client code won't end up using features that you didn't want to expose. Why is it bad? If you forgot to expose something important, someone else will have to re-implement it. But that's your fault, then, not the language's fault.
SML also allows you to build modules from other modules through something called `functors', but let's leave that for another time.
Now, SML's modules have issues-- you can't have mutual dependencies between them (which does have advantages, too, though), and the question of how to integrate type classes (something you may know as `C++ concepts') is unresolved. But the concepts behind the module system are clear and powerful. So if you want to teach the concepts underlying modular software design, this is a vastly better choice than most other options out there. (I remember the Modula-3 module system being fairly good, too, but not quite at this level.)
So, for teaching purposes I'd say Bob Harper is closely connected to the best system out there that has actual working implementations tied to it.
Some program analyses are linear, others log-linear, others worse. Some require fixed point computation that may run as long as you want it to run. Check the program analysis literature: you'll find analyses for almost any level of complexity you want, and if you pick carefully, more run-time will usually give you better results (though it may or may not be worth the effort).
Was your tool flow-sensitive? Was it context-sensitive? If so, to what level? Did it normalise the AST, or did it represent the source code (as you might want to do for a source code clone analysis)? What kind of alias analysis did you use?
Please don't go tossing all program analyses into the same bin. If you've implemented a type checker for C, you may think that the idea of type checking being exponential is ridiculous-- yet that is what it is in languages like SML or Haskell.
For the needs of a modern VM, Python would be a step back from Java. To jit a language efficiently, you want to have as much information about the programs as you can get, particularly static types. Python as a dynamically typed language is about as hard to jit as Javascript is-- we're only just beginning to see adaptive compilation systems (i.e., composed baseline/optimising-compilers or composed interpreter/compilers) for that.
Python has its niche, but it's not "a platform for competing on equal terms with native-code apps for iOS".
You could pick a different statically typed language (e.g. something based on Modula-3 or Eiffel), but even if you provide a re-engineering tool to translate from the old code to the new code, you are going to alienate many of your coders, especially inexperienced ones who have trouble seeing beyond syntax. And those are in the majority, in my experience.
...that most other countries made: don't let the transportation companies keep the rail networks. (At least) one company for the rails, and as many for the trains as are willing to invest-- the same way cable/DSL should be handled. Unless you want Amtrak to become the Comcast of transportation, of course.
That being said, I've commuted by rail in Germany, and I've travelled through much of Europe and parts of Japan that way, and it beats all other forms of transportation I have tried. Based on that, I'd consider a 10% increase in federal taxes to finance European-level public transportation to be a good deal.
On second thought, someone else could re-encode as jpeg. So you may want to resize and perhaps blur a little. Either way I don't see why this wouldn't be trivial to defeat.
From reading the article, I don't think that this is intended as a replacement for deb/rpm or tarballs with configuration scripts. (If it is, it is a very bad idea.)
The tool constructs a reduced dynamic I/O trace of a single program run to determine file dependencies, then packages these. This is great if you're benchmarking deterministic programs on different hardware, and useful for quickly migrating your code onto a bigger machine when a paper deadline is around the corner.
But again, the files it picks are based on a dynamic trace. If you run `cat foo.txt', then `foo.txt' will be part of the trace. If you run it on apache, all the apache modules that apache wound up loading will be part of the trace, but no others. So it's not very general-purpose. Still useful, in the right situation.
I've found that switching for C/C++/Java to SML with its wide-ish pattern matching constructs works fairly well on a wider-screen desktop. I don't think anyone with a `normal' display can read any of the code I write like that (my EMACS can display 314 characters horizontally now), but I'm in CS research, so chances are that nobody ever will.
More seriously, I second and third your complaint. There are laptops with rotatable displays out there, but those generally don't allow you to use the keyboard after rotation due to physical limitations (plus, they have crappy resolutions because they also try to be touchscreens for some reason). Lenovo's concept system with a detachable display plus keyboard sounds the most promising to me as far as future technologies go that might resolve this issue.
after some quick googling around, it seems that the relevant numbers are as follows:
- One hour of programming in the US usually contains 15 minutes of commercials. - Commercials time is worth about 4 cents per minute per viewer.
So the price of not getting ads should be around 60 cents per episode of most television shows. YMMV, but IMO that's a lot less than the opportunity cost for wasting my attention on ads, even ignoring the cost of a television set.
While we're modifying physics, may I submit feature requests for anti-gravity and faster-than-light travel, please?
Also, do they have a public bug tracker up yet? I think I found a division-by-zero bug involving a cat and butter, but I'm having trouble reproducing it (as I am running out of band-aids.)
Yes, SPJ works at Microsoft Research these days, since they sponsor his primary pet project (the Glasgow Haskell Compiler), but he has been extremely successful before and after going there. I've done enough writing to basically agree with him-- there are variations here and there when it comes to structuring the paper, but his main points are very sensible and good.
Also, the downside of this approach is that the government doesn't benefit from attacking these practices directly, which decreases the motivation from enacting it.
That's insufficient. Let's say that the probability of getting caught is p. p is = 1. Now, the average cost for unethical behaviour is the same as the profits of this unethical behaviour times p. Hence, it is rational to remain unethical: you can only win.
Ideally, the penalties for such behaviour would be in a different category than profits, i.e., not money: jail time for executives who made this decision, forced donation of part of their company to a randomly selected competitor, forced public-domain-making of all of their patents. None of these are things that they can easily pass on to the consumer as cost, and they may in fact all be beneficial for the market.
Slashdot Mirror
I'm not aware of any static analysis that can factor in unit tests (as this work does) to decide what does and what does not make a suitable patch. Note that these patches are about dynamic semantics, not just about name or type analysis failures (which might indeed be easy to fix purely by using static analysis).
The reason for not attaching his name (or the name of the students working on the project) is to minimise bias. A patch coming in from a widely-published and highly experienced formerly-INRIA-now-KTH researcher might be viewed very differently than a patch coming in from a noob.
The reason for `not just checking the patches themselves' is again to reduce bias, though you'll note that they did a manual sanity check every time before they submitted the patch. That is, they only submitted patches that they hoped wouldn't waste the devleopers' time after submission. Evaluating purely by manual validation means that the judgment of whether the result is useful relies purely on the honesty of the researcher, since most publication venues don't leave enough space for researchers to submit source code (nor sufficient time for the reviewers to analyse the source code and patches in detail, unless it's all pretty small and can be squeezed in with the rest of what one must describe in the typical 6-12 pages (double-column) or up-to-25 pages (single-column).
See, I've heard this argument many times, but I've never been able to wrap my head around it. If you tell me that a social system (such as a system of government) has trouble scaling from 1 to 10 people, or from 10 to 100, or from 100 to 1000, then yes, I can see that. If you tell me that it scales fine up to 1000, but has trouble scaling to 10,000, then that's a bit odd (unless we have time/storage constraints and superlinear factors, of course, but that's not really an issue here). My line of thinking is that if you can scale fine to 10 million, then why wouldn't you be able to scale to 400 million or however many people live in the US these days?
In other words, there must be other reasons, and `we could never do that in the US / in Germany / in France / in Japan' is not something that I'm willing to buy.
I haven't tested this link yet (hesitant to update my Skype for that very reason), but here's a list of DNS names that supposedly cover all that Skype uses for ad lookup:
https://gist.github.com/eyecat...
Now, Skype could circumvent such a mechanism (hard-code the IPs-- which could be circumvented with custom routing tables-- or inline the ads into the regular data stream, which would be very hard to circumvent, or just refuse to run if it can't access any ads (or `signed ads')), so even if it works now, it may not be forever. ...and now I'll shut up and stop giving Microsoft ideas...
From that perspective, you might as well argue that the market distortion here is that the government doesn't permit foreign workers to work in the US under the same conditions as US nationals, since that `unnaturally' restricts the job market (i.e., `national borders distort the job market').
OP pointed out that the situation is more similar to the French Revolution than to the Kristallnacht/disenfranchisement of Jews in 30s Germany. I agree with you that most of the tech workers are scape-goats (I have been part of this very group in the past, for the record), but I agree with OP that the situation is closer to that in the French revolution:
(a) The targetted group holds considerable power and is connected to an apparatus that is seen with approval and benevolence `all the way up'
(b) The targetted group lives in a `bubble' that separates its concerns from those of the `lower' classes
(c) Targetting is driven by public disapproval, rather than by governmental machinations (sort of a fall-out of (a)).
Now, are the Googlers etc. to blame for the situation? Most of them aren't of course, they're just innocent participants `in the system' and can't be blamed for not wanting to not participate. But I'm confident that most of the French aristocracy had little intent of stomping on the common man either-- they just didn't deal with them much. Didn't do their necks much good, in the end.
So yes. This looks way more French revolution, `to the barricades, comrades! We shall throw off our shackles, and then guilloutine everyone who was or might have been sympathetic to these oppressors!' than Nazi `you really want to be there tonight to throw stones at the Jews, dude, or the Gauleiter will want to have a word with you, and you do remember that you have a wife and kids to feed, right?' Reichskristallnacht.
Except modulo the guilloutines. Please.
Based on his description, he is using a very synthetic benchmark:
The code I’m testing contains no #include directives, and makes use of only standard C++ code. It starts with one class, and then is followed by 6084 small classes derived from various instantiations of the template classes. (So these 6084 classes are technically not templates themselves.) Then I create 6084 instantiations of the original template class, using each of the 6084 classes. The end result is 6084 different template instantiations. Now, obviously in real life we wouldn’t write like that (at least I hope you don’t).
So in his own words, the code does not reflect realistic compiles. There is no reason to assume that the result generalise to any programs that anyone actually cares about.
Also, there are no error bars of any kind listed.
In other words, I have no reason to assign any meaning to these numbers.
There's one big change that you are not considering there: the _rate of change_ is greater than ever before. In the past, if someone invented a loom, then a bunch of workers unable to learn the new skills would be out of work and replaced by (mostly younger) people who had grown up with the new technology. This was a problem for about half a generation, during which the younger people could support their out-of-work relatives.
Nowadays, the new skills come and go at a much faster rate. The 16 bit assembly programming skills I learned as a kid about a generation ago are almost useless to me today (in the sense that everything I _need_ to know about low-level programming I could have learned from C). Imperative programming, the way I learned it, is considered largely obsolete by today's vocal OO majority. The APIs I developed against in the late 90s are dead and buried, subsumed in wrapper APIs that one should use instead (who programs directly against xlib these days?) or evolved into entirely new forms (such as OpenGL). Sure, the core Unix APIs are still alive (and so is XML, sadly), but the vast majority of APIs, languages, tools, and hardware from the last few decades have gone the way of the dodo. Compare that to the small number of technological advances we saw in centuries past.
Now, I'm not complaining-- many of these changes were for the better, and even the ones that weren't are likely to be superceded by better ideas within the next couple of years. But note that at the same time at which we see this unprecedented rate of change, poverty statistics show that the gap between rich and poor is growing at similarly unprecedented rates.
Yes, this is merely correlation, and it shows nothing. For all I know it might just be that TPTB have become more effective at making people docile and exploitable, or that laws and legal practice have gradually become so complex and expensive that the privilege of freedom has become even more exclusive than it used to be.
But I'd like to think that the increased rate of change is a strong contributor to that change in poverty rates, if only because that is one thing that I see some hope for, via improved education and better tools.
The pledge is not about not submitting to these venues. It's about not reviewing for them.
No, there is no assumption that an H-1B holder `will return to their home country.' The H-1B is a dual-intent visa, meaning that you can apply for a permanent resident card while in the US and then legally stay as long as you want.
Incidentally, I'm currently on that very route. I still don't expect to ever see any benefits from the near-decade social security and taxes I've already paid while working on F-1 and J-1 non-immigrant visas.
Does it have flappy ears and say `haro' a lot?
That was helpful information, thank you! (Unfortunately I can't mod you up.)
So they are useful in the grand scheme of things for reducing the amount of `please explain X to me' or `please fix Y on my computer' incidents.
Can someone explain the use cases IPad-like finger-only tablets are intended for to me?
Laptops I understand: you can use them to code, do your e-mail, ssh into machines to get stuff done etc.
Phones I get: you can use them to read your e-mail `on the go' and perhaps even send quick replies to important things, read maps, and do skype if you're the adventurous kind who likes voice communication.
Tablets with pens I also get: you can read and annotate papers/books with them or draw.
But I don't understand the use cases for finger-only tablets. They seem to be selling well, so my guess is that it's games or porn. Does anyone have experiences with these fingery tablets?
Yes, there has been much progress in module systems. The very Bob Harper mentioned there was involved in the design of the SML module system, which is often cited in the CS literature as `the' reference module system. SML achieves a level of isolation that is simply impossible to achieve in a language like Java or Smalltalk. in Java, any object you can still call `hashcode()' and `toString()' etc. on, and it's often possible for someone to subclass one of your internal classes and thereby break your intended module structure.
In SML, you can confine types through (e.g.) the following signature:
(* this is imperative code; a typical SML program focuses on functional code, but it's good enough for illustration purposes. *)
signature STACK =
sig
type 'a stack (* 'a is a type parameter, so "'a stack" is what OO-land calls a `generic type' *)
empty : unit -> 'a stack (* create fresh stack *)
push : 'a stack -> 'a -> unit (* take a stack of 'a elements, take an element of type 'a, and plug them together *)
pop : 'a stack -> 'a option (* "'a option" means that the operation may fail *)
end
You can then implement this stack in various structures that match this signature, and confine it in such a way that only the operations listed above are available. That is, you can't stringify stacks (there is no such operation listed there, though you can choose to add one), you can't compare them (again, no such operation), you can't `reflect' on them and you can't access their `protected' functionality by subclassing them, unless the stack implementer put a separate view of the structure into place for that particular purpose.
Why is this good? Client code won't end up using features that you didn't want to expose. Why is it bad? If you forgot to expose something important, someone else will have to re-implement it. But that's your fault, then, not the language's fault.
SML also allows you to build modules from other modules through something called `functors', but let's leave that for another time.
Now, SML's modules have issues-- you can't have mutual dependencies between them (which does have advantages, too, though), and the question of how to integrate type classes (something you may know as `C++ concepts') is unresolved. But the concepts behind the module system are clear and powerful. So if you want to teach the concepts underlying modular software design, this is a vastly better choice than most other options out there. (I remember the Modula-3 module system being fairly good, too, but not quite at this level.)
So, for teaching purposes I'd say Bob Harper is closely connected to the best system out there that has actual working implementations tied to it.
Some program analyses are linear, others log-linear, others worse. Some require fixed point computation that may run as long as you want it to run. Check the program analysis literature: you'll find analyses for almost any level of complexity you want, and if you pick carefully, more run-time will usually give you better results (though it may or may not be worth the effort).
Was your tool flow-sensitive? Was it context-sensitive? If so, to what level? Did it normalise the AST, or did it represent the source code (as you might want to do for a source code clone analysis)? What kind of alias analysis did you use?
Please don't go tossing all program analyses into the same bin. If you've implemented a type checker for C, you may think that the idea of type checking being exponential is ridiculous-- yet that is what it is in languages like SML or Haskell.
For the needs of a modern VM, Python would be a step back from Java. To jit a language efficiently, you want to have as much information about the programs as you can get, particularly static types. Python as a dynamically typed language is about as hard to jit as Javascript is-- we're only just beginning to see adaptive compilation systems (i.e., composed baseline/optimising-compilers or composed interpreter/compilers) for that.
Python has its niche, but it's not "a platform for competing on equal terms with native-code apps for iOS".
You could pick a different statically typed language (e.g. something based on Modula-3 or Eiffel), but even if you provide a re-engineering tool to translate from the old code to the new code, you are going to alienate many of your coders, especially inexperienced ones who have trouble seeing beyond syntax. And those are in the majority, in my experience.
...that most other countries made: don't let the transportation companies keep the rail networks. (At least) one company for the rails, and as many for the trains as are willing to invest-- the same way cable/DSL should be handled. Unless you want Amtrak to become the Comcast of transportation, of course.
That being said, I've commuted by rail in Germany, and I've travelled through much of Europe and parts of Japan that way, and it beats all other forms of transportation I have tried. Based on that, I'd consider a 10% increase in federal taxes to finance European-level public transportation to be a good deal.
On second thought, someone else could re-encode as jpeg. So you may want to resize and perhaps blur a little. Either way I don't see why this wouldn't be trivial to defeat.
...just make sure you save as png, not jpeg.
From reading the article, I don't think that this is intended as a replacement for deb/rpm or tarballs with configuration scripts. (If it is, it is a very bad idea.)
The tool constructs a reduced dynamic I/O trace of a single program run to determine file dependencies, then packages these. This is great if you're benchmarking deterministic programs on different hardware, and useful for quickly migrating your code onto a bigger machine when a paper deadline is around the corner.
But again, the files it picks are based on a dynamic trace. If you run `cat foo.txt', then `foo.txt' will be part of the trace. If you run it on apache, all the apache modules that apache wound up loading will be part of the trace, but no others. So it's not very general-purpose. Still useful, in the right situation.
I've found that switching for C/C++/Java to SML with its wide-ish pattern matching constructs works fairly well on a wider-screen desktop. I don't think anyone with a `normal' display can read any of the code I write like that (my EMACS can display 314 characters horizontally now), but I'm in CS research, so chances are that nobody ever will.
More seriously, I second and third your complaint. There are laptops with rotatable displays out there, but those generally don't allow you to use the keyboard after rotation due to physical limitations (plus, they have crappy resolutions because they also try to be touchscreens for some reason). Lenovo's concept system with a detachable display plus keyboard sounds the most promising to me as far as future technologies go that might resolve this issue.
Hi,
after some quick googling around, it seems that the relevant numbers are as follows:
- One hour of programming in the US usually contains 15 minutes of commercials.
- Commercials time is worth about 4 cents per minute per viewer.
So the price of not getting ads should be around 60 cents per episode of most television
shows. YMMV, but IMO that's a lot less than the opportunity cost for wasting my attention
on ads, even ignoring the cost of a television set.
While we're modifying physics, may I submit feature requests for anti-gravity and faster-than-light travel, please?
Also, do they have a public bug tracker up yet? I think I found a division-by-zero bug involving a cat and butter, but I'm having trouble reproducing it (as I am running out of band-aids.)
As for writing the paper, here's my favourite set of slides on this topic:
SPJ's `How to write a research paper'
Yes, SPJ works at Microsoft Research these days, since they sponsor his primary pet project (the Glasgow Haskell Compiler), but he has been extremely successful before and after going there. I've done enough writing to basically agree with him-- there are variations here and there when it comes to structuring the paper, but his main points are very sensible and good.
Sorry, forgot about the HTML. p is <= 1, I meant.
Also, the downside of this approach is that the government doesn't benefit from attacking these practices directly, which decreases the motivation from enacting it.
That's insufficient. Let's say that the probability of getting caught is p. p is = 1. Now, the average cost for unethical behaviour is the same as the profits of this unethical behaviour times p. Hence, it is rational to remain unethical: you can only win.
Ideally, the penalties for such behaviour would be in a different category than profits, i.e., not money: jail time for executives who made this decision, forced donation of part of their company to a randomly selected competitor, forced public-domain-making of all of their patents. None of these are things that they can easily pass on to the consumer as cost, and they may in fact all be beneficial for the market.