Python’s tug of war between beginner-friendly and advanced features

I think the time is ideal for the &quot;next Python&quot;. A new, general-purpose, beginner-friendly language focused on readability, but designed from the ground up with the techniques &amp; features learned in the past 2 decades.<p>Python has added lots of features to stay current with the latest trends in programming languages, but this has come at the cost of complexity and redundancy (e.g. look at all the ways to format strings or do filesystem operations). And many of the new features such as type annotations have a compromised design due to their being added to Python late in the game. Python&#x27;s &quot;batteries included&quot; approach of a large standard library was a great asset in the days before package managers but these days I think it would be better to start with a much leaner stdlib and add things in more stringently.

I thought that article was going to be about the newer stuff like decorators, &quot;async&quot;, and unchecked type hints. But no.<p>The Rust compiler is doing a reasonably good job on error messages. It&#x27;s especially good at explaining that thing A being done here is incompatible with thing B way over there. It prints the source for both places, which is a rare feature.<p>A compiler that does global analysis can tell you more about what&#x27;s wrong. Python, in its interpreter implementation, doesn&#x27;t have the global info to tell you about global problems.

Python is a very intuitive and easy-to-read language for experienced programmers, but I wouldn&#x27;t consider it a &quot;beginner-friendly&quot; one. It&#x27;s packed to the brim with features that are hard for beginners to understand without first coming to grips with a more simple language. Those features are extremely useful for experienced programmers who want to get stuff out the door quickly and easily, but they&#x27;re overwhelming for novices. Most <i>experienced developers</i> I work with produce what I would consider to be pretty bad Python code - not because they are bad developers but because they haven&#x27;t had enough experience with Python to understand everything it comes with out-of-the-box.

I teach Python to learners.<p>It has substantial pain points, the most significant in my opinion being the semantic white space that never really ever stops being a problem.<p>JavaScript runs in the browser, has relatively trivial syntax, no semantic white space, C-like, a superior and more useful GUI, etc.<p>I see no reason to teach Python per se unless people request it.

the reason this is a conversation is because of how massively successful Python has been at the intersection of &quot;reasonably simple syntax, reasonably simple language, reasonably simple runtime, reasonably simple builtins&quot;.<p>Python is the biggest victim of its own success. There have been warts in Python since the beginning, but they mostly only look like warts in retrospect because of how much Python has shifted the conversation about what a language _could_ be.<p>I hope someday something truly better along all the relevant axes will replace Python. But Python has maximized utility along so many of those axes that it&#x27;s an (observably) uphill battle for everybody who is currently trying.

I am a noob in programming. My impression is Python is easy language but only for day to day simple task. When you start to delve deeper, it is actually very big and complex language. Sometimes I feel like it is the C language which is actually a very small language and <i>easier</i> to learn (I know writing correct and complex C program is hard).

Another example of the support for type hints turning code which should be invalid into valid code with unexpected behaviour:<p><a href="https:&#x2F;&#x2F;mobile.twitter.com&#x2F;reuvenmlerner&#x2F;status&#x2F;1290317124997648386" rel="nofollow">https:&#x2F;&#x2F;mobile.twitter.com&#x2F;reuvenmlerner&#x2F;status&#x2F;129031712499...</a>

What is this vodoo syntax:<p>x = list[1, 2, 3, 4]<p>I assume yet another new bit of python syntax thats unguessable what it means...

Python is my favorite programming language because of its simplicity and ease of use. For example, working with lists in a REPL is easy:<p><pre><code> &gt;&gt;&gt; print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] </code></pre> Integer math works exactly the way you would expect with no horrible surprises at all:<p><pre><code> &gt;&gt;&gt; print [x * 3 for x in range(10)] [0, 3, 6, 9, 12, 15, 18, 21, 24, 27] &gt;&gt;&gt; print [x &#x2F; 3 for x in range(10)] [0, 0, 0, 1, 1, 1, 2, 2, 2, 3] </code></pre> Python is great for little one-off tasks; say you want a color half the brightness of #308cfb<p><pre><code> &gt;&gt;&gt; hex(0x30 &#x2F; 2) &#x27;0x18&#x27; &gt;&gt;&gt; hex(0x8c &#x2F; 2) &#x27;0x46&#x27; &gt;&gt;&gt; hex(0xfb &#x2F; 2) &#x27;0x7d&#x27; </code></pre> The built-in support for dictionaries and JSON parsing make data conversion easy:<p><pre><code> &gt;&gt;&gt; import json &gt;&gt;&gt; json.dumps({&#x27;foo&#x27;: 42, &#x27;bar&#x27;: 132}.values()) &#x27;[42, 132]&#x27; </code></pre> If there&#x27;s one thing I love about Python, it&#x27;s how easy and consistent it is. It sure is great that we&#x27;ve spent the last decade teaching Python to every scientist, academic, and hobbyist.<p>If there are two things I love about Python, it&#x27;s that and the reliable, well-supported Python package manager.

Is there a strongly, statically typed language with a syntax similar to Python? Why even newest languages embrace the braces and can&#x27;t tolerate python indentation block system? (I do understand that these are controversial features, please forgive me!)<p>I was so upset when Boo was ditched from Unity, I loved it so much!

This was interesting, although slightly confusing to read since it was written in the context of using the author&#x27;s &quot;Friendly Traceback&quot; [1] system.<p>I would humbly suggest that maybe the <i>name</i> &quot;friendly traceback&quot; is not the most beginner-friendly thing, since if you are a beginner programmer you are perhaps not 100% sure what a &quot;traceback&quot; is, and why you would benefit from friendlier tracebacks.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;aroberge&#x2F;friendly-traceback" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aroberge&#x2F;friendly-traceback</a>

Or a beginner-friendly REPL could link errors directly to Stackoverflow search results page.

I thought the article would talk about new features like optional types and asyncio and how beginners are having trouble understanding them (specially asyncio). But it is only about error messages. To be honest the only hint I nedded was the line number and the error became pretty obvious. Sure, new languages like Rust and Elm are doing exciting work in this space, and I am excited to see how other languages will adopt them. But, TBH, I had more problems with complex language constructs (like asyncio and the borrow checker) than with error messages.

To generate a more helpful error message in this case, you could just look at the arguments to the list type to check if they are values or other types. In the case of list[1, 2, 3, 4] it should be straightforward for the error reporting mechanism to see that these are values and based on that, suggest list(1, 2, 3, 4).<p>I don&#x27;t see type annotations as adding a fundamental difficulty to the sorts of error reporting described in the article, just something which makes it a bit more challenging to achieve.

I teach R in a graduate course. As long as you teach the concept of vectors right, and it’s not hard, you’ve overcome R’s main cognitive hurdle, in the eyes of computer science people. The rest of R is beautiful, assuming a focus on the Tidyverse.<p>Python feels like a mess by comparison. As a computer science type myself, my tribe’s provincialism towards “languages like C”, like Python, just gets old.

Python&#x27;s really as good as the underlying libraries and bindings. As long as you play within the standard library everything&#x27;s fine but for most large projects that require a button of dependencies I&#x27;ve quickly ran up to the wall of needing more features &#x2F; performance and ended up patching the underlying C++ code...

Why is this an either or?<p>That level of debug information is useful to &quot;advanced&quot; users. Sometimes the hardest things to debug are brain fart moments. also when a library raises an exception that you&#x27;ve never seen before, extra context is useful.<p>I frankly couldn&#x27;t give a shit about :=, but I would give money for GIL-less multithreading.

I’m not interested in using type annotations in Python. But, whenever I express my wish that they hadn’t been added to the language, the reply is always “they’re optional, you don’t have to use them”.<p>Thank you for yet another example of why there’s really no such thing as an “optional” feature.

I honestly can’t think of a better language for beginners and experts alike with the exception of perhaps JavaScript.

If you can’t create beginners, you can’t create juniors, or seniors.

There are three observations which are really interesting to me.<p>One is that traditionally, there was a clear split between &quot;system languages&quot; which were usually fast, compiled languages that were relatively verbose, not very comfortable, and comparatively unsafe -- and &quot;scripting languages&quot;, which were dynamically typed, dynamic memory management, often interpreted, offered more data types and facilities, but were slower.<p>C belonged clearly to the first group and shell scripts, Perl and Python to the second.<p>But the gap between these two groups has been shrinking, as languages are overall converging: Java uses dynamic memory management, Go has a very fast compiler, C++, Scala and Rust have iterators, type inference and such. On the other hand, script-like languages added type annotations, got generally faster, and so on. Much of this is due to better and better compilers.<p>Python stands out in this landscape like a sore thumb - its performance did not profit much from better compilers.<p>There is another axis which is the range between direct low-level manipulation of bits and bytes and symbolic computation and functional languages. Lisps, OCaml, Scala and Haskell are from the family tree of symbolic computation. Traditionally, these languages were heavy-weights and slow compared to the system languages, but they also have seen enormous progress from better compilers - Common Lisp implementations like SBCL can now produce code which is almost as fast as C. As a consequence, there is also a convergence of general languages with &quot;symbolic&quot; features like first-class functions, type inference, list comprehensions, and so on.<p>The third observation which I find very interesting is how much Python and modern Lisps&#x2F;Schemes do have in common. If one has a close look, the extend of this convergence is really astonishing.<p>Here are some things that modern Lisps like SBCL, Schemes and functional languages on the one hand side, and Python3 do have in common:<p>* a Read-Eval-Print Loop (REPL)<p>* strong dynamic typing<p>* automatic memory management<p>* memory safety<p>* exceptions<p>* a wide choice of built-in data types: lists, strings, vectors, arrays, dictionaries &#x2F; hash maps, tuples, sets<p>* keyword arguments and optional arguments in functions<p>* handling of names in scopes and names spaces<p>* closures and lambda functions<p>* list comprehensions<p>* pattern matching (limited support for tuples and lists in Python)<p>* Unicode strings<p>* arbitrarily long integers<p>* complex numbers<p>* rational numbers<p>* number type are part of a hierarchical type hierarchy (numeric tower)<p>* empty sequences, containers and strings are logically false<p>* support for threads (but no real parallelism in Python)<p>* low-level bit operations (a bit limited in Python)<p>* easy way to call into C code<p>* type annotations<p>* if ... else can be used as an expression<p>* string formatting is a mini language<p>* hexadecimal, octal and binary literals<p>* standard functions for functional programming like map and filter<p>* support for OOP (e.g. by the Common Lisp Object System)<p>* support for asynchronous execution<p>The few remaining distinctions between Lisps and Python are:<p>1. Lisps use parentheses to determine scope, while Python uses indentation and white space.<p>2. Lisps usually compile either to native code or to JIT-compiled byte code, while standard Python uses interpreted byte code.<p>3. Python does not support true parallel execution within the same process.<p>4. Lisps have of course the typical macro system which, for example, allows to define new control constructs, while Python does not have macros.<p>5. Lisps and Schemes have with conditions, restarts, and continuations some unique way to handle errors and manipulate the control flow (see <a href="http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;book&#x2F;beyond-exception-handling-conditions-and-restarts.html" rel="nofollow">http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;book&#x2F;beyond-exception-handling-co...</a> )<p>So, what I find really interesting is that for example Common Lisp, which was standardized first in 1984, has so many features in common with more recent languages - and still much better performance than python:<p><a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;fastest&#x2F;python3-java.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a><p><a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;fastest&#x2F;lisp.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a><p><a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;fastest&#x2F;racket-java.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a><p><a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;fastest&#x2F;ocaml-java.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a>

hmm I really didn&#x27;t find the examples in this article to be compelling reasons to suggest the problems highlighted in its main thesis: that there is an inherent problem with fitting its audience.<p>In fact I think Javascript fits the title better. Python3 is still simple and advanced enough over Python 2, I just don&#x27;t really agree with the author here.

This article felt a little bit silly to me, Python intentionally is one of the easiest languages to use. And this article kind of argues it needs to get even easier?<p>The only thing I can dream about is some type of typescript like version of Python with good old-fashioned type checking. I prefer C# and Flutter only because I really need types when my applications get larger.