Java or Python for first language?

[probE466]

Just now, vorticalbox said:

for me its just down to time, having ** is faster that math.pow() more time to code.

 

 

eh, with an ide like intellij, its negligible, how often do you write pow functions anyway?

[vorticalbox]

6 minutes ago, probE466 said:

eh, with an ide like intellij, its negligible, how often do you write pow functions anyway?

depends on how often I need them lol, actually not that often.

[Enderman]

8 hours ago, probE466 said:

This is so wrong. Have you ever even programmed in Java (Note: a hello world does not count... :))? 

https://pythonconquerstheuniverse.wordpress.com/2009/10/03/python-java-a-side-by-side-comparison/

 

You tell me, which is easier to understand for someone that only knows english?

Quote

public class Employee { private String myEmployeeName; private int myTaxDeductions = 1; private String myMaritalStatus = "single"; //--------- constructor #1 ------------- public Employee(String EmployeName) { this(employeeName, 1); } //--------- constructor #2 ------------- public Employee(String EmployeName, int taxDeductions) { this(employeeName, taxDeductions, "single"); } //--------- constructor #3 ------------- public Employee(String EmployeName, int taxDeductions, String maritalStatus) { this.employeeName = employeeName; this.taxDeductions = taxDeductions; this.maritalStatus = maritalStatus; } ...

class Employee(): def __init__(self, employeeName , taxDeductions=1 , maritalStatus="single" ): self.employeeName = employeeName self.taxDeductions = taxDeductions self.maritalStatus = maritalStatus ...

It's obvious which one is python and which is java. Python is on the right fyi.

Quote

public Vector<Integer> aList = new Vector<Integer>; public int aNumber = 5; public int anotherNumber; aList.addElement(aNumber); anotherNumber = aList.getElement(0);

aList = [] aNumber = 5 aList.append(aNumber) anotherNumber = aList[0]

 

[Midnight]

Why don't you just go with C#? It's better than Java, in my opinion. Python isn't bad, but the writing style is a bit too unique to learn as the first language.

[literallywho]

Start learning the basics with Python, then move on to Java or C# to learn proper OO design.

[thermophobe]

Python.

 

It will be easier to understand and make programs. After you master one language, you can always learn new ones with ease.

 

Btw, consider other options as well. C or C++ are not bad options either. Moving to Java will be easier in this case.

[Lawrenz]

My honest opinion? Start with java (even though I am a strong advocate for Python - I use it much more often than Java)

Reason? Java is a great way to get into the "nitty-gritty" of OOP concepts and will help build good programming practices.
It enforces datatypes, wherein python has a very loose attitude when it comes to datatypes.

In other words, learn Java. It's good for building your foundations in OOP. You can easily transition into Python and apply the same practices as Java and write some beautiful code, since you honed your OOP habits/skills in Java.

[straight_stewie]

Java is the devils language, so not java.

[SSL]

8 hours ago, Lawrenz said:

Reason? Java is a great way to get into the "nitty-gritty" of OOP concepts and will help build good programming practices.
It enforces datatypes, wherein python has a very loose attitude when it comes to datatypes.

 

I disagree. Programming in an "object oriented" (what does that really mean) language is not a good way to learn object oriented concepts OR good programming practices in general. The best way to learn those concepts ... is to learn them, period.

 

In case it isn't clear, I'm an advocate of OOP; but the way Java is frequently used to realize OO is just awful. Forcing everything into a class is not enough to make code good OO.

[Pomfinator]

Java is a terrible first language.  I know, because I learned Java first in APCS.

 

If your goal is to learn programming concepts and practices, interpreted languages are just better.  They are easier to teach, learn, and practice with.  In Python you can just pop the interpreter up and practice basic skills, hell you can even write whole functions in it (not that I recommend that).

 

Going to steal a quote from my APCS teacher

 

"You see this static main void stuff? Just know that it has to be there, I can't tell you why it's there until you've learned more."

[Lawrenz]

22 hours ago, SSL said:

 

I disagree. Programming in an "object oriented" (what does that really mean) language is not a good way to learn object oriented concepts OR good programming practices in general. The best way to learn those concepts ... is to learn them, period.

 

In case it isn't clear, I'm an advocate of OOP; but the way Java is frequently used to realize OO is just awful. Forcing everything into a class is not enough to make code good OO.

Not saying you're wrong - Java is an overly complicated language, at least when compared to Python - but, for those who learn through application (like me, for example), Java feels like a good place to start. At least to learn the basics of Classes (and data encapsulation, abstraction, etc.), inheritance and other OOP concepts. Once you manage to get a grip of the OOP concepts, you can drop the training weight (that is Java) and fly freely and explore other languages like python  

Of course, python "forces" you to write nice, legible code - at least in part - by forcing you to use good indentation practices  
And yes, you can also learn the same OOP principles in Python as well, not saying you can't...

[sukhvir41]

i would recommend java as it is purely OO language and it is strict in its structure. you may have to type more lines but in java compared to python but having a statically typed language makes you understand the core concepts of OO programming and then learning any other language will be easier like python. I am quite good at java and love it , thats why i tend to lean towards java and it has great third party support.  

[SSL]

2 hours ago, Lawrenz said:

inheritance and other OOP concepts.

 

This is a good example of the limitations of learning within the confines of a language - inheritance is kind of an antipattern. But you wouldn't know that from looking at most OO languages - or even a lot of OO code.

 

[Midnight]

14 minutes ago, SSL said:

 

This is a good example of the limitations of learning within the confines of a language - inheritance is kind of an antipattern. But you wouldn't know that from looking at most OO languages - or even a lot of OO code.

 

I disagree with inheritance as an antipattern. There's nothing inherently wrong with inheritance. It's just that people misuse it too frequently.

[Z11]

Most jobs usually ask for some Java experience. Once in a while you'll get python. Regardless, learning a dynamic language like python will make it easy for you to learn other languages like Javascript and Ruby.  Choosing either one will be good for you as a beginner. 

[shifatkhan]

I feel like it doesn't really matter THAT much. You're most likely over-thinking. I learned Java first in College. After that, it was a breeze to learn other programming languages since they're practically the same. It's just the syntax that changes tbh

[SSL]

2 hours ago, Midnight said:

I disagree with inheritance as an antipattern. There's nothing inherently wrong with inheritance. It's just that people misuse it too frequently.

 

Wrong. Dead wrong. Inheritance reduces flexibility and increases coupling. Interface "inheritance" (composition) can achieve the same behavior without the drawbacks. Inheritance can be convenient in very limited cases, but that doesn't change the fact that it is inherently flawed and should be excluded from most OO designs.

 

1 minute ago, shifatkhan said:

I feel like it doesn't really matter THAT much. You're most likely over-thinking. I learned Java first in College. After that, it was a breeze to learn other programming languages since they're practically the same. It's just the syntax that changes tbh

 

Agreed. Ultimately, learning is an ongoing process that will span multiple languages. It can help to build good habits from the beginning, though; breaking bad habits and relearning is a challenging and time consuming process.

[Midnight]

1 hour ago, SSL said:

 

Wrong. Dead wrong. Inheritance reduces flexibility and increases coupling. Interface "inheritance" (composition) can achieve the same behavior without the drawbacks. Inheritance can be convenient in very limited cases, but that doesn't change the fact that it is inherently flawed and should be excluded from most OO designs.

 

I think you're confusing subtyping with composition, for which they are NOT the same thing at all. If that's the case, then how can I take you seriously?

 

As I have implied before, if inheritance is done right, then there's usually no problem. Also, reduced flexibility and increased coupling are GENERALLY bad, but it can be tolerated depending on context and system design. Your attitude implies that it should never be allowed, and sometimes this is impossible without over-complicating the design.

 

Finally, you didn't explain why it is inherently flawed and just telling me to believe you... and I won't, without good, hard evidence.

[SSL]

9 minutes ago, Midnight said:

I think you're confusing subtyping with composition, for which they are NOT the same thing at all. If that's the case, then how can I take you seriously?

 

As I have implied before, if inheritance is done right, then there's usually no problem. Also, reduced flexibility and increased coupling are GENERALLY bad, but it can be tolerated depending on context and system design. Your attitude implies that it should never be allowed, and sometimes this is impossible without over-complicating the design.

 

Finally, you didn't explain why it is inherently flawed and just telling me to believe you... and I won't, without good, hard evidence.

 

I'm not confusing inheritance with composition. I clearly stated that the desired behavior of inheritance can be achieved through composition (without "over-complication"), thus obviating it.

 

Reduced flexibility and coupling qualify as inherent flaws. I'm not sure how else to make the point without getting into semantics. There is also no need to provide "evidence"; this is a logical argument. When you subtype a class, you create coupling. It's that simple. About the only case where inheritance should be used is with abstract classes, and even then care must be taken with the design of final vs abstract methods. Instead, abstract base classes all too often end up serving as bags for shared utility methods.

 

If you really want to get into evidence, I think the onus is on you here to provide evidence of when coupling can be tolerated (what context? what designs?). As you pointed out, I'm speaking in generalities, for which there is no need to provide specific evidence. There are of course situations where reduced flexibility is acceptable (YAGNI) but then why clutter code with sub-types at all? Or OO for that matter?

[Midnight]

14 minutes ago, SSL said:

 

I'm not confusing inheritance with composition. I clearly stated that the desired behavior of inheritance can be achieved through composition (without "over-complication"), thus obviating it.

 

Reduced flexibility and coupling qualify as inherent flaws. I'm not sure how else to make the point without getting into semantics. There is also no need to provide "evidence"; this is a logical argument. When you subtype a class, you create coupling. It's that simple. About the only case where inheritance should be used is with abstract classes, and even then care must be taken with the design of final vs abstract methods. Instead, abstract base classes all too often end up serving as bags for shared utility methods.

 

If you really want to get into evidence, I think the onus is on you here to provide evidence of when coupling can be tolerated (what context? what designs?). As you pointed out, I'm speaking in generalities, for which there is no need to provide specific evidence. There are of course situations where reduced flexibility is acceptable (YAGNI) but then why clutter code with sub-types at all? Or OO for that matter?

 

Uhh, but you said interface inheritance, which isn't really composition... And favoring composition will definitely complicate the design.

 

Your logic doesn't make sense. Subtyping creates coupling. That makes sense, but you didn't follow through with your argument. I already said that it's generally bad, which means it's not always bad to do so, and you've (sort of) agreed with me in your last sentences.

 

Finally, using interfaces, sub-types, and/or composition will produce their own "clutter code". You FAVOR composition over inheritance, not FAVOR ONLY composition. Otherwise, we wouldn't be having this conversation. I suggest you read (or re-read) Design Patterns by the Gang of Four.

[leobeosab]

I'd go with Python, I started with C++ and starting out with a strict OO language is not the greatest. Python is much easier to get into because it's kind of a 'loose' language and easy to pick up. Graphics are also way easier on it if you wanted to make a game or something with a GUI. Python also allows for GPIO programming 'programming the real world' if you have a Raspberry pi, you can turn lights off and on, make a home automation system. Tons of stuff. Python will allow you to get a feel for programming without being really hard on you if you have a small mistake in your code.