Should I learn C++ or Python?
secretsofconsulting.blogspot.com
secretsofconsulting.blogspot.com
If you're excited about web servers, pick up Ruby/Rails - or if you think you might want to create a client side application, pick up Javascript and some framework like Angular or React and build something that you can deploy as soon as possible.
If you're into Machine Learning, pick up Python and start going through ML tutorials and jupyter notebooks while attempting to solve some problem in ML that you find interesting.
Don't pick a language based upon some esoteric development principle that undergirds it. Pick a first language based upon its ability to keep you banging away at the keyboard all night, doing something you think is cool.
As crusso basically stated, the answer is actually twofold because you have to:
#1 Choose a problem that is fun to solve. #2 Learn the language that is the best suited to solve that problem.
Regarding #1 up there, the reason you choose something fun to solve is because programming is hard. But, if you are having fun, the enjoyment of solving will keep you motivated through the tough times. You'll find solutions, push through and level up.
Its the same reason you should pick a career you enjoy.
You hit the nail on the head.
Maybe you want to make cabinets, or houses, or decks. Pick the tools that help you make what you want to make.
Both Python and C++ are general albeit Python had a major disadvantage in performance while C++ in clarity. (That said, more modern versions of both have the disadvantages reduced.)
Or get Unity and learn their built-in scripting language. No need to spend years learning C++, OpenGL, etc. if you're not planning on being the next Carmack.
Yes. After much reflection, I decided that I'm at the "fuck it, I'll use Rails" point for new projects. It's easy, batteries-included, and (mostly) fun.
But I'm willing to stand corrected, because Node holds the capability to revolutionize writing single page web apps (SPA) the way rails did for database-backed server-side apps ten years ago.
(I.e. is there a Node SPA equivalent that can automagically build with a one line scaffold command what Rails did for CRUD?)
https://github.com/libgdx/libgdx/wiki/Using-libgdx-with-Pyth...
Here's a screenshot of something I prototyped. http://pasteboard.co/y6bxRPA3e.png
The answer to this question is unequivocally "screwdrivers". The answer to the original question (if you find yourself asking it), is "Python."
The analogy is perfect for this situation, but the answer provided here is wrong.
The original question [1] is unqualified, so I will take a liberty or two here and assume that they're new to programming and want to learn more. And since there's no real dichotomy here, I'll infer they're really asking "should I learn C++ or Python [first]?"
Well, C++ is indeed a saw and while they're incredibly capable, injuries are included for free. Python, like a screwdriver offers maximum utility. Learn Python first.
> Do you think someone could be a top-flight carpenter knowing only one?
Who cares about being a top-flight carpenter? Just figure out how to open up the battery pack for your kids' toys and you will be a hero. Whether you're starting a career in CS or you just want to cleanup the data in the office's mega-spreadsheet-that-has-all-our-critical-info, start with Python. Get that productivity that enables a positive feedback loop of design/test.
I started with C/C++ before Python existed and it was just so easy to get stuck on several classes of failures that were difficult to understand without outside help. Python has some of those but IMO far fewer.
It'll be hard for a while, but you will have learned a lot when you get there.
Python is what everyone's switching to because it's easier. If that's your goal, just build stuff and don't care about how it works, then sure, go python. And I would encourage you to learn Python (and Java, and Go, and Haskell, and Prolog, ...) to get more tools in the toolbox eventually.
Only a few Java specific things and an emphasis on patterns and workarounds for things you cannot do directly because the language is so limited.
Java is a decent first choice, but not a second one.
I think when we talk about languages we talk about 2 different things. Some people talk about syntax and some about paradigms. Computer languages and some claim human ones too (see https://en.wikipedia.org/wiki/Linguistic_relativity) shape how we think about problems. They are not simply tools. Languages withing the same paradigm can probably be interchanged as tools. I programmed in C++, Java, Python and C#. I can switch between them effectively after a few weeks of remembering "how things are different", well ok maybe not C++... But I cannot switch easily to logic programming like that though. Even if it had a C like syntax instead of Prolog or LISP, because it requires a different way of thinking.
One you learn a paradigm you start solving problems differently and potentially a lot more efficiently, (Well and some less efficiently too). And also it may be hard to switch to another paradigm, because once everything is an object, and you keep state there, switching to functional language can be trickier than just starting with functional to begin with.
The analogy is bad. One cannot use a screwdriver to cut boards. Those two tools serve completely different functions. But most of the things that one can do with C++, one can also do with Python. And considering you are just starting out, that "most" is virtually 100%.
A better analogy would be, "Should I learn band saws or circular saws or hand saws?" To become a master carpenter, one will of course need to learn them all. But when just starting out, picking one kind of saw is just fine.
Java/C# are boring, but once that little script grows into a massive beast you will be glad you can rely on the compiler doing a basic unit test of your program.
This is even considering that even though you have a huge amount of advantage with a dynamic type system most people don't end up using it. (http://neverworkintheory.org/2016/06/13/polymorphism-in-pyth...)
Not if I bother to write a few suitable unit tests, which I should really be doing anyway. Typechecking is absurdly far from substituting for checks that my code actually does what I intended it to do.
(As opposed to automated functional tests or pure regression tests.)
Also that evidence was comparing test driven against test later, not against no test. That project tested was small enough and short enough to be ran by a single dev.
I'd say 90% of developers, which includes a lot of good ones too, never learned to write good unit tests. Poorly written unit tests are worse for productivity and no better for correctness than no unit tests.
The other problem is when you're starting out you lose out on a lot of historic perspective. You get smashed over the head with Maven, Spring 1,2,3 (ORM, JPA) inverse versioning code, Hibernate, Transactions, Annotations, Servlet, JSP document/JSP pages.
Each collectively take about a year to get confident to give accurate quotes for large government projects. Let alone figuring what the hell the framework is doing.
The Python door opens to a large and playful room with about 100,000 packages ready for download on an incredible range of topics.
The C++ door opens to a room of lower level tools that can help you understand how your machine "thinks" about problems and how the data flows. It gives you more low level control but takes it also takes more effort to write multi-featured applications.
IMO, programmers should know at least one high level rapid application development language (such as Python, Ruby, or Perl) and at least one lower level language (such as C, D, Go, or Rust).
In addition, it is worthwhile to learn Javascript because it has a near monopoly on an enormous ecosystems of client-side tools.
The language is fluff around the concepts. Get the concepts and you can go to any languages.
If you learn C++ you will understand the collection of tradeoffs that go into making Python surface-level pretty and below-surface as ugly as anything else.
If you learn Python you will be wildly productive until you paint yourself into a corner.
Mind you, for a big enough problem any system currently available is restricted.
For instance you have your standard list, which IIRC is implemented as a dynamically allocated array of pointers to Python objects. This gives very fast append and pop operations on it's right side, making it a wonderful stack. However it's interface specifically lacks a dedicated prepend/appendleft operation, because appending to the left of the array involves shifting the entire structure over one place in memory. This is a very slow operation, because it must copy the entire structure to simply insert a single element. Python get's away with append on the right, by allocating a bit of extra "padding" memory on the right side, to avoid having to copy the structure. For the situation where you want to append to either side, Python offers `collections.deque`. This structure is implemented with a linked list of pointers, IIRC. Which gives very fast append operations from either side, because adding a new element only involves "hooking" the new element to the preferred side, kind of like a chain.
However for understanding how these structures are implemented C based languages are the way to go.
Not quite sure I get this. What's this got to do with Python? Arrays, or more specifically resizing arrays, are supposed to work like what you just described. Appends are constant time and you almost always have extra memory because of the resizing nature. Is this different in other languages?
This isn't to say that Python is somehow, the be-all end-all language, but it's a very nice language, with many nice aspects to learn from.
C++ and python are something you may want to learn depending on your needs.
Rust might have a future or it might be dead in 10 years. Its main focus is a very narrow definition of safety (memory safety and partial data trace safety) at low cost.
For Rust, I agree 100%, and that's why I qualified my statement the way I did. It's too immature a language used mainly by people who are vested in it and few others.
I suggested OCaml for its static typing features, speed (comparable to C++), potential to deploy universally (desktop, mobile, web), and last but not least because of its pragmatism--if you need to do some imperative programming, it gets out of your way.
On a serious note: these are the 2 primary languages at companies like Google, so it can't hurt.
typically, those new to programming have written in some language prior. it's usually just a few lines, but it's enough to get them hooked!
encouraging them to explore what they've already touched upon gives them something to latch onto. they presumably already had the tools set up, so what's wrong with continuing?