macOS Xcode for Java?

[ITASOR]

I downloaded Xcode 2.4 and went to install it, but I stopped because I have some questions. Should I be using Xcode for Java stuff? I don't know Java, but I'm supposedly supposed to be learning it. If it's good for Java, what do I need and what don't I need? I'm not too fond about giving up 2.7GB only because I don't know what to uncheck.

Thanks!

 

[plinden]

I downloaded Xcode 2.4 and went to install it, but I stopped because I have some questions. Should I be using Xcode for Java stuff? I don't know Java, but I'm supposedly supposed to be learning it. If it's good for Java, what do I need and what don't I need? I'm not too fond about giving up 2.7GB only because I don't know what to uncheck.

Thanks!

You can use XCode for Java, but if you're learning Java, the best way to start (and learn what you really need to know about it) is to use a text editor (like TextWrangler, which has syntax highlighting) and the command line. You should already have the Java SDK installed (but I'm not sure about that, I can't remember if I had to install it on my Mac or if it was there already)

Then when you get better at it, and are learning how to create Java UIs, it probably better to use a crossplatform IDE like eclipse, which will make you more productive eventually with things like autocompletion, syntax checking etc. The simple applications you will write while learning will be easy enough to keep track of with a text editor, but if you get involved with a large project, you will lose track of what's happening very quickly.

But really, keep away from any IDE including XCode and Eclipse for a few months. Learn how to compile on the command line using ant and build.xml files.

 

[Kunimodi]

But really, keep away from any IDE including XCode and Eclipse for a few months. Learn how to compile on the command line using ant and build.xml files.

I know what you mean and I mostly agree, but I think Eclipse can actually be a big help for people learning Java:

• Autocompletion
• Javadoc Integration
• Continuous Error Checking

I think the key is to avoid either GUI RAD design or learning an IDE instead of a language. Ant is reasonably complex, however, and I think learning that does not benefit a person's understanding of Java.

 

[mrichmon]

I know what you mean and I mostly agree, but I think Eclipse can actually be a big help for people learning Java:

• Autocompletion
• Javadoc Integration
• Continuous Error Checking

The problem with people learning to program in Eclipse is that autocompletion and continuous error checking gets in the way of learning how to write code. Instead, many people end up falling into the habit of changing things randomly to eliminate errors. The autocompletion ends up enabling and reinforcing this approach to coding.

Now, admittedly I often lean heavily on autocompletion when I am exploring a new and undocumented API. But the difference is that I have over 20 years of coding experience and 10 years of formal training in software engineering. For experienced developers an integrated IDE with continuous error checking, document integration, autocompletion and automatic refactoring support makes the developer more productive.

The productivity gains with something like Eclipse are mostly about eliminating tedious parts of writing code... the parts that any experienced developer does not need to think about. But, for someone who is trying to learn how to write code, it is vital that they both know and understand these simple aspects of writing code. The understanding that comes from these simple things go a long way to helping the proto-developer learn programming and the basic theory behind development.

 

[Eraserhead]

I think XCode is OK for learning Java, I used it (and haven't asked too many questions (OK I lie, I've asked loads and thanks for all the answers!))

To be honest you need a program with syntax colouring and that's about it, XCode is nice in that you can also press the big build button and it verifies your code is correct (and you haven't made any typos which I do regularly) without having to use the command line which is easier for a beginner, I'm not sure myself on the big advantage of compiling on the command line though I suppose it gets you used to it which is definitely a good thing for programming. I never used auto-completion in XCode as it's not very good IMO (certainly at least for Java, Obj-C is OK though).

 

[Kunimodi]

The problem with people learning to program in Eclipse is that autocompletion and continuous error checking gets in the way of learning how to write code. Instead, many people end up falling into the habit of changing things randomly to eliminate errors. The autocompletion ends up enabling and reinforcing this approach to coding.

A vast amount of newbie difficulty comes from very simple typos and errors. You probably won't forget to put a semi-colon on the end of a line (although fact of the matter is even experienced programmers make typos and thinkos every day), but a new programmer very well might. Saving someone frustrating minutes or hours of time because they didn't properly match their parentheses is a kindness that will not impair their learning to program.

Also a new programmer (especially in a language with a huge base library like Java) is going to be continually referring to the documentation. Showing them the correct possibilities and inlining the JavaDocs is a huge help to them and is equivalent to them looking it up except that it is vastly more efficient.

For experienced developers an integrated IDE with continuous error checking, document integration, autocompletion and automatic refactoring support makes the developer more productive....The productivity gains with something like Eclipse are mostly about eliminating tedious parts of writing code... the parts that any experienced developer does not need to think about.

Would you agree that those two statements are not the same? I think, with the exception of automated refactoring, the benefits you listed in the first statement definitely apply to new programmers as well.

 

[mrichmon]

A vast amount of newbie difficulty comes from very simple typos and errors. You probably won't forget to put a semi-colon on the end of a line (although fact of the matter is even experienced programmers make typos and thinkos every day), but a new programmer very well might. Saving someone frustrating minutes or hours of time because they didn't properly match their parentheses is a kindness that will not impair their learning to program.

Parenthesis matching is available in many, many plain old text editors. This feature has nothing to do with syntax aware auto-completion that was mentioned earlier. The experience of forgetting a semi-colon and then tracking down the problem may take time. But it is not wasted time if the programmer pays attention to the compiler errors and thinks about what is going on. Error marking short-cuts this process and in the long run generally results in a less capable developer because the developer has never been forced to understand what is going on.

Also a new programmer (especially in a language with a huge base library like Java) is going to be continually referring to the documentation. Showing them the correct possibilities and inlining the JavaDocs is a huge help to them and is equivalent to them looking it up except that it is vastly more efficient.

A new programmer is different from someone who is just learning how to program. Someone who is only just learning how to program should not be touching much of the massive base library that Java offers. However when they do touch the library it is well worth the time for the new programmer to develop the skill of skimming the relevant library documentation to find the information they need. But again, a learning programmer should not be touching the library documentation very often.

Would you agree that those two statements are not the same? I think, with the exception of automated refactoring, the benefits you listed in the first statement definitely apply to new programmers as well.

In my opinion a learning programmer should not be concerned with efficiency of producing code. Rather, they need to focus on learning how to program. As I pointed out, the simple/repeatative/tedious parts of writing code that can be automated by tooling is vital to learning how to program. In my experience teaching programming the simplicity and repeatition of these parts of the code very much help to ingrain an understanding of what the language is doing and help establish good coding style and practices.

 

[Kunimodi]

Thank you for taking the time to reply. I think I share some of your sentiments and I definitely believe that IDE's can be a crutch But, at the same time, I think when a tool can help a programmer avoid simple errors and not have to thumb papers as much, it is a great way to give new programmers warm fuzzies. Programming is fun! It's fun in a way few other things are, but it can be a frustrating experience without care and I'd hate to think that future great programmers were being turned off because of some macho programming experience.

The experience of forgetting a semi-colon and then tracking down the problem may take time. But it is not wasted time if the programmer pays attention to the compiler errors and thinks about what is going on. Error marking short-cuts this process and in the long run generally results in a less capable developer because the developer has never been forced to understand what is going on.

Why exactly is being shown the error immediately instead of waiting until the programmer manually compiles it going to make a less capable developer? Are you also against pair programming? How about people teaching or helping others program?

Someone who is only just learning how to program should not be touching much of the massive base library that Java offers.

I completely agree. Unfortunately, Java is a popular first language for people learning how to program and knowing at least some of the JCL is essential to getting anything interesting done. It's too bad really.

a learning programmer should not be touching the library documentation very often.

Why not? Every language I've learned (about 25 of them) I've studied the libraries, especially when first learning it.

As I pointed out, the simple/repeatative/tedious parts of writing code that can be automated by tooling is vital to learning how to program. In my experience teaching programming the simplicity and repeatition of these parts of the code very much help to ingrain an understanding of what the language is doing and help establish good coding style and practices.

Do you discourage the use of copy and paste also? While I would totally agree that code refactoring can be tedious and repetitive, autocompletion and constant compilation is a QA and documentation advantage, not a time saver.

 

[mrichmon]

Why exactly is being shown the error immediately instead of waiting until the programmer manually compiles it going to make a less capable developer?

A compiler error indicates the nature of the error. Reflecting on the error and finding the problem and resolving it is a very valuable learning exercise for people learning how to program. An IDE such as Eclipse eliminates this process by marking the specific part of code that contains a problem. As I stated in a previous post, many people learning to write code end up making random changes rather than trying to understand what is going on in their code. An IDE that points to the problem area of code reinforces this approach to coding.

In addition, very few real world developers have the luxury of only writing new code. The skills developed resolving your own bugs are vital for serious development.

Are you also against pair programming? How about people teaching or helping others program?

I would be against pair programming for novice programmers but that is a very different discussion. I would also be against test-driven development as an approach to teaching programming to novices. Are there any other trendy approaches to software development that you want to suggest are relevant to teaching programming? Software development is not the same as learning how to write code.

I am expressing an opinion different than your own, no need to become hysterical. My opinion is based on a number of years teaching computer science and I have explained my reasoning. What I am not doing is insisting that everyone must agree with me.

Why not? Every language I've learned (about 25 of them) I've studied the libraries, especially when first learning it.

To answer your "why not?" question: Because novice programmers easily get lost in the libraries. Novices often also get confused between the language and the library and it is useful for them to understand the boundary and the distinction.

Learning to program is not the same as learning a new language. In fact learning to program has very little to do with learning a new language. Learning to program is about learning how to break down the problem into manageable pieces and then learning how to express those pieces at the level of detail that a compiler and by extension a computer can understand. Learning a new language is generally (ignoring differences between imperative, functional and logical languages) about learning the syntax, expression formats and the statements offered by the new language in question.

Learning a new language for an experienced programmer is at most 2 weeks of work. Learning to program for the first time often takes a number of months followed by a few years to really become proficient. The original question and the second post appeared to focus on a learning how to program not on learning yet another language.

Do you discourage the use of copy and paste also?

Yes. If a developer is using cut and paste in their own code then they are probably doing something wrong. If a novice programmer is using cut and paste then they are almost certainly doing something wrong. Use of cut and paste by a novice programmer generally indicates that they have not understood; functional abstraction, code structuring, loop statements, conditional statements or some combination of these four vital concepts.

While I would totally agree that code refactoring can be tedious and repetitive, autocompletion and constant compilation is a QA and documentation advantage, not a time saver.

Auto-completion and constant compilation have nothing to do with QA nor documentation. Neither auto-completion nor constant compilation produce any kind of documentation. The fact that code compiles does not mean that the code has any quality assurance whatsoever. Compilation of code doesn't even mean that the code will necessarily function let alone conform to the program requirements.

Documentation is about the developer capturing their intent, their assumptions and other details about their code that is not readily expressed in the code itself. The intent of documentation is to expand upon what is captured in the code. In the specific case of libraries and frameworks documentation is used to explain assumptions and behavior inherent in the code. None of this is aided by auto-completion or continuous compilation.

QA (Quality Assurance) is about ensuring that the program conforms to the stated program requirements. QA is a process by which a human (often aided by automated tools) ensures that a program does what it is intended to do. Code completion and continuous compilation does nothing to aid the QA process. On anything but the smallest of development teams the QA process is performed by a completely different set of people from those who develop the code. A significant reason for this separation is to ensure that the developer's assumptions do not inadvertently allow code to pass QA testing. QA testers themselves often do not access the source code of an application so code completion and continuous compilation have no impact on the QA process.

 

[demallien]

Learning to program is learning a new way to think

mrichmon has the right idea here. Learning to program is not at all the same problem as learning a new programming language.

To program you need to be able to make abstractions, to understand important ideas like the fact that all a computer ever does is move numbers around and perform simple arithmetic on them. For example, if you can't understand the difference between an image on the screen, and the underlying series of numbers used to represent that image, you are never really going to be able to program well. If you see '0' and don't think immediately 0x30, life just won't be fun in front of a computer.

The closer you can get someone to the silicon when they are learning, the easier it will be for them to build up afterwards. I may make one exception to this rule in stating that perhaps, just perhaps, you don't need to start at machine language/assembler level. Even there, a higher level assembly language is in my opinion the best place to start learning to program. All of the other abstractions (functions, objects, messages etc etc) are easier to understand if your building up from the bottom.

A classic example - I tried to understand multi-threaded programming by looking at the API documentation for threads, but could never understand exactly what it was that mutexes, and semaphors and all the rest of the machinery were actually doing, until I was forced to look under the bonnet at the scheduler code for a system. These days I find it relatively easy to do multitreaded programming, because I understand the underlying technology, not because I understand the metaphors used in the API....

 

[Kunimodi]

A compiler error indicates the nature of the error. Reflecting on the error and finding the problem and resolving it is a very valuable learning exercise for people learning how to program. An IDE such as Eclipse eliminates this process by marking the specific part of code that contains a problem. As I stated in a previous post, many people learning to write code end up making random changes rather than trying to understand what is going on in their code. An IDE that points to the problem area of code reinforces this approach to coding.

Do you have any logical arguments to back that up? I am hearing a steady stream of 'expert' opinion stated as fact, but very little in the way of reasons why something you are saying is true. Why does having an IDE pointing out where a mistake was made encourage voodoo programming? How is it at all functionally different if I compile in a terminal and get a message like "line 35: '(' expected)" and if the IDE automatically compiles the file, highlights the line and presents the same message the compiler does?

I would be against pair programming for novice programmers but that is a very different discussion. I would also be against test-driven development as an approach to teaching programming to novices. Are there any other trendy approaches to software development that you want to suggest are relevant to teaching programming?

Trendy, eh? Pair programming is simply two people working together, side by side on a problem. That's been going on since pre-history.

To answer your "why not?" question: Because novice programmers easily get lost in the libraries. Novices often also get confused between the language and the library and it is useful for them to understand the boundary and the distinction.

Yes, perhaps you could point out the boundary between a language like Java and its class library. Because, if I was considering someone for a Java position and they didn't know a solid portion of the JCL, I would believe they wouldn't know Java.

Learning a new language for an experienced programmer is at most 2 weeks of work.

As defined by you as 'learning the syntax, expression formats and the statements' I presume. Which, I will point out, does not result in learning a language in a sense that the vast majority of people mean. If that were the case, then most C++ programmers would have almost immediately understood and been useful with Java because (I would estimate) 95% of it was a subset of C++. Except that in reality it takes good programmers much longer because they need to know the library as well. In addition, they need plenty of time and exposure to pick up on Java conventions, styles, patterns and antipatterns and technologies (like RMI, JSPs and servlets, JNI, Web Start, jar files, signatures, JDBC, etc, etc, etc). 2 weeks indeed. I would not trust the code of a programmer that thought they were done learning Java after 2 weeks.

Auto-completion and constant compilation have nothing to do with QA nor documentation. Neither auto-completion nor constant compilation produce any kind of documentation. The fact that code compiles does not mean that the code has any quality assurance whatsoever. Compilation of code doesn't even mean that the code will necessarily function let alone conform to the program requirements.

I would assert (get it?) that if code doesn't compile, it's pretty likely it won't meet any kind of software requirements. As someone who has been on the receiving end of commits (in more than one company) that broke the build and wouldn't have even compiled on the committer's computer, let me express clearly that compilation of code is an important, basic QA step.

I was not talking about producing documentation; I was talking about showing you the reference documentation (and even the method signatures) inline.

Look, 35 years ago a class of programmers were up in arms about the new fangled 'code on the machine' practice that was becoming popular. Programmers need to write (or punch) it out by hand to properly learn how to program, they felt. They were distrustful of the 'trendy' teletypes and interactive editing that went on to revolutionize software development. But, other programmers saw strengths (and weaknesses) in these technological advancements and adapted. And, then it happened all over again with stepping debuggers, and IDEs, and the internet versus paper reference manuals, and....

You're going to believe what you're going to believe and it seems to me that your mind is made up. But, for new programmers out there I have a message: there is no need to make programming more difficult than it is already. If you've made the choice (or were required to make the choice) to start with a language like Java rather than a kinder, gentler language like Haskell or Python then purposefully depriving yourself of inline documentation or debugging clues is, honestly, pretty masochist. And, one more message: never believe a programmer just because of 'n' years experience.

<what's funny about dismissing continual compilation is that many (maybe even most) programmers have been doing it for years manually -- code a bit, save, compile, rinse and repeat>

 

[TEG]

XCode does work with JAVA, but it is best to only use it if you are creating a GUI. If you will just be using text and file input/output use jGrasp (http://www.jgrasp.org/) it is light on resources, and has a great color coded interface, plus integrated compile/run system.

TEG

 

[ITASOR]

If I do install Xcode for Java use (just to play around with), what do I need to check off on the installer?

 

[HiRez]

If I do install Xcode for Java use (just to play around with), what do I need to check off on the installer?

I think the only thing not in the default installation list is the Java API documentation (I think it also uses this for code completion). You would definitely want this.

 

[ITASOR]

I think the only thing not in the default installation list is the Java API documentation (I think it also uses this for code completion). You would definitely want this.

Yeah, I'm trying to avoid a 2.7GB install...lol...right now I'm using it for Java and that's all, so I want to not install the other stuff, but I'm not sure what I need to leave checked and what I don't need to leave checked, so I haven't installed it yet.

 

[kalun]

use Eclipse for java.......