programming environment ?

i would just recommend using project builder and interface builder. cocoa is OS X's language, which is basically objective-c with apples UI builder. these tools are free and are also of professional quality. no real point in buying programming software, especially if its just a hobby.

 

If you want a commercial project and interface builder, the best one in my opinion is Metrowerks Codewarrior... but if you want something like Real BASIC, I dunno... anyone?



irmongoose

 

Programming has evolved a bit since the Apple IIe. Apple has finally come into the 1990s.

I would suggest getting the Aaron Hillegass book "Cocoa Programming for Mac OS X" and reading tutorials on the O'Reilly network Mac DevCenter at http://www.oreilly.net. Apple also has tutorials, within Adobe Acrobat files on the developer website, for both Carbon and Cocoa.

Project Builder/Interface Builder is the better environment for Objective-C, Java, C, and C++ but Metrowerks CodeWarrior has the better compilers.

 

Along with your chosen IDE, you should have BBEdit (the best Mac text editor).

It integrate well with everything from CodeWarrior, to the command line, and is really a better text editor than is built into IDEs.

I myself use CodeWarrior, Project Builder, BBEdit, and the command line tools, and can say that the Mac has become an awesome dev platform since the intoduction of OSX.

If you are just getting back into things, get BBEdit ($129) and Project Builder ($free [that's not a var]). Once you feel you're taxing project builder's capabilities, look into CodeWarrior, or some of the command line binaries.

 

cant he use the free developer tools that
comes with every mac? is that project builder
interface builder?

 

Porject Builder and Interface Builder are part of the dev tools suite.

 

I agree. I think Project Builder and Interface Builder are not going to be any harder to learn than RealBasic which also has a fairly steep learning curve. Tutorials are included with the Developer install. I suggest you start with Java if you're starting from scratch considering it does a lot of the difficult stuff for you such as memory management. Objective C is a lower level language that you probably don't need.

Project Builder also lets you create programs with standard text interfaces which anyone should have no problem programming.

 

programming with C

I am taking a C class and I was having problems doing simple I/O in project builder. I know C++, but I dont know what i could be doing incorrect. Does any1 know of the proper type of project I should select to do simple ANSI C? Also, the exact code worked perfectly in Codewarrior, so my assumption is I am choosing the wrong type of project.

 

Re: programming with C

The tool projects will be what you want to do scanf/printf (C) or cin/cout (C++).

The problem could be the project, but I've found small issues with the standards support in GCC. Remember that it isn't a commercial compiler (collection), CodeWarrior's are.

 

I was using tools

Here is the code, and the problem is when I use printf and scanf it does not prompt me. I enter 2 and 2 and it should display 4. What happens is it runs w/ a blank screen I enter 2 and 2 and -2(to quit then it shows the "please enter #" 2 times and then "Total is ..." with the correct answer. Maybe the code is wrong, but like I said codewarrior Edu edition works fine. This is compressed so I know the spacing may be hard to read. Thanks for any help.
/*
This program sums all of the positive integers entered and displays the result to the screen once a negative integer as been input.*/
#include <stdio.h>
int main(void)
{
int i = 0,
total = 0 ;
printf("Please enter an integer\n") ;
scanf("%d", &i) ;
while(i >=0){
total = total + i ;
printf("Enter another integer\n") ;
scanf("%d", &i) ; }
printf("The total is %d", total) ;
return 0 ;
}

 

CodeWarrior vs PB & IB

I use both and for anyone trying to learn programming I would start with PB & IB plus a copy of O'Riellys "Building Cocoa Applications". PB & IB do a lot of things automatically for you which is nice. After you get the hang of programming and the bug really bites you - think about CW, but if you are only developing for OS X, PB & IB may be the best route even then. I'm developing for Windoze on a mac so CW is the only choice for me

by the way - one of the cocoa apps in the book is a calculator - very cool

 

It's not GCC. I tested that program with GCC in Linux (x86) and GCC in Windows, and it runs correctly with the proper output. Hope that helps in your search for why it's not working...

 

It's not your code, it's ProjectBuilder.

I created the project.
I copied your code into the main.c file.
I renamed the main.c file to ryme4reson.c.
I created the application.
I ran the application and nothing showed up. This is typical PB behaviour concerning command line programmes.

I went to the command line and created the programme. cc -o ryme4reson ryme4reson.c
I ran the programme with ./ryme4reson

It works fine.

 

It's not your code, it's ProjectBuilder

Thanks, I am trying to work with it right now, and again its acting dumb. I wonder how I can contact (or if I need to) Apple to let them know this. I was under the impression I would have not problem with Java, C, C++ with PB. I took 1 year of C++ and had no problems with PB, now I have C and Java coming up and I am running in2 these probs. Its very discouraging. Thanks for your help Bous...
EDIT** I ran my current project via CL, and it worked. If I wanted to code in the CL how would I do it? Could I use vi? i guess I can use PB as an IDE, and compile via CL right? Thanks

 

Come on, don't use project builder for this.

For a simple stdin/stdout program, just open terminal and type
cc -o program program.c
./program

And you can use make too, like all good Unix programmers. You can edit with vi, who needs BBedit.

Personally, I don't like IDEs, they are too visually complicated and waste too much time. I want to build Aqua apps using Carbon and a makefile. And I intend to find out how, too. But don't let me bias you. I only wish to point out that for terminal-type programs, you can develop them in terminal with no overhead whatsoever.

Have fun!

 

No Overhead

I cannot believe how much fast it is to compile my simple C apps via CL rather than PB. In the CL it is almost instantaneous, in PB atleast 5-7 seconds.

 

Re: No Overhead

Ain't Unix Grand

Once you learn makefiles they are very powerful - you can build makefiles that automatically find your code, do the right things with it, and build multiple versions all in one swell foop

 

Im not programming expert but can't you put

Int main()
{
blah
blah
blah
return 0;
}

w/o the void etc.

 

You may either define it to return an integer (int) or nothing (void). If you need the shell to see the errorcode you've set, you need to define it as int.

 

What does Apple use?

I am here trying the simplest C apps, and in PB it sucks, so my question is: Does Apple us PB for its software development? come to think of it, I have a friend who was an intern @ Apple last summer, I will email 2night and get the answer and post later

 

I use PB all the time for Java work under WO and I think it is fantastic.... apart from the time it takes to compile.

I was going to say that I should not complain about stuff like that with an app that I did not pay for but, in a scene, I did pay for it because I had to purchase the WO kit.... although that was only an add on to PB.

 

Far larger programs have been written with vi and make...

... than with IDEs such as PB. I doubt that Mac OS X itself, for example, is done with PB/IB (altho perhaps Aqua is). Large programs with hundreds of source files require documented makefiles, perhaps many nested makefiles. Now that we have a real operating system on the Mac, we can bring some real discipline into the programming process. IDEs are for solo programmers writing small- to medium-size programs. They save time only in the short run. Maybe the short run is all that most programmers need. But that's no reason to pooh-pooh techniques that programmers have used for years before the Mac came on the scene, and continue to use, and will continue to use when the Mac is a fond memory. May that day be long in coming.