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.
Related
I need to choose a language/platform for the new development of a series of services in a SOA. I'm looking into Scala and Clojure but don't think the community and products are mature enough for a real-world enterprise product yet.
Update/Clarifications:
Of course we can use many languages/platforms for SOA but some language/platforms are easier and more suited for an SOA. IMO the best ones for SOA should allow interface programming (to ease definition of contracts), should have options for hosting the services (like Felix for Java or WCF in .NET) and scale well (see Twitter issues with RoR).
Java has always been the favourite in the enterprise market. However, many developers are looking into dynamic languages as well as talking about stagnation of Java after v6. As a result many new post Java languages have arrived: Scala, Clojure and Groovy to name a few that still run on JVM but are not Java.
I hope these clarify the question.
Depends what you mean by "mature enough for a real-world enterprise product", and your relative level of tolerance for living on the cutting edge.
For example, I'm currently building a "real-world enterprise product" in Clojure (I'd have been equally happy with Scala, it was only that Clojure fitted my needs slightly better from the concurrency and meta-programming perspective).
I'm very happy with my decision.
Some quick perspectives if you are considering this "post-Java" path:
The communities are great and supportive, but you'll still have to solve problems yourself, if only because nobody else has run into the same problem yet. None of these are likely to be insurmountable, but it does present a bit of extra risk to delivery schedules.
Both Scala and Clojure can be very productive (in terms of value delivered to customers per hour coding), but you can equally well write bad and unmaintainable code in any langauge. Java pretty much forces you to write things in a standardised, somewhat verbose but syntactically simple and understandable way. With Scala and Clojure you get a whole new arsenal of crazy ways to hit your target or shoot yourself in the foot. Is your team going to be able to make the best use of Scala/Clojure advantages?
It's harder (though by no means impossible) to bring skilled people on board with existing Clojure/Scala skills. On the flipside, the people who do have these skills (or are keen to acquire them) are likely to be among the more talented / motivated developers so the search may still be productive.
Be prepared to make tough decisions regarding whether to target language/library features that are "just round the corner". For example, do you wait for the enhanced primitive support coming in Clojure 1.3? Or make do with the perfectly adequate but slower boxed primitive functions in Clojure 1.2?
A great benefit of being on the JVM is that you can still take full advantage of the Java ecosystem without being tied to Java as a language. Don't underestimate how useful this is: for example, I use a number of extremely well tested, mature Java libraries (e.g. Netty) pretty much transparently in my Clojure application. This significantly reduces your risk and the amount of new development that you need to do.
At the moment (having just completed a services/integration project ) Jersey on top of Spring are right up there on my favourites list for web services.
I can't offer any suggestions for a SOA framework, last time I was involved in that type of thing we user Oracle BPEL Process Manager and I have mixed feelings about it. We weren't using REST then either and I'm not sure how well the Oracle software works with it.
For me python seems the easiest way to do some SOA and have interoperability with Windows computers. I don't have frameworks name but there is a lot of them in SOAP, REST, RPC...
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.
I am new to Web Programming and I hear that there are many biggies like Java, .Net and PHP for Web Application Development.
I would certainly appreciate if I can get some insights on how this technology stack up in comparison and in what scenarios one would prefer one technology over the other.
Thanks for all guidance in advance.
PHP has low resource requirements, really cheap hosting, really low barrier to entry and is the most popular Web framework bar none.
That being said, PHP is a purely interpreted language (opcode caches notwithstanding) so tends to be slower than Java (not that that usually matters), the syntax is inconsistent and it's easy to make huge errors (like not sanitizing database query inputs; but you can do that in any language).
Neither is better than the other. For casual Web development I definitely prefer PHP most of the time. Java is probably better for more "enterprise" type software.
This is just my opinion:
PHP is a great language for building the web pages themselves. It is relatively easy to learn. And it is very easy to combine the static HTML and the custom generated one. It is quite powerful. For example, Wikipedia's MediaWiki is written in PHP. It is also straightforward to access databases. But in the end, it is essentially a scripting language.
It's hard to write maintainable code, and complex logic (e.g., a lot of calculations, algorithms, etc.) is not very natural in PHP.
Java is more of a "serious language". It can do a lot of things. Including web. However, creating the HTML is more "painful" and less natural than in PHP. Java shines, however, where there is a lot of smart logic in your program. There are also advantages to writing in non-scripting languages. And of course, if you know Java, you can use it for a lot of things.
.NET is nice, but generally restricts you to windows platforms, and the best tools are not free (unlike Java). I would only go into .NET if your local job market has a lot of .NET jobs, that changes a lot from place to place.
Also, PHP jobs generally pay less than Java/.NET jobs and seem to have a lower reputation.
If you're new to web application development, make sure to give Ruby on Rails a try as well. It's a joy to work with compared to Java and PHP (I've worked with all 3). It's fast, common tasks are very easily accomplished and the community is huge and vibrant.
One thing to look at when making your decision is how you are going to host your web-app. If you are looking to host it somewhere cheap you will be limited to what you can use, most likely things like PHP or ASP. If however you are willing to spend more money (or host yourself) you can get more control over your hosting and therefore make use of more technologies.
I have fairly good control over my hosting package but I have stuck with PHP because I found it easier to get to grips with having not really done anything like it before.
I agree that the barrier of complexity to entry for php is lower, so on average you probably get more supply (php programmers), more demand (php type jobs), at a lowered-by-competition price (lower job salaries on average).
From a starting web-programmer perspective, php is good because you can use it in so many ways, html + a tiny bit of scripting, extensive procedural programming, OOP, and even something resembling functional programming. Since the web is so easy to get an audience for your software, you can really keep learning while you're doing. Php is what let me break into programming, which I don't think I would have managed if I were working with a language less tied to the web. After a good 6 years, off and on, I've got myself to the point where I'm comfortable with php as a job, but am looking to personally break from web programming to off-the-web programming (trying to get into clojure) and different languages. After all this time, I've become more and more aware of the often-lacking-security and the filled-with-legacy-functions nature of php.
The php language itself has a huge base of relatively high level functions built in that match tasks that people have done in the past, so you can get some complex concepts distilled into simple functions, even before you go messing with the many choices of libraries that are out there. So you can pretty much work with a huge body of code out of the box on most servers.
So it's an enjoyable way to break into web programming and build up your body of knowledge, a great jump-off points, though not such a specialized language that you can rake in the dough without a lot of work. From a hiring perspective, it's probably pretty easy to pick up a kid off the street who can write a quick web-app in php (that probably describes me a few years ago), but much harder to get someone who will write code that will be maintainable in five years.
Oh, and one more thing: doing programming needs source control, so get to know git and github.com or gitorious.com. It's hard when you first start to get into it, so cheat and use whatever tools and aids you can, but it's so worth it to have the freedom of being able to write whatever kind of programming you want.
The git website about git:http://git-scm.com/
Github guides on git: http://github.com/guides/home
It'll open up how you work and prototype.
People make a good point about the inconsistencies of PHP. However there are numerous frameworks available that alleviate a lot of the problems of 'vanilla' PHP. So the low barrier of entry + huge community + numerous frameworks = the best web programming language IMHO.
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'm trying to learn Java but it just seem like there are too many parts to put together.
You have JSP, Java EE, Java SE, Java ME etc....
I can get Netbeans to do basic but just taking a peek at spring framework it seem like a lot of work to get it to run in the ide from the numerous configuration .
I want to get into web programming and maybe mobile.
Any advice?
Another programming language?
Is java this complex or does it get easier?
Java as a language is certainly not too complicated. J2EE in its entirety is only just about feasible for a one-man team - but you rarely need the whole of J2EE.
It's perfectly reasonable for a one-man team to implement a medium-sized web application. I'm not saying one person could write GMail on their own, but you shouldn't be too scared of the technology stack - find the bits you actually need and concentrate on those. On the other hand, that in itself takes a fair amount of experience - I wouldn't really want to be starting off on an enterprise app (even a small one) on my own as a newcomer to Java.
Start small. Learn the core (the language, IO, collections) - and then start with small projects. Work out whether you want to be in mobile, desktop, server or whatever - don't try all of them simultaneously. Gradually you'll build up your experience.
It's not that Java-the-language is complex, it's that vast libraries and frameworks exist that can help you do your work. This is true for many programming languages. Look at CPAN for Perl, for example. What language to use depends in great part on what your goals are.
You can start simple and work your way up to larger and larger projects.
Java is by no means too complex for a one-man operation, but learning any form of full-formed web programming is a lot to learn when it's all new. If you were looking at .NET for the same purpose, there is a lot there too.
Unless you are doing huge-enterprise applications, ignore all of J2EE except for JSP and JMS and a very few other components. The lion's share of J2EE is only useful in the context of an enterprise application that needs to scale, and in fact can be harmful when used in smaller applications.
The frameworks such as Spring, Hibernate, Apache-*, Web Services, and so on help you do your job, but are yet more things to learn to do your job. There is a lot to learn.
Should you use Java? Well, quite a lot of development is done with LAMP (or WAMP): Linux (or Windows) + Apache-HTTPD + MySQL + PHP. With this, you don't need to worry about Java or .NET or any of those frameworks. LAMP/WAMP works very well for a wide class of applications.
Java and .NET on the server are (sort of) more appropriate for larger services, but once you are familiar with them, they work just fine for smaller services as well.
You have to decide what your exact goals are, then look at how people have implemented the kind of thing that you're looking at doing. This will help you figure out what technologies are the most necessary for the niches you're looking at going into.
Java -- the language -- is one of the simplest strongly typed languages in existence. Vastly simpler than C++ or even its close cousin C#, I would argue.
The standard APIs/libraries really are huge, but nobody learns the whole thing. You're suffering from the intimidation all beginners feel when they look at something that big and new, but this will pass as you just do stuff. First, you need to learn the standard utility stuff -- the collections in java.util, mostly -- and then, for basic web dev, probably next the JDBC library and Java Servlets and JSP. And that's it.
As an alternate tact here...
Another problem you will encounter in Java is Choice. You have a LOT of it in terms of frameworks and technologies etc.
My best advice is search around for about a day if you're so inclined to find what technologies attract you, or who's arguments sway you. Then, pick one. ANY one. Really, it doesn't matter, especially for a first project. They all have learning curves, they all have strengths and weaknesses, they all have fans and foes.
The key though, is once you have chosen, STICK WITH IT. You will inevitably stumble upon some problem, you will pose this problem to someone else, someplace else, and they will say "oh, you should have used QED instead of KnifeForkSpoon". And you will second guess yourself, go off and hear about the wonders of QED, and all of the kittens born under it and hungry children fed by it. If you succumb to that siren song of "greener grass", your project will flail. (Not fail, flail.)
Don't be wooed, don't fall for it. Just fix your problem and move on. At the end, and you're on a new project, THEN go and look for the more bestest greatness silver bullet.
As an aside, if I were just getting in to web programming today in Java, I would humbly offer this simple recipe:
JSP 2.0 with JSTL for markup and presentation
Stripes or Struts 2 for logic (note Struts 2 (TWO), Struts 1 is plain evil)
"raw" JDBC with a database pool for persistence
Tomcat or Glassfish for a container (tomcat more popular, GF easier to use out of the box)
Netbeans or Eclipse (NB is easier to use out of the box)
This uses the most fundamental, yet functional facilities for web apps in Java today, lots of applicability, and solves the major issues of a web app without covering them up with thick, impenetrable layers.
You will learn a lot using these "crude" tools.
You need to learn to pick your battles. Covering the whole J2EE is a massive task and, for most, unnecessary to begin with. I think a common mistake for beginner programmers is that they think they need to learn everything. You'll find your time much more productive if you focus on the core language constructs to begin with, and focus on either web or mobile programming.
You'll be extremely surprised (and pleased) at how much you can carry over from one area to the next. Once you know the language, the different libraries for different platforms are just tools...Stick with Java. It is a good language to learn.
Can I take "get into web programming" to mean that you're just learning web programming in general? If that's true, if you have the time you might consider setting Java aside temporarily and giving LAMP/WAMP a closer look as Eddie suggested. (Though I'd personally use Perl instead of PHP. PHP is sexier resume fodder and lets you do some very cool things on the front end, but in my experience, when it comes to writing server-side code Perl simply blows PHP's doors off. And I've heard that the HTML::Mason extension puts Perl on pretty even footing with PHP's front-end niftiness, but I haven't used it myself.)
I've made a living writing writing web apps in Java and web apps in Perl. I'm fond of both languages, but as a learning tool, I'd put Perl well ahead of Java. As you're finding out, Java's a bulky bastich. Part of that is, as others have mentioned, a function of Java being a mature language with a variety of extensions that are unlikely to apply to your immediate needs. But even stripped down, you'll still need to deal with quite a bit of overhead before you can even get your first "Hello World" web app to run. Comparatively, you'll get rolling much quicker with Perl.
(In fact, Java tends to be pretty verbose in general compared with other languages. That's not necessarily a bad thing; my one big complaint with Perl is you often encounter code that leverages various shortcuts and side effects to do an unholy ton of work in just a few lines. This code is often brilliant, elegant, compact, and utterly bloody unintelligible to a non-expert. Terseness is not a virtue for the poor idiot who has to modify code six months after it was written -- especially when you wind up being the poor idiot in question.)
And as a way of learning web programming, Java's sophistication can actually work against it. As a professional, I'm glad Java's web-based tools automagically take care of a lot of grunt work for me, like session management. But I didn't completely understand what it was doing until I was thrown into a Perl-only environment and had to deal with all that stuff myself.
I guess it depends on why you're doing this and how much time you can devote to it. If time is limited and you're looking for something that will appeal to prospective employers, then yeah, Java's an excellent choice, and you've gotten some solid advice in this thread about how to get started using it.
But if you do have the time, I highly recommend giving old-school Perl/CGI programming a sniff. It ain't a particularly marketable skillset anymore, but you'll learn things worth knowing.
You don't have to learn all of Java and its libraries. Just learn what you need for the job at hand. You will find there are plenty of options, but you don't have to get the best option every time.
If your base programming concepts are clear no
language should be difficult for you. I have switched over from vb 6 to java to c# to objective c now. What really makes a coders life easy is the IDE, debugging tools, documentation and lot of blog posts which google can search :-) regarding one man team my personal view is I am at my best when left to code and research alone with the help of google and stack overflow ofcourse :-) so I do think in programming large sized teams often lead to more screw ups than results
Java is not a complex language, altough it looks frightening at first.
I started learning Java from home, not a school, at 15 years of age (yes, yes, I know that's nothing to brag about) trough a book. It's a norwegian book, so I won't link to amazon;)
After reading/hacking trough half the book I found out I was better off ditching the book and looking for more stuff online. Google really IS awesome!
I would often read about all the fancy features of the JVM, frameworks, third-party libraries, JSRs and so on, and how much better my life would be with them all, but I just ignored them all. Yes I tried, but found it too confusing to learn Java and a framework that wasn't really necessary, at the same time.
Some people gave me hell for not using insertRandomLibraryName() or insertFancyFrameworkName(), and told me all about how much time and effort i would save, but I'm glad I didn't listen.
Now times have changed, and I still learn new things, or easier ways to do old things, every day. And I'm glad I took the time to learn the language itself before all the fancy stuff.
Also, don't use a notepad for writing code, use an IDE from the beginning. The only one I've ever really used is NetBeans, so that's the only thing I can recommend, but I sure am really happy with it!
As to Java SE, ME and EE, start with SE, and you'll propably find that it's enough for now. You don't have to use EE to write for the web, SE is fully capable of webernet stuff;D