No, they didn’t. And I’m sure recruiters are just as clueless as I was.
It’s not difficult to learn though there are some syntax challenges - for example a more traditional language might have a structure like
IF blah blah
THEN
do something;
do something else;
END IF;
Whereas Python handles this via indenting.
IF blah
do something
do something else
So for this, indenting is key. Sloppy, to some extent, because there’s no visual cutoff.
Playing with the various data structures can be interesting - and there are libraries to do some pretty nifty statistical stuff - I had to maintain some programs last year that were written by a statistician.
As a hint: someone who has a broader knowledge of programming in general would have done a better job. I came at it from a database perspective, and there were things there that would have been FAR more efficient if that part of the workload had been done in the DB vs the code. Whereas she was a statistician, and knew Python well, but had limited DB experience.
(added preformatting for clarity).
The operative point was that the first example could be written as:
IF blah blah THEN do something; do something else; END IF;
Which people would do, and the resulting code would be unreadable. Or even in C, something like:
if (blah)
do something;
do something else;
Where the indentation actively misleads the reader as to which statements are controlled by the if (only the first).
Python’s significant whitespace was in no small part to prevent readability abominations and mistakes like those. But it didn’t catch on for most programming languages, and we just rely on code formatters for that.
It is; if only Python followed it.
Explicit is better than implicit.
A shame that Python has no variable or type declarations. Even JavaScript has those now (well, technically TypeScript)! What type is this variable? An array, you say? Which of several different array types is it? Bleh.
Actually, a " IF…ELIF…ELSE" statement in Python would look like this:
If a>0:
print('Greater than zero.')
elif a<0:
print('Less than zero.')
else:
print('Exactly zero')
The indenting is the visual cutoff, and because it indenting is enforced (technically you could put a single line response statement on the same line after the colon but it is not done) there is none of this business about stringing commands across one long line as if you’re writing an overly complex Bash script. Far from being “sloppy”, it is parsimonious in not requiring a superfluous THEN or ENDIF statement, and you can identify the entire response block via indentation; no lost semicolons or mistakes in cascading conditional statements.
As for conditionals, Python does a good job of minimizing those via list comprehensions and slicing, and for handling complex numerical transformations NumPy has a long list of different options that can virtually eliminate manually iterating through arrays and speed of performance because all of the computation is done in C within the NumPy libraries instead of the Python bytecode. List comprehensions are an additional complexity to learn but like regex, once you understand how to do it you can write remarkably powerful routines in very compact statements that are efficient by design.
Python isn’t necessarily the best tool for everything–I certainly wouldn’t use it in any kind of real time system programming, and certainly not for some kind of mission critical software even if you could install a Python interpreter on it–but from a language design standpoint it integrates a lot of features and design patterns into the core of the language that, even if you aren’t using it to write explicitly object oriented code, give a lot of benefits in terms of minimizing programming effort to get to a very efficient program.
I can understand why professional programmers, and especially those whose experience in producing highly optimized performance in their code, would dislike dynamic typing, but really the decision to eschew static typing in Python is down at the core of the language insofar as it allows dynamic casting without a bunch of overhead on the programming end. It does mean that the programmer has to be cognizant of what a user might try to provide as an input, but then that is really true with static typing as well. Python does allow for explicit definition of type at the time a data structure is populated so it isn’t as if there is no control; it just isn’t a constraint that I have to know up front that a list is a set of letters, integers, floats, et cetera.
This also makes it work from an imperative sense the same way that numerical computing environments like Matlab and Mathematica work, and while I don’t think that was the intention it does make it easier to transition from one to another without having to remember to declare every variable type before it is used. Frankly, at this point, despite having grown up writing C and Fortran, I consider static typing as much of an anachronism as 80 character limits in Fortran and COBOL, but again, I wouldn’t use Python to write embedded code for anything more sophisticated than a BeagleBone, and would expect the kind of performnce and reliability of well tested C code.
Stranger
Don’t get me wrong–I get why they did it. Python’s a scripting language; dynamic typing is almost the definition of a scripting language (ok, not really, but in practice it’s part-and-parcel). I’m more just amused at the contradiction with their “explicit is better than implicit” dictat.
Typing is more than for performance, though. I see it as similar to units in physics, which enable unit analysis and other useful things. Sure, it adds some upfront overhead, and might even be confusing for newbies, but the benefits largely outweigh the costs–with the exception of small projects (similar to how you might not write down your units for some physics napkin math). Types allow you to judge correctness as you’re writing the code, and in many cases form the basis for “if it compiles, it works”.
I’m not opposed to Python, but someone’s gotta write the underlying libraries. People do write performance-critical code in Python, but as they say, the parts which are fast are not Python, and the parts that are Python are not fast.
That said, I am using Python for more projects, such as robot controllers and clocks (and robot clocks). I don’t know that it’s winning me over from Perl but it is splitting my attention (mostly due to the libraries).
I consider static typing to be having a renaissance, having gotten substantially more sophisticated in the last 5-10 years. Mostly because of type inference in modern languages where you don’t have to name the type every time you declare a variable. (e.g. “auto x = 1;” can be inferred by the complier to mean “int x = 1;” because you just assigned an int to it).
Not having to spell the types out means that the types themselves can become more sophisticated without increasing programmer burden. “auto result = f(x,y,z);” is just as simple to write if f returns a StatusOr<unique_ptr<vector>> as it is if f returns an int.
I love auto typing in C++. It’s basically the best of both worlds. Never mind that you must use it in some cases (lambda functions with capture). It also makes changing types as easy as if they were dynamic; if you want to switch your implementation of ::vector, you only have to do it once at the top of your function.
True - there are definitely benefits to this approach - but it’s also easy to mis-type (forget to indent, indent too much etc.) which has its own problems.
if blah
do task 1
do task 2
Is “do task 2” really supposed to be part of that same if, or is it a different command. and you just forgot to indent? An explicit “endif” or similar isn’t necessarily a bad thing. If you goof up the indenting - a space or two too many or too few - will cause a runtime error.
if blah
do someting
do a second thing
do a third thing
Some interpreters also behave differently if your indent is handled by tab versus space - Spyder was fine with it, but the Linux-based interpreter I was using last year was not happy, even when the code looked identical in a text editor.
Now, the sort of thing mentioned where you jam everything onto one line is just WRONG:
if blah then something1; else something 2; something 3; endif;
There lies madness. Like 99.9 % of GOTO statements in code, just because you CAN do something does not mean you should. Throw in some Unix constructs where a single cryptic string can basically test a condition, pipe output one place if it works and another if it fails… that sort of thing may be uber-cool and all the really in-the-know geeks know it in their sleep, but unless you do shell scripting full time, you are not going to read that easily. For me, who does shell scripting in short bursts - just long enough for me to need to look up about 20% of what I’m doing
Anyway - I was raised on a strict diet of “whitespace don’t count” (said with a strong Southern accent, due to my choice of college and early years of my career) and Python’s approach, while it has its value, hasn’t quite converted me over yet.
I will grant that if you’ve messed up the indenting, you’re likely to find it out in early testing because it behaves wrong (or flat out throws an error). I had the “pleasure” of working with a shell script last fall that was many hundreds of lines long, and the indenting was a nightmare - and there were so many lines of code in each section that I had a hell of a time even figuring out what happened when
if [[ $a == $b ]]
blah
a zillion more blah blah lines with some more if/elif/fi thrown in for fun
blah
blah
fi
I think python is an amazing language, I use it almost daily at my work ( data analysis ). If I need fast code I just write the critical bits in cython (not that beginners should do this). The vast majority of the time python is perfectly fast enough.
I’ve heard that the tutorial “learn python the hard way” is very complete, free, and good python tutorial (though I haven’t really used it myself).
i think python is very easy to learn, probably the easiest I’ve seen, while still being very functional in a professional setting. My ONLY serious gripe is that variable declarations are implied.
I.E.:
A = 5
Could be either assignment or variable declaration. This has caused me to trip many times when I accidentally overwrite an existing variable.
I can certainly see why python isn’t for all situations though. I use C++ when I feel the program is sufficiently complex. However, while I think C++ fits a unique nitch among languages (expressive yet fast), it is a VERY ugly and difficult language. I do NOT recommend C++ for beginners.
I really wish there was a halfway language. That had both dynamic and static variables and you could choose if you want speed or concise language. A language that was as beautiful and concise as python but had the power of C.
To this end I’m actually writing my own language I call cyth. The compiler is in C++. I’ve got some of my ideas written down (poorely) here: 00 Home · Bhare8972/Cyth Wiki · GitHub
WRONG it may be, but I love and use the Python ternary operator (a if x else b) all the time. It’s both convenient and intuitive to me.
Python has no separate variable declaration. There is only assignment.
And I like it that way!
I’ve spent about half my career working in statically typed languages (mostly C# & Java) and half in dynamically typed languages (mostly Ruby & Javascript). I vastly prefer dynamically-typed and I’ve rarely made a mistake because of type errors.
I miss the auto-completion that you get in an IDE in statically typed languages and I appreciate the immutability checking that const vs let gives you in modern Javascript but typing variables … don’t miss it at all.
My hovercraft is full of eels.
Hopefully your hovercraft is a float, and the number of eels is a short int.
My nipples explode with delight!
(Yes, I’m finished. TY.)
Certainly duck-typing great. You can have variable declaration and dynamic types. Requiring variable declaration doesn’t mean you need to have a static type. The variable declaration wouldn’t include a typename like it does in C or C++.
I was in the position of having to teach a short course where some programming was required— not numerical analysis, though. Finally I just looked at the popularity of languages on Github; JavaScript was #1, but for various reasons (perhaps influenced by Crockford’s comments about the “steaming pile of good intentions and blunders”) we did not pick it, and just went with Python, especially since students could easily install the Pycharm editor.
Type hinting in newer versions of Python addresses this. You can (optionally) declare expected types in function parameters, and declare what types a function will return. The interpreter treats these declarations as comments but IDEs and static analysis tools use them to provide better autocomplete and type checking.
I’m a self-taught hobbyist programmer and Python is my first and only language, so I suspect I’m fairly close to the OP (and certainly closer than professional computer scientists and programmers).
I dabbled with other languages over the years - Pascal, C++ and C# - but Python was the one that stuck. I found it very easy to learn and make somewhat useful things with, which is an important part of adopting programming.
There’s a guy called Michael Kennedy who hosts a Python Podcast and he talks about how learning a bit of Python in an otherwise non-technical role can be a “superpower” - enabling to do whatever your day-job is quicker and easier. One oft-quoted use-case is wrangling data or processing files and the like. I suspect this is the context of the job roles the OP mentions - an ability to do the day-job better with a little bit of code rather than being a computer programmer.