That's standard practice in education. It's very hard to sell new products in that market, and customers rarely switch products regardless of how badly they're treated. Acquisitions are the only way to grow quickly. Every large company serving the education market is a patchwork of milch cows acquired over the years and squeezed until dry.
Of all the programming languages I've used (C#, Java, Visual Basic, Python, Javascript, C++, C) is is my favourite.
Not that the other languages are bad but I prefer to write in Objective-C for the frameworks that Apple provides and the syntax (which makes it easy to read IMO). Also the fact that it is a superset of C gives me the ability to get my hands dirty if need be.
It is of course just my opinion. I "do" enterprise Java as my day job. I've programmed in C, C#, VB, Ruby, etc..heck even some assembly language in college and for some reason I find objective-C and the iPhone SDK in general the most painful language/platform I've dealt with in years. I have used Web Objects before (after Java was included) and I wasn't crazy about that either.
I've resorted to using third party engines to do iPhone development. I've settled on CoronaSDK (Lua), but I could easily see using unity3d or some other engine if it fit my needs. I absolutely won't go back to using Objective C. I've come to the conclusion that what language your programming in relates to your quality of life, and after 10 years professionally in Java, I have no desire to learn another platform where it feels like I'm fighting the language/api at every turn. Lua along with the Corona API's feels like fun, and iPhone development is a part time endeavor for me.
1. Verbose, it's very hard keeping ObjC code in 80 columns (if you linebreak too much it's completely unreadable)
2. Lack of generics make the code not feel as safe as the verbose presence of types everywhere would make you think
3. I hear Xcode 4 improved things (and appCode is an actually good IDE), but Xcode 3-generation tooling really is quite terrible, I miss having errors display as I type. Also the autocompletion is garbage, it's barely as good as dynamically typed languages
4. NO NAMESPACES
5. Many solutions feel old/hackish: separate interface/implementation files, macro-looking code (@property/@synthesize never feels right), objective context ("[" and "]", especially as you're repeating them all the bloody time), the severe dichotomy between objects and values or structs requiring things like content wrappings/unwrappings in NSValue (and then there's bloody `id`, which does not look like a pointer but is still an object)
stuff like that. I don't really feel good coding in Obj-C, the frameworks are very complete and often wonderfully thought but I really have a hard time enjoying the language.
1. It's verbose for sure, but why be limited to 80 columns? My screen can show 240 columns, so even showing two files at once, there's 120 columns to play with.
2. Do you actually experience bugs which would be caught by generics? I'd say that most of the time, generics are just a way to add purposeless abstraction without any tangible benefit.
3. Xcode is still terrible, but 4.2 is an improvement over 3.2 at least. Code completion is much better than 3.x.
4. In my eight years of writing ObjC, I have not encountered one single namespace conflict.
5. Agreed, separate interface/implementation files are a historical artefact, and I'd love to see them go. But that's the price of compatibility with C (which is extremely useful).
1. I love that about the language. The 80 character limit has never made sense to me. The resolution of our monitors is so high nowadays that if you've got to a point where linebreaks are making your code unreadable you've got the equivalent of a run-on sentence in English.
2. Totally understand. I've used generics in Java/C# and I've definitely run into instances where I would have loved to have them.
3. Xcode 4 is great for code competition and much better at reporting errors.
4. I haven't worked on massive projects where namespacing could potential be a problem. The 2 character namespace for each class has worked great for me. But again I can totally understand how someone could dislike this.
5. id is amazing. The dynamic nature of Objective-C is the thing I like most about it. Having to wrap ints in NSNumber does get old I admit but id combined with protocols removes so much of the need to cast EVERYTHING in Java/C# before you can perform something on it.
What do you mean by frameworks are incomplete? Third-party frameworks I can understand because there are a lot of novice Objective-C programmers out there making their code available but Apple's frameworks have been near bulletproof for me. Sometimes they are limited (which is Apple's way of forcing you to do things like they do) but in the end if I you need to heavily customize something you can access CoreFoundation and do whatever you need.
I use both Java and Obj-C at work. Objective-c suffers from its C heritage.
1. Pointers (just not useful or needed these days)
2. Memory-management (you don't get ARC unless you're happy to not cater for users using <5.0 (apparently this may not be true. thanks for the comments), and even with ARC you still need to do more than you do in Java)
3. Message-passing (Not bad per se, apart from this: you can send any selector to a nil object, meaning your app will fail silently in many instances. And that is huge.)
4. Header files (the #import is an advantage over usual C, but it's still a pain to remember to import any object before using it)
5. A hodge-podge of syntax: it's smalltalk-inspired syntax, with the more recent dot operator, with the usual C syntax.
6. Painful process of defining/declaring variables. Usual initiallisation, the @property, then @synthesize then initilise it in init: then nil it in viewDidUnload:, then decalloc it in dealloc:.
7. masklinn's point about Namespaces is important, too. Making a library with the standard three letter prefix on every class seems very hackish.
8. masklinn's point about the 'id' variable catch-all also: its very often misused. And your code is full of class checks.
I can live with those things. And that's even if they do make Java look like a nice language. What I really hate is Xcode. (And used to HATE eclipse before encountering Xcode)
1. After you get use to Eclipse's intellisenseque features, using Xcode is like wading through treacle. As one example, initilising a new member field is 1/2 a second job. In Xcode, you have to do what was in the last bullet point. For. Every. Single. Variable.
2. It's debugger/variable inspector, compared to Eclipse, is substandard.
3. Xcode crashes. Often.
4. It just doesn't feel as fast as Eclipse.
5. The debugger can hang on the iPhone a lot, meaning you need to turn it on and off quite often. It's okay in the simulator, I've found.
Regarding ARC: it's handled purely at compile time and works fine with iOS 4 (modulo weak references).
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.
1. Took a while to get used to but if you don't like pointers then yeah I understand.
2. In iOS (especially before the iPhone 4) memory management is one of the things that allows it to be as smooth as it. Adding GC overhead will eat up precious resources. On desktop this is usually masked by the absurd amounts of RAM most modern machines have.
3. Message-passing is one of the best things about Objective-C. You no longer have to perform null checks because if you structure you code correctly it will continue gracefully. The dynamic nature of Objective-C is what I love most about it.
4. I love the verbose syntax but that is a personal thing I guess. I love structuring my code and selector names so that everything almost reads like a paragraph of text.
I think we have to agree to disagree about Eclipse. I've been using it since University and I much prefer Xcode to Eclipse. To me Eclipse is the slow behemoth eating up my system memory.
I can understand the variable inspector. The GUI in Xcode is throwaway but once I got used to gdb I've grown to like it.
Xcode 4 crashed like crazy. It looks like they've finally stabilized it but I can't deny that the first 4 months after Xcode 4 was migraine inducing.
Yeah at first, but once you get used to the syntax and long method names, it's your standard static OOP language. Has some cool feature actually, like Blocks etc. Like it more then Java now.
Also what's really cool is, that you can seamlessly mix in C if you feel like low-level programming, I like that.
"you can seamlessly mix in C if you feel like low-level programming"
This is a huge plus. I've dropped to the C level on a number of occasions already in my projects. I also makes it MUCH easier to drop in existing C libraries for extra functionality since you don't have to write language bindings for it.
> Has some cool feature actually, like Blocks etc.
The blocks are kinda crummy though, and the verbosity is definitely verbose. `enumerateObjectsUsingBlock:` is a far cry from Smalltalk's `do:` (and its signature is awful too, even more so due to ObjC's lack of generics)
- No namespaces. Two letter prefix hack from the old C days
- Still makes use of a preprocessor
- Slow compilation times
- The way properties are declared just feels like an hack
- Automatic memory management extensions (GC & ARC) feel like an hack
- You need a Mac to properly learn it. gcc+GNUStep don't really count.
Namespaces would be nice, however I wouldn't drop the preprocessor; it's just too damn useful for code generation.
I haven't noticed slow compilation times. A 20MB codebase (big by iPhone standards) takes 40 seconds to clean compile on my mbp. (Xcode's indexing behaviors, on the other hand, leave MUCH to be desired).
Properties don't feel hacky to me; The @ syntax is a good compromise for preserving C compatibility while introducing more powerful constructs. Same goes for GC and ARC.
> You need a Mac to properly learn it. gcc+GNUStep don't really count.
Out of curiosity, why not? You don't get the Cocoa/Cocoa Touch APIs, but those frameworks are independent of the language itself. Relying on them is akin to saying you can't properly learn C++ without Qt, or Ruby without Ruby on Rails.
Cocoa and Cocoa Touch are integral to being paid for Obj-C, and they're by far the hardest part of it.
Learning objective-c, especially if you already know C, is pretty easy. The syntax is a bit weird but not hard, then you've got a few quirks and stuff, but fundamentally you can build a working model of the language in half a day tops if you're already a developer.
Understanding Apple's conventions (libraries, memory management, etc...) and merely knowing where to find the stuff you need in the doc, that's what take time. Cocoa is huge and is a complex beast, even if you don't dive into the C "Core*" stuff and remain at the NS/UI levels.
This sentiment is probably why there is such a proportionately low number of devs who take the time to learn Objective-C, which in turn makes those who do learn it even more valuable.
I really like Objective C, but I don't know that I would call it the most elegant. I agree it is an elegant solution to adding objects and messages to C (especially when compared to C++), but it is still an extension of another language, which makes it more pragmatic than elegant.
If you've never used an NSMutableURLRequest object before, but know how HttpRequests are made, you can figure out what's going on without having to dig into any documentation.
Many languages I've seen (C in particular) hide that explicitness. You call someFunction(arg1, arg2, arg3), but what do arg1, arg2, and arg3 do? Can you pass a 4th or 5th argument too? Unless you've memorized what someFunction() does, you have to dig into the docs, which makes the language harder to read. Obj-C method calls always list "every" available parameter, regardless if its used or not (e.g. nil).
------------------------------
Obj-C takes up a lot of horizontal screen space. It works best on high-resolution widescreen monitors, with a modern editor, and modern mouse, both supporting vertical AND horizontal scrolling. Limiting lines to 80 characters, or anything really, destroys its readability.
The most unreadable Obj-C code I've seen is usually formatted this way. Google's Obj-C code is a nightmare to read; they limit it to 80-characters (http://google-styleguide.googlecode.com/svn/trunk/objcguide....). Great for a 1980's terminal, not for modern 2560x1440 displays.
Frankly line-length should not be the job of the programmer writing the code, but of the IDE/Editor displaying it properly on-screen. When you say "all code must be 80 lines long", you've forced that upon every programmer regardless if it's a good decision or not.
It's like decoupling the Model and View. The Model is the actual code written, where the View is how it's displayed. Programmers should be able to customize how their View looks using their IDE/Editor. When you hard-code the View into the Model, you break decoupling, and force everyone to use the same View.
Most Editors/IDEs let you customize the view somewhat, like color-schemes and "wrap text". But I haven't seen a "complete" decoupling of the model (code) and view (how it's presented) yet, in any IDE/Editor. Someone please correct me if one exists. This is a feature I'd "LOVE" to see in all IDE/Editors and programming languages, as it will make verbose languages like Obj-C much easier to read based on the programmers preference.
This is more of a praise of Apple's naming conventions with the ios and Cocoa sdk's (which I agree are very good, as is auto-completion in XCode) than of Objective-C itself. Of course the quality of the framework is hugely important in how pleasant a language is to work with, but I wouldn't say that Objective C is an elegant language compared to everything else that's out there (IMO Python and Haskell are both very elegant, but there are a lot of languages I've never played with).
I agree about Google's styleguides... I used to code like that and line up all the :'s vertically, and i finally realized I was making my code harder to read.
So i refactored all my existing code to have every statement on one line. Yeah it's long, but my huge monitor and xcode in full screen remedies that.
Absolutely, I've been thinking this as well. But to make it really seamless, SVN/Git would have to work that way too, and they'd have to have knowledge of the language's syntax for that, which is not going to happen.
I've always seen it as an imitation Smalltalk but with segfaults. Does it have any advantages in expressiveness, rather than merely being native for two platforms some people are interested in?
Duh. Every single real language (not deliberately painful languages like brainfuck) makes PHP look terrible in comparison. That says nothing about objective C other than "it is not the worst language ever made".
A number of Cornellians have been prominent innovators, starting with Thomas Midgley, Jr. ('11),[287] the inventor of Freon. Jeff Hawkins ('79)[288] invented the Palm Pilot and subsequently founded Palm, Inc. Graduate Jon Rubinstein ('78)[289] is credited with the development of the iPod. William Higinbotham developed Tennis for Two in 1958, one of the earliest computer games and the predecessor to Pong, and Robert Tappan Morris developed the first computer worm on the Internet. The most direct evidence of dark matter was provided by Vera Rubin ('51).[290] Jill Tarter ('66)[291] is the current director of the SETI Institute and Steve Squyres ('81)[292] is the principal investigator on the Mars Exploration Rover Mission. Eight Cornellians have served as NASA astronauts. Bill Nye ('77) is best known as "The Science Guy".[293]
Really, you should know the Robert Morris one off the top of your head at the very least.
Also, Cornell is named after a guy who made his money in the communication technologies business. Unlike Yale, Stanford, Duke, and most of the other elite schools in the U.S., which are named after drug dealers.
http://en.wikipedia.org/wiki/ANGEL_Learning