I have been developing applications based on C# (.net) and Java (J2EE) for the last 3 years.
But now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
So, I am trying to learn C++, but I find it a little "confusing" due to pointer, multiple inheritance, some conventions and other concepts of C++ which don't exist in Java. So, what do you guys suggest? How should I feel about it?
Thanks
PS: I am a student, so have all the time in the world and actually shift.
In my opinion, you should learn C first in order to properly understand the base upon which C++ is built. Pick up a copy of "The C Programming Language" by Kernighan and Ritchie, widely considered the best reference on the language, and start reading through it. Once you fully understand C, you'll have the low-level base you need.
C++ is no more "basic and underlying" than any other modern programming language. It has a model of a computer (a flat memory address space), but the OS and CPU merely simulates that model using many layers of caching and paging, so it's not "real". The result is that the same operation may sometimes take 1000s of times longer to complete than at other times.
Also modern C++ has lots of powerful abstractions that have no more direct relationship with how a computer works than do the abstractions provided in Java and C#. The OP mentions multiple inheritance - clearly no more elemental than inheritance in other OO languages. Many other features of C++ omitted from Java are high-level abstractions (or allow you to build them) and so in some ways Java is the more low-level language. In Java the meaning of operator symbols is always the same, whereas in C++ a simple == might build an object that will later be used to generate a SQL expression instead of being executed in-process.
The JVM and CLR runtimes are (almost certainly) written in C and/or C++, so in that sense obviously they happen to form layers today. But at the C/C++ layer you will still be working in an abstraction that is not "how the machine really works", so you'll really just be learning a different set of abstractions, rather than "reality". And an OS (or indeed a hardware chip) can be designed specifically so that JVM or CLR like runtimes are the native low-level layer of the system; on such a system it would be the C/C++ runtime that would require a "high-level" (expensive) emulation layer in order to work.
So it is probably not worth trying to learn how to program in "reality". No one really does that these days; it's a waste of time. You're better off learning about how programming abstractions help you to write correct programs. If a language makes life difficult for you, that doesn't prove you're doing the "real thing". It just means you picked the wrong language for what you're trying to do.
I disagree with the sentiment that you need to learn C or assembly language first. C++ and C may be similar in theory but are very different in terms of practical use. One gains little to nothing in the way of C++ idioms by using only C, and while it is good to have practical experience in multiple languages, it's an exercise in futility to specify prerequisites in language learning. I think the best way to learn the concepts of programming is to sit down with someone who understands them well and just talk about it, be that on StackOverflow, in forums, or, if you're lucky, in person.
At the end of the day, I think programming really isn't all that hard, and you may need someone to explain it right just one time to have everything click. It's all about rehashing the same simple concepts over and over to build complex and beautiful machines.
For learning c++ I reccommend reading C++ for Java Programmers by Mark Allen Weiss. It helped me alot when moving from Java to C++ as it is very good at highlighting the differences between the languages.
But, now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
If you're trying to learn the concepts of programming, rather than machine architecture, there's not much benefit to learning C++. I would suggest going with something different from Java all together. A Lisp variant, perhaps.
How To Design Programs is a pretty good book.
If you want to understand the underlying concepts of programming languages, I would suggest a book such as John Mitchell's Concepts in Programming Languages. Follow this up by writing a few parsers/interpreters for simple languages. Another good resources is SICP, which is specific to Scheme (a LISP dialect), and available in full here. Once you've learned a few languages, it doesn't take too long to pick up the syntax and semantics of a new one (the core libraries on the other hand, can take quite a while to be familiarized with).
If you want to learn about how today's computers work, I'd recommend learning C and reading books such as Tanenbaum's Modern Operating Systems. C is useful in this context mostly for reading systems level code. Implementing a (very) simple operating system can be incredibly educational. However, something as simple as implementing a basic shell (like bourne shell, except simpler) is probably a better place to start. I'd also recommend learning about how networking works specifically, since it's such an integral part of modern computer systems.
C and C++ make some basic underlying programming concepts more evident, but they weren't designed by God. I'd second the suggestion to study the actual low-level systems behind your low-level code: operating systems, compilers/runtimes (try "Essentials of Programming Languages"), and machine architecture.
P.S. In general it may be better to study C++ on its own, rather than starting with C, but for your particular purpose -- getting more intimate with low-level, unsafe constructs such as pointers, after already learning Java -- I think it's better to start with C (and K&R) where these are front and center.
I would suggest learning assembly language first. This will give you a very solid foundation in what is happening at a low level. This will also help to reinforce the idea that "everything is really just an address".
Taking a class which focuses on assembly language is advisable since it will "force" you to learn it (personally, I don't think ASM is /that/ fun, but it was worthwhile [and a requirement for graduation] for me to take the class).
After you know assembly, go on to C and C++.
Have a lot of fun!
It sounds like you're avoiding the first mistake most people make, which is assuming the new language is the same as the old one. C++ is different and should be learned as a neww(-ish) language.
A reference I would suggest would be C++ How to Program which is used at my University for the introductory C++ classes.
After that, then look at previous Java software that you have written and seeing how you would translate them to C++. The syntax can easily be referenced from CPlusPlus.com. While doing this, it is important to keep in mind what all the different syntax represents, and how it changes what is going on in the software (i.e. The differences between the two languages). This has the added benefit of allowing you to see how the underlying architecture is represented for both languages (and for programming languages in general). I don't know of a good book that explains how programming languages work under the covers, or I'd recommend that.
If you are, however, interested in learning how programming works, then Assembly language would be a good place to start. Assembly language for Intel-Based Computers is what I used to learn assembly language and it was very useful.
Assembly Language.
Start with the Z-80. Then add 'x86. Then try 68000. Then the TI 320 series of DSP. You might also wish to add the Z-8. Just to see how different machines do it.
If you really want to know more about low level programming I would recommend learning C and Assembly. C++ is much more complex than C but really doesn't give you much more insight into low level concerns. It might be interesting if you want to learn about what type of concepts and constructs a programming language can be made up of though, since C++ has a lot of them.
There is also a lower level of your VM you don't seem to know yet and which you might want to explore. To learn about the internals of Java I would recommend learning how to program the JVM in (Java) Assembly language. Jasmin (http://jasmin.sourceforge.net/) is the reference assembler/syntax for this kind of programming. Another great resource is the Java Language specification (http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html) which contains a lot of Java internals. When you have learned C you can also use some lower level APIs the JVM provides (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/) that allow you to retrieve low level information about a running JVM and write interesting things like debuggers.
If you learn this stuff and do some hacking on your own you will learn how the JVM works and what the compiler actually puts into your class files. It's also very likely that you discover some new things about the Java programming language itself you didn't know before even if you think you know everything about it.
You can also program the .Net VM in assembly by the way.
I think you should start with C, but not as a necessary preamble for learning C++. Rather, for learning C. In other words, while you learn C put your efforts into learning the language, feeling the philosophy of the language and focusing on letting it sip into your skin. Be a good C programmer and you will be a good programmer, period. Not just a good C++ programmer -- this has nothing to do with learning C -- but a good programmer.
There's another reason for learning C first. It's easier than C++, much easier than C++, and it bridges well to C++ (in contrast to Java, which doesn't in all aspects but the most superficial object-oriented ones). I'm not talking about the syntax similarities: I'm talking about low-level programming. I'm talking about the concepts of pointers, which exist as themselves and in the form of iterators in C++. You can pass around functions in C, and you can pass around function objects in C++. C is fast to learn, and it will warm you up very effectively.
Learning C will also eliminate the fear of free functions some pure OO programmers tend to have. C++ is a hybrid language, and C truly is a subset of C++, not just by syntax but by philosophy as well.
Start by getting yourself the K&R book and drinking it through. You won't regret this.
Whatever you start off with, my suggestion would be dump the full fledged IDE's. Use good text editors (vim/emacs)
The learning curve is better when using text editors since everything needs to be written on your own. No prompts and no pre-written code.
You have all the best answers above, in anycase. :)
Ivar
Set up a performant C++ compiling environment such as Microsoft Visual C++ 2008 Express and go through all links in Bjarne Strousrup's The C++ Programming Language site, beginning with C++ Style and Technique FAQ.
If you are experimented in any other language you don't need more :-)
Learn C and C++ at the same time, I'm talking from experience here. Very often I come across code that mixes C and C++, so it's better to know both and their differences. Pick up K&R for C (understand pointers, header files and manual memory allocation and cleaning...which are not used by Java!) and any decent C++ beginner book (I picked Prata, but whatever you are more comfortable with). Practice the same examples doing versions of C, C++ in a sequential fashion, object-oriented (OO) fashion, generic/template fashion etc. C++ has a larger standard library than C: templates, STL containers (no need for pointers, but you can do pointer fine tuning writing your own container), threads (since C++11). You can always use C if you have no choice (or Boost libraries), any C++ compiler will allow it.
If you come from Java you should already know OO concepts for C++, and, perhaps, some generic programming as in C++ templates. C++ is mistakenly regarded as an OO language, but it's more than that. BTW, objects are a dynamic concept (runtime), whereas templates are static (compilation time), so learn the language CONCEPTS, not just the syntax! Once you learn the concepts read Stroustrup's book (he created C++) to learn his philosophy for the best design rules for C++ code.
Learn the latest C++ standard (C++11) as it adds many new things to the language (auto, nullptr, threads, lambda functions, new containers, etc.). Last but not least, please use Doxygen in C/C++ the same way you used Javadoc....there is nothing worse than undocumented, unreadable code no matter what language you're using.
Learn Forth. It has better Objects. And it is a virtual machine. Unless you want a real machine see Green Arrays or Sandpiper/John Rible for that.
Free threaded interpreted versions are all over the 'net. For practice. When you understand it write your own Direct Threaded version. Or see Forth Inc and buy one for your machine or use their free windows version.
Java is a Forth/C hybrid so if you want to go Java you will have some of the stuff under your belt.
Education:
Starting Forth - Brodie
Thinking Forth - Brodie
The second is excellent for any language because it is the best book on factoring I know. Free Versions of both on the net.
If you want to do a hardware/FPGA Forth Stack Machines: The New Wave by Koopman
All the above books are free on the 'net.
Related
Why is it that the C threading library (pthreads) not as popular as the java one when it comes to application development?
Is it just the memory management issue or are there other major advantages involved?
pthreads are not implemented natively on all OSes, such as Windows (there is a Win32 API for that). In fact, C as a language has no concept of threads.
Java was built with threads integrated into the language. C was not.
It's not entirely portable -- pthreads is parts of POSIX, and not normally provided under (for one obvious example) Windows.
C++ 0x adds threading primitives to the standard library (and they're mostly quite similar to pthreads) which is what most new code is likely to start using fairly soon (and some already does).
pthreads are also fairly low-level and kind of a pain to use well; many application programs will probably be better off using futures (roughly similar to the Java objects of the same name) for many of the relatively simple threading situations.
It depends completely on which type of application you have in mind writing. Perhaps the applications you're referring to are more convenient to write in a high level language such as Java.
In addition to the matter of (non-)portability mentioned by others, systems that implement pthreads often also implement cheap and easy multi-process programming, and that was how parallel unix programs were written for a very long time.
I'd say threading is too popular in Java, for example because it is hard to do asynchronous I/O. It looks to me like libraries in Java are designed with the attitude that threads are good. Library designers using C simply have the opposite attitude :)
The Qt framework offers a platform independent implementation for threads in C++.
It has borrowed extensively from java and is a lot newer than some the libraries mentioned earlier so its still gaining in popularity.
Surely this is a question about the popularity of Java vs C rather than one library over the other. I imagine most developers select the development language not the threading library. Once the language is selected this constrains the library choice; after all you cannot use pthreads in Java.
Another point is that in C there is no standard threading library, although pthreads is commonly available on many platforms.
I also doubt the premise; if we assume that you really mean that Java is more popular than C (since that is perhaps the implication), then I doubt it is true generally. In certain application domains maybe, but it is not an easy thing to measure. Depending on how you measure it, you can make Java, C, C++, PHP, JavaScript, Python, and even D look like the world's most popular programming language.
It is possible I suppose that if you choose to use multi-threading, this may lead to a decision to prefer Java (though I doubt that too), but that is a different decision process than choosing pthreads over Java threads.
Java is mainly application programming language so more people and companies are on to it, whereas c is more of a system level programming and core programming which is less popular compared to application programming.
I am learning Java.
I have learned and used Ruby. The Ruby books always tell the advantages of Ruby over Java. But there must be some advantages, that's why lots of people (especially companies) use Java and not Ruby.
Please tell the absolute(not philosophical!) advantages of Java over Ruby.
Many more developers experienced with
Java than with Ruby.
Many existing libraries in Java (That
helps JRuby too).
Static typechecking (can be seen as
advantage and as disadvantage).
Existing codebase that has to be
maintained.
Good tool-support.
More and deeper documentations and
tutorials.
More experiences with good practices
and pitfalls.
More commercial support. That's
interesting for companies.
Many of these advantages are the result, that the Java-ecosystem is more matured, than that around Ruby. Many of these points are subjective, like static vs. dynamic typing.
I don't know Ruby very well, but I can guess the following points:
Java has more documentation (books, blogs, tutorial, etc.); overall documentation quality is very good
Java has more tools (IDEs, build tools, compilers, etc.)
Java has better refactoring capabilities (due to the static type system, I guess)
Java has more widespread adoption than Ruby
Java has a well-specified memory model
As far as I know, Java has better support for threading and unicode (JRuby may help here)
Java's overall performance is quite good as of late (due to hotspot, G1 new garbage collector, etc.)
Nowadays, Java has very attractive and cheap server hosting: appengine
Please tell the absolute … advantages of Java over Ruby
Programmers should rarely deal in absolutes.
I'll dare it, and say that as a rule, static typing (Java) is an advantage over dynamic typing (Ruby) because it helps recognize errors much quicker, and without the need to potentially difficult unit tests1).
Harnessed intelligently, a strong type system with static type checking can be a real time-saver.
1) I do not oppose unit testing! But good unit testing is hard and the compiler can be a great help at reducing the sheer number of necessary test cases.
Reason #1. There's a lot of legacy Java code out there. Ruby is new, there's not so many programmers who know it and even fewer who are good at it. Similarly, there is a lot more library code available for Java than Ruby.
So there may be Technical reasons Ruby is better than Java, but if you're asking for Business reasons, Java still beats it.
The Java Virtual Machine, which has had over a decade of improvements including:
just in time compilation in the HotSpot compiler (JIT - compiling byte code to native code)
a plethora of garbage collection algorithms and tuning parameters
runtime console support for profiling, management etc. of your application (JConsole, JVisualVM etc)
I like this Comparison(Found on link Given by Markus!Thanks!)... Thanks to all... i am also expecting some more discrete advantages
And its Great!!
The language.
My opinion is that the particular properties of the Java language itself lead us to the powerful capabilities of the IDEs and tools. These capabilities are especially valuable when you have to deal with very large code-base.
If I try to enumerate these properties it would be:
of course strong static typing
the grammar of language is a LALR(1) grammar - so it is easy to build a parser
fully qualified names (packages)
What we've got in the IDE so far, for example Eclipse:
great capabilities of exploring very large code bases. You can unambiguously find all references, call hierarhy, usages of classes or public and protected members - it is very valuable when you studying the code of the project or going to change something.
very helpful code editor. I noticed that when I writing code in the Eclipse's java editor I'm actually typing by hand only names of calsses or methods and then I press Ctrl+1 and editor generates a lot of things for me. And especially good that eclipse encourage you to write the usage of piece of code first and even before the code is aclually writen. So you do the method call before you create the method and then editor generates the method stub for you. Or you add extra arguments to the method or constructor in the place when you're invoking it - and editor change the signature for you. And enev more complicated things - you pass some object to the method that accept some interface - and if the object's class do not implement this interface - editor can do it for you... and so on. There's a lot of intresting things.
There is a LOT of tools for Java. As an example of a one great tool I want to mention Maven. Actually, my opinion is that the code reuse is really possible only when we have such a tool like Maven. The infrastructure built around it and integration with IDE make feasible very intresting thinsg. Example: I have m2eclipse plugin installed. I have new empty project in the Eclipse. I know that there is a class that I need to use (reuse actually) somewhere in the repositories, let say StringUtils for example. I write in my code 'StringUtils', Eclipse's editor tell me that there is no such class in the project and underlines it with red. I press Ctrl+1 and see that there is an ability to search this class in the public repository (actually in the index, not the repository itself). Some libs were found, I choose one of them at particular version and the tool downloads the jar, configures my project's calsspath and I alredy got all that I need.
So it's all about programmer's productivity.
The JVM.
My opinion is that the JVM (Sun's HotSpot particularly) is a one of the most intresting pieces of software nowadays. Of course the key point here is a performance. But current implementation of HotSpot JVM explores very cutting edge ways to achieve such really great performance. It explores all possible advantages of just-in-time compiling over static, collects statistics of the usage of code before JIT-compile it, optimise when it possible virtual calls, can inline a lot more things that static compiler can, and so on. And the great thing here that all this stuff is in the JVM, but not in the language itself (as contrary with C# as example). Actually, if you're just learning the Java language, I strongly encourage you to learn the details of modern implementations of JVM, so you know what is really hurt performance and what isn't, and do not put unnecessary optimizations in the Java code, and do not afraid to use all possibilities of the language.
So...
it's all about IDEs and tools actually, but by some reason we have them for Java not for any other language or platform (.NET of course is a great competitor in the Windows world).
This has probably been beaten to death, but my personal opinion is that Ruby excels at quickly created web apps (and frameworks) that are easy to learn, beautiful to read, and are more than fast enough for web apps.
Where Java is better suited for raw muscle and speed.
For example, I wrote a Ruby program to convert a 192 MB text file to a MongoDB collection. Ruby took hours to run. And the Ruby code was as simple/optimized as you could get (1.9.2).
I re-wrote it in Java and it runs in 4 minutes. Yes. Hours to 4 minutes. So take that for what it's worth.
Network effect. Java has the advantage of more people using Java. Who themselves use Java because more people use Java.
If you have to build a big software, you'll need to collaborate. By having a lot of programmers out there, you are sure that there will be someone that can be asked to maintain your software even if the original developers have left the company.
Static type checking and good Java IDE offer no magic and this is good for a lot of maintainer instead of Ruby.
It is not sufficient to indicate that java is statically typed and ruby is dynamically typed.
Correct me if I'm wrong, but does this cover the fact that in ruby you can add to and even
change the program (class definitions, method definitions etc) at runtime? AFAIK you can have dynamically typed languages that are not "dynamic" (can be changed at runtime).
Because in Ruby you can change the program at runtime you don't know until you've actually run the program how it is going to behave, and even then you don't know if it will behave the same next time because your code may have been changed by some other code that called the code you're writing and testing.
This predictability is, depending on the context, the advantage of Java - one of the contexts where this is an advantage is when you have a lot of developers of varying skill levels working on a fairly large enterprise application.
IMHO, what one person considers an advantage might be a disadvantage for someone else. Some people prefer static typing while others like dynamic. It is quite subjective and depends largely upon the job and the person doing it.
I would say just learn Java and decide for yourself what its strong points are. Knowing both languages yourself beats any comparisons/advice some other person can give. And its usually a good thing to know another language, so you're not wasting your time.
Negatives for Java:
There is a lot of duplication in libraries and frameworks available for Java.
Java developers/communities tend to create over complicated solutions to simple problems.
There is a lot more legacy in Java to maintain.
Too much pandering to business users has introduced cruft that makes middle managers feel better. In other words, some philosophies in Java are more concerned with BS instead of getting the job done. This is why companies like to use Java.
You'll generally need to write more code in Java than Ruby.
It takes a lot more configuring/installing/setup to get a fully working Java development environment over Ruby.
Positives for Java:
Speed.
Documentation.
Lower level language than Ruby, which could be a good thing or a bad thing, depending on your needs.
None of my points are very scientific, but I think the differences in philosophy and personalities behind Java and Ruby is what makes them very different to each other.
Better performances
There are more choices:
Developers - lots to hire
Libraries - lots of wheels already invented.
IDE's - lots of development environments to choose from. Not only just vi/emacs + a shell.
Runtimes - if you for some reason do not like the JVM you use on the system, you can either download or buy another implementation and it will most likely Just Work. How many Ruby implementations are there?
Please note that this has nothing to do with the LANGUAGES as such :)
Reading up on this : Is Ruby as cross-platform as Java? made me realize at least one factual advantage of java over ruby:
The J2ME-compatible subest of java is more portable than ruby
as long as JRuby won't run on J2ME which may be forever
I'm a highly skilled Java dev contemplating learning iPhone development. Mac only dev aspects aside, how much of a leap would learning the mobile application stack be? Sure I understand that its closer to C in how one should approach it, and with that comes memory management and so on.
My queries would also include
How well is OOP/OOAD supported?
Is there some API(s) which enable unit testing?
I'd encourage those who answer to quote external sites and references to help elaborate the detail
The development language is Objective-C, which is pure C with a very thin object wrapper over the top. They syntax is kind of weird looking, but it's pretty easy to get to grips with if you know C once you get over the message calls - myself I have a solid C background and only started picking up Objective-C a month or two so back but I'm finding it really rather pleasing - more so than C++.
The difficulty you're going to have if you have only coded Java is pointers and memory management. Memory management isn't conceptually hard as it's simply (!) a question of keeping track of what you are allocating and releasing, plus XCode seems to come with good tools for detecting leaks (although I haven't used these in anger yet) - and as iPhone programs are relatively small it's not like coding a big system program where this can be extremely tough. The major conceptual difficulty you are likely to have is simply getting your head around pointers as they are used extensively (as in just about on every line of code) and you do need to grok these completely. One of Joel's reoccuring themes on the podcast is the difficulty some coders get using pointers, so I'd recommend you take that carefully and possibly pick up a good book - perhaps the original K&R.
Someone may like to correct me, but although the Cocoa API appears excellent, there seem to be few libraries available outside the framework (unlike C++ or Java). For instance I had to add my own queue and stack classes - although the NSMutableArray makes that extremely easy.
All in all though I'm certainly finding it one the most fun platforms to play with I've used for a while.
A few months ago I was a Java web programmer who hadn't touched C since college. Now I've got one iPhone app completed (for my day job, stuck in the bureaucracy there so it's not in the app store yet) and my second app nearing completion.
To answer your question the biggest hurdles are understanding the conventions (Delegate pattern, Categories, etc.), getting a grasp on memory management, and working with XCode (a good IDE but definitely steps behind Eclipse and IntelliJ).
I also think the documentation in the Apple Developer Center website is well-written, and a good developer can get up and running quickly.
To more specifically answer your question, I haven't tried Unit Testing yet but I think the OOP is great - my domain objects in my iPhone apps are as robust and powerful as those I've written in Java.
I came out of college as Java developer. My first (real) job was Mac Development. Transitioning from a language I know (my starting point was Java) to something like Objective-C was fairly easy, code-wise. To maximize your time developing iPhone / Mac Applications, you have to make use of XCode and Interface Builder. Once you get the hang of attaching events and GUI outlets (the objects your UI want to communicate with), you'll be set for normal iPhone app development.
Here are the steps I went through learning Objective-C (the programming language for iPhone development) having my Java background:
Learn the basic OC object-oriented concepts. Subclassing (Inheritance), protocols (Java Interfaces), object properties (Bean properties), methods (you have to explicitly indicate the "parameter entry" labels, unlike in C / C++ / Java where you guess the parameter ordering).
Understand the difference between Objective-C, Cocoa, Aqua, and C. Then learn about how to use frameworks. Frameworks are pretty much the same as Java Packages.
Familiarize yourself with using these Foundation classes: NSString, NSArray, NSDictionary, NSSet, NSURL, NSAutoreleasePool.
Study more about Interface Builder. I thought before that the Visual Basic way of programming limits the programmer. I was wrong. It is better you "visualize" the app first before you get the hang of how things go in it. Take note about the keywords IBAction (analogous to making an EventListener), Outlets (you only have a few objects "exposed" for your UI elements), Views (UIView in case of the iPhone, everything that's "visible" in the application can be considered a "view"), and Controllers (there are ready-made controllers that you could use to populate Table Views, flip Card Views, etc.).
Learn how to deploy your app through the iPhone Developer Portal. You cannot send any iPhone app to any device if you don't have this "right". Yeah, I know it sucks, but you have to go through this process, anyway, if you want to sell your apps.
BTW, you could use the following for unit testing iPhone code: iPhone Unit Testing
Hope this one helps. :)
Objective-C is an object oriented language so, as far as OOP is concerned, pretty much anything you can do in Java you can do with Obj-C.
I don't have any experience with it but here's at least one resource on OCUnit, the objective-c equivalent to JUnit: http://developer.apple.com/tools/unittest.html
The biggest problem I'm having with the transition is definitely the memory-management aspect. Learning the syntax and APIs is pretty straight forward but life's tough without the GC!
EDIT: Oh yeah, the second biggest problem is XCode, the IDE used for Mac/iPhone development. Refactoring support is minimal and I find it a pain to navigate between files. Expect this to slow you down quite a bit, too.
For unit testing there are a few options, OCUnit was linked above. There is also google-toolbox-for-mac.
The OOP in objective-c is good, fairly clean. You will encounter old school C functions on occasion as well.
The API used is called Cocoa-Touch, and is built on Cocoa, which was built from NextStep, so there is a great history of design and refinements out there.
No garbage collection on the iPhone. The golden rule is "If you alloc, then you release". There are plenty of questions on SO regarding memory management, so I won't go into details here.
The major hurdle is the design / architecture differences. iPhone apps and java apps are build using different conventions. So consume as much objective-c / cocoa / cocoa-touch code as you can find / stand.
Spend some time working with Interface Builder, it can be aggravating, but that usually means your not understanding what its up to. Once you have a clear view of how IB works, and what it can do for you, you will really appreciate it.
Cocoadev.com is a handy resource for picking up design and code examples.
Cocoadevcentral.com has an excellent collection of articles, including desktop cocoa development. His learn objective-c article is one of the best you will find.
Get an Apple Developer Connection account if you don't have one yet. You don't have to pay for this one, but will get you into the documentation and tools.
ADC iPhone
iPhone Reference Library API Docs, guides, sample code, The official Apple stuff.
I wouldn't say that I'm an expert in any language but I'm competent in a few. Most of the code I've written recently has been "enterprise"-type stuff.
Assuming you're comfortable learning a new API and language, the biggest difference I found is how constrained the iPhone is in terms of CPU performance and available memory. I'm very used to trading off a bit of memory for better performance -- almost unconsciously -- or being a little wasteful because I've got eight cores at my disposal. That's a really bad idea on the iPhone!
The other hard thing is making sure that it's iPhone-y. Making a good app is not just a matter of shrinking the GUI down, you really need to think about presenting the data effectively.
The technical aspects are all pretty much sorted. The unit test side is less advanced than on the Java side. On the other hand I find that I can be much more productive and less error-prone in Objective C than Java, and this is probably due to the object model which is quite different (you tend to delegate rather than inherit).
Well, Java was based on Objective C and Smalltalk, which are object oriented languages. The big issues will be syntax (which is not entirely C based like C++ and Java), pointers and manual memory management.
This is based on some very old Objective C knowledge, but I do know that when I switched from Objective C to Java (around 2000), it was pretty easy since the underlying concepts were pretty close.
Based on Objective C
Memory management
It is worth mentioning that you can use C++ and C++ objects within your Objective-C code, often referred to as Objective-C++. This can be a valuable approach to separating your data model and other platform-independent code (written in standard C++) from your UI code (written in Objective-C using the Cocoa framework).
If you understand the idea of OOP through your Java experience, and if you have a basic idea of what pointers and memory management are, then the last obstacle in your way will be the alien syntax.
Syntax: I found this tutorial, among others, very clear and concise. In my mind, I conceptually mapped Objective-C and Java infrastructure, which you can do for the most part (i.e. a message is for the most part a method, a protocol is an interface, and so forth). Once you get over the initial shock, you will find that Objective-C development for UI applications can be rather intuitive and pleasant.
Structure: I don't program UI so much, so I found that I needed to get a better grasp of the MVC paradigm.
You may also find some cool language features, such as categories, that you wish you had in Java. I likewise find the lack of some other constructs, such as the lack of static members.
I am primarily a Java developer, and I've been reading a lot of in-depth work on threads and concurrency. Many very smart people (Doug Lea, Brian Goetz, etc) have authored books on these topics and made contributions to new concurrency libraries for Java.
As I start to learn more about Python, Ruby, and other languages, I'm wondering: does all of that work have to be re-created for these languages?
Will there be, or does there need to be, a "Doug Lea of Python," or a "Brian Goetz of Ruby," who make similarly powerful contributions to the concurrency features of those languages?
Does all of this concurrency work done in Java have to be re-created for future languages? Or will the work done in Java establish lessons and guidance for future languages?
The basic principles of concurrent programming existed before java and were summarized in those java books you're talking about. The java.util.concurrent library was similarly derived from previous code and research papers on concurrent programming.
However, some implementation issues are specific to Java. It has a specified memory model, and the concurrent utilities in Java are tailored to the specifics of that. With some modification those can be ported to other languages/environments with different memory model characteristics.
So, you might need a book to teach you the canonical usage of the concurrency tools in other languages but it wouldn't be reinventing the wheel.
Keep in mind that threads are just one of several possible models for dealing with "concurrency". Python, for example, has one of the most advanced asynchronous (event based) non-threaded models in Twisted. Non-blocking models are quite powerful and are used as alternatives to threads in most of the highest scaling apps out there (eg. nginx, lighttpd).
Your assumption that other popular languages need threads may simply be a symptom of a java centric (and hence thread-centric) world view. Take a look at the C10K page for a slightly dated but highly informative look at several models for how to handle large volumes of concurrent requests.
I think the answer is both yes and no. Java arguably has the most well-defined memory model and execution semantics of the most commonly used imperative languages (Java, C++, Python, Ruby, etc). In some sense, other languages either lack this completely or are playing catch-up (if that's even possible given the immaturity of the threading models).
C++ is probably the notable exception - it has been treading the same ground for C++0x and has possibly gone beyond the current state of the Java model from my impression.
I say no because the communities are not isolated. Many of the guys working on this stuff are involved (at least from a guidance point of view, if not from a direct hand in the specs) in more than one language. So, there is a lot of crosstalk between guys working on JMM and guys working on C++0x specs as they are essentially solving the same problems with many of the same underlying drivers (from the hardware guys at the bottom and the users at the top). And I'm pretty sure there is cross-talk at some level between the JVM / CLR camps as well.
As others have mentioned, there are also other models for concurrency: actors in Erlang and Scala, agents/STM in Clojure, FP's rise in F#, Scala, Haskell, the CCR and PLINQ stuff in CLR land, etc. It's an exciting time right now! We can use as many concurrency experts as we can find I think.... :)
This is not flame bait, but IMHO Java has one of the simpler and more restricted models for threading and concurrency available.
That's not necessarily a bad thing, but at the level of granularity it offers it means that the perspective it gives you of what concurrency is and how to deal with it is inherently limited if you have a "java centric" view (as someone else put it).
If you're serious about concurrency, then it's worth exploring other languages precisely because different models and idioms exist.
Some of the hottest areas are lock-free programming (you'll see a lot of it, but often done badly, in C++) and functional programming (which has been around for a while but arguably, is becoming increasingly relevant. A prime example in the case of concurrency is probably Erlang).
Kamaelia is a project (which I started, and continue to work on) that has specifically the goal of making concurrency a tool you want to use, rather than a pain to use. In practical terms this means that it is primarily a shared-nothing model with message passing model (based on a world view from Occam & Unix pipes).
Underlying that goal is a desire to make concurrency easy to use for the average developer, shielding them from the nastier problems caused by a number of approaches to concurrency. (There's a bunch of presentations on slideshare explaining the why & how there)
Additionally it provides a simple software transactional memory model for the situations where you must share data, and uses a deliberately simple API.
Kamaelia's primary implementation is in python, with a toy implementation in Ruby & C++. Someone else has ported the underlying approach to E and also to Java. (though the Java person has disappeared) (The toy implementations are sanity checks the ideas can work in other languages, if needing to be recast as local idioms)
Perhaps your question shouldn't be "what can these languages learn", but "what can the Java community learn by looking elsewhere?". Many people who learn python are liguistically immigrants from elsewhere and bring their knowledge of other languages with them, and so from where I sit it looks like python already looks out to other languages for inspiration.
Picking something concrete, for example, this speak and write application - which is a tool for teaching a small child to read and write, based around pen input, handwriting recognition, and speech synth - uses several dozen concurrent subsystems, runs at an acceptable speed on a single core machine, would be easily amenable to running on a many-core machine. However, the reason for the number of concurrent subsystems however has nothing to do with "wanting to make the application parallel", but more to do with "How can I make the application easier to write, extend and maintain?". The fact it ends up embarassingly parallel is a secondary bonus.
There's a full tutorial - Pragmatic Concurrency - linked from the front page. (Notes, slides, video & code bundle)
The model can be improved, and suggestions are welcome - life would be very boring if we all just "stopped" trying to make better tools - but ignoring what already exists seems a little ... parochial. If that seems a little harsh, please look at today's dilbert.
I'm a pretty experienced Java programmer that's been doing quite a bit of Win32 stuff in the last couple of years. Mainly I've been using VB6, but I really need to move to something better.
I've spent a month or so playing with Delphi 2009. I like the VCL GUI stuff, Delphi seems more suited to Windows API calls than VB6, I really like the fact that it's much better at OO than VB6, and I like the unit-testing framework that comes with the IDE.
But I really struggle with the fact that there's no widely-used garbage collector for Delphi - having to free every object manually or use interfaces for everything seems to have a pretty big impact on the way that you can do things effectively in an object oriented way. Also I'm not particularly keen on the syntax, or the fact that you have to declare variables all at the top of a method.
I can handle Delphi, but I'm wondering if C++ Builder 2009 might be a better choice for me. I know very little about C++ Builder and C++, but then I know very little about Delphi either. I know there's a lot to the C++ language, but I suspect it's only necessary to know a subset of it to get things done productively... I have heard that the C++ of today is a lot more productive to program in than the C++ of 10 years ago.
I'll be doing new development only so I wouldn't need to master every aspect of the C++ language - if I can find an equivalent for each of Java's language features I'll be happy enough, and as I progress I could start looking at the more advanced stuff a bit more. (Sorry if that sounds painfully naive - if so please set me straight!)
So, for a Java programmer that's new to both Delphi and C++ Builder, which would you consider to be a better choice for productive development of Win32 exes and dlls, and why? What do you see to be the pros and cons of each?
Delphi or C++ Builder - it's a difficult choice!
As you're aware, they're basically very similar, from the IDE and RAD point of view.
The pros and cons of each - irrespective of background - are a bit like this. Both share a great 2-way RAD form designer and framework (VCL) that are ideal for native Windows development.
Delphi:
FOR: Large, active, enthusiastic community
FOR: Delphi 2009 is the best version for many years
FOR: Delphi "units" make C source/header file pairs seem archaic
AGAINST: No automatic destruction as objects leave scope, hence lots of 'finally's in your code
AGAINST: Language can be 'wordy', which is a matter of taste
AGAINST: Using third-party DLL's or libraries in other languages (esp. C) requires Delphi header files to be written
C++Builder
FOR: C++Builder 2009 is probably the best version ever
FOR: RAII idiom simplifies memory management hugely
FOR: Templates are incredibly useful and powerful, even if the C++Builder implementation has some bugs with them.
FOR: Support for BOOST and other modern template-based libraries (even though the Boost support is not 100%)
FOR: Great interop with Delphi means most Delphi components can easily be used.
FOR: Easy to use with third-part DLLs/libraries with C/C++ headers.
FOR: C++ may look better on a CV than Delphi.
AGAINST: CB2009 is "unicode only" - the implications of this for code portability are different and less well thought-out than for Delphi
AGAINST: C++Builder user-base is much smaller than Delphi. Maybe 20% or less.
AGAINST: Borland/Inprise nearly killed BCB a few years ago, and it was only resurrected after major efforts from the community. (However, Codegear/Embarcadero commitment does seem impressive)
AGAINST: C++Builder is not top of the pile within Codegear.
AGAINST: Third-party component vendors don't always understand/support C++Builder
That's about it. Just to state my position, I'm a happy BCB2007/2009 user (since BCB5), and I also infrequently use Delphi. A few years back, I considered a switch from C++ to Delphi, but the lack of RAII idiom was the one thing that I found difficult to come to terms with.
Go with Delphi and you can use the Boehm Garbage Collector API written by Barry Kelly so you can have garbage collection in Delphi. Barry wrote this before he went to work for CodeGear as a compiler architect. It does have issues with really large applications, and most likely won't work with 64-Bit Delphi. He talks about it quite a bit in this podcast interview.
Even if you don't use that garbage collecting memory manager, I would still recommend Delphi over C++. The only advantage C++ gives you for general development is the curly brace syntax. If you don't mind the Delphi syntax, then for most things you will find it better. Granted C++ Builder has the whole Delphi VCL and RTL, so it isn't as bad as Visual C++, but I still think Delphi would be a better choice.
For Excel add-ins (as you mentioned in your comment) I would recommend Delphi over C++ builder because it has better COM support (which I believe you need for Excel add-ins).
Delphi will be a lot easier for you to come to terms with, sure you have to manage your memory, but its very simple
MyObj = TMyObj.Create;
try
MyObj.DoSomething;
finally
MyObj.Free;
end
In Delphi all your objects are allocated on the heap, so the rule is very simple if you create it you free it.
C++ with its stack and heap based objs means you have a little more to learn and more scope for getting into trouble.
After working with Borland C and C++ compliers since BCC 4.1/DOS and Delphi from 3.0 thru 2007 I can tell you honestly that you're in for a great adventure either way. Moving from C/C++ on Borland's Builder and RAD IDE's is a substantial paradigm shift (and learning curve) from Microsoft's VC++, C++ and .NET (have used VC from the first MS-DOS release -- the beige three ring mini binders).
The choice between C++ and Delphi is one I suggest you make after getting your feet wet on a few small to mid sized projects in both languages. I started out a C programmer and after about five years switched to Delphi (V3.0) when the VCL just made Windows programming a lot easier and more productive.
Be warned, Delphi is a seductive language for programmers coming from other languages like COBOL, FORTRAN, VisualBasic because its syntax and code rules enforce a kind of discipline that keeps one out of trouble. The terseness and raw metal power of C makes it a great systems programming language (device drivers, O/S code, real-time embedded programming), but in inexperienced hands it can bite you.
Borland's C++ Builder (Delphi's VCL added to C++ compiler) takes many of C++ sharp edges off and is my second favorite language. Since Borland added .NET support to both languages
there's a strong argument to use Builder instead of VC++ for MS framework programming. Although C# has a good amount of 'friendliness' built in compared to C++, if pushed I'd still stick to Delphi or Builder if I was just starting out.
For learning the ropes, for prototyping and quick concept programs there is simply not a language out there that can beat Delphi especially with the VCL and the third party components. No hype, just facts.
Personally, I think there are other important considerations apart from the differences between the languages. For example, the Delphi IDE is totally freakin' awesome for building GUIs in a WYSIWYG fashion. I haven't used the C++ builder IDE, but I'd be really surprised if it has a GUI builder that's as nice as Delphi.
Although superficially the syntax of C++ looks more like that of Java, Delphi's object model is actually closer to that of Java. Although pointers exist in Delphi, in practice object references (like those in Java) are used 99% of the time. Even in modern C++, I don't think it's possible to avoid pointers. Not that there's anything wrong with pointers per se, but in practice....
On a personal note, I'm mostly a Java guy these days, but I spent 2 years working with Delphi and would go back to it in a heartbeat. In contrast, I have only very limited experience with C++ and would prefer to clean toilets than return to that language :)
I think if you go with Delphi you will find it more easier after few times of using, also it has more third party support and some of the features introduced in Delphi before C++ Builder
also read this blog from ex-Java and now the guy behind most of database and datasnap work in Delphi Steve Shaughnessy, about his experience about programming Delphi after 10 years of Java :-)
http://blogs.codegear.com/steveshaughnessy/2006/12/03/30193
Of course java sintax is more like c++ than like delphi, but I think that the object model is more similar to delphi:
single inheritance. Interfaces exist but are more like COM than like java interfaces.
objects are allocated on the heap and accessed by reference
you can find a paper comparing the three languages here
There is nothing I haven't been able to do in C++ VCL that I couldn't do with Delphi VCL and almost all Delphi components work fine in C++ Builder. Since I program for both Windows and UNIX, C++ is more portable.
If you use C++ STL or an other well designed library for your containers, garbage collection sort of becomes a moot point, and otherwise manual GC is not difficult (one quickly learns good habits - which you should be practicing anyways irrespective of a GC). As long as you use RAII where possible, keep your memory management encapsulated in containers, be clear on object ownership and only use pointers as nilable references (all of which you should also be doing irrespective on the language), GC really should not be an issue.
"For example, the Delphi IDE is totally freakin' awesome for building GUIs in a WYSIWYG fashion. I haven't used the C++ builder IDE, but I'd be really surprised if it has a GUI builder that's as nice as Delphi."
Actually the C++Builder GUI editor is exactly the same editor, and works in the same way. It is fantastic.
.Net has a huge number of classes, much like Java. C# has similar syntax to Java and because of the huge class library works fairly similarly. And it's a perfectly adequate environment to program in. But frankly Delphi is a much more pleasant language, IDE and general environment to work with. C# was designed by the same person who designed Delphi and "feels" very similar in many ways, so don't assume that because Delphi compiles to native code (though you can use Delphi .Net as well) it's fundamentally harder to use. It's not, at all.
My personal recommendation would be for Delphi, because it's a cool language. However if you're interested in learning C++, C++ Builder is probably the nicest way you could do it.
I program professionaly in Delphi for the last 10 years and have a good knowledge of C++.
I'd go to the Delphi way. Syntax is much simpler and memory management also. That GC for native Delphi I don't have heard yet... Although I didn't like much the traps on Delphi.Net code introduced because of the .NET gc, I'm not much fond of gcs ;-)
One thing I forgot to mention before:
From a cost perspective, you don't really need to choose. Buy the RAD Studio package, and for a modest extra cost over one individual language, you get both Delphi and C++Builder personalities in the same IDE.
And, it's worth mentioning that the C++Builder package includes the Delphi compiler, and you can write/add Delphi .pas files and include them as part of your C++ projects.
If you're going to do a lot of Windows programming, learn C++. Would you learn German in preparation for a trip to France? C/C++ is the native language of the Windows API. Dealing with WinAPI data structures and calls is so much simpler in C/C++. As to RAD, I've used MSVC for about 13 years and I can whip together a GUI app as quickly as anybody using Visual Studio's GUI editor.