I am comming from a .NET background, mainly c#. i love visual studio, and although i know the mac tools dont come close to its functionality, il be happy with dev tools that let me create an interface via drag and drop. my problem is what language will allow this? i do not want to learn objective c, c, c++ ( gave it a go before but its just too much for me). i was thinking about python, but im not sure if you can easily create interfaces in the dev tools when using python. also, im not sure if python has access to all the coca api's.is python the way to go, or should i learn something different?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS what programming language suits my needs?
- Thread starter schmintan
- Start date
- Sort by reaction score
B
BigMäc
Guest
Just a thought
Switching from C# to Objective-C is not as difficult as switching from .NET Framework Class Library (FCL) to Cocoa. The latter won't be solved by Python with Cocoa bindings.
Switching from C# to Objective-C is not as difficult as switching from .NET Framework Class Library (FCL) to Cocoa. The latter won't be solved by Python with Cocoa bindings.
I think you'll be presently surprised when you actually start using the Developer Tools, especially on Leopard. They may not be there to do everything for you like it seems most MS apps try to do, but you'll find a certain sort of simple elegance about the way you'll start using and getting used to the tools. The OSX developer environment can be very productive.
Take a read at this guy's blog post (http://dotnetaddict.dotnetdevelopersjournal.com/cocoaday1.htm) and some of his other Cocoa-related posts. He's a .NET developer exploring the Cocoa world, and he's been pleasantly surprised by a lot of the things he's discovered.
Objective C has the worst syntax ever for a programming language, but if you can pass that, its very good. I really tried (for a week) and gave up, it was too unatural for me.
Personnaly, I would recommand Ruby. You can build cocoa apps straight from XCode with Ruby and it is a far superior language for an elegance and power point of view. I guess there is a performance hit to use Ruby tho but it shouldnt be that big.
But the more mainstream road would be to forget everything you know and get used to Obj C... You will get way more support from other devs.
Personnaly, I would recommand Ruby. You can build cocoa apps straight from XCode with Ruby and it is a far superior language for an elegance and power point of view. I guess there is a performance hit to use Ruby tho but it shouldnt be that big.
But the more mainstream road would be to forget everything you know and get used to Obj C... You will get way more support from other devs.
Interface Builder is a separate application, so yes you can (almost) just as easily create Mac native UIs for Python/PyObjC. That said, I still think it's easier to just use Objective-C, as that's still the way Apple intended everything to work. But Python is a great language with some nice libraries available, including some things that would be impossible in Objective-C or a real PITA to drop down into a lower-level API for, like serial control or web programming. Ruby is a nice language but Python just feels more elegant to me. I've been playing around with Django and Python lately and I'm loving it. Objective-C is great for writing a lot of standard native Mac desktop applications, but it has limitations outside of that. Bottom line is you're probably going to have to learn multiple languages anyway if you want some flexibility.
So Objective-C doesn't have variables, classes, methods etc? You know the things he might already know?
You're just allergic to square brackets [[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]
I'll second (or third) python but I don't think Xcode, especially for python, measures up to VS with .Net or Eclipse with Java. Python is much faster than Obj-C to develop with but you will need to read the Obj-C / Cocoa documentation. In addition, you can use the two languages together in the same app.
It would be nice if Apple took Python on-board and made it a first class Mac citizen.
It would be nice if Apple took Python on-board and made it a first class Mac citizen.
Interesting to hear that C# and Java have such similar syntax. I'm a PHP developer that's been considering something new, something capable of allowing me to move more into a direction of desktop application and hybrid web/desktop applications.
I've been playing with Ruby/Rails, but have heard terrible things about its performance (slower than Java, etc.). Heck, I'm still trying to figure out how to deploy a Rails app to Dreamhost with Capistrano in RadRails! (Recently migrated from Windows, I don't understand a lot of the Unix command line stuff).
That makes Java an interesting option if it's similar to C#, seems like that would make it easy to switch between Java and .NET/Mono perhaps?
I've been playing with Ruby/Rails, but have heard terrible things about its performance (slower than Java, etc.). Heck, I'm still trying to figure out how to deploy a Rails app to Dreamhost with Capistrano in RadRails! (Recently migrated from Windows, I don't understand a lot of the Unix command line stuff).
That makes Java an interesting option if it's similar to C#, seems like that would make it easy to switch between Java and .NET/Mono perhaps?
Of course Rails is slower, but slower than what? With a good setup (and I dont mean a powerfull server) and decent coding, it can be as fast as you need. Unless you are planing to be the next YouTube, it will be fast enough. And once more efficient Ruby interpreters are made (more are coming) we will see huge increase of performance.
The way you talk about java let me think that you think its slow... Its only slow because idiots instal in on websphere servers. You can squeeze a lot of performance out of java with the right server and JVM.
My whole point is that you should NEVER talk about performance of a language. Talk about the performance of deployement, development, etc... Because execution performance is mostly impacted by bad code, not the interpreter.
If you want to have fun when developing webapps, go for Rails(my fav) or Python.
It's a mistake to suggest that the Mac tools are inferior to Visual Studio. They're different, and the learning curve is pretty steep, but Apple has provided a pretty good environment.
Admittedly there are convenience features in C# that are not available even to C++ developers in Visual Studio, but you lose a lot of power as a tradeoff. Personally I only use C# for rapid prototyping. It has the advantage of eliminating a lot of housekeeping tasks, and offers you the luxury of writing code while only sort of knowing what you're doing.
The bottom line, though, is that having a tool that compensates for only sort of knowing what you're doing is no substitute for really knowing what you're doing. I strongly suggest not shying away from learning to do things "the hard way," especially when that's coincident with "the right way." Pros don't do things the hard way just for bragging rights. We're as lazy as the next programmer. We all just use the tools that do what we need them to do, and frequently there are good reasons to know how to use a language like Objective-C.
Objective-C doesn't have bad syntax; it has syntax you're not familiar with. If you'd ever programmed in Smalltalk, you'd recognize Objective-C's ancestry instantly. As a way of adding OO extensions to C, the Simula/C++ conventions became more popular, especially after Sun adopted them for Java, but the Smalltalk-like model in Objective-C works just as well. Admittedly it's a little awkward that method syntax looks different from function syntax, but one advantage is that it makes you think about whether a particular piece of code is really more appropriate as a function or a method, which C++ doesn't so much. Additionally, the way Objective-C incorporates full late binding and a message-based architecture into a language that still compiles into native code is something I'd kill for in C++.
C# is the ultimate result of Microsoft's attempts to "embrace and extend" Java technology out from under Sun/Javasoft's control. Having failed to pull that off, they decided to make their own. The CLR is essentially Microsoft's take on a Java bytecode interpreter, and C# is more or less what the Java language would have turned into had Microsoft succeeded in usurping it. At least initially they were only different enough to avoid legal issues. The .NET class library is a different beast. They couldn't just clone the Java interfaces without being too obvious, so that's where the major differences between C# and Java programming appear.
Admittedly there are convenience features in C# that are not available even to C++ developers in Visual Studio, but you lose a lot of power as a tradeoff. Personally I only use C# for rapid prototyping. It has the advantage of eliminating a lot of housekeeping tasks, and offers you the luxury of writing code while only sort of knowing what you're doing.
The bottom line, though, is that having a tool that compensates for only sort of knowing what you're doing is no substitute for really knowing what you're doing. I strongly suggest not shying away from learning to do things "the hard way," especially when that's coincident with "the right way." Pros don't do things the hard way just for bragging rights. We're as lazy as the next programmer. We all just use the tools that do what we need them to do, and frequently there are good reasons to know how to use a language like Objective-C.
Objective-C doesn't have bad syntax; it has syntax you're not familiar with. If you'd ever programmed in Smalltalk, you'd recognize Objective-C's ancestry instantly. As a way of adding OO extensions to C, the Simula/C++ conventions became more popular, especially after Sun adopted them for Java, but the Smalltalk-like model in Objective-C works just as well. Admittedly it's a little awkward that method syntax looks different from function syntax, but one advantage is that it makes you think about whether a particular piece of code is really more appropriate as a function or a method, which C++ doesn't so much. Additionally, the way Objective-C incorporates full late binding and a message-based architecture into a language that still compiles into native code is something I'd kill for in C++.
C# is the ultimate result of Microsoft's attempts to "embrace and extend" Java technology out from under Sun/Javasoft's control. Having failed to pull that off, they decided to make their own. The CLR is essentially Microsoft's take on a Java bytecode interpreter, and C# is more or less what the Java language would have turned into had Microsoft succeeded in usurping it. At least initially they were only different enough to avoid legal issues. The .NET class library is a different beast. They couldn't just clone the Java interfaces without being too obvious, so that's where the major differences between C# and Java programming appear.
Actually the current version of Cocoa can run mixed Obj-C and C++ code. With toll free bridging you can call a lot of Carbon code from Cocoa without doing much if any work.
As for RAD work core data and interface builder can do a lot of stuff without writing any code. If you need to extend that there is AppleScript Studio.