26 ms·

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

227 points by aroberge 6y ago

offtop5 6y ago
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? 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.
- quibono 6y ago
  What about the typing module in py3? I now try to use it whenever I'm doing things in Python, it makes it a lot easier to orient yourself around a codebase.
- The_rationalist 6y ago
  Mypy allow basic type checking
- londons_explore 6y ago
  > Python intentionally is one of the easiest languages to use. That was python 2... Python 3 is "growing up" and losing the simplicity and ease of use for complex hard to understand power-user features... It's the lifecycle of any language - see C++ which is 20 years ahead on the same curve...
  - RHSeeger 6y ago
    Honestly, I don't recall any time at which C++ was intentionally easy to use.
    - loopz 6y ago
      With the right tooling and libraries, C++ could be both powerful and easy. Of course it means marrying a platform usually, of which there are many..
    - londons_explore 6y ago
      I guess back in 1985, it was the easy to use version of C... It handles allocating and deallocating memory for you, keeping data and code together, a nicer way to write to the console, and other basic things. I think you have to look at it with 40-year-ago eyes to see it...
  - offtop5 6y ago
    I disagree, I learned Python 3 and found it very very easy, even in a professional setting. If I need to knock out a script to format a CSV file, Python 3 is an easy and fast choice.
- tcbasche 6y ago
  A typescript-like version of Python is basically the latest version of Python with static-analysis tools like mypy or pyright
  - BadInformatics 6y ago
    The type system is a lot less sound and expressive than even TypeScript's though, so it doesn't quite offer the same level of security. I find any doesn't tend to stick around long when I use TypeScript, but my Python projects are full of cast()s and Pyright ignore comments. Typeshed is nowhere as comprehensive as DefinitelyTyped either, but that's more of a community building problem.
londons_explore 6y ago
What is this vodoo syntax: x = list[1, 2, 3, 4] I assume yet another new bit of python syntax thats unguessable what it means...
- travisjungroth 6y ago
  It’s a type hint. But this is a tricky bug and it would normally be more obvious.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- duckerude 6y ago
  It's nonsense that happens to not raise an exception. Typical use would look more like this: x: list[int] = [] i.e. x is a list of integers that starts out empty. It doesn't automatically do anything at runtime, it's basically a glorified comment for tools and libraries to use. So that does make it harder to figure out what it is.
- filmor 6y ago
  That is completely normal syntax that "always" worked with the right thing named `list`.
  - dmurray 6y ago
    It worked if "list" was specifically a dictionary one of whose keys was the tuple (1, 2, 3, 4), and only then because Python allows you to omit the parentheses around the tuple in most situations. Or it could work with a custom type with overridden operators through __getitem__. It's a stretch to call it "completely normal" though I believe you're correct in a strict sense: you could always construct the rest of your program such that it would contain that line and still compile. It would be extremely bad style.
    - 6y ago
CivBase 6y ago
Python is a very intuitive and easy-to-read language for experienced programmers, but I wouldn't consider it a "beginner-friendly" one. It'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're overwhelming for novices. Most experienced developers I work with produce what I would consider to be pretty bad Python code - not because they are bad developers but because they haven't had enough experience with Python to understand everything it comes with out-of-the-box.
- Bostonian 6y ago
  What language would you consider beginner-friendly?
  - retrac 6y ago
    Python is great glue. But it's huge. Packed full of features. Has all sorts of syntactic sugar. It's the C++ of scripting languages. Great for an intermediate programmer who just needs to slap something together. But at the very beginning, these can actually be drawbacks because there's so very much to learn. I would suggest something small, that you can realistically fit all in your head. I honestly believe Pascal is still an excellent choice. For something a little less low-level and more scripting-like, Lua seems nice. The JavaScript ecosystem is awkward, and there are things to criticize (no integers?) but by itself, it's a nice small language as well.
    - echelon 6y ago
      > It's the C++ of scripting languages. This is such a fantastic analogy. Thank you! C++ tries to be all the paradigms, even if they're bolted on. Python is similar in that regard. Complex OO, functional, exceptions, decorators, lots of container types, iterators, generators, operator overloads... The only thing it's missing is a macro language. Python's "batteries included" standard library stance takes it even beyond the C++ analogy in terms of sheer volume of out of the box capabilities you get.
Animats 6y ago
I thought that article was going to be about the newer stuff like decorators, "async", and unchecked type hints. But no. The Rust compiler is doing a reasonably good job on error messages. It'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. A compiler that does global analysis can tell you more about what's wrong. Python, in its interpreter implementation, doesn't have the global info to tell you about global problems.
- j-krieger 6y ago
  rustc sadly comes to a screeching halt when anything is done with generics. I seriously don‘t understand the obsession with naming generics „T“, „X“ or „Z“. Single character variables have been declared bad since the 60s, why hasn‘t the same happened for generic type parameters?
  - creata 6y ago
    Do you have an example of where single-letter type parameters lead to confusion? I haven't seen one yet.
    - deleted 6y ago
      [deleted]
    - Omin 6y ago
      This Rust function has badly chosen single-letter type parameters that confused someone on my team recently: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.map_err https://doc.rust-lang.org/stable/std/result/enum.Result.html... Result<T,E> uses T for a generic contained value and E for another generic contained value that should be an error. So far so good. The `map_err` method then uses F for the new error type because it's just next alphabetically to E and uses O for the closure it accepts as parameter because F is taken. Usually, F is used for function arguments. F and O are not just non-descriptive, having F not be the function when there's a function argument is actively misleading. Instead of `F`, something like `NEW_E` or `NEW_ERROR` would have been much easier to understand.
pansa2 6y ago
Another example of the support for type hints turning code which should be invalid into valid code with unexpected behaviour: https://mobile.twitter.com/reuvenmlerner/status/1290317124997648386 https://mobile.twitter.com/reuvenmlerner/status/129031712499...
- IgorPartola 6y ago
  I still can’t quite figure out why type hinting is such a sought after feature. Over the years I’ve worked with various programming languages and I can’t recall any instance where I wrote code that contained a type bug that I didn’t instantly catch without the aid of any specialized tooling. The only use for it I can see is type checking for user input. Say you create an API for calculating sales tax and as an input it takes a subtotal of the cart as an integer and I instead pass in a dict or a list. But at the same time, shouldn’t you be sanitizing your inputs more than just by type? Like for example against negative numbers? I suppose code highlighters and autocomplete could also use that information but then again I rarely use those. What am I missing with the obsession over type hinting?
  - munchbunny 6y ago
    Over the years I’ve worked with various programming languages and I can’t recall any instance where I wrote code that contained a type bug that I didn’t instantly catch without the aid of any specialized tooling. Guess you're just a better programmer. I've run into many in JavaScript and Python.
    - IgorPartola 6y ago
      I don’t think that’s it. Maybe it’s my style of debugging or some such, but while I am a competent developer I wouldn’t attribute this to some kind of brilliance or exceptional way of thinking. I’ve pair programmed enough to know that I do things the conventional way. About the only thing I can think of is that I still routinely switch to C for Arduino projects so I am cognizant of things needing to be the right type and don’t rely on automatic casting like you get in PHP and JS.
  - 6y ago
pansa2 6y ago
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”. Thank you for yet another example of why there’s really no such thing as an “optional” feature.
franklyt 6y ago
I teach Python to learners. It has substantial pain points, the most significant in my opinion being the semantic white space that never really ever stops being a problem. JavaScript runs in the browser, has relatively trivial syntax, no semantic white space, C-like, a superior and more useful GUI, etc. I see no reason to teach Python per se unless people request it.
- Kim_Bruning 6y ago
  That's interesting. The semantic white space is part of what made me fall in love with the language[1]. What kind of problems do your learners have with it? [1] (You should be indenting to indicate your block structure anyway. A lot of beginners I've seen get their indents mixed up with the actual block structure. Not so with Python: The code runs like how it looks.)
  - jampekka 6y ago
    I'm really starting think there are a lot of people who think "programming" is mindlessly copypasting snippets off somewhere until something works. And they don't like significant whitespace because it reduces the chances of randomly copypasted stuff doing something.
    - newen 6y ago
      This is what is generally called a straw man logical fallacy. The issue is that something as simple as copying and pasting code (say from one file to another, both of which the programmer has written) is made excessively complex due to whitespace being significant. Call it code smell or developer smell or keyboard smell or whatever you want but this issue simply does not exist for programming languages that do not have whitespace significance.
  - bobbylarrybobby 6y ago
    The correct solution to this problem is an autoformatter. You should be indenting your code to match its structure, yes, but if you use Python you have to do so, whereas if you use a brace delimited language you don’t, as it’s handled for you (by the autoformatter). In both cases, your code looks right before you run it, but the editing experiences differ drastically. In Python, a simple cut/paste is nontrivial to get right and it’s difficult for editors to infer how to indent a line when you press the return key. In a brace delimited language, these problems simply don’t exist.
yout2 6y ago
I think the time is ideal for the "next Python". A new, general-purpose, beginner-friendly language focused on readability, but designed from the ground up with the techniques & features learned in the past 2 decades. 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's "batteries included" 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.
- systemvoltage 6y ago
  I agree with you except the last bit - I want a giant language with professionally developed official libraries. Not some junkies slapping half-baked libs together. There is so much calm and peace that comes with std libs. It's not mutually exclusive. You can have a well crafted and large std lib and still can use external libraries. Nothing is stopping you from BYOL. I would also want some kind of a typing support, ala Pydantic built in. If for nothing else, I would like to know wtf is this function taking in as args. Can we also run this in a browser!? One can dream.
  - yout2 6y ago
    I agree with you that it's great to have a comprehensive stdlib but I think the process should be careful and gradual. Python's stdlib has a lot of stuff that is not really best-in-class or consistent in design. I think with today's ubiquity of package managers, we could get away with a smaller stdlib initially, and take time to validate libraries with real world usage before blessing them with official status.
    - systemvoltage 6y ago
      Indeed, but from your own original comment - we have hindsight. So we can build an excellent std lib from the get go. There are other bundles that are very popular for a reason. Conda. That's all you need to know. People want stability of dependencies, not wild wild west on pulling libs from random github repos.
lwneal 6y ago
Python is my favorite programming language because of its simplicity and ease of use. For example, working with lists in a REPL is easy: >>> print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Integer math works exactly the way you would expect with no horrible surprises at all: >>> print [x * 3 for x in range(10)] [0, 3, 6, 9, 12, 15, 18, 21, 24, 27] >>> print [x / 3 for x in range(10)] [0, 0, 0, 1, 1, 1, 2, 2, 2, 3] Python is great for little one-off tasks; say you want a color half the brightness of #308cfb >>> hex(0x30 / 2) '0x18' >>> hex(0x8c / 2) '0x46' >>> hex(0xfb / 2) '0x7d' The built-in support for dictionaries and JSON parsing make data conversion easy: >>> import json >>> json.dumps({'foo': 42, 'bar': 132}.values()) '[42, 132]' If there's one thing I love about Python, it's how easy and consistent it is. It sure is great that we've spent the last decade teaching Python to every scientist, academic, and hobbyist. If there are two things I love about Python, it's that and the reliable, well-supported Python package manager.
- rightbyte 6y ago
  > Integer math works exactly the way you would expect with no horrible surprises at all: >>> print [x / 3 for x in range(10)] [0, 0, 0, 1, 1, 1, 2, 2, 2, 3] Wont that print floats nowadays?
  - pansa2 6y ago
    Without parentheses, it won’t print anything.
  - duckerude 6y ago
    All the examples are things that no longer work in Python 3. Half of them are about functions like range() and .values() becoming lazy instead of returning simple lists. I think this is a genuine blow to ease of use, though it does get rid of performance pitfalls. The other half are about / always doing float division. But I think that's actually more intuitive for people who aren't already used to other programming languages, and it's much more predictable given that Python is dynamically typed and floats and ints sometimes get mixed up. It's also not awkward to work around, you can just write // instead of /. (Working around the other issue requires wrapping list() around things, which gets ugly very fast.)
f430 6y ago
hmm I really didn'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. In fact I think Javascript fits the title better. Python3 is still simple and advanced enough over Python 2, I just don't really agree with the author here.
ledauphin 6y ago
the reason this is a conversation is because of how massively successful Python has been at the intersection of "reasonably simple syntax, reasonably simple language, reasonably simple runtime, reasonably simple builtins". 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. 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's an (observably) uphill battle for everybody who is currently trying.
deleted 6y ago
[deleted]
est 6y ago
Or a beginner-friendly REPL could link errors directly to Stackoverflow search results page.
whalesalad 6y ago
I honestly can’t think of a better language for beginners and experts alike with the exception of perhaps JavaScript.
mayankkaizen 6y ago
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 easier to learn (I know writing correct and complex C program is hard).
- odonnellryan 6y ago
  Im not sure python gets harder once you dive in. The hardest part of python is performance (when you need it) and making sure you don't make too much of a mess with the freedom you're given (though every language has this to some degree imo).
nromiun 6y ago
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.
j45 6y ago
If you can’t create beginners, you can’t create juniors, or seniors.
peterkelly 6y ago
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). I don'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.
unwind 6y ago
This was interesting, although slightly confusing to read since it was written in the context of using the author's "Friendly Traceback" [1] system. I would humbly suggest that maybe the name "friendly traceback" is not the most beginner-friendly thing, since if you are a beginner programmer you are perhaps not 100% sure what a "traceback" is, and why you would benefit from friendlier tracebacks. [1] https://github.com/aroberge/friendly-traceback https://github.com/aroberge/friendly-traceback
- aroberge 6y ago
  I agree with you: it is a bit of a "chicken and the egg" problem. I see it mostly as a tool that would be used/suggested by teachers, and that it would possibly be integrated in some editors targeted at beginners, such as Mu and Thonny. I have had discussions with developers for these two projects who all showed some interest in doing so when Friendly-traceback is more mature.
KaiserPro 6y ago
Why is this an either or? That level of debug information is useful to "advanced" users. Sometimes the hardest things to debug are brain fart moments. also when a library raises an exception that you've never seen before, extra context is useful. I frankly couldn't give a shit about :=, but I would give money for GIL-less multithreading.
deleted 6y ago
[deleted]
AuthorizedCust 6y ago
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. 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.
Lucasoato 6y ago
Is there a strongly, statically typed language with a syntax similar to Python? Why even newest languages embrace the braces and can't tolerate python indentation block system? (I do understand that these are controversial features, please forgive me!) I was so upset when Boo was ditched from Unity, I loved it so much!
- nepeckman 6y ago
  Well since you asked, there is Nim (nim-lang.org). The syntax isnt exactly Python, but it is whitespace sensitive and heavily draws from Python. It has a lot of great features, if you want a typed language with whitespace sensitive syntax, I recommend it!
- Rendello 6y ago
  When I was primarily developing in Python I hated using languages with braces, and especially Lua with is then...end blocks, but I think I've come around now. I appreciate the ability to format things on the next line without worry about how the system will handle it. It's more of a formatting edge case but it comes up enough to be useful. In the end, I feel like it doesn't matter to me nearly as much as other syntax choices in languages, as I've done a lot of Python with no braces and a lot of other stuff with them. I don't even notice anymore (although maybe counterintuitively I find braces a bit more readable now).
- N1H1L 6y ago
  Technically Cython is also a answer
kuroguro 6y ago
Python's really as good as the underlying libraries and bindings. As long as you play within the standard library everything's fine but for most large projects that require a button of dependencies I've quickly ran up to the wall of needing more features / performance and ended up patching the underlying C++ code...
jnxx 6y ago
There are three observations which are really interesting to me. One is that traditionally, there was a clear split between "system languages" which were usually fast, compiled languages that were relatively verbose, not very comfortable, and comparatively unsafe -- and "scripting languages", which were dynamically typed, dynamic memory management, often interpreted, offered more data types and facilities, but were slower. C belonged clearly to the first group and shell scripts, Perl and Python to the second. 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. Python stands out in this landscape like a sore thumb - its performance did not profit much from better compilers. 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 "symbolic" features like first-class functions, type inference, list comprehensions, and so on. The third observation which I find very interesting is how much Python and modern Lisps/Schemes do have in common. If one has a close look, the extend of this convergence is really astonishing. Here are some things that modern Lisps like SBCL, Schemes and functional languages on the one hand side, and Python3 do have in common: * a Read-Eval-Print Loop (REPL) * strong dynamic typing * automatic memory management * memory safety * exceptions * a wide choice of built-in data types: lists, strings, vectors, arrays, dictionaries / hash maps, tuples, sets * keyword arguments and optional arguments in functions * handling of names in scopes and names spaces * closures and lambda functions * list comprehensions * pattern matching (limited support for tuples and lists in Python) * Unicode strings * arbitrarily long integers * complex numbers * rational numbers * number type are part of a hierarchical type hierarchy (numeric tower) * empty sequences, containers and strings are logically false * support for threads (but no real parallelism in Python) * low-level bit operations (a bit limited in Python) * easy way to call into C code * type annotations * if ... else can be used as an expression * string formatting is a mini language * hexadecimal, octal and binary literals * standard functions for functional programming like map and filter * support for OOP (e.g. by the Common Lisp Object System) * support for asynchronous execution The few remaining distinctions between Lisps and Python are: 1. Lisps use parentheses to determine scope, while Python uses indentation and white space. 2. Lisps usually compile either to native code or to JIT-compiled byte code, while standard Python uses interpreted byte code. 3. Python does not support true parallel execution within the same process. 4. Lisps have of course the typical macro system which, for example, allows to define new control constructs, while Python does not have macros. 5. Lisps and Schemes have with conditions, restarts, and continuations some unique way to handle errors and manipulate the control flow (see http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co... ) 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: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ocaml-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

227 points by aroberge 6y ago

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? 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.

quibono 6y ago
What about the typing module in py3? I now try to use it whenever I'm doing things in Python, it makes it a lot easier to orient yourself around a codebase.
The_rationalist 6y ago
Mypy allow basic type checking
londons_explore 6y ago
> Python intentionally is one of the easiest languages to use. That was python 2... Python 3 is "growing up" and losing the simplicity and ease of use for complex hard to understand power-user features... It's the lifecycle of any language - see C++ which is 20 years ahead on the same curve...
- RHSeeger 6y ago
  Honestly, I don't recall any time at which C++ was intentionally easy to use.
  - loopz 6y ago
    With the right tooling and libraries, C++ could be both powerful and easy. Of course it means marrying a platform usually, of which there are many..
  - londons_explore 6y ago
    I guess back in 1985, it was the easy to use version of C... It handles allocating and deallocating memory for you, keeping data and code together, a nicer way to write to the console, and other basic things. I think you have to look at it with 40-year-ago eyes to see it...
- offtop5 6y ago
  I disagree, I learned Python 3 and found it very very easy, even in a professional setting. If I need to knock out a script to format a CSV file, Python 3 is an easy and fast choice.
tcbasche 6y ago
A typescript-like version of Python is basically the latest version of Python with static-analysis tools like mypy or pyright
- BadInformatics 6y ago
  The type system is a lot less sound and expressive than even TypeScript's though, so it doesn't quite offer the same level of security. I find any doesn't tend to stick around long when I use TypeScript, but my Python projects are full of cast()s and Pyright ignore comments. Typeshed is nowhere as comprehensive as DefinitelyTyped either, but that's more of a community building problem.

londons_explore 6y ago

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

travisjungroth 6y ago
It’s a type hint. But this is a tricky bug and it would normally be more obvious.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
duckerude 6y ago
It's nonsense that happens to not raise an exception. Typical use would look more like this: x: list[int] = [] i.e. x is a list of integers that starts out empty. It doesn't automatically do anything at runtime, it's basically a glorified comment for tools and libraries to use. So that does make it harder to figure out what it is.
filmor 6y ago
That is completely normal syntax that "always" worked with the right thing named `list`.
- dmurray 6y ago
  It worked if "list" was specifically a dictionary one of whose keys was the tuple (1, 2, 3, 4), and only then because Python allows you to omit the parentheses around the tuple in most situations. Or it could work with a custom type with overridden operators through __getitem__. It's a stretch to call it "completely normal" though I believe you're correct in a strict sense: you could always construct the rest of your program such that it would contain that line and still compile. It would be extremely bad style.
  - 6y ago

CivBase 6y ago

Python is a very intuitive and easy-to-read language for experienced programmers, but I wouldn't consider it a "beginner-friendly" one. It'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're overwhelming for novices. Most experienced developers I work with produce what I would consider to be pretty bad Python code - not because they are bad developers but because they haven't had enough experience with Python to understand everything it comes with out-of-the-box.

Bostonian 6y ago
What language would you consider beginner-friendly?
- retrac 6y ago
  Python is great glue. But it's huge. Packed full of features. Has all sorts of syntactic sugar. It's the C++ of scripting languages. Great for an intermediate programmer who just needs to slap something together. But at the very beginning, these can actually be drawbacks because there's so very much to learn. I would suggest something small, that you can realistically fit all in your head. I honestly believe Pascal is still an excellent choice. For something a little less low-level and more scripting-like, Lua seems nice. The JavaScript ecosystem is awkward, and there are things to criticize (no integers?) but by itself, it's a nice small language as well.
  - echelon 6y ago
    > It's the C++ of scripting languages. This is such a fantastic analogy. Thank you! C++ tries to be all the paradigms, even if they're bolted on. Python is similar in that regard. Complex OO, functional, exceptions, decorators, lots of container types, iterators, generators, operator overloads... The only thing it's missing is a macro language. Python's "batteries included" standard library stance takes it even beyond the C++ analogy in terms of sheer volume of out of the box capabilities you get.

Animats 6y ago

I thought that article was going to be about the newer stuff like decorators, "async", and unchecked type hints. But no. The Rust compiler is doing a reasonably good job on error messages. It'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. A compiler that does global analysis can tell you more about what's wrong. Python, in its interpreter implementation, doesn't have the global info to tell you about global problems.

j-krieger 6y ago
rustc sadly comes to a screeching halt when anything is done with generics. I seriously don‘t understand the obsession with naming generics „T“, „X“ or „Z“. Single character variables have been declared bad since the 60s, why hasn‘t the same happened for generic type parameters?
- creata 6y ago
  Do you have an example of where single-letter type parameters lead to confusion? I haven't seen one yet.
  - deleted 6y ago
    [deleted]
  - Omin 6y ago
    This Rust function has badly chosen single-letter type parameters that confused someone on my team recently: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.map_err https://doc.rust-lang.org/stable/std/result/enum.Result.html... Result<T,E> uses T for a generic contained value and E for another generic contained value that should be an error. So far so good. The `map_err` method then uses F for the new error type because it's just next alphabetically to E and uses O for the closure it accepts as parameter because F is taken. Usually, F is used for function arguments. F and O are not just non-descriptive, having F not be the function when there's a function argument is actively misleading. Instead of `F`, something like `NEW_E` or `NEW_ERROR` would have been much easier to understand.

pansa2 6y ago

Another example of the support for type hints turning code which should be invalid into valid code with unexpected behaviour: https://mobile.twitter.com/reuvenmlerner/status/1290317124997648386 https://mobile.twitter.com/reuvenmlerner/status/129031712499...

IgorPartola 6y ago
I still can’t quite figure out why type hinting is such a sought after feature. Over the years I’ve worked with various programming languages and I can’t recall any instance where I wrote code that contained a type bug that I didn’t instantly catch without the aid of any specialized tooling. The only use for it I can see is type checking for user input. Say you create an API for calculating sales tax and as an input it takes a subtotal of the cart as an integer and I instead pass in a dict or a list. But at the same time, shouldn’t you be sanitizing your inputs more than just by type? Like for example against negative numbers? I suppose code highlighters and autocomplete could also use that information but then again I rarely use those. What am I missing with the obsession over type hinting?
- munchbunny 6y ago
  Over the years I’ve worked with various programming languages and I can’t recall any instance where I wrote code that contained a type bug that I didn’t instantly catch without the aid of any specialized tooling. Guess you're just a better programmer. I've run into many in JavaScript and Python.
  - IgorPartola 6y ago
    I don’t think that’s it. Maybe it’s my style of debugging or some such, but while I am a competent developer I wouldn’t attribute this to some kind of brilliance or exceptional way of thinking. I’ve pair programmed enough to know that I do things the conventional way. About the only thing I can think of is that I still routinely switch to C for Arduino projects so I am cognizant of things needing to be the right type and don’t rely on automatic casting like you get in PHP and JS.
- 6y ago

pansa2 6y ago

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”. Thank you for yet another example of why there’s really no such thing as an “optional” feature.

franklyt 6y ago

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

Kim_Bruning 6y ago
That's interesting. The semantic white space is part of what made me fall in love with the language[1]. What kind of problems do your learners have with it? [1] (You should be indenting to indicate your block structure anyway. A lot of beginners I've seen get their indents mixed up with the actual block structure. Not so with Python: The code runs like how it looks.)
- jampekka 6y ago
  I'm really starting think there are a lot of people who think "programming" is mindlessly copypasting snippets off somewhere until something works. And they don't like significant whitespace because it reduces the chances of randomly copypasted stuff doing something.
  - newen 6y ago
    This is what is generally called a straw man logical fallacy. The issue is that something as simple as copying and pasting code (say from one file to another, both of which the programmer has written) is made excessively complex due to whitespace being significant. Call it code smell or developer smell or keyboard smell or whatever you want but this issue simply does not exist for programming languages that do not have whitespace significance.
- bobbylarrybobby 6y ago
  The correct solution to this problem is an autoformatter. You should be indenting your code to match its structure, yes, but if you use Python you have to do so, whereas if you use a brace delimited language you don’t, as it’s handled for you (by the autoformatter). In both cases, your code looks right before you run it, but the editing experiences differ drastically. In Python, a simple cut/paste is nontrivial to get right and it’s difficult for editors to infer how to indent a line when you press the return key. In a brace delimited language, these problems simply don’t exist.

yout2 6y ago

I think the time is ideal for the "next Python". A new, general-purpose, beginner-friendly language focused on readability, but designed from the ground up with the techniques & features learned in the past 2 decades. 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's "batteries included" 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.

systemvoltage 6y ago
I agree with you except the last bit - I want a giant language with professionally developed official libraries. Not some junkies slapping half-baked libs together. There is so much calm and peace that comes with std libs. It's not mutually exclusive. You can have a well crafted and large std lib and still can use external libraries. Nothing is stopping you from BYOL. I would also want some kind of a typing support, ala Pydantic built in. If for nothing else, I would like to know wtf is this function taking in as args. Can we also run this in a browser!? One can dream.
- yout2 6y ago
  I agree with you that it's great to have a comprehensive stdlib but I think the process should be careful and gradual. Python's stdlib has a lot of stuff that is not really best-in-class or consistent in design. I think with today's ubiquity of package managers, we could get away with a smaller stdlib initially, and take time to validate libraries with real world usage before blessing them with official status.
  - systemvoltage 6y ago
    Indeed, but from your own original comment - we have hindsight. So we can build an excellent std lib from the get go. There are other bundles that are very popular for a reason. Conda. That's all you need to know. People want stability of dependencies, not wild wild west on pulling libs from random github repos.

lwneal 6y ago

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

rightbyte 6y ago
> Integer math works exactly the way you would expect with no horrible surprises at all: >>> print [x / 3 for x in range(10)] [0, 0, 0, 1, 1, 1, 2, 2, 2, 3] Wont that print floats nowadays?
- pansa2 6y ago
  Without parentheses, it won’t print anything.
- duckerude 6y ago
  All the examples are things that no longer work in Python 3. Half of them are about functions like range() and .values() becoming lazy instead of returning simple lists. I think this is a genuine blow to ease of use, though it does get rid of performance pitfalls. The other half are about / always doing float division. But I think that's actually more intuitive for people who aren't already used to other programming languages, and it's much more predictable given that Python is dynamically typed and floats and ints sometimes get mixed up. It's also not awkward to work around, you can just write // instead of /. (Working around the other issue requires wrapping list() around things, which gets ugly very fast.)

f430 6y ago

hmm I really didn'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. In fact I think Javascript fits the title better. Python3 is still simple and advanced enough over Python 2, I just don't really agree with the author here.

ledauphin 6y ago

the reason this is a conversation is because of how massively successful Python has been at the intersection of "reasonably simple syntax, reasonably simple language, reasonably simple runtime, reasonably simple builtins". 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. 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's an (observably) uphill battle for everybody who is currently trying.

deleted 6y ago

[deleted]

est 6y ago

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

whalesalad 6y ago

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

mayankkaizen 6y ago

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 easier to learn (I know writing correct and complex C program is hard).

odonnellryan 6y ago
Im not sure python gets harder once you dive in. The hardest part of python is performance (when you need it) and making sure you don't make too much of a mess with the freedom you're given (though every language has this to some degree imo).

nromiun 6y ago

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.

j45 6y ago

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

peterkelly 6y ago

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). I don'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.

unwind 6y ago

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

aroberge 6y ago
I agree with you: it is a bit of a "chicken and the egg" problem. I see it mostly as a tool that would be used/suggested by teachers, and that it would possibly be integrated in some editors targeted at beginners, such as Mu and Thonny. I have had discussions with developers for these two projects who all showed some interest in doing so when Friendly-traceback is more mature.

KaiserPro 6y ago

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

deleted 6y ago

[deleted]

AuthorizedCust 6y ago

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. 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.

Lucasoato 6y ago

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

nepeckman 6y ago
Well since you asked, there is Nim (nim-lang.org). The syntax isnt exactly Python, but it is whitespace sensitive and heavily draws from Python. It has a lot of great features, if you want a typed language with whitespace sensitive syntax, I recommend it!
Rendello 6y ago
When I was primarily developing in Python I hated using languages with braces, and especially Lua with is then...end blocks, but I think I've come around now. I appreciate the ability to format things on the next line without worry about how the system will handle it. It's more of a formatting edge case but it comes up enough to be useful. In the end, I feel like it doesn't matter to me nearly as much as other syntax choices in languages, as I've done a lot of Python with no braces and a lot of other stuff with them. I don't even notice anymore (although maybe counterintuitively I find braces a bit more readable now).
N1H1L 6y ago
Technically Cython is also a answer

kuroguro 6y ago

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

jnxx 6y ago

There are three observations which are really interesting to me. One is that traditionally, there was a clear split between "system languages" which were usually fast, compiled languages that were relatively verbose, not very comfortable, and comparatively unsafe -- and "scripting languages", which were dynamically typed, dynamic memory management, often interpreted, offered more data types and facilities, but were slower. C belonged clearly to the first group and shell scripts, Perl and Python to the second. 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. Python stands out in this landscape like a sore thumb - its performance did not profit much from better compilers. 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 "symbolic" features like first-class functions, type inference, list comprehensions, and so on. The third observation which I find very interesting is how much Python and modern Lisps/Schemes do have in common. If one has a close look, the extend of this convergence is really astonishing. Here are some things that modern Lisps like SBCL, Schemes and functional languages on the one hand side, and Python3 do have in common: * a Read-Eval-Print Loop (REPL) * strong dynamic typing * automatic memory management * memory safety * exceptions * a wide choice of built-in data types: lists, strings, vectors, arrays, dictionaries / hash maps, tuples, sets * keyword arguments and optional arguments in functions * handling of names in scopes and names spaces * closures and lambda functions * list comprehensions * pattern matching (limited support for tuples and lists in Python) * Unicode strings * arbitrarily long integers * complex numbers * rational numbers * number type are part of a hierarchical type hierarchy (numeric tower) * empty sequences, containers and strings are logically false * support for threads (but no real parallelism in Python) * low-level bit operations (a bit limited in Python) * easy way to call into C code * type annotations * if ... else can be used as an expression * string formatting is a mini language * hexadecimal, octal and binary literals * standard functions for functional programming like map and filter * support for OOP (e.g. by the Common Lisp Object System) * support for asynchronous execution The few remaining distinctions between Lisps and Python are: 1. Lisps use parentheses to determine scope, while Python uses indentation and white space. 2. Lisps usually compile either to native code or to JIT-compiled byte code, while standard Python uses interpreted byte code. 3. Python does not support true parallel execution within the same process. 4. Lisps have of course the typical macro system which, for example, allows to define new control constructs, while Python does not have macros. 5. Lisps and Schemes have with conditions, restarts, and continuations some unique way to handle errors and manipulate the control flow (see http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co... ) 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: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ocaml-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...