C# on Mac

I think you want Boot Camp or maybe Parallels.

C# is the microsoft spawn of satan java hack that is windows only. Go C++ or use the OSX development tools from Apple

C# programs are just scripts passed to the runtime, which translates them into machine code on the fly. slow as shit. I'm not aware of any way to compile directly into a real executable. It should be avoided at all costs.

I dislike MS as much as anyone else out there, but after the first sentence the rest is a load of crap and pretty factually incorrect .

Bytecode != scripting;

Newer JIT compilers that consume bytecode can be even more efficient at wringing out performance benefits than static compilers. To the point that overall performance is just plain native. Heck even Rosetta only takes about a 20-30% speed hit and it has to create the bytecode AND do the JIT compile, over twice as much work as Java & C# which only have to do the JIT compile.

Yes, I was very sloppy with my language in that post.
BUT

You'd have to show me some evidence before I buy that bytecode can approach the speed of machine code. Bytecode MUST be translated into machine code before it can be used, thereby adding at LEAST one extra cycle for every command. How can that be anywhere close to the speed that you can get from a machine code compile? By using an efficient JIT compiler and an inefficient machine code compiler? Go get an efficient machine code compiler.

Additionally: Every program written in C# requires .NET framework to be present on the computer... I THINK.... verify please?

Additionally: C# is EXTREMELY high level. The higher the language, the less efficient it is, by necessity.

Additionally: C# does stupid things like require you to store the Main function (called methods in C#) as a class object. You then must instantiate an object of that class before you can use any functions that you may have written outside of the Main. That should be implicit.

Additionally: It's 3 am and I can't think of anthing else right now. Go with C++, and use visual studio if you wish, so that you can take advantage of the .NET libraries. You will have the benefits of C# (the library) and also the ability to use the same language on multiple platforms.

I believe you can use this to compile C# software for OS X:

http://www.mono-project.com/Mono:OSX

I tried to compile a program written in .Net that changed the aspect ratio of an Mpeg-4 movie without re-encoding. I didn't have the patience to get it to work so I ended up running the binary under Virtual PC at the time.

Now that I have Parallels and and Intel Mac, I'd have just used that.

Overall, I'd agree to avoid C#.

If you need scripting, go with Python, Perl or Ruby - Python is my preference but I think Ruby is similar
If you need compiled languages, go with C, C++, Java or Objective-C - C would be my preference but C++ for Object-oriented programming, simply because it is more widely accepted
For cross platform network programming, Java is great. I wrote a multi-threaded LAN networked game in Java once and it was actually pretty straightforward.

Use the right tool for the right job. Forget about making Mac apps with C#, or anything .NET/Mono, for that matter. Use Cocoa and Objective-C. Use .NET and C# on Windows.

Use other languages and frameworks on other systems.

Right tool. Right job.

Why do you want to use C#? As far as I know, the job market for C# programmers is much smaller than that for Java programmers, and they are very similar.

Similar, except for Java being sucky. There is not a single good environment in which Java provides benefits over other more specialized solutions.

I make my living programming in Java, and while I think Java's great in a lot of ways, I've looked at C# and would love to have some of C#'s features in Java. Java does have it's uses, but it's got some big limitations too. Take the best features of Java and C#, keep the final result as platform neutral as possible, improve platform-specific look and feel, and make it a little easier to optionally tie-in in platform-specific features, and I'd be a happy camper.


The problem with what you say here is what to do when you'd like to develop cross-platform code, when you'd like to use more-or-less the same code base to create an app that runs on both Mac and Windows, and maybe even Linux too. The main options for that these days seem to be Java or C++, with a few other oddball cases like C# using Mono. Use Java, and you'll have a hard time creating a really good Mac GUI, and may have performance issues on all platforms. Use C++, and you'll have to stick with Carbon instead of Cocoa for the Mac version.

If I had to create a high-performance cross platform app with a high quality GUI these days, the best looking option I've seen (apart from the cost of the commercial use license ) is Trolltech's Qt cross-platform C++ library.

My other problem with the idea of using Cocoa and Objective C, or even C++... I'm lazy. I've been programming in Java for over seven years now. I'm good at it, and I'm comfortable with it. I dread the idea of going back to having to worry about consciously allocating and deallocating every scrap of dynamic memory I use. And while I'm sure I'd get used to it quickly enough if I had to, right now Objective C syntax hurts my eyes... blecccchh!

I've heard that Objective C might be getting real automatic garbage collection, instead of just the half-useful reference counting it has now. That would increase my interest in the language, but, of course, code written in Objective C using Cocoa libraries still isn't going to be of much use for a cross-platform app.

Obj-C 2.0 in Leopard will have full GC if you want it.

The only piece of C# that has intrigued me is the 'delegate' keyword. Nice move there, pulling the concept of a First Responder into the language itself. Other than that? Yet Another Language. Whoo.

The answer to that is: don't do it. Ever.

Split your codebase into a cross-platform backend, which you might as well write in C, and a platform-specific frontend for which you better use a platform-specific environment.

Come on, even Skype can pull that off.

Well, don't do that unless you're Adobe, and have $$ to burn on maintaining your own internal codebase that users then complain about, but don't have any real alternatives. :P

Seriously, chucker's on the right path: separate out your logic back end (which you should always do anyway), and choose the right x-pat solution for that, *independently* of what front end you want to use on the various platforms you'll support. Logic != UI. Treat them as separate projects (because they really are), and then again... the right tool for the right job.

Where he and I differ is... C? Really? When there are much better productivity- and maintenance-oriented options? I'd only use raw C if a) it was forced on me by team policy, b) I needed to use that tool for that job for whatever realistic technical reason (pre-analysis claims of optimization don't count). Personally, I think it's a lousy default, but YMMV. *shrug*

Oh, I hate C, and I avoid any line of code written in it. But if you want a reasonably fast and as-cross-platform-as-possible backend, it's just about your only option.

What would you suggest?

I don't understand why people equate Ruby to a scripting language. It is more than that. With the Rails framework, you can develop very decent applications in a truly object oriented language with ease. Dig deeper into what Ruby is all about.

Because it's interpreted. You can precompile it with some tools, but that's not generally the way it's done.


I think you're under the wrong impression that someone says "scripting language" that it's derogatory. Ruby is an excellent, versatile, smart language. But it's not a fast one, and there's a lot of things it lacks.

You can create great web apps with it thanks to Rails, but don't even bother trying to make a remotely good GUI application with it. The frameworks available to do that suck. Awfully so.

The difference between creating a desktop app with Ruby and creating one with Objective-C and Cocoa is night and day.

Which brings me right back to my previous point. Right tool for the right job. For desktop apps, Ruby just isn't the right tool. Perhaps one day it will be. (Yes, I know about RubyCocoa, but that's essentially wrapping faux Objective-C into a Ruby syntax. It doesn't feel right.)

If I have to build in Leopard, but what I build will run on earlier versions of OS X, great. If what I build will only run on Leopard, that's not so great.


It's been a while since I last looked at C#, but part of what I liked is that it wasn't so determined to try to force you to behave yourself like Java does. It's like Java with the training wheels taken off.

Yes, a preprocessor can be abused. Horribly so. But still, I'd like to have one so I can at least #ifdef debugging code and differences between different target builds.

I like the idea that, where performance is needed, you can declare an "unsafe" code block, and eliminate the overhead of things like checking if every array index is safely in-bounds, every single time you perform an array reference.

I think I remember that C# supports operator overloading like C++ too. Another thing with potential for abuse, and some might dismiss as nothing but "syntactic sugar", but try writing much code dealing with three dimensional coordinates and you'll be wishing you could just type a "+" sign to add two of the f*ckers, instead of something clunky like pointA.add(pointB).

The clean room implementations of Java that use AOT compiling are quite useful. These include J2ME and various custom blends that lie somewhere between ME and SE. In this respect Java is very handy for development of mid-level embedded software. That is, stuff for set top boxes, phones, and other various widgets, often linux based. It allows a decent degree of UI portability across different types of hardware.

You only pay a performance penalty if the bytecode is interpreted. A good JIT compiler doesn't wait when it doesn't have to. JIT is a bit of a holdover name, it's not all "Just In Time" anymore. It's true that first pass through sequential code that bytecode through a JIT cannot be faster than something statically compiled, but to paraphrase an old 1992 election saw: "It's the loops, stupid!". Also anything that uses dynamically allocated objects and memory has a much better shot at being highly runtime optimized than is even possible at static compile time.


No, but yes. C# has an ISO standard that allows machine code output so you should be able to do console type apps without .NET (why anyone would want to, I don't know). BUT the only compilers available target MS's CLI layer which is part of .NET.



You have to narrowly define efficient fairly narrowly for this to be true. Compiling a high level language into optimized assembler and then machine does not have to loose you efficiency in the language. I think what you are confounding is the high level languages with the libraries that the high level languages bring along as part of the overall package. library calls are always more expensive than completely inline code because there is a function involved. But if you roll your own function from "efficient" low level commands you still incur the same function call penalties and unless you are a crack optimizer your code will usually be slower than a provided library anyway. Not to mention rolling your own function took time away from coding efficiency and opportunities to tune your app's bottlenecks, further eroding automatic wins from low level languages.



No arguments there.

Compiles the function the first time it's called, then stores it when it's done, and just goes back to the same already-compiled code each subsequent time? That makes sense. Then, the efficiency compared to static compilation depend on the compiler?


Now I feel dumb. Most of the programs I've been writing in class are console apps. Duh. Please clarify, you CAN output machine code rather than bytecode? How?

Console apps are still platform dependent though, I believe.



Point taken.


Please clarify?


Point taken.

No, I certainly like C# a lot better than C++, if you're writing for .NET. But you shouldn't do that on a Mac.

Why not? C# is a good language. And mono is a pretty darn good C# environment that works on the Mac. So why not support it? Because MS created it? Then what about AJAX? That was something Microsoft created.

The fact is that each language has its use. I'm a C++ guy myself, but if I needed to write business apps for an IT group, C# or Java would be my #1 tool to look at depending on the business needs.

Being tied to a single language is stupid. Learn multiple languages and environments and use the best one.

What? Mono? On a Mac?

Next you'll be suggesting we write GUIs in Tk.


No, nothing to do with that.


Agreed.

yes.



The standard allows it, but nobody has publicly released a compiler that will do it. So while it should be possible, it currently isn't.


Only because of the above. Other languages console apps are not platform dependent unless you use something not part of the language standard.



These 3 go together and equate to: Use the library functions because the chance you can write something faster is slim. If you pay the development time price and do write something faster, it usually won't be faster enough to have made up for the dev time you spent on it. Sure there are exceptions, but when you find them they will stand out like sore thumbs as prime places to put in the effort. If you don't forsee a BIG payoff before you start rolling your own replacement for a library function it is best to just use the library function, even in higher level languages.

Of course keeping the backend well isolated from the GUI is an important design concept, but often there's a lot of work, and logic, in the GUI itself and how it functions.

Take a program like iTunes. I have no idea how Apple actually goes about writing this code, but iTunes (from what I last heard -- anyone can correct me if I'm wrong) is a Carbon app, not Cocoa on the Mac. If true, I'll bet that's because the GUI, which is so similar across platforms, has an awful lot of common code and is built around some sort of cross-platform GUI library.

What's the "backend" for iTunes anyway? Not much there but Quicktime, iPod synchronization, and some code to maintain to iTunes library database. If you have a good cross-platform GUI library, and it's flexible enough so you don't always have to go "lowest common denominator" with your interface, why not take advantage of it?

I can't imagine ruling that out in favor of trying to maintain to completely separate GUI projects, one in Objective C/Cocoa, the other in C++ or C# written for the Windows API, both of which have to converge separately on an almost identical interface, but not sharing anything more than, perhaps, some common graphics and text resources.

Yes, iTunes is Carbon, and yes, the vast majority of iTunes's code is shared between Windows and Mac OS X. But that's okay, because a design goal with the Windows version was familiarity. It doesn't feel as much as a Windows app as it could, while at the same time accounting for Windows-specific features such as a taskbar toolbar band and a system tray icon.


Right, for the most part, iTunes is just an elaborate QuickTime client. But you're only proving my point: QuickTime, in turn, does indeed have a rather strict separation between front-end and back-end. Most of it is back-end, and that doesn't use Carbon code at all. Think of all the optimizations towards SSE3, etc.

C# and Managed C++ compile down to MSIL code and executes in the CLR. C++ can actually run slower than C# but depending on application you may not see much difference at all (ie when you are IO bound). There are benchmarks where C# ran faster than managed C++ but slower than Java or C++.

For an example of speed try NASA World Wind. Written in C# and Managed Direct X.

The biggest advantage of C# over unmanaged C++ is that the .NET framework is soooo much nicer to work in. Likewise Java vs C++ though STL and newer extensions have closed the gap. A little.

IMHO as a C/C++/Java/C# developer I think that C++ isn't very compelling anymore. C for speed and C#/Java for ease of programming. ObjectiveC for Mac.

C++ is kinda half way inbetween low level (pointers) and modern high level languages.


Java is faster than gcc in some benchmarks:

http://java.sys-con.com/read/45250.h...84C96D46498798

Granted that gcc is one of the slower (if not slowest commonly used) compilers. Presumably using an Intel, Sun or even MS compiler would have resulted in a faster executable. Definiately Intel...it's one of the nicer advantages of moving to the intel platform for the mac. The potential of using Intel's compilers to generate fast code on the platform.


Yes and no. Mono's CLI isn't called .NET but it is a CLI. However, it's like complaining that Java must be installed. So what? The installer takes care of it for you.


See above. In any case C++ is considered a high level language as well. Just an older one with modern extensions hacked on.

Efficiency is goverened by many things but typically programmer efficiency is considered more important than language efficiency these days...or we'd still be using Assembly.


Never learned about static methods have we? If you have a static method called Bar in class Foo you can call Foo.Bar() without instantiating a Foo. In fact you can't call Bar except as Foo.Bar(). Calling it via FooInstance.Bar() should result in a compilation error.


Managed C++ appears to be the worst of all worlds in terms of performance (the collection class called appear to be abysmally slow in comparison to C#), syntax and cross platform compatibility (managed C++ is the least likely to run under Mono).

Java is more cross platform and C is faster. If you know both C#/Java and C you can likely handle most idiosyncracies of C++.

Vinea

PS. C#/.NET was one of the two hot software careers on Money. The other was quality assurance (ugh). Can't find the link but that's what I remember seeing last year. Fortunately it seems we're on a rebound with Software Engineer (in general) topping the charts again:

http://money.cnn.com/magazines/money...p50/index.html

Eh, its all yet another language kinda like C until you get a little esoteric like Haskell.

Oddly, all the "new" languages are all contemporaries from the late 80s or early 90s. C# is later but it's not really "new". Creating new languages appears to be passe.

Its the frameworks that are new and constantly evolving.

Vinea

(JavaScript, PHP and Python are from the early-mid 90s, Ruby from 1993)

I'm tempted to go back to C++ for a cross-platform app I have in mind simply because I'm not convinced from what others have said here (for whom, perhaps, a "front end" is seldom more than a dialog or two and an OK button ) that making my Mac and Windows interfaces two almost entirely different projects written in two different languages is such a hot idea. Given that I'd still like to use more or less the same codebase for the GUI, C++ seems to present me with the best options -- for example, using Trolltech's Qt library. Both platforms provide good C++ APIs for nearly anything else that's platform native that I'd want to do.

If I did stick with Java, just to make life easier during a lot of the coding and debugging, I'd at least have to see how well SWT works. Swing is functional enough for some things, but it's still pretty far from what you need to get a good "shrink-wrapped" commercial quality interface.

Even with Java and SWT, however, I'd envision having to use a lot of JNI to access native platform capabilities, and that starts to get ugly. I'd like my app to be scriptable on OS X (AppleEvents/AppleScript) and Windows (COM). From what I've seen of trying to make a non-Cocoa Java app scriptable on the Mac, things get even uglier. Further, I've heard that SWT is fairly Windows-centric, so I might end up having to waste a lot of my time browbeat SWT into doing what I want on a Mac.

C++ is faster than Java for most things, taking on the grief of alloc/dealloc memory management at least means never having to worry about garbage collection hiccups, and C++ can be just as fast as C if you want it to be, where you want it to be, simply by dropping down to pure C code where necessary.


I wonder if part of the reason for this might be how often outsourcing doesn't pan out, and that perhaps more businesses are beginning to realize that paying the extra for a software engineer in the US is often a better investment.

I don't know if that's exactly "proving your point". iTunes is a damned elaborate front end for Quicktime, and Apple didn't seem to think that maintaining two almost entirely separate codebases in two different languages, one for Mac and one for Windows, was the best way to go.

I hate to be deliberately vague, but I can't talk about the details of what I have in mind. The front end, however, can and should look very similar on Mac and Windows, as iTunes does, and it's a bit complicated as a GUI, with a fair amount of gestural interaction, drag-and-drop support, etc. The back end is actually less complex than the front end, at least for first-rev features. It's still a sh*tload of work for one guy to take on by himself as a shareware project, and I'm pretty sure maintaining two very different GUI code bases would cause me much more grief and duplicated effort than could be compensated for by any extra zing using Cocoa and Objective C might bring me.

If you're using Firefox right now, like I am, there's another example of a cross-platform app where the supposed wisdom of maintaining what would have been not just two, but three almost entirely separate GUI code bases (for Mac, Windows, and Linux) was avoided.

My condolences.

You should definitely try to keep the back end separate from the front end no matter what you use. In a project, I had to put a Cocoa GUI on someone's 10,000 line C++ codebase, which originally used Tcl/Tk. It wasn't all that difficult because the code was well designed.

Personally, I'd use C++ for the back end, Qt for the GUI toolkit and Python for scripting because an interpreter can be embedded easily in C code.


I feel the same. Someone at work uses Firefox all the time and he gets so many broken downloads and sites that don't work that he often has to end up using Safari anyway.

(Casually allowing the thread to veer wildly off on a tangent, he said, "...) Odd. I rarely have any problems with Firefox at all. The most notable problem I've run into now and then is an annoying issue with Firefox getting confused about keyboard focus and ignoring Command-C (or Ctrl-C when I'm on Windows) to copy text I've selected. So far I haven't seen that problem in Firefox 2.0, so maybe that's finally been fixed.

At any rate, I was on Windows at work when writing that post, so Safari wasn't an option. When on my Mac, I use Safari either to test compatibility of my own web code, or on the rare occasion a page doesn't work for me in Firefox (I honestly don't remember the last time that happened). I used to have to use Safari for accessing my bank account, because my bank for a while only officially supported IE on Windows and Safari on Mac, but that's fortunately not an issue anymore.

I like the geekier nature of Firefox. I like being able to control pop-ups and cookie filtering on a site-by-site basis. I really like being able to use Adblock. And it's not like Safari is bug free -- there have been times I've been using Safari and couldn't get a web page to work properly, and I've had to turn to Firefox to get around the problem.

1. The top Indian programmers move here.
2. The global separation makes management a PITA.
3. For projects smaller than a few million dollars, the extra management required often isn't worth it.

My company recently had a bust with offshore development. We actually outsourced the project in general, and the US company that was doing that outsourced part of the job to India. The results were not pleasant. A few people in the US company lost their jobs due to failure to deliver.

But with that said, software engineers are still an overpaid lot. Finding a good one can be tough, and the average ones cost more than they're worth. How a software engineer can demand a higher wage than a hardware engineer has been, in my opinion, the greatest magic trick of the 90's. The increasing dominance of the embedded arena in the high-tech job market, however, seems to be correcting this oddity. Incidentally, this is why I suggested Java. C++ has been eschewed in the embedded world in favor of plain C and AOT Java. A lot of this has to do with the ubiquity and compactness of the ulibc in embedded Linux distributions. Then there's eCos, and the odd truth that a standard Java KVM has a smaller footprint than a C++ library.

Perhaps developing software is harder than writing small programs might imply?

Naw...its because software geeks pulled a fast one...of course that doesn't make hardware geeks any brighter. It has absolutely nothing to do with a reasonably free market and it paying relative worth...

Vinea

There are really good software engineers, developers, coders -- whatever you want to call them. There are also a great deal of mediocre and downright bad software developers. With hardware, there's instant quality control: cost, obviousness, and lower tolerance for error (fire). It's much easier to detect a bad hardware design job, so in the United States, Taiwan, and Japan there aren't too many bad or even medicore hardware design teams in business. Anywhere else, though, YMMV. But with software, it's much easier for a crappy product to slip through the cracks.

Yes, Mono on the Mac. For commercial apps? No. For hobby, learning, or even doing ASP.NET work on someone else's sever - definitely.

Which has zip to do with compensation and relative worth (from a business perspective).

While it does cost more to spin a hardware prototype I've seen my share of bad board designs requiring the respin of a set of boards. There's nothing "instant" about quality control in either the hardware or software domain.

Besides, perhaps the lower error rates is due to the lower complexity of the task? There's two ways to spin any given perspective.

Vinea