Stanford only changed the font of the wordmark, not the S or the S-and-tree or the seal. I, for one, welcome our new wordmark. It's a pretty inoffensive change, compared to the lolfest that is the "perpetually loading" new UC logo.
Anyone has a good summary of Scala vs Go? I know a bit of the former (with typeface for high-concurrency) and was wondering what Go might have to offer.
Go is far simpler and smaller. You can learn go in an evening. It comes with a nice standard library, but the ecosystem isn't as lively as what you get on JVM. But if you have native library for a task, using it from Go is straight forward. Web frameworks are in their infancy. Writing network programs in Go is a pleasure. You write code in the natural way(no callback spaghetti) using go-routines, and go takes care of making it non-blocking. The go oop is structural sub-typing based. Though it might seem lacking at first glance, it's actually quite wonderful.
Bottom line: Learning go is far simpler than learning Scala. Read and write some programs, and make up your mind. Here is an example you should read through to get a feel of the language.
Yeah, I like modern languages that don't need an IDE or other complicated mechanisms to get started. Go seems to have made a lot of good design choices too.
Scala takes more time to learn, but targets a different audience. Scala runs on the JVM which lets you leverage Java libraries etc. For long-running apps Scala is usually faster than Go, but will use more memory than Go.
Well, both have good support for concurrency through Actor implementations. They have a little bit similar syntax, both have a basic level of type inference. After that, pretty much everything is different about them.
There are really too many differences to consider, but some things come to mind first. I apologize for the problems in this description. At some point I may write a detailed article with examples, so any feedback on inaccuracies in this would be helpful.
Go is designed as a minimalist language. This has some benefits and drawbacks.
Scala is design as a language that is small but very extensible, making for a much larger programming system that you have to learn to use effectively.
Scala has lots of advanced language features from functional programming. Idiomatic Scala uses these features extensively. Go has closures, but not any other features for functional programming - for example it has no immutable data structures, no pattern matching, no tail optimization.
Scala has advanced features from object-oriented programming; everything is an object but basic types are compiled to JVM primitives where possible. It has traits/mixins which provides a way to implement multiple interfaces but they can also provide implementations which makes it a lot easier to provide default implementations so that a previously-written class can be declared with that Trait even though it does not know how to satisfy the interface. Go has a simplified and in some respects novel approach to OOP. It has interfaces and duck-typing which may be familiar but you really have to learn "the Go way" to understand what is happening with features like embedding which may seem to have some superficial similarity to inheritance in Java/C#.
Both provide a means to multi-plex Actors (Goroutines) onto threads. Using the Akka package with Scala provides an Actors implementation which will work with both in-process and out-of-process Actors. Google's netchan package was dropped before 1.0 and I do not know if there is any productive development being done in this direction. So to scale goroutines out of a single-process you'd need to use RPC, zmq or some other low-level socket approach.
So far, the Scala code I've looked at in different open-source projects seems fairly consistent. While the language-space seems big, I have not seen the fragmentation problems that some people may have predicted. With Go there is little chance of this, often there is only one reasonable way to do a given thing.
Go compiles to native code but the compilers are optimized for very fast compile times - the code produced is 2-3x slower than Scala in doing math-intensive benchmarks. For most apps we'd actually write, I'll bet they are pretty close. Go statically links a runtime and has garbage collection. It starts up VERY fast compared to any JVM application.
I think it's a bit off on the predictions relating to energy. The best way to explain why is to borrow from Vinod Khosla's theory of energy black swans, and assume that the forms of energy we know and make use of today are going to be replaced by forms of energy we either don't know of or haven't yet managed to master.
500 years is simply a long, long, long time from now in terms of human progress. I think the energy description provided here might possibly fit a model of our energy mix 100 years from now. However, it's very unlikely to be the one we follow 500 years from now, simply because the basis for energy-related discoveries dictates that every few decades an entirely new form of energy is discovered and gets subsequently iterated upon until economically viable. It simply isn't factually reasonable to assume that we have already discovered all possible forms of energy production.
By the way, i did energy-related research which is why i wanted to point this out. Regardless of these flaws, I thoroughly enjoyed reading that essay.
tl;dr: energy-predictions 500 years out are not reasonable because of Vinod Khosla's theory of energy black swans.
The initial mobius.io device has 16 general purpose I/O lines, several serial ports, and analog in, so it is much more flexible than Nest. As for Android@Home, mobius also has its own cloud service, so you don't need to worry about infrastructure. What we would like to do is to have the same functionality of something like NI USB-6009 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/201987) without the computer. And we also have LabVIEW drivers for our device. So you can automate things in your business/home from anywhere using JS/LabVIEW/HTTP GET if you wanted to.
Just to be clear, he's not "leaving." He got fired. He got fired because after the map fiasco became apparent, he refused to send out an apology or sign his name to the one Tim Cook sent. (internal knowledge)
I'm surprised he got fired over maps. Mapping is hard - comparable to writing a search engine. Apple did as well as can be expected for a first attempt. They had some kind of problem with Google Maps, and wanted to build their own capability, which was never going to be easy.
He might have been fired if he cheated, by creating a well curated Valley dataset to prove to the other execs what a great job he'd done. That would annoy people.
I've heard rumors that he was seen as "better managing up than down" (impressing his boss, at the expense of results), and that doesn't strike me as something Tim Cook would like very much (both from his reported management style, and the number of stock options he has). I can see that being a last straw from Tim - "You screwed up, now own up to it. Or else."
> I'm surprised he got fired over maps. Mapping is hard - comparable to writing a search engine. Apple did as well as can be expected for a first attempt.
The problem is that they released that first attempt. iPhone and iPad weren't their first attempts at phones and tablet computers, they were simply the first ones good enough to take to market.
There are ways of dealing with hard problems- managing scope, managing expectations. I'm not too surprised he was fired for not executing. Remember Papermaster and the antenna?
Mapping is very hard, and he shipped it before it was ready. That was a pretty bad event for them; caused lot of negativity from users. I'm not surprised.
I learned a long time ago honesty and taking ownership is the best policy.
It possible that he though he did no wrong. Or maybe he thought he was above the fray. But if he wanted to save his job, owning the wrong is the best way. People forgive when the apology is genuine.
While it hasn't seemed to have an appreciable affect on sales or the stock price, the shortcomings of the new Maps have been an embarrassing PR mess for Apple and a hit to its reputation for uncompromising quality that sets it so far apart from everyone else.
It does not surprise that he's being fired for this or that his departure is going to be transitional since he's so intricately involved with so many central aspects and initiatives at the company.
Mapping is NOT hard. I know from personal experience.
The reason Apple screwed up maps is because of one reason and one reason only. Licensing. The app itself is great. The 3D maps are great. The data is the problem.
Apple chose not to license data from many of the key players they should have to at least be competitive. My guess is Apple arrogantly thought they could get enough feedback from users to fix up the problem themselves.
A basic map application just requires data, projections (which is a solved problem, if a little tedious), and a rendering system. Path finding is also basically solved (it's Algorithms 101, though you need something a bit more sophisticated to make it scale). A basic mapping app can be hacked up in a week. A good mapping app is obviously much harder, but it's still doable.
But like taligent said, it's data that's the real problem. Mapping data tends to be dirty and heterogeneous. Do you have a point, or a polygon? You're in trouble if you just have a street address (geocoding can be very hit and miss). Metadata (like the projection) can be missing. Locations can be slightly wrong, and you'll draw a highway running through a shopping mall, or connect streets which don't quite connect, or have gaps in a street because it changes street names and there's a tiny gap between the two streets (which doesn't exist in the real world). How do you normalise the field names? How do you even get the data? Once you've got everything into your database, you move onto the next city / state / country.
Lets see if I understand you right. Mapping is not hard. You just have to get good data. Getting good data is hard though. And getting good data is part of doing Mapping. So basically you said Mapping wasn't hard and then said that a crucial part of Mapping was really hard.
All of which is a roundabout way of contradicting? yourself.
This answers my point better. The fact is that many of these mapping companies that even Google still licenses to this day have been driving around countries in some cases for decades.
That is the real hard part. Trying to obtain all that data. Because every mistake is potentially one person complaining loudly on the internet.
OK, but that's like saying, "Defeating the aliens is NOT hard... The biological vulnerabilities of human DNA are the problem... you just have to be impervious to ionizing radiation."
Much like machine translation and teledildonics, once you start to try to scale globally, mapping is actually one of the hardest problems that is remotely viable at our current technological level. There's a tiny handful of companies that can do a barely usable job, and everything else is worthless garbage.
In Japan, at least, Apple has gone from the former to the latter with iOS 6. (Maps.app did work great last week on a business trip to Austin, TX, however.)
This makes me wonder - who at Apple decided it was necessary to make their own maps app?
It's easy to blame Forstall for a crappy product. But if someone else was responsible for mandating the change, assigning him the project, and pushing an impossible deadline, maybe it's more their fault.
It was a decision that was forced by a number of factors. Google wouldn't agree to providing directions for turn-by-turn navigation, so Apple had to seek other solutions.
"Jobs tells the VP that if the garbage in his office is not being emptied regularly for some reason, he would ask the janitor what the problem is. The janitor could reasonably respond by saying, "Well, the lock on the door was changed, and I couldn't get a key."
It's an irritation for Jobs, but it's an understandable excuse for why the janitor couldn't do his job. As a janitor, he's allowed to have excuses.
"When you're the janitor, reasons matter," Jobs tells newly minted VPs, according to Lashinsky.
"Somewhere between the janitor and the CEO, reasons stop mattering," says Jobs, adding, that Rubicon is "crossed when you become a VP."
Scuttlebutt is that it was an executive-wide decision based on the coming renegotiation of their 5 year agreement with Google regarding Maps. Google has been letting iOS maps lag behind Android maps (e.g., Android has turn-by-turn navigation, iOS maps didn't), so Apple was understandably not excited about renewing that agreement, and leaving themselves very vulnerable to one of their biggest competitors. But they didn't have something comparable, so they pushed a weak maps app early to catch Google off-guard--and they did. Google didn't have an app ready in the app store to replace the one they lost in the OS.
That's my synthesis of the analysis of a bunch of Apple watchers, so take it with a bowl of salt. But it makes sense to me.
It seemed obvious that his back-to-back failures with Siri + Maps and the fact that lots of people inside Apple hated him were the reason for this, but it was impossible to know for certain without somebody inside taking a risk and saying that.
Care to speculate on who would be next in line to be CEO now? That was presumably Forstall. Now it would be Cue or Ive or...?
Jury's still out at this point[1], but this certainly makes me optimistic. Or, at the very least, intensely interested in what this new arrangement will yield.
[1] He seems to certainly not be a bad CEO if we're talking about the set {All CEOs}. But you'd have to be really really good to not look awful if you're following Jobs.
I don't know if anyone ever doubted Tim Cook as a good/credible CEO. The only issue is whether or not he can be jobs-level which is unlikely but remains to be seen.
material scientist here. I've worked on carbon nanotubes (cnt if you want to sound cool) for a few years. Looking at them under the electron microscope, I've always wondered how in the hell we'd ever line them up without having to recourse to nano-tweezers (which of course is impractical if you want to scale to a few billion switches). Looks like IBM finally cracked a decent technique (though I suppose the device yield isn't that great), and it hopefully will be a path toward production. What would be really cool is if we can find economically-viable application for carbon nanotubes outside of semi-conductors. The biggest problem right now is their cost (~$400/gram for good purity [for reference: 20X the price of gold]) and the fact that platinum is used as a destructive catalyst to make them.
Ah, good catch! I remember a while back comparing CNT prices per gram versus gold and it was something like $20 a gram for gold. Must have been a low then. Thanks for catching it.
Well, right now their yield is only 70% of the transistors, so effectively 0 for chips. Improving that is probably the biggest research breakthrough still remaining.
http://www.stanforddaily.com/2012/11/15/1073130/