41–50 of 125 posts
Earlier quoted context omitted.
Why is C#'s OOP disappointing to Smalltalk guys?
Well, off the top of my head C# doesn't support mixins or multiple inheritance. You can get around the lack of mixins with extension methods and tight scoping but it's messy.
I was not aware that Smalltalk provided either.
The vast majority of the code in most apps is not core code, it's display code. That's STILL entirely device specific. I think the C# advocates oversell how much it is reusable If you STARTED with a great pile of C# code, say, running on the desktop or server, then wanted to port that to an iOS device, then you have a point. One big problem with non-native code is that example code is almost always written in native…
That's actually not what we see with our customers and their apps. Here is a real-world example of code sharing percentages for an iOS, Android, and Mac app written in C#: http://lipsky.me/blog/2012/9/11/touchdraw-code-reuse-updated And here is another one across iOS, Android, Mac, and Windows, also in C#: http://praeclarum.org/post/31799384896/icircuit-code-reuse-t... Both of these apps are using 100% _native widget…
Additionally, you really want "Time spent per area", which is very different from LOC in some cases.
But thanks for showing real data for named projects. Mine is from some LOC counts on customer projects (and not directly sharable), and from Mono____ advocates in the Atlanta iOS group.
Earlier quoted context omitted.
Xamarin's examples for MonoDroid are (IMHO) pretty solid, to the point where I'll go to them first instead of the Android docs (even though I'm writing Java[0]). It's true you have to re-write the UI code on every platform, but it's still the same language on all platforms, so less of a barrier vs. a total ground-up rewrite. Frankly, I see that as a plus, else you end up with badly cloned iOS-like UIs everywhere. [0]…
I've looked at MonoDroid as I really hated Appcellerator when I tried titanium, and the default Android toolchain is painful. I too was worried about the accidentally importing iPhone UI into Android. Any tips on avoiding it?
As I said, you have to write separate UI on each platform, and you use the native toolkits (there's no fancy abstract cross-platform UI kit in Mono), so there's little chance of looking much out of place as long as you follow local conventions. It bewilders me to see native Android apps going out of their way to clone iOS widgets and stylings. Not as common lately though; you see it more in usage of PhoneGap and similar, since there's nothing stopping you from shipping an iOS-like CSS on Android.
PS: In the case of Android, I'd flip through [0], and check out Google's apps on a proper device to get the lay of the land.
Sigh . Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection…
Earlier quoted context omitted.
Yes, but it's not specific to LINQ or MS or C# We are specifically talking about C#. LINQ was specifically held as one of the improvements to the language. I am not quite sure what your point is relative to that. There are shockingly few examples where LINQ is superior to alternatives. LINQ is the brute force technique of avoiding proper collections/algorithms.
I don't understand. Are you saying that map, filter, reduce and al. on lazy sequences in functional languages are inferior to loops, or that Python list comprehensions and generators are inferior to loops? That's basically LINQ to objects. Maybe you're refering to LINQ-to-whatever (LINQ to SQL, etc.), a LINQ generalization where you can quote your expressions, rewrite the AST and emit something else (a very constrain…
Take a block of code with LINQ in it and rewrite it minus LINQ but logically performing the same operations that the sugar is resolving to. To most developers it would offend the sensibilities of construction, but somehow in LINQ-land all seems fine.
Sigh . Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection…
LINQ is pretty sick and if obj-c has a similar feature I have never seen it.
But it is nice. I do love LINQ-to-objects.
Sigh . Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection…
I'd rather eat a burrito than a salad. This is not a very good technical critique of the nutritional benefits of salad vs. burritos.
> "Reliability" – type safety. Really? And Java/Objective-C aren't type safe? I seriously doubt that anyone considers Java or Objective-C to not be reliable languages when it comes to type safety. This is almost laughable, IMO.
I like Objective-C, but objectively speaking, Objective-C is horrible for type-safety. The id type is used in a lot of places (e.g. every collection class), and you can magically convert anything to anything else without a peep from the compiler through the id type. There is no easy way to say "This is an array of Foo" and have that checked.
A cursory glance at the Objective-C tag on Stack Overflow will show you a lot of programmers coming from safer languages like Java or C# who are confused by Objective-C's lack of type safety.
In practice this is not generally a huge problem once you get into the "Objective-C way of thinking," but static type checking really wasn't a huge consideration in the design of the language. It was designed with the Smalltalk philosophy of "a bunch of things sending messages to each other and responding with messages of their own," which heavily de-emphasizes the importance of concrete types in favor of interfaces.
> "Fast execution. C# on iOS is powered by the LLVM optimizing compiler." Uh, I think I'd rather use Objective-C compiled with LLVM.
This is another "I like burritos" argument.
> "Portability" - this is a decent point, but let's be realistic - we're talking "minimally portable" here. Write-once run-anywhere is a pipe dream, IMO (at least at this point).
While there will always be platform-specific debugging and often some platform-specific code required, it is indeed quite possible and even common to write portable programs. You probably use many of them. Ever used Clang? GCC? Emacs? Ruby? The Bash shell? None of these programs have a completely different codebase for different platforms. They might have some platform-specific code, but having a common, portable base is hardly a pipe dream.
Earlier quoted context omitted.
And if you've worked on a large project with a lot of cats to herd for both platforms, you will appreciate java very quickly.
I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.
Earlier quoted context omitted.
for #1, there's a bit more to asynchronous programming in C# these days than the TPL. Take a look at the new async/await keywords in C# 5. Lets you write asynchronous code without having to deal with callbacks.
True. That being said, I don't really feel like I am hugely more productive with C#'s asynchronous support than Obj-C's. I'm a huge fan of GCD's serial/parallel queues. I haven't found anything in C# with similar functionality that is as simple as GCD.