Sort of crazy to me that the budget for SF is $9B. Boston, which is around 200k people smaller, has a budget of <3B, which seems like a huge gap. What kind of services does SF provide that a pretty comparable city like Boston doesn't?
One example, public safety is almost 3 times more expensive. It looks like social services is also about 3 times higher. On a per capita basis, it looks like SF actually pays less for transportation. But since the budgets are broken down by different categories, it's kind of hard to tell. I'd need to do more research.
Scala Some is a box (i.e. it takes up 8 bytes on top of whatever's in it). It would be nice to represent Some(x) as just the value x (at the Java bytecode level) and None as null. The problem with that is that if you have an Option[Option[A]] you can't tell the difference between None and Some(None) (which might be semantically important), and whatever you do to solve this your Option is no longer generic and behaves in different ways depending on what's inside it, which is a disaster for being able to understand and reason about code.
Kotlin treats nullability as an ad-hoc special case. This allows them to save those 8 bytes occasionally, but it means you simply can't handle optionality generically (in Scala you can write methods that will work generically with Option and also with other cases, e.g. "sequence" does the same thing when you call it on a List[Option[Int]] or a List[Future[Int]] or a List[Writer[String, Int]] or... and it all makes sense, because Option is just another plain old type in the language). IMO that's the wrong tradeoff for almost all use cases, but evidently the Kotlin folk disagree.
• 4 bytes to point to it, unless you need a big heap and OOP compression isn't usable, in which case it's 8 just on the pointer.
• Either 4 or 8 bytes of mark word, depending again on 32 vs 64 bit mode.
• Either 4 or 8 bytes of class pointer, ditto.
• Then another 4 or 8 bytes for the pointer inside the box.
• GC algorithms impose some additional overhead too.
That's hoping there's no alignment padding going on.
If the JVM supported real value types, then a lot of this overhead would boil away, but not always all of it.
When you use Option[] as a local variable or as a return type of a method, then HotSpot can sometimes optimise it out using escape analysis. Unfortunately the escape analysis in the C2 compiler is quite conservative and can often fail. The Graal compiler has a different design for its escape analysis and can remove the overhead a lot more often. Graal does show better speedups on Scala code than on Java code:
The ability to nest optionalities is not something I've wanted to do so far, whereas the ability to freely represent optionality without having to worry about cost is quite freeing. I think Kotlin has the right tradeoff here, especially as in the rare cases where you do want the ability to represent Optional<Optional<T>> you can just use the Optional class from the Java 8 standard library to do so.
I very rarely want to explicitly use an Optional<Optional<T>>. But every day I write code that works with a generic Option[A] and I want to not have to worry about what happens if someone calls it with A=Option[B]. I also frequently use Option as a parameter to some other datastructure like Kleisli or WriterT, which only works because it's an ordinary datatype that behaves like any other.
You say "you can just use the Optional class from the Java 8 standard library", but as far as I can see porting code that was written to use nullables would be a pretty big refactor, and there's no way at all to write generic code that works with both, so you'd end up having to maintain two parallel copies of your common functions.
Efforts to improve the performance of Option are of course to be applauded, but for a lot of use cases we're talking about the difference between (say) 50x faster than Ruby and 40x faster than Ruby. Scala is more than fast enough for a huge range of use cases; I don't think I've ever seen someone port code off Scala because the runtime performance wasn't good enough.
Honestly, I'm starting to feel like the lack of comments from European leaders about the infringement of non-American's data might be because they know they might be the next to get caught with their hands in the honey pot. I can't tell if I'm just starting to be part of the tin-foil hat crowd though.
What is a good resource for understanding the DOM/query selectors and their performance (JS and CSS selectors)? All that I know about it is just through word of mouth and it would be great to look at a resource that covers these things.
Also, is document.createElement('div') really much faster than $("<div></div>")? Just checked and a lot of well-respected JS libs use (including Backbone) use the jQuery version.
There are good talks by the Chrome dev team from various GoogleIO's. CSS selectors used to have a lot of voodoo about them but no longer matter that much in terms of performance.
Try the blog of one Paul Irish and spread out from there.
> but no longer matter that much in terms of performance
That's not quite true. They matter enough that WebKit is implementing them incorrectly because they can't figure out how to make a correct implementation performant enough...
The normalisation is purely to support older browsers though. Backbone doesn't really use that much of jQuery, have a search for 'Backbone.$' through the annotated source [1]. There are only 10 uses of it in the whole file, and not for anything too crazy. In modern browsers you could probably do away with jQuery and still avoid "if safari then...".
Recently decided to use Backbone as a JSMVC Framework on my team. Although I looked at Ember and Angular, which obviously both have many more features than backbone out of the box, We chose to use Backbone because it seems to have such a large and vibrant community behind it - seems like angular and ember are both lacking in this respect.
However, as our Backbone application grew in complexity, we noticed that Backbone is so bare in terms of functionalities that we had to build our own half-baked framework on top of
it to make up for the gaps.
I think the Backbone project needs to make Backbone's intentional feature sparseness clear. I've come to realize that backbone is more of a library which provides a basis to make a client-side framework rather than a something that can be used standalone by app developers.
If I could go back and change our original choice, I definitely would have gone with one of the Backbone-derived frameworks (chaplin, marionette) or just gone with something more fully-featured like angular. While backbone is beautiful and elegant for small projects, it just doesn't provide much convenience as a stand-alone library for larger applications.
I have found the Angularjs community to be thriving and most helpful. Check out their google group (1), g+ page (2), g+ community (3), irc room (4) and youtube channel (5) for an excellent place to get help. I usually get help as soon as I need it, amazing.
Also I have been impressed with the active community projects AngularStrap (6) and AngularUI (7)
We recently faced a similar decision, and ultimately went with angular - the two-way binding sold it for me, plus the concept of pushing all DOM manipulation into directives (declared in the HTML), to get that out of the controllers. We've spent ~8 weeks using it: our codebase is smaller, easier to mantain/adapt, and better modularized -- we love angular. The docs are great, and the IRC community is there when you hit something quirky.
I always said it, Backbone is not a JSMVC Framework; It's a JSMVC Framework Framework (How to go meta!) Basically, it's a solid foundation to create a JSMVC Framework.
