Yahoo Excludes BlackBerry From Employee Smartphone List 192
Nerval's Lobster writes "Freshly minted Yahoo CEO Marissa Mayer is promising the company's U.S. employees a new smartphone of their choice. There's just one catch: it can't be a BlackBerry. According to Business Insider, which posted significant portions of Mayer's memo, employees will have a choice of the Samsung Galaxy S3, HTC One X, HTC EVO 4G LTE, Nokia Lumia 920, or the upcoming iPhone 5. 'We'd like our employees to have devices similar to our users, so we can think and work as the majority of our users do,' she wrote, adding that Yahoo will shift away from BlackBerry as its corporate device of choice. Somewhere up in Waterloo, at least one Research In Motion executive could be screaming in frustration over this development. Not because Yahoo is a bellwether for corporate smartphone use; its U.S. employees shifting to an iOS, Windows Phone or Android device won't automatically drive other major companies will follow suit. But as a symbol of RIM's current issues, it's difficult to find a better one than a high-profile technology company dumping its collective BlackBerry stock in favor of pretty much any other platform."
Re:No real keyboards? (Score:4, Informative)
Perhaps you don't realize, but the physical keys are roughly the same size as the on-screen ones.
Being able to feel the keys (and press down on only the one you want) is a huge difference. Maybe when touch screens get haptic feedback, they'll catch up. But until then, on devices smaller than tablet size, a physical keyboard is the only good option for me.
Good (Score:0, Informative)
Good news. As someone whose IT department supports BlackBerries, this trend can't spread fast enough. No offense to RIM but blackberries should have died out many years ago - and not that I like apple or droid so much, but they should have killed the BB off for corporate use. BlackBerries are terrible phones with inconsistent UIs, no slide out keyboards, changing usb cords, and are overly secure, nor does anyone who has one know how to use it.
Re:Nokia Lumia 920 (Score:5, Informative)
With a comparison like that, I guess there would no differences between C, C++, JavaScript, Objective C.
A few differences copied from a Stackoverflow post:
Generics are completely different between the two; Java generics are just a compile-time "trick" (but a useful one at that). In C# and .NET generics are maintained at execution time too, and work for value types as well as reference types, keeping the appropriate efficiency (e.g. a List as a byte[] backing it, rather than an array of boxed bytes.) .NET in general) than Java's JNI .NET is a more transparent affair, with a reference type being created for boxing by the CLR for any value type.
C# doesn't have checked exceptions
Java doesn't allow the creation of user-defined value types
Java doesn't have operator and conversion overloading
Java doesn't have iterator blocks for simple implemetation of iterators
Java doesn't have anything like LINQ
Partly due to not having delegates, Java doesn't have anything quite like anonymous methods and lambda expressions. Anonymous inner classes usually fill these roles, but clunkily.
Java doesn't have expression trees
C# doesn't have anonymous inner classes
C# doesn't have Java's inner classes at all, in fact - all nested classes in C# are like Java's static nested classes
Java doesn't have static classes (which don't have any instance constructors, and can't be used for variables, parameters etc)
Java doesn't have any equivalent to the C# 3.0 anonymous types
Java doesn't have implicitly typed local variables
Java doesn't have extension methods
Java doesn't have object and collection initializer expressions
The access modifiers are somewhat different - in Java there's (currently) no direct equivalent of an assembly, so no idea of "internal" visibility; in C# there's no equivalent to the "default" visibility in Java which takes account of namespace (and inheritance)
The order of initialization in Java and C# is subtly different (C# executes variable initializers before the chained call to the base type's constructor)
Java doesn't have an equivalent of the using statement for simplified try/finally handling of resources
Java doesn't have properties as part of the language; they're a convention of get/set/is methods
Java doesn't have the equivalent of "unsafe" code
Interop is easier in C# (and
Java and C# have somewhat different ideas of enums. Java's are much more object-oriented.
Java has no preprocessor directives (#define, #if etc in C#).
Java has no equivalent of C#'s ref and out for passing parameters by reference
Java has no equivalent of partial types
C# interfaces cannot declare fields
Java has no unsigned integer types
Java has no language support for a decimal type. (java.math.BigDecimal provides something like System.Decimal - with differences - but there's no language support)
Java has no equivalent of nullable value types
Boxing in Java uses predefined (but "normal") reference types with particular operations on them. Boxing in C# and
This is not exhaustive, but it covers everything I can think of off-hand.
Nice! (Score:2, Informative)
I wish I worked at a tech company that would do something like that for it's employees, although granted it is a work phone though... *shrugs*
I think RIM seriously needs to rethink their strategy when it comes to users and business which to them have been one and the same. Except while their infrastructure might have been the "bees knees" 5-10 years ago, it's old and unreliable to most of what people use today. for instance my parents used blackberries (despite my constant objections) up until their last phone upgrade a little less than 1 year ago. The Blackberry storms or storm 2's or something like that I think they had. Always having problems, screen popping out of the device (well that's a unit defect, but it happened more than once, even on replacements). Emails and texts not appearing for hours or even a day+ later, despite having a perfect signal. That was I believe due to RIMS network and not the carriers. Rim kinda does their own thing with your emails and texts and then sends them over to your carrier who sends them to your phone.. or that's how I thought it was.
That isn't much different from Google in a way, except Google actually works, and works very very well. If someone sends me a text or email and I have a usable data signal (doesn't need to be a perfect signal 3g or 4g) it will show up almost instantly on my phone or tablet or whatever I'm using. Rim.. I could text my parents and not get a response the entire day, go home and be like WTF didn't you respond and DING... there is my 12 hour old message finally arriving in their inbox, NOT COOL. and not a one off thing, this was a fairly common occurrence.
Then if you needed to fix anything on those damned things, good luck. They had clunky awful interfaces and ui's (especially compared to android phones and even the Iphones we have now. Trying to find the setting for some trivial little thing ended up turning into a test of patience and deciding whether or not to throw it through a wall. Everytime I have to touch one and see that god awful clickable screen... not like most new phones where you tap it to click.. i mean the screen was a damn button literally.. I cringe. Add to that it's closed source and who knows what Rim does on their network with your data or information you send through it's network and the fact that it can't run the majority of things out there, unless you love the $$$ verizon apps you could buy (unless rim has some new app market? anything better than what we already have with Google or apple or any 3rd party app stores, like on android? )?
I think this is something the company is doing right and I think a lot more companies need to take note and dump rim as well. RIM really needs to come out with something new and exciting instead of using the same old same old it always has.
Re:Nokia Lumia 920 (Score:5, Informative)
Oh, let's see.
Proper anonymous functions, including lambdas.
Proper function pointers (called delegates) without needing to write entire classes for them.
Support for stack-allocated complex types (structs).
Support for bi-directional and output parameters, even of types normally passed by value.
Unsigned integer types.
Object parameters (technically functions, but cleaner than a bunch of Get*and Set* function definitions and usages).
Proper generics (try declaring an array of generic type in Java, for example).
Easy interop with native code (P/Invoke, good marshaling capabilities, support for ordered structs and unsigned types, etc.).
Support for direct memory access (if you want/need it; use the unsafe keyword and byte* or similar types).
LINQ.
Tuples.
No one-public-class-per-source-file restriction, or the associated restriction on file name.
No restriction on project directory structure.
Partial classes (allows separating parts of the same class, such as autogenerated code from developer code, into different files).
The using keyword (in both of its uses).
Conditional compilation (similar to C preprocessor) to do things like exclude debug code without any overhead at all.
These are the ones that came to mind in just a few minutes of thinking about it, based on personal experiences, I'm sure there's a ton more. C# is a vastly more advanced language than Java. I don't deny that MS learned heavily from Java, but half of that learning was "let's not repeat their mistakes" and the other half was "what is it really lame that this language lacks? Let's do better."