For those who ask: "What programming language should I learn?"

[shivajikobardan]

@pbuk I mean because of standard template library it is easier to study leetcode in c++.

 

[pbuk]

@pbuk I mean because of standard template library it is easier to study leetcode in c++.

I think you are mistaken, what gave you that idea?

The STL implements in C++ features that are built in to other high level languages. So the leetcode C++ template for the above problem uses std::vector from the STL not to make it easier, but because it has to.

The Python template uses Python's built in lists, the JavaScript template uses JS's built in arrays...,

 

[.Scott]

I) Speed is not the only issue
When you have a speed or timing constraint that gets you worrying about milliseconds or microseconds, then C and C++ look very good. But in many applications, particularly embedded applications, the greatest imperative is for the object code footprint - including engines, libraries, and the runtime environment.

II) First language for hobbyist:
I suggest HTML/CSS/JavaScript. For Chrome and Firefox, it's as convenient as the F12 key.

III) First language for the pre-professional:
There was once a time when there were only two types of programmers, Cobol and Fortran - and Fortran programmers were expected to be comfortable with assembler.
Now the market is not so simple: Here's an article that gives the rundown.

But as important as it is to have a SW skills attractive to potential employers, more important is that you find it attractive. Otherwise, you will never enter the marketplace. It is okay for your first language to be cheap, easy, with lots of opportunity to quickly see the results of your creative efforts. Once you known what programming is, and you have proven to yourself that you can survive happily in such a world, then perhaps something like this will work for you:

1) Find some job listing that describe what you want.
2) Practice the additional software language and tool skills that you need to move in that direction.
3) If you ended up choosing skills that are too much of a challenge, you may need better mentorship or you may need to retarget the kind of job you are looking for.

and best of luck

 

[Rene Dekker]

I would recommend people to learn Java as their first programming language. Yes, you may say it has a lot of boilerplate code. But dealing with indentation errors is not what I would like to encounter when I am absolutely new to programming, and not fully familiar with an IDE. Maybe you will say that learning OOP is not necessary for programming. True, but OOP helps build programming logic in a certain direction. Each variable always having a global scope is also an issue in Python. The loop variable is available even outside the loop. For a newbie, this could give rise to logical errors if not careful. In Java, declaring a variable inside the loop keeps it inside.

I can fully support this. As a first programming language, I would always recommend Java. It makes you learn about structured code, forces object oriented thinking, separation of concerns, and keeping track of type-checking, without the added complexities of C++.
Python is great for prototyping (basically the modern Perl), but is very hard to manage in large scale programs.

JavaScript is a lousy language, but unfortunately mandatory for client side web programming.
For systems programming on Windows, learn C#. For systems programming on any Apple platform: Swift. For any other platform (including Android): Java.

To add to that: in the day-to-day practice of programming, you will find out that you spend a lot more time learning libraries than learning the programming language.

 

[pbuk]

Who is the audience?

Mainly this:

Is it people that need to be steered away from C++ as a good starting point?

 

[Vanadium 50]

That's fair, but I might focus on that.

I do think C++ has gotten a bit of an unfair rap (but some of its problems are ignored, so maybe it averages out) because it exposes what people don't understand. Scoping certainly. Strong typing. Pointers. Maybe you remember confused by call-by-value. Toss in STL and now you expose a lack of understanding of data structures - do I want a list or a vector or a dequeue or...

 

[jedishrfu]

One thing that’s not been brought up here is the fragile base class issue of OOP languages like Java or C++.

https://en.wikipedia.org/wiki/Fragile_base_class#:~:text=The fragile base class problem,the derived classes to malfunction.

C++ allows for multiple inheritance and as a result can introduce some funky errors in code. As an example, say you have a class C that inherits from classes PA and PB and they in turn inherit a common class G. G has a variable x that a method in class C changes.

The question is how should one access x from methods in C? Via PA to G or via PB to G. It turns out that in C++ there are two instances of the G class and hence two x variables. The solution was to always design with getter and setter functions and not allow direct access to the variables of another class.

These subtleties can really mess with a beginning student and must be approached carefully as they get comfortable with whatever OOP language they choose.

in the past, I’ve championed the Processing approach to learning to program because of it immediate feedback and relatively simple editor and runtime. It’s based on Java but introduces students to the setup and draw model allowing them to get immediate feedback when something it run. Java is a good language on several fronts, single inheritance, platform agnostic, rich library of features, good vendor support and great IDE tools.

The student has a clear path from Processing to more serious projects and an easier transition from hobbyist level to professional developer while maintaining what they’ve learned.

Processing has a similar path for Python folks when the Jython mode is selected although it’s not as easy to transition to developer level since Jython is at v2.7 and most modern Python development is done with Python 3.

Another popular Java student IDE is BlueJ. I’ve played with it but feel that Processing has more to offer.

Anyway, this is an endless flame war topic with no clear winner only many options for folks to choose from and lots of people with varying opinions and positions on what works best.

 

[pbuk]

One thing that’s not been brought up here is the fragile base class issue of OOP languages like Java or C++.
...
These subtleties can really mess with a beginning student

I don't think multiple inheritance is something a beginning student should be learning anyway.

The student has a clear path from Processing to more serious projects and an easier transition from hobbyist level to professional developer while maintaining what they’ve learned.

I accept what you say, however I believe it is better to be able to move to more serious projects without having to change language.

Processing has a similar path for Python folks when the Jython mode is selected although it’s not as easy to transition to developer level since Jython is at v2.7 and most modern Python development is done with Python 3.

No, Python 2.7 reached end of life three years ago and should not be used by anyone for anything, let alone be taught to beginners.

Anyway, this is an endless flame war topic with no clear winner only many options for folks to choose from and lots of people with varying opinions and positions on what works best.

I have two thoughts on this:

1. Although there are many opinions stated among posters here and elsewhere, I believe that there is now a consensus among the academic community, particuarly in STEM, that Python is the best first language (some indicative evidence below). I think PF would benefit from a sticky post joining this consensus.
2. Alternatively, there does at least appear to be a consensus on here for "don't learn C++ just because someone has told you it is fast", and I think a post along those lines that we could link in answers would be useful.

@Greg Bernhardt what do you think?

Spoiler: Some indicative evidence

FAQ: Can you recommend any books or activities to do that would help my application and/or studies?
A: If you choose to learn a new language, it may be a good idea to learn one that is not explicitly taught in the Tripos. Doing so obviously helps to avoid repetition, but also gives you a wider perspective on languages that can be useful later in the degree and in employment. A popular choice is Python, for which there are many tutorials available.
https://www.cst.cam.ac.uk/admissions/undergraduate/faqs

Since 2016 Python has been the first language taught to University of Cambride Engineering students
https://github.com/CambridgeEngineering/PartIA-Computing-Michaelmas

This page will help you begin to learn programming and computer science, with some suggested introductory courses on OCW.
These courses introduce principles of computer science and begin to develop programming skills, specifically in the Python language. Learn more about these courses’ learning goals, history and student experience in this MIT news article.
Introduction to Computer Science and Programming in Python
Introduction to Computational Thinking and Data Science
Programming for the Puzzled
https://ocw.mit.edu/course-lists/general-introductions-to-programming/

 

[Rene Dekker]

Although there are many opinions stated among posters here and elsewhere, I believe that there is now a consensus among the academic community, particuarly in STEM, that Python is the best first language (some indicative evidence below). I think PF would benefit from a sticky post joining this consensus.

Among the academic community, particularly in STEM, it is prototyping that is mostly needed, not serious programming. For that purpose Python is a good choice. But the academic community is an extremely small sample of all programmers.
To the general question: "what programming language should I learn", I'd say the consensus in the industry is that it should at least be an object-oriented language with static typing.

Even people using Python would do well to learn a statically typed language with separation of concerns first. That would greatly improve their programming style.

 

[pbuk]

Among the academic community, particularly in STEM, it is prototyping that is mostly needed, not serious programming.

I think you have misunderstood my point, which is that if institutions such as the University of Cambridge and MIT are recommending and using Python as the first language to learn for computing and STEM students then why would it not be good for PF to do that too?

Even people using Python would do well to learn a statically typed language with separation of concerns first.

I don't understand your reference to separation of concerns as a language feature, surely it's a (highly desireable) programming style that can (and should) be used in any language?

 

[Wrichik Basu]

Although there are many opinions stated among posters here and elsewhere, I believe that there is now a consensus among the academic community, particuarly in STEM, that Python is the best first language (some indicative evidence below).

I beg to differ on this. Python is a good language for scientific computing, no questions regarding that. But that's primarily due to the availability of libraries like numpy, scipy and matplotlib - the foundations. If these libraries were written for Java, the scenario would have been different.

An absolute beginner needs to learn programming first, before going into scientific or numerical programming. Without the notion of data types, for instance, I am not convinced how programming logic can be created. A solid base in programming would help you master any programming language in the future.

I am not saying stay with Java. Switch to whatever language you want, based on your needs. But start with Java.

 

[pbuk]

I beg to differ on this.

Then you are differing with the recommendations I quoted from the University of Cambridge and MIT which are not specific for scientists.

An absolute beginner needs to learn programming first, before going into scientific or numerical programming. Without the notion of data types, for instance, I am not convinced how programming logic can be created. A solid base in programming would help you master any programming language in the future.

I agree completely. Data types are encountered early in learning Python with

# Adding numbers.
print(2 + 2) # 4

# Adding strings (concatenation).
print("2" + "2") # 22

# You can't mix types.
print(2 + "2") # TypeError: unsupported operand type(s) for +: 'int' and 'str'

 

[Vanadium 50]

On Python:

There are research groups out there beimg strangled (get it?) by too much Python. They depend on thousands of lines of unmaintainable Python code written by a parade of students, and never really designed. "Prototypes" are sent straight into production.

This was done with American automobiles in the 1980s and it worked about as well. I suppose it worked out very well..if you are Toyota.

On C++:

Just because you can doesn't mean you should.

We have a discussion upstream about the "diamond of death" inheritance pattern. As a friend said "this should onl;y be used in compiler test suites, and not any actual running code." I dislike it too, not because of the probelms with it so much as it is almost never what you want.

There is a tendency of beginning C++ programs to overuse inheritance. This is aggravated by textbooks using geometric shapes to showcase it ("look, it inherits the perimeter clas") which is a bad choice - it's contrived, saves little coding, and turns the classes into monstrsities of exception handling.

The design philosophy is good - if you write code to do one thing, you write it one time and put it in one place. If you are using a feature of the language in some other way, there will be harder times ahead.

 

[pbuk]

There are research groups out there beimg strangled (get it?) by too much Python. They depend on thousands of lines of unmaintainable Python code written by a parade of students, and never really designed. "Prototypes" are sent straight into production.

Yes, you can write bad code in any language. In the 1990s the same groups struggled with FORTRAN77 legacy code, in the 2000s it was Fortran 90, the 2010s C++ and Java. Perhaps if we teach people how to write good Python code from the get-go this will be better in future.

We have a discussion upstream about the "diamond of death" inheritance pattern. As a friend said "this should onl;y be used in compiler test suites, and not any actual running code." I dislike it too, not because of the probelms with it so much as it is almost never what you want.

Absolutely.

There is a tendency of beginning C++ programs to overuse inheritance. This is aggravated by textbooks using geometric shapes to showcase it ("look, it inherits the perimeter clas") which is a bad choice - it's contrived, saves little coding, and turns the classes into monstrsities of exception handling.

I don't know what idiot it was that confused the perfectly sensible "Shape" example of polymormorphism and the equally sensible "calculatePerimeter" example of function overloading to come up with a Perimiter class. I hope they were sacked, but somehow their legacy lingers on. Personally I prefer the "Animal" example.

 

[Vanadium 50]

you can write bad code in any language

Go too far down that path and you will reach the conclusion "nothing wring with just writing that code in C++".

If the story is "There's a lot of Python out there. so it;s a good thing to learn" it's hard to argue with. If the story is "Python encourages good programming habits" I think you can find a lot of counter examples.

But I think this dances around the real issue - people want to be programmers without learning any programming (and worse, they think they are good at it). Not too long ago, we had a thread where someone wanted to learn a particular database query language - but wasn't willing to put in more than two days on it.

To steal a phrase, if you want to build a doghouse, you can run down to Home Depot, pick up some wood and nails and go. If you want to build a house, you probably at least want blueprints. If you want to build a skyscraper, you want engineering. CS gets in trouble when people treat skyscrapers as great big doghouses.

 

[Greg Bernhardt]

I don't think multiple inheritance is something a beginning student should be learning anyway.I accept what you say, however I believe it is better to be able to move to more serious projects without having to change language.No, Python 2.7 reached end of life three years ago and should not be used by anyone for anything, let alone be taught to beginners.I have two thoughts on this:

1. Although there are many opinions stated among posters here and elsewhere, I believe that there is now a consensus among the academic community, particuarly in STEM, that Python is the best first language (some indicative evidence below). I think PF would benefit from a sticky post joining this consensus.
2. Alternatively, there does at least appear to be a consensus on here for "don't learn C++ just because someone has told you it is fast", and I think a post along those lines that we could link in answers would be useful.

@Greg Bernhardt what do you think?

Spoiler: Some indicative evidence

Since 2016 Python has been the first language taught to University of Cambride Engineering students
https://github.com/CambridgeEngineering/PartIA-Computing-Michaelmas

Would you like to take a try at writing this post?

 

[shivajikobardan]

Python's indentation is a bit hard to realize. In C++, I can use codeblocks to format on save. And it auto formats code for me. I'm pretty sure there's not one in python because that's the whole thing it is built in.

 

[PeterDonis]

I'm pretty sure there's not one in python

If by "one" you mean "a tool that auto-formats Python code", there are multiple such tools available:

https://github.com/life4/awesome-python-code-formatters

 

[PeterDonis]

Python's indentation is a bit hard to realize.

I'm not sure what you mean. PEP 8 gives perfectly good guidelines for indentation (and formatting of Python code in general):

https://peps.python.org/pep-0008/#indentation

 

[.Scott]

One thing that’s not been brought up here is the fragile base class issue of OOP languages like Java or C++.

https://en.wikipedia.org/wiki/Fragile_base_class#:~:text=The fragile base class problem,the derived classes to malfunction.

Very interesting: I have never run into this problem.
I converted the example provided in that wiki article to C++ and included it here:
[CODE lang="cpp" title="Wiki example to C++"]
class base {
public:
// int incA() { return counter++; }
int incA() { return incB(); }
virtual int incB() { return counter++; }
private:
static int counter;
};
int base::counter = 0;

class derived: public base {
public:
int incB() { return incA(); }
};
[/CODE]
First off, I think this is an excellent example of how mentorship is really important to a beginning programmer. Without mentorship, a novice will fiddle with this code until it works and leave mystery and frustration in its wake.

Although the semantics of the language are very important, in my mind, this "fragility" is more profound than just semantics. In contrast to addressing semantics, I think it is important to track this issue all the way through the design process - because that is where the problem lies.

When coded exactly as it is written above, it will drop into infinite recursion and fail.
The way to correct this would depend on the actual purpose of base::incA(). Of course, in this case it is only to provide an example. But in "real life", you would need to determine if it was correct for it to call this-> incB() or base::incB().
If base::incB() is needed, then "int incA() { return incB(); }" needs to be corrected to "int incA() { return base::incB(); }". And the bug is fixed.

On the other hand, it could be that base::incB() really should be relying on the derived version of incA().
If that is the case, the problem is with derived::incA(). That function should not rely on base::incB() and the fact that it was coded that way indicates that the coder did not understand how the classes 'base' and 'derived' are being used to address the "real life" problem. I such a case, I would expect that the derived::incA() has been completely mis-coded and that fixing it will involve more than just replacing one or two lines of code. In other words, the problem isn't just inadvertent recursion, it is a misunderstanding of what incA() was supposed to do.

C++ allows for multiple inheritance and as a result can introduce some funky errors in code. As an example, say you have a class C that inherits from classes PA and PB and they in turn inherit a common class G. G has a variable x that a method in class C changes.

The question is how should one access x from methods in C? Via PA to G or via PB to G. It turns out that in C++ there are two instances of the G class and hence two x variables. The solution was to always design with getter and setter functions and not allow direct access to the variables of another class.

So here is my rendition of the example you describe in C++. If this is not what you have in mind, let me know and I will take another shot at it.
[CODE lang="cpp" title="Wiki example to C++"]
class G { public: int x; };
class PA: public G {};
class PB: public G {};
class C: public PA, PB
{
void SetX(int n) { x=n; }
int GetX() { return x; }
};
[/CODE]

That code will not compile. The C++ compiler complains that the x's in SetX() and GetX are ambiguous.
To correct the code, you need to replace each 'x' with either 'PA::x' or 'PB::x'.

 

[.Scott]

Although there are many opinions stated among posters here and elsewhere, I believe that there is now a consensus among the academic community, particularly in STEM, that Python is the best first language (some indicative evidence below). I think PF would benefit from a sticky post joining this consensus.

If such a sticky note is included, it should specify its advantages. In your "spoiler" section, only the availability of tutorials is mentioned as an advantage. If that is the only advantage, Python is not worth a sticky note. If there are more advantages, then they would need to be enumerated.

Alternatively, there does at least appear to be a consensus on here for "don't learn C++ just because someone has told you it is fast", and I think a post along those lines that we could link in answers would be useful.

And don't learn assembler just because it is fast - or either C/C++ or assembler because they create binaries that are easy on the processors other resources.

What might interest someone to learn C/C++/C#:
1) it has application in industry;
2) since most operating system are written in C/C++/C# and assembler, you have more confidence that the restrictions to the resources in your operating environment will be at a minimum.
3) Once you gain some mastery in it, it is quick to code and check.

Previous academic "darlings" have included Basic, Pascal, ADA, Lisp, Forth, C, and C++.
The difference between C, C++, and later C# and those others is that C/C++/C# have led to high productivity in the workplace. Coders got good at it and and ran with it. It was a solid replacement to all of those Fortran-like languages that preceded it and it took the lead as the favorite language for "heavy lifting".

I don't know where Python lands. I find it a handy "supplemental" language. In contrast, I would describe Pascal as 'lame'. I don't thing Python falls into that category. Python has found a place in industry.

 

[pbuk]

Would you like to take a try at writing this post?

Yes, I started this thread as a first prototype

 

[pbuk]

I'm pretty sure there's not [an equivalent to Code::Blocks for] Python.

You must be joking - there are many IDEs for Python, including in no particular order:

• IDLE which is the 'default' Python IDE, shipped with Python since forever;
• Thonny, which is easy to install along with Python and good for beginners;
• PyCharm, as for Thonny but also part of a robust professional family offering from JetBrains;
• Visual Studio Code, which is not really an IDE but has plugins that mean that it has pretty much replaced IDEs for a large part of the development community in most languages.
• The online IDE from Programiz which is probably the easiest and quickest way to start programming and can run on almost anything e.g. a Chromebook.

 

[Vanadium 50]

unsupported operand type(s) for +: 'int' and 'str'

I admit I never tried that in Python, but I find that astonishing and not very Pythonic. I would have expected Python to promote teh 2 to a "2" and make this a "22".

 

[PeterDonis]

I would have expected Python to promote teh 2 to a "2" and make this a "22".

That would be guessing that the intent was string concatenation rather than integer addition. But why should that be the default? One could just as easily argue that it's more likely that the programmer meant to do integer addition so the "2" should be interpreted as an integer and added to the 2 to make 4.

Python would rather make the programmer be explicit and correct about stating what they intend, instead of guessing about incorrect constructs that could be interpreted multiple ways.

 

[pbuk]

Python would rather make the programmer be explicit and correct about stating what they intend, instead of guessing about incorrect constructs that could be interpreted multiple ways.

That was a good decision. Shame that whoever made it was out of office when the decisions about the relationships between True, False and 1, 0 were made (and why were they not fixed in v3?). Anyway this is OT.

# The power of truth.
print(10 ** True) # 10

# The power of double truth.
print(10 ** (True + True)) = 100

# Wait for it...
print(True == 1) # True
print((True + False) == 1) # True
one = 1
print((True + False) is one) # True
print(True is one) # False - gotcha!

 

[PeterDonis]

the relationships between True, False and 1, 0

I agree that treating bool as a subtype of int doesn't make a lot of sense. Historically bool was tacked on as a separate type during the evolution of Python 2 but I don't think the consequences were ever fully considered.

why were they not fixed in v3?

My ranting answer: they were too busy making bad decisions about how to "fix" the handling of Unicode to make good decisions about other stuff. (AFAIK making bool its own independent type has never been on the radar of the Python core developers anyway.)

 

[Rene Dekker]

I agree completely. Data types are encountered early in learning Python with

# Adding numbers.
print(2 + 2) # 4

# Adding strings (concatenation).
print("2" + "2") # 22

# You can't mix types.
print(2 + "2") # TypeError: unsupported operand type(s) for +: 'int' and 'str'

I don't want to be harsh on you, but this is exactly the kind of thing that we are trying to avoid. If "data types" are mentioned, and you can only think of numbers and strings, then you may have learned a programming language, but have not learned software design.

The most striking disadvantages of Python wrt. for example Java:
- limited focus on separated data structures with defined, encapsulated functionality.
- no static type checking, meaning that type faults come up at run-time rather than compile time.
- limited support for separation of concerns.

If you have already learned software design based on a more structured language, then it is easy to put something together in Python, and you can even write decent programs in it. But the lack of static type checking would still be blocking for large scale deployment.

So as a first language to learn software design, I would definitely say that there is a consensus NOT to use Python, or any other dynamically typed language.
There is a consensus to use a more structured language like Java.

I also agree with the others that C++ is not suited as first language. It is overly complex, with loads of features and peculiarities that distract from the program solving focus. Multiple inheritance, as discussed in this thread, is almost never required or used.

 

[PeterDonis]

limited support for separation of concerns

What exactly is the difference between Python and Java in this respect?

 

[Vanadium 50]

But why

I ask myself that every time I sue Python., Wht? Why of why?

With strong typing, the language never needs to guess. With weak typing, it does, although often the choice is obvious. Python is kind of slushy. But the guesswork goes like this: 2 + "a" can onlt be "2a" so 2 + "2" should be 22.

I'm not complaining about what it's doing, hjust astonished. Like running into an exotic deancer in church on Sunday. You can be glad she's there but still be surprised to see her.