The Apple Watch has accelerometers which make it a far more effective way to detect masturbation, and then track and plot graphs of masturbation efficiency. Social network features can allow the sharing and aggregation of these vital statistics. Apple's patents for this particular use of technology won't affect Android users, who have no need to detect masturbation.

This year, Apple will introduce an app for Apple Watch to track and produce graphs of masturbation efficiency. The app will have social network features allowing the sharing and aggregation of these vital statistics. Android users will have no need for such an app. Then in 2016, Apple will ban its own app for violating unwritten parts of Apple's TOS. In 2017, Microsoft will copy Apple's now banned app hoping to attract users fleeing Apple because of the removal of such an important application from the iTunes store.

You seem to believe that incorrectly perceived cost savings of outsourcing programming is unique to the Java language.

Several things can make your job more secure. Be excellent at what you do. Irreplaceable. Be the source of all leading edge knowledge. Be the one management comes to when they first hear of the new buzzword of the month. Don't focus on the tasks that interchangeable programming drones can do. Management loves interchangeable drones, and partly for the reason you describe. Identify and solve the really hard problems that others won't look at. Be willing to do some of the interchangeable tasks. The value you bring should exceed your coworkers. This should be reflected in your performance reviews. If it were easy, everyone would do it.

But MS never came up with a "bundle" concept like OS X (I think it was in 9 as well) that presents a folder as through it were a single application

This idea was present in RISCOS long before Apple came up with it.

Java has great free and Free development tools like Eclipse and NetBeans. You can also get the community edition of IntelliJ, or a paid edition.

Java, and its development tools, run on every desktop: Mac, Linux, Windows.

If you know Java, then you've already got a leg up on doing Android development; and doubly so if you use Eclipse or IntelliJ.

If you want to develop complex web applications, then Java is the way to go. You can write a large web application in a dynamic language, but maintenance will become a long term problem in a gigantic code base. There is a reason that Java is used for very large websites. (Not to confuse large with high traffic.)

Java is used in high speed trading.

Java is used in the SIM card of your phone. Your bluray player.

Once you are familiar with running Java on the JVM (Java Virtual Machine) you'll discover that there are dozens of other languages that run on the JVM with complete interoperability with other JVM languages. This is because of the common runtime and type system, and because of GC. With GC in the underlying runtime, the entire contract of who is responsible to dispose of what goes away. Did this library create that data structure? Maybe, but nobody has any responsibility to keep track of it and dispose of it.

The JVM is an industrial strength platform. You can have heap sizes of dozens or hundreds of gigabytes. With a dozen gigabytes you can have GC pause times under 10 ms with little to no tuning. If you need hundreds of gigabytes in a single heap with 10 ms GC times, then contact Azul systems who can sell you their Zing JVM. Which brings up the fact that JVMs (like everything in the Java world) has multiple vendors. Don't want to run Tomcat, then use Jetty, or one of several other choices.

Your favorite language compiler emits JVM bytecode which the JVM compiles into native code. It has an extremely aggressive global optimizer. The JVM compiler can optimize globally, something that compilers like GCC cannot do. The JVM can inline other methods into YOUR method. But the JVM can also dynamically reload classes. So what happens if class A is reloaded, but your method now has stale inlined code from Class A? The JVM will de-optimize your method so it is back to running as interpreted JVM bytecode. Now if your method (still) is one of the CPU hotspots, then the JVM will re-compile your method back to native code again. The overall application never stops. The only methods that get compiled to native code are the ones that dynamic profiling proves to be ones that would make a difference to aggressively compile. Call me when you other language runtime can do all that.

Java is where the jobs are. Look for yourself.

There is much more. But I'll stop.

When the only hammer you have is C++, every problem begins to look like a thumb.

No need for UTF-64. You could double the huge space of UTF-32 by just introducing UTF-33. Unlike UTF-8 or UTF-16 there would be no unpredictable memory allocation problems. Every character would get a nice clean 33 bits. Be sure to bitshift and pack characters so that no memory is wasted. That should make the world a wonderful place and everyone will be happy.

Masochists use code pages from Microsoft.

Hopefully we'll find out eventually.

I think you are missing the application for an Open gate array.

It is not really for you and your company. You don't have any particular interest in the open part, and thus you and your company don't fit the demographic of the sort of user we would want. We don't need your money. I can do the first runs of this using Mosis and its ilk for chump change, and go from there.

It simply doesn't matter if it's 32 nm or 15 nm or 50 nm. What matters is that the user can completely understand the bitstream and produce their own tools for it. We have no shortage of users who want that.

It doesn't matter if it is on the leading edge in terms of cost, speed, power, thermal efficiency, or size. It matters that it's open.

And maybe we can do something that you can't do with any integrated circuit available to you, which is verify from first principles that the manufactured device is without deliberately hidden security back-doors. Because we don't have intellectual property to hide and thus we don't mind producing it in a way that would make it capable of being examined.

So, I am not particularly worried about what foundry I'll use and whether I can compete on the same playing field as Xylinx and Altera. I have my own playing field, with radically different rules from the ones they are using. I have my own customers to satisfy.

One well-known market would be immediately available and very eager to embrace an open FPGA, namely EE education.

Yes. EE education and academic research.

There is also the security problem. How can you determine from first principles that the chip really contains what it says it does? Insoluble with any commercial component. Maybe we could make ours sufficiently visible.

So, my feeling is that we could get a grant for this.

There's a partial list of fabs at Wikipedia. There are more than just those three.

Sure, process optimization per fab is an issue. We would probably need to start on the very conservative side.

A lot of the time, building a custom ASIC rather than using an FPGA just isn't an option. Most of the products I'm concerned with need to be programmable.

David Rowe makes a point about echo cancellers and voice codecs, which he's written in Open Source, working alone. They were supposed to be magic. They were supposed to take big expensive research labs to make. When he actually got down to the work, he found there wasn't really magic there. Codec2 can get clear speech into 1200 Baud, and OSLEC (the echo canceler) is part of every Asterisk system and other digital telephony platforms.

Steve Jobs also told me this when I was leaving Pixar. He didn't believe that the Linux guys could make a decent window system, because it had taken a Billion dollar research lab at Apple. Two years later he unveiled Safari, which was derivative of KDE.

There is no question that we can make a good gate array. The technology is very well known. Can we make one that is on the absolute leading edge of the technology? We don't really have to. Making a good one that was open would be enough. But maybe we can make a great one. That depends upon what makes it great. We have a collaborative advantage as far as the software tools are concerned, the same as with compilers. Can we design a really good logic element and fabric? Probably. Can we prototype a gate-array in a gate-array? Sure! Can we use the various devices that OpenCores has developed? I don't think there would be a problem. So we could have on-chip peripherals, CPUs, etc. Once we're sure of it, can it be well-tuned to a fab? Probably, but even if we are conservative about using the fab's capabilities it would work.

Yes. And looking at the way things have gone previously in JEDEC, we would have to be very aware of manufacturers desire to embed their patents in standards.

Enderman only steal a limited amount of block types. Coal, ores and paper are not amongst those.

Or so I guess. ;)