jslowik

Honestly you have absolutely nothing to worry about. I'm proficient in a wide array of things which I use daily out in the industry and I still have to spend time looking stuff up that I've done many times before. It's completely normal and all of my collogues do the same - I don't know a Software Developer/Engineer who doesn't.
Why do you doubt yourself so? The only difference is familiarity with design and engineering principles as well as frameworks and APIs... The only way that comes is with experience over time. The single most important thing that you you need right now is a desire to program. The strength of that desire will be directly proportional to the strength of your drive to progress. It's that simple and all you need to do is believe in yourself.

Probably mostly personal preference. Don't worry too much about it as you won't be writing console style applications for very long.
 
Just to explain a little, println adds a line break after the printed line, and print doesn't. Some examples here...
 
System.out.println("This is a line"); System.out.println("This is a new line"); will look like:
This is a line
This is a new line
 
Where
System.out.print("This is a line"); System.out.println(" This isn't a new line"); Will look like:
This is a line This isn't a new line

Additionally you're never printing the value from that method. Your print line should be similar to:
System.out.println(SecondClassObject.simpleMessage(name)); And just for giggles, writing your second class like the following is a few less keystrokes:
public String simpleMessage(String name){ //this is taking the varible sent from the call method name += " Is a god"; return name; }  

Add a return statement to your method, then in your main class with the main method don't print the local variable, but the method from the other class.
 
You could just make a public variable, but that's poor design.

Im not sure what you mean by where to start. I'd suggest the bottom?
Only advice is that make sure you're using Python version 3.x not 2.x  where x is whatever.
Choose a Python for beginners or similar and watch it through beginning to end, make sure you're coding along with the person rather than just watching, just watching you'll never learn

Many languages already have local-variable type inference and it looks like Java may finally be getting there too. JEP 286 has the proposal details. There's also a survey you can take to go with it to give them some feedback about the proposal. One thing the survey asks about is the preferred syntax for the feature. Options are
//A: var only (like C#) var lib = getMusicLibrary(); var artists = lib.getArtists(); var personCount = artists.size(); var works = lib.getTracks(); var workCount = works.size(); //B: var/val (like Scala, Kotlin) val lib = getMusicLibrary(); val artists = lib.getArtists(); var personCount = artists.size(); val works = lib.getTracks(); var workCount = works.size(); //C: var/let (like Swift) let lib = getMusicLibrary(); let artists = lib.getArtists(); var personCount = artists.size(); let works = lib.getTracks(); var workCount = works.size(); //D: let only let lib = getMusicLibrary(); let artists = lib.getArtists(); let personCount = artists.size(); let works = lib.getTracks(); let workCount = works.size(); //E: auto only (like C++) auto lib = getMusicLibrary(); auto artists = lib.getArtists(); auto personCount = artists.size(); auto works = lib.getTracks(); auto workCount = works.size();  
It's small, and there's still a lot more that can be done to reduce boilerplate, but I expect many people who use Java will support this proposal (and as always, many people will probably hate it for some reason too).

Currently running an FX-8150. No complaints. Haven't felt the need to overclock it yet since I haven't had any problems playing the handful of games I play regularly, but that's on the to-do list in the near future.
 
Wouldn't classify myself as an AMD "fanboy", but this is the first machine I built that wasn't Intel based. I'm not disappointed.

The goal isn't the least number of lines. Readability and consistency are bigger factors. Style guides can be useful for keeping everyone in sync so you don't have to worry about these little details. Sometimes reducing the number of lines can help readability, sometimes it can hurt it (complex one liners, etc).
 
Your example is pretty trivial so I don't think it really matters much although I don't think you gain anything with option 1. I personally prefer option 2. Given how verbose Java can be, I can understand why it might look pretty ugly to one line it. In C#, which is still more verbose than many languages, you get to use var keyword to help shorten things but Java has no such luck.
// Java HashMap<String, String> map = new HashMap<String, String>(); // C# var map = new Dictionary<string, string>(); It's still not too bad when you're looking at it in an editor with syntax highlighting though so I still probably wouldn't break it up across two lines.
 
If you have a large/complex method where things are declared all over the place, it might be useful to have the declarations grouped together somewhere but chances are you have bigger issues if that's the case.
 
Stick to a style you like and be consistent. When working with a team it's useful to use a style guide as mentioned above.

Thanks for the replies, I didn't expect people to answer after a couple of hours so I forgot to check my messages sorry. I have created a new navigation, so the problem is no longer present.

You're getting errors on the return because you're returning something from a method that has no return type. The method signature is also incorrect. You're also lacking getters and setters which means the setColor and setRadius calls in the driver class won't work.
 
Here's a functioning example of what your class should at least resemble. I added some comments in to hopefully help clear up any questions. Though feel free to ask more.
 
public class Circle { private String color; private int radius; /** * Constructor that accepts all values. You aren't using this, but I * included it out of habit * * @param color * @param radius */ public Circle(String color, int radius) { this.color = color; this.radius = radius; } /** * This is the constructor that the CircleDriver class is calling * */ public Circle() { } public String getColor() { return color; } /** * Setter method for color. Required for driver class as written * * @param color */ public void setColor(String color) { this.color = color; } public int getRadius() { return radius; } /** * Setter method for radius. Required for driver class as written * * @param radius */ public void setRadius(int radius) { this.radius = radius; } /** * Your display method. Void return type, handles the print line itself * */ public void display() { System.out.println("I am a circle"); System.out.println("My color is " + color); System.out.println("My radius is " + radius); } /** * Compute area. Returns a double which is output by the driver class * * @return - radius = pi r ^2 */ public double computeArea() { return (Math.PI * Math.pow(radius, 2)); } /** * Compute circumference. Same as area, but different formula * * @return - circumference = 2 pi r */ public double computeCircumference() { return (2 * Math.PI * radius); } }  

It's recommended to use distilled water over de-ionized stuff the main difference being the ions in the water are gone so when in the loop it readily strips them from metal parts in the loop. 

I'm in exactly the same boat. No complaints for my tower's CPU, and I'm definitely satisfied in its performance for the pricepoint I bought it at. Not anything glamorous, but I haven't been let down by it yet.

If this is your first language and you've never done any programming before then you'll probably want to just focus a little on Java first. You don't need to become an expert in Java before you move on, but it'll help to know the basics. You'll be diving into Android before you know it.
 
Here are some Java resources to get you started.
Head First Java (book) Java Tutorial for Complete Beginners (video course) More stuff (also includes an Android section)

always use the first one, fucking hate it when people use the seccond...

I like the first (left). It just looks neater for some reason, than breaking up the code.

Just a few quick things. First of all if you're going to use a sentinel value you have to account for it. As written your program will be off by whatever that value is. Also as it's written you're never going to output your sum line. The value required to exit the do-while is a number less than zero, which will set the next variable to a number less than zero. The if logic you have written tests to see if next is greater than or equal to zero, which it will not be in order to exit the first loop. Also (and this may not be the case always) I was always told by an instructor that they used to harass people that added two values by writing int1 = int1 + int2. I don't know why someone would be made fun of, but whatever. Try writing it as int1 += int2. I did a quick couple edits you can take a peek at. The modifications I did will accept negative numbers other than negative one, so you can change that if you wish, but otherwise I think it functions as you intended.
 
Also it's a better idea when using the scanner to grab a nextLine rather than a nextInt. In this program it's not an issue, but it will be problematic later. Grab the nextLine as a string, and parse it to what you need. I've added that in as well.
 
Hope it helps!
 
int sum = 1, next = 0; Scanner keyboard = new Scanner(System.in); System.out.println("Please enter a list of positive intgers and when you have reach the desired amount of intgers enter -1. "); do { String nextString = keyboard.nextLine(); next = Integer.parseInt(nextString); sum += next; } while (next != -1); { System.out.println("The sum is " + sum + "."); } }  
 

Hello! As a fellow programming student I'm hoping I can shed some light onto why the instructor would actually take points off for this.

Lately we have been discussing a study (I'm sorry I haven't yet been able to find the link myself, so I cannot offer it yet) that shows that for a majority of "keyboard time" programmers are actually reading code. This could be for debugging reasons, or any other.
 
I believe that using extraneous markup could warrant a point deduction if for no other reason than it could potentially slow someone up who was reading it, and came across an unexpected character. There are also extra keystrokes, but I'm not about to wholeheartedly defend labeling two extra key presses as inefficient. I think the more pressing issue is to try to conform to standards that are widely accepted, if not required by a compiler/interpreter. In the case of Python that means you don't see parenthesis or brackets to the extent you would in a C-style language like Java.
 
We've always had it explained to us that in the perfect world of academia the expectations are sometimes significantly different than the requirements of real world development. In that particular case there is no need for the parenthesis, and since we are dealing with the "perfect world" scenario simply remove them. I believe madknight3 said it more succinctly, so I quoted their post in case mine was too long winded and rambling.