We were thinking maybe Mono? Would that work? I really have no experience in this area so I can't say what I need exactly. Hence the "For Dummies" book.
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.
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 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.
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.
Quote:
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.
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 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 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.
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*
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.
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.
I don't understand why people equate Ruby to a scripting language.
Because it's interpreted. You can precompile it with some tools, but that's not generally the way it's done.
Quote:
It is more than that.
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.)
Obj-C 2.0 in Leopard will have full GC if you want it.
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.
Quote:
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.
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).
Similar, except for Java being sucky. There is not a single good environment in which Java provides benefits over other more specialized solutions.
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.
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.
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.
Quote:
Additionally: Every program written in C# requires .NET framework to be present on the computer... I THINK.... verify please?
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.
Quote:
Additionally: C# is EXTREMELY high level. The higher the language, the less efficient it is, by necessity.
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.
Quote:
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.
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.
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?
Quote:
Originally Posted by Hiro
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.
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.
Quote:
Originally Posted by Hiro
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.
Point taken.
Quote:
Originally Posted by Hiro
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.
Please clarify?
Quote:
Originally Posted by Hiro
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.
Comments
No I don't want Windows....
I want a native C# editor. Is there not one?
We were thinking maybe Mono? Would that work? I really have no experience in this area so I can't say what I need exactly. Hence the "For Dummies" book.
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.
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.
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.
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 other languages and frameworks on other systems.
Right tool. Right job.
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.
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.
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
My other problem with the idea of using Cocoa and Objective C, or even C++... I'm lazy.
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.
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 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 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.
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*
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.
What would you suggest?
I don't understand why people equate Ruby to a scripting language.
Because it's interpreted. You can precompile it with some tools, but that's not generally the way it's done.
It is more than that.
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.)
Obj-C 2.0 in Leopard will have full GC if you want it.
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.
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.
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).
Similar, except for Java being sucky. There is not a single good environment in which Java provides benefits over other more specialized solutions.
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.
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.
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.
Additionally: Every program written in C# requires .NET framework to be present on the computer... I THINK.... verify please?
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.
Additionally: C# is EXTREMELY high level. The higher the language, the less efficient it is, by necessity.
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.
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.
No arguments there.
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.
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?
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.
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.
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.
Point taken.
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.
Please clarify?
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.
Point taken.