Insurance increases can be considerable and ongoing (not one time) [it can add up to thousands of dollars per year]. But the real deterrent is loss of points leading to suspension or loss of license. You really want to stop something, take their license away for incremental amounts of time.

Demerit points are much more of a deterrent to things like speeding in Canada (speeding while going at the same speed as traffic although is typically not enforced as speeding - i.e. normal speed on 401 is about 120 - 130 while the posted limit is 100....) Caught for speeding 16+km and you lose 3 points, insurance goes up... and if you repeat you have to go to an interview... and at 15.... poof goes your license.

It is not considered a currency -- or you would run afoul of other law.... and it is not a security otherwise they would have run afoul of reporting / tax regulations....

I write and speak similarly, but it is easy to misinterpret when I am writing to get offended by taking my often blunt way of arguing my ideas without a grain of salt. If they are able to see me and I them (their expressions) both they and I are able to communicate more effectively and avoid situations. To keep face to face meetings on point, hold them standing up and keep them short (figure out how long it will take beforehand and stick to it). Many short meetings are more productive than large long meetings. Unfortunately none of that is available to me these days since I work at home half a world away from the office. I would like the ability to hold videoconferencing calls (at peoples desk similar to using the phone with a camera) but the office is not very advanced. You could easily install a system that allows you to hold and archive video "standup" meetings these days if you want backup. The other alternative is to hold the short meeting, agree on what you can and summarize it in a short email after the fact (since it is just facts of the outcome it is no longer an argumentative situation).

Not an appeals court, that is several levels up. It may already be too late since you might be required to post a bond in the matter of 100s of millions of dollars while you are appealing - which in many cases force the company into settlement talks since that may not be affordable. There should be a specialized court which handles patent cases right at the beginning of the process. Decisions would still be able to be appealed through the appropriate channels.

WIth Nuclear, Hydro, gas and coal you generate the amount of electricity that you expect the demand to be. The only time I ever had a problem with this type of power in Toronto is when a grid failure shut down the nuclear reactors and they had to do a cold restart. A once in a lifetime event. Rolling blackouts like what you mentioned often come from the lack of investment in generating supplies for the growth in usage (in addition to peak demand due to heat waves etc.). That type of blackout does not happen except when you have mismanagement in the grid or if you make it impossible to build new generating capacity. When you talk about things like solar or wind -- your generation is not driven by demand.... you could have even a constant demand but if you have days without wind or a drop of 50%, or you need power at night when the sun goes down..... You still need generation capacity to fill that lack of power. People don't just cut back when the wind drops, they don't shut off all the lights at night..... they need a predictable amount of power. Solar and wind cannot produce that. You can build banks and banks of very expensive battery backup for when the grid fails (in my case locally it shuts off for 5 minutes every few days) if you are a company, but usually that is a stopgap measure that then for prolonged power outages switches over to gas generating backup generators (or some other fuel like that). This is the type of backup generating capacity for wind and solar - but no-one ever mentions it because it is a dirty little secret. They have mandates to buy power from home solar setups, they have to buy it whether there is a demand or not..... but there is no penalty if that same house which is on the grid fails to deliver power when people need it.... so there is a hidden subsidy of the grid supplier to buy backup power to supply both you and that house when the sun doesn't shine.

On top of the normal maintenance etc., the problem with the current crop of "renewable" energy is you cannot count on them producing enough energy when you actually need it. You may be able to count on a mean or average amount, but consumption is more of a constant. You have to have backup power (non-renewable) or very expensive storage systems to provide power when the wind dies down (or sun goes down, etc.) or you end up with rolling or regional blackouts when you don't have the power available. Those backup sources require maintenance and upkeep as well as the renewable energy.

When you hear puffery about how much the renewable energy will save - they tend to omit those backup plants etc. My father was given the option of "paying for" wind power in a coastal area or just the grid power.... when I mentioned that the electricity goes on the same grid and you don't get what you pay for (someone else might) and the cost of having someone else use the power that you are paying more for.... he opted for the normal power grid power. Without subsidies, it was more expensive.

They have to take the patent cases out of the regular court system where places like east texas can be used to load the dice. Maybe create a federal patent court that specializes in patent cases would do the job - so you cannot shop for the best venue. They also have to make the plaintiff pay court costs for failed lawsuits plus maybe 10% of the claimed damages which would be split between the defendant and the courts/government. They also have to tighten up what is patentable, and for the most part software should not be patentable - it should be copyrightable only. Anything that is used for interoperability (APIs, interfaces and languages should be excluded).

Refactoring does not necessarily mean superior code.... it depends on the coder doing the coding and the refactoring as well as many other factors such as the history of the source itself.

Refactoring is something you should think of whenever you revisit your code to make changes as you are developing. Can I do this better? I don't know many programmers that write something once and it is perfect. Sure you can come back to it and make some changes that are necessary and do no thinking about anything other than just hacking in a change to make it work.... but that leads to worse and worse code, longer development cycles to deal with the repercussions of aging unmaintainable code etc. People have to start thinking of their source code as a depreciable asset not as an investment. A good percentage (depending on technology and industry the software is written for) of the cost of developing the system should be written off each year, and you require a certain amount of additional investment just in upkeep.

Of course to be able to properly refactor, your system cannot be a fragile system (lacks unit tests). If it is then refactoring may cause more problems than it solves. To properly refactor, you really need to have taken the time to write a full slate of unit tests as you were developing the system. This allows developers to be able to focus on the changes and be reasonable assured that if the tests say everything works, that the changes have not caused problems elsewhere in the system. If someone tries to measure refactoring as separate from all of the other good practices - you won't necessarily be able to measure much difference....

If he were returning home (seriously) and not just messing around, all he has to do is come to some agreement on the charges and venue of the trial before arriving back in the US. That is all that is available to him, and the only guarantees that he get. There are plenty of high-power lawyers from prestigious law firms that would handle his case pro-bono because of the exposure, the courts are the courts and they are not going to make changes to them just for him..... the only issue is what the charges would be.... which would be very serious no matter what.

"Cfront was a compiler that compiled early C++ to C"

"A preprocessor is a program that processes its input data to produce output that is used as input to another program. The output is said to be a preprocessed form of the input data, which is often used by some subsequent programs like compilers."

It is a preprocessor. It might be an advanced one, but it is still a preprocessor.

What???? As far as I was aware... Swift is language which depends on LLVM (which is not a virtual machine as in jvm). This is the same as Objective-C which is now compiled using Clang (many many years since gcc was replaced with clang). LLVM is just a pseudo assembly language which is compiled down to machine code. It is not a virtual machine. It is compiled down just like Objective-C. When using the REPL or as with Objective-C when it is being run inside xcode I believe it is in jit form, but this is no different than Objective-C.

You have your history mixed up. They are different directions from the same root language, but Objective C is not a "superset" of C++. C++ (preprocessor for C) started as C with Classes. Objective C was originally a preprocessor for C which tried to patch in Smalltalk ideas ontop of C. One is not a superset of the other... but they both have the same C roots. It is not much different than having all the different languages compile down onto the jvm, they are not supersets or subsets of each other - they just use the jvm. It provides a transportable platform onto which to compile/run the "compiled code". Creating preprocessors on top of C gave similar advantages to both of these "new languages".

Yes, Apple has millions of lines of code and yes Apple is not going to re-write all that code in the next couple of years.... but there is no denying that Swift is more productive than Objective-C easier to maintain. Apple is not going to say, Objective-C is dead but it is now very much a "legacy language" where you maintain the code but new stuff will be written in Swift. Swift though is a new language and it still has maturing to do. Being that Apple is both the user and creator of the language, most if not all that Swift may not be "able to handle" right now will eventually be added. If there is something that for performance reasons is not there yet - it can still be written in Objective-C and used in a Swift project.

If you are developing for the Mac OS X or iOS platforms - you would chose Swift from this point going forward. You would maintain your legacy Objective-C code until the point where it makes sense both business and risk-wise to rewrite it as part of some upgrade. As far as Linux, Apple has made no commitment (yet) on when/if they will open-source / multi-platform it so it is moot for the purposes of the OP. To be quite honest the original requirements for the OP seems to be centered around that he missed out on some fad/direction and now is asking what he should pick-up but only wants to use "classic" languages, but without any real clear reason on what his "needs" are. This is backwards. Languages are tools, you don't pick a tool first. It would be akin to picking a hammer then turning and saying, good... got that out of the way.... now I think I will fix my watch.

Also some people have already had noticeable lag on the screen for the update of the mouse position when using 4K monitors at 30hz (caused by double-buffering in combination with low refresh rates) - now increase the latency and that would cause people to complain that it is unusable.