17 ms·

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

by 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.
    - BadInformatics 6y ago
      IMO the bundling and curation is the least interesting part of Conda. What's really nice are the build infrastructure, quality checks and proper dependency bounds (looking at you, PyPI). Something like R's CRAN already has those without bundling.
      - systemvoltage 6y ago
        Can poetry do that or that’s different?
        nerdponx 6y ago
        Poetry is pretty much a Setuptools replacement, with optional features to help manage Python virtual environments. It's not a package manager and it does not provide any environment isolation of its own. Conda provides both of those things, and quite a bit more. They are totally different tools. Conda is more like Homebrew than Poetry. What Poetry and Conda have in common is a not-really-bad dependency resolver.
      - nerdponx 6y ago
        And now we have Mamba, which is just like Conda. Except it has a better-documented (and more open) tooling ecosystem. And it lacks the debilitatingly slow/unreliable dependency resolution of Conda. https://mamba.readthedocs.io/en/latest/ https://mamba.readthedocs.io/en/latest/
  - mjmahone17 6y ago
    Most languages would probably benefit from having a “experimental for the standard lib” package that doesn’t guarantee perfection, and might get deprecated then abandoned before making it to the stdlib. But all new features go through that library first. That experimental library could even be backed by other packages, so you could iterate on the interface while allowing other packages to continue to improve the core. But the assumption is for any clearly solved problem, these “batteries” provide one recommended way to solve the problem, and as of now it’s either the only or at least not the worst way to do it.
    - roenxi 6y ago
      Language features either can, or cannot, be used. Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work. Because either it can or cannot be used, and if it can't be used it is a waste of time, if it can be used it must be supported. Once people use a library, there will be pressure to support it forever and the mindshare switch is a real cost. A language bleeds users every time it drops a feature. The Python namespace is still polluted by documentation and tutorials talking about how to do things in v2 too.
      - duckerude 6y ago
        Rust seems to handle it ok. Features can spend a long time being nightly-only gated behind feature flags, while nevertheless seeing real world usage from people willing to brave the risk and churn. But Python has a very different release schedule. Rust's nightly releases nightly and stable every six weeks, while Python only releases once a year. I don't think it could adopt the same model.
      - coldtea 6y ago
        >Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work Well, it can. That's what you get when there's no official package and you depend on third party packages that change all the time (e.g. common in the Node ecosystem, in GTK+ land, etc.), or are abandoned, etc. Compared to that, a scheduled, anticipated process for candidate packages to include in the language (or remove eventually) is much easier.
  - pjmlp 6y ago
    Standard library works pretty much in every platform the language targets, a random package on a package manager might be available, with luck.
- AtlasBarfed 6y ago
  I would also like pip and packaging "fixed", which from my standpoint of a python software user is "broken". The three I rely on are in a constant cycle of breaking each other. ...although that might all be the fault of aws-cli. Which by the way doesn't install on a vanilla Ubuntu 20.04 ami via apt which is just... really really bad. Aws cli continues the inexplicably horrible aws interface that makes me shake my head at people lauding their might, along with their console. The console rewrite... anyway, pip seems to be a headache, certainly not as good as gems.
  - EdwardDiego 6y ago
    I love how you can tell which parts of aws-cli were written by different teams because of how the inconsistencies are consistent within a certain domain.
  - staticautomatic 6y ago
    For god’s sake at least let requirements install in order.
    - CraigJPerry 6y ago
      Are there scenarios where this doesn’t happen? I had a quick look in pip and install order is predicated on requirements order https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15dd06023f4daf2/src/pip/_internal/req/__init__.py#L58 https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15...
  - CraigJPerry 6y ago
    I finally switched to poetry for python deps and happy ever since. It’s basically the gems approach applied to python.
- deleted 6y ago
  [deleted]
- chillfox 6y ago
  I would prefer a simple language with a giant stdlib. Every common protocol/algorithm should be in the stdlib.
  - dietr1ch 6y ago
    This seems too hard to evolve. I'd instead aim for a language that supported interface/trait/typeclasses with a huge standard library of those that allowed writing uniform benchmarks and unit tests to every implementation that shipped simple implementations for some of those and made it easy to use different implementations and experiment with them. This seems like solving just dependency injection instead of trying to solve every library ever, which seems a much more realistic problem to solve correctly, or at least in a way better way.
  - Mauricebranagh 6y ago
    Fortran then :-)
  - 7952 6y ago
    I think a lot of the benefits can be achieved by making more sophisticated types a first class citizen in the language. So for example things like date/time, intervals, and geometries are just another type. And you use normal operators to interact with those types and invoke algorithms.
  - ocdtrekkie 6y ago
    Visual Basic .NET is your perfect beginner language with a rich built in framework and standard library. Ironically, it likely fell for the same reason discussed in this article: It got a lot more complex over time.
  - pas 6y ago
    It's not ... possible/viable at this time. Every common X means thousands of complex things. There are over 9000 RFCs (insert Vegita meme). Even more popular APIs, libs, algorithms, whatevers. Even basic support would be near impossible. A constant race between what constitutes basic and releasing it. (Plus upkeep/maintenance, as things continue to evolve at a rather fast pace.) And if the language enjoys at least a minimal level of successful then a lot of non-stdlib packages are likely to become standard by convention. It's no wonder that new languages nowadays start with minimal stdlibs. (I just noticed that there's an SMTP server in Python3! It's ... great, I guess. But there's no DNS resolver library. So either the SMTP client (and now server) packages do not handle anything related to DNSSEC / DANE / TLSA / MTA-STS / DKIM / DMARC and others, or they bundle it. Sure, maybe it's enough to outsource these to the upstream SMTP server and the SMTPd package is just for "testing" ... but, this just shows how arbitrary "commonness" is.)
- at_a_remove 6y ago
  I agree about the stdlib. There was a reason that xkcd had the "import gravity" joke. One of the reasons I ditched perl was having to evaluate so many different perl libraries, which would do anywhere from thirty to eighty percent of what I needed, and tended to come with some really exciting dependency chains. I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future). Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.
  - CraigJPerry 6y ago
    Anecdotally, this approach has been replicated by go. The stdlib in go is surprisingly complete. I’ve seen several go developers cite this as an advantage, being able to write many apps without adding dependencies from external to the language runtime. I definitely think they’re onto something. Dependencies are a hard problem to solve. Modern build tools like gradle work great at resolving deps, until they don’t and at that point we’re in for a world of shock at just how complex dependency resolution can be in large projects.
- orangetang 6y ago
  How I dream of a future language with the power of rust, ease of python, and the ability to work in a browser.
  - bbojan 6y ago
    Rustonscript :-)
    - deleted 6y ago
      [deleted]
  - cb321 6y ago
    Sounds not far from https://nim-lang.org/ https://nim-lang.org/
- atom_arranger 6y ago
  I'm thinking ReasonML or OCaml might be able to take on this role. I was sad to hear about the change to ReScript though. ReasonML targeting the browser and native seemed nice to me, although I do agree the documentation situation and DX wasn't ideal.
  - leonidasv 6y ago
    Hindley-Milner typing systems are a great way to introduce typing without making beginners afraid of it. The inference make things just work, the way a beginner may expect from the computer.
  - deleted 6y ago
    [deleted]
- Layke1123 6y ago
  Is there a specific advantage to running in the browser versus running in everything at the OS level? I've always been a little confused why are abstractions went all the way up to the browsers. It seems that you could push a lot of browser functionality down the stack and simplify a lot or architectures and remove a lot of cruft we don't need.
  - CraigJPerry 6y ago
    Deployment is easier. Upgrade is easier. Access control, restrictions, permissions; you don’t have to add a user account to namespace/sandbox a process in browser tab. The facilities provided by a browser are almost (but not quite) a complete superset of those provided by an OS. file io, peripheral io, etc. Can all be done via the browser. Additional facilities are provided too (security/sandboxing).
    - Layke1123 6y ago
      Right, but you could implement all of that at the OS level too, which to a large part of my understanding is what things like docker is built on. Changes to the kernel to allow sandboxing at the kernel level for instance versus doing it in user space (which browsers could theoretically implement with syscalls now?), and would reduce a lot of overhead no? Or are browsers faster because they stay in user space and avoid context switching?
      - CraigJPerry 6y ago
        I don’t think so - OS’s have been around much longer than browsers. People have been trying (without anywhere near the success of browsers) to do cross platform deploys for almost as long as OS’s have existed. Now a common model has arrived (dom + js) allowing multiple browsers to just run your app. I’m not sure browsers are faster (there was a thing called pepper api in chrome and nacpi or something in firefox - i’m not familiar with the space) that allowed native code to run. I’m not sure browsers are generally faster than native OS binaries, but they are an easy to deploy to environment that doesn’t need syscall emulation like freebsd can do for running linux binaries.
- nerdponx 6y ago
  I'm not sure I care about the "run this in a browser" part (unless someone developed a WASM backend for it). And FOSS would be a requirement for me. Given those criteria, I would gladly pay a recurring subscription or donation for such a language. For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche. What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc. The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery. edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis. edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
  - raiph 6y ago
    > Raku ... lacks widespread adoption Right. It clearly doesn't have a strong enough offering at the moment to attract anyone beyond a few early adopters. > last I heard it fell significantly short of Perl 5 performance Likewise. I'm pretty sure Perl still roundly trounces it for a lot of operations, especially in regex processing. I think it will need to be significantly faster than Perl before it will have a chance at gaining significantly more adoption. > I'm not sure what kind of library ecosystem it has nowadays The raku.land directory has less than a thousand packages and many seem to be jokes, unloved, poorly tested and documented, version 0.x, or even 0.0.x. [0] The standard library is a different ballgame. It's generally well designed and very large, cutting out the usual blizzard of folk reinventing the wheel for basics. So that's good. > I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. I agree. > Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling. This is where I think Raku's strength lies. A lot of the effort that went into Raku was to build a platform that could just directly use tooling and libraries of other PLs while insulating developers from their downsides. That way you get to use Raku tooling, syntax and semantics at the surface level with other PLs' tooling and modules and performance. Kinda like using C code in a non-C PL, but generalized to using code from any other PL in Raku. The exemplar was supposed to be Perl, but it was also supposed to extend to many other PLs. Starting 7 years ago this became the Inline family.[1] Inline::Perl is the most mature. Imo it's remarkable. But it was always supposed to just be the first one to get the polish to demonstrate that the approach works and works great. About a year ago the author behind it said it was nearly time to do the same for Python modules. And now I see a GSOC proposal to do that.[2] The Inlines hide the warts (though you do have to read the modules' documentation to know what their API's are etc). I think the impact of Inline Python will be huge because it takes away the complaint about reading Perl documentation and code. Instead you read Python API docs but get the benefits of using Raku. (And, in the wings, there's Inline::Ruby, Inline::Lua, and so on.) [0] https://raku.land/ https://raku.land/ [1] https://raku.land/?q=inline https://raku.land/?q=inline [2] https://github.com/perl-foundation-outreach/gsoc-2021-ideas/blob/main/raku/Inline::Python-Update.md https://github.com/perl-foundation-outreach/gsoc-2021-ideas/...
- didibus 6y ago
  Aren't there plenty of languages that fit that description? Java, C#, TypeScript, Kotlin, Swift, et all ?
- fnord123 6y ago
  >Not some junkies slapping half-baked libs together. This is offensive. Whether the people who work hard to make and share (for free) half baked libraries are addicted to drugs is really not part of the main thrust of your argument. You could leave it out, save words, and not have distracting comments from people like me while still making your point.
  - systemvoltage 6y ago
    Are you seriously taking this literally? I didn’t even think this deep when writing it. Honestly! Lighten up. No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. Come on. I am offended that you’re offended by this. Usually, I would apologize for saying something offensive, but I guess someone will get offended on the internet. If I said “Wild Wild West” then may be some Texan would be offended by it. Intention matters. Smile more and be tolerant, no offense :-)
    - fnord123 6y ago
      > No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. If you feel love, share love. xx
      - systemvoltage 6y ago
        Amen.
      - warlog 6y ago
        It's bringing love, don't let it get away! Break it's legs!
    - devoutsalsa 6y ago
      It’s 2021. The Earth is heating up, we have a cult member who believes in baby eating pedophiles in the USA government, and people are still dying from their inability to afford insulin. It’s not that name calling will be taken seriously by everyone, but thoughts like that are distractions we can no longer afford to think about. Put your energy towards ensuring there’s a future worth worrying about.
- arethuza 6y ago
  What about Microsoft's Blazor - compiling C# down to wasm: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
- dvfjsdhgfv 6y ago
  > There is so much calm and peace that comes with std libs. This, and library documentation. It's probably the single practica issue I have with D and Nim. They seem to have fairly robust standard libs but when I look for something specific it always turns out this feature is missing, outdated, or badly documented.
- N1H1L 6y ago
  Libraries in Python are hell. And Stackexchange can be almost pedantically useless in those things. For example let's take OpenCV bindings for Python. 3 separate libraries provide it, which all are called in as import cv2 Yes, Stack Exchange, I know OpenCV can do this for me, but integrating that into my package dependencies is time down the drain which I am never getting back.
xixixao 6y ago
Totally. What Rust is to C.
marmada 6y ago
I've been thinking for a while that it's about time a new (maybe jit compiled?) language hits the scene with: - A simplified/sounder natively integrated version of Typescript's type system - Javascript's easy notation for manipulating objects - None of Javascript's other baggage/cruft - Something akin to go routines Basically, something with the performance of Go/Java (so there would be no need to rewrite your code once it starts serving millions of people) but the elegance of Typescript. Not sure if this is similar to your vision of a "next Python" but it feels somewhat similar. Basically I think right now: C -> Zig C++ -> Rust Java -?-> Go Python/Javascript --> ??? With native typing we could get a language as fast as Java/Go but with the cleanliness of Typescript.
- BadInformatics 6y ago
  I remember a few years back when Nim was going to be the next big thing here, but unfortunately it never gained that level of traction. Still an interesting language even without bigco levels of support behind it.
- deleted 6y ago
  [deleted]
- valenterry 6y ago
  Scala comes very close to that.
  - ledauphin 6y ago
    the JVM is an incredibly heavyweight runtime compared to CPython. I don't think we're going to find the next beginner-friendly language coming out of the most professional runtime in human history.
    - pbourke 6y ago
      > incredibly heavyweight runtime The apps may be heavyweight, but the runtime was designed to run on set-top boxes 25 years ago.
fnoof 6y ago
Keep the python brand and fix these things in a new backwards incompatible python release. Call it Python 4. I’m sure it’ll only take a couple of years for everyone to migrate
II2II 6y ago
Two pieces of advice: - Just learn the language with all of its quirks - If you are new, ignore the quirks until you are ready Creating a new language sounds ideal, but there are a whole slew of caveats. Python tends to be recommended as a beginner language since it is reasonably easy to learn and offers considerable room for growth By the time the Next Python reached that stage, we would have accumulated a new two decades of techniques and features that would leave Next Python in a similar position to Python today. That assumes that people would even agree upon which language would serve as Next Python as a standard recommendation. One of the advantages of having so many people agreeing upon Python as a starting point is it eliminates the first hurdle novices most novices face: figuring out where to start. As for the batteries being included, it is also a strength of Python. Choosing libraries can be difficult. That's true for the novice and it's true for anything but trivial projects. Lean standard libraries encourage fragmentation. We should have learned that from the shortcomings of C, yet many languages have followed in the same footsteps with similar results. We should have learned that large standard libraries can be useful, from the success of languages like Java and Python. Package managers don't change the degree of fragmentation, they only make it easier to deal with.
- smitty1e 6y ago
  > Creating a new language sounds ideal I seriously cannot think of anything I could do to exceed Python. Does it do everything? No. But name a tool with significantly greater overall reach. Some compete, but seriously. . .
  - jimbob45 6y ago
    Better main method calling, better chaining, multiple constructors, and better reflection.
  - jtdev 6y ago
    Agreed. I’ve always felt that the following sums up why Python is my preferred language: Python is the second-best language for everything.
    - 6y ago
belorn 6y ago
New languages need to have a distinct benefit in order to be enough encouraging for new people to learn it over picking something which is already well established. In python case it was something that replaced shell language for data administrators, and many of the quite complex languages used by data scientists. The one big selling point a future language could have would be inherent parallelization that uses all the 32+ cores of the developers machine, but that are as beginner-friendly as python. Such language does not exist. A dynamic, easy to use, and built from the ground up to always utilize all cores all the time without demanding that the programmer are handling side effects.
- fulafel 6y ago
  Using a lot of execution resources is not a direct benefit from the user POV. Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases. Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).
- valenterry 6y ago
  Such a language _can not_ exist, because it stops fulfilling the "beginner-friendly" criteria. As soon as you deal with concurrency, things either get hard to learn or get super messy. Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.
  - jerf 6y ago
    Go minus concurrency actually is a good candidate for a solid beginner language. It has quirks, but no more so than any other choice, and fewer than most, for a beginner. However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later. The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.
bobbylarrybobby 6y ago
In terms of style, Swift feels like the next Python. And it’s starting to pick up a sizable standard library.
- Redoubts 6y ago
  Yeah, every time I’m playing with typing and mypy I start yearning for Swift’s type system instead.
deleted 6y ago
[deleted]
arthurcolle 6y ago
f-strings are amazing Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax. Yes please, and thank you
- pansa2 6y ago
  `str.format` can’t be removed completely - it’s necessary if you want to build format strings at runtime. But otherwise, yes - make f-strings the “one obvious way to do it” and use `format` only when necessary. And get rid of the old %-formatting. Also consider making f-strings the default: https://pyfound.blogspot.com/2020/04/all-strings-become-f-strings-python.html https://pyfound.blogspot.com/2020/04/all-strings-become-f-st...
- woodruffw 6y ago
  > Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax. `format` is still useful, particularly when working with pre-templatized strings. It's also a (relatively) new feature; Python 2 didn't have it at all. OTOH, I wouldn't cry if Python 3.X finally removed %-formatting. `format` does everything that `%` does, with a much nicer API (especially in 3.7+).
- kortex 6y ago
  Jokes on you, my coworker still obsessively uses % args syntax.
  - roelschroeven 6y ago
    I can understand that, to a point. Not the so much the obsessive part, but I sometimes fall back to % formatting too since that uses the formatting syntax I'm familiar with from C and C++. The syntax used in f-strings and .format is probably better, but requires re-learning.
  - CodeGlitch 6y ago
    Please tell me you correct them in the code reviews? Everytime someone uses %args inappropriately a baby seal dies.
- 6y ago
didibus 6y ago
Python 3 ? I feel like Python just went through that big shift. Doubt we need a other one of those. Also, I'd just look at Julia for some of what you're describing. It's basically going for a more focused approach with the learnings of Python in place.
MagicWishMonkey 6y ago
What's wrong with having a robust stdlib? Are those extra 50 megabytes really a problem?
- yout2 6y ago
  The issue is not the size of the stdlib but rather the process for how things get in there. IMHO Python's stdlib has a number of modules of sub-standard quality and design. It would be good to have a gradual process for inclusion in the stdlib, so that different 3rd party libraries could be vetted by the community before we bake one into the language.
jshen 6y ago
Please no, the migration from python 2 to 3 was a disaster and we’re finally on the other side of it.
a3n 6y ago
> I think the time is ideal for the "next Python". We could call it Python 6.
analog31 6y ago
Could something be added to the linter, to flag language features that you don't want to use? This would allow creation of a beginner mode, where all but the most primitive features are left out. It would also be a potentially useful way for us to impose consistency on our codes as they grow in size.
wryun 6y ago
Relatedly, I made a flake8 linter plugin for modern Python if you really feel like being constrained: https://pypi.org/project/flake8-simplicity/ https://pypi.org/project/flake8-simplicity/ https://github.com/wryun/flake8-simplicity/blob/master/flake8_simplicity.py#L7 https://github.com/wryun/flake8-simplicity/blob/master/flake...
nojito 6y ago
F# is that language and is rapidly gaining steam.
pansa2 6y ago
I don't think any single language will be the "next Python" for everybody. Many seem to be happy replacing Python with Go, to get better performance, parallelism and packaging support. However, for my uses I'd much rather replace it with another high-level scripting language, even if it's still slow and single-threaded.
- tcbasche 6y ago
  This is what I’ve done and it’s way easier from a packaging perspective but the thing that stings is Go misses out on all the data science stuff like pandas, numpy etc
dehrmann 6y ago
So a Kotlin for Python?
- Too 6y ago
  Yes, but the other way around :) Kotlin solved the syntax and language warts on top of a good runtime. For python the syntax is (mostly) good but the runtime and package management needs a rehaul.
  - dehrmann 6y ago
    > mostly Bolted-on classes and types annotations, and missing real lambdas isn't awesome, and lack of proper variable scoping is error-prone. I agree that the runtime is a mess, but more in naming inconsistencies and how its organized than functionality.
  - pjmlp 6y ago
    Kotlin solved Google's Android problem, on the JVM it is just another radar noise in the set of guest languages.
    - tpxl 6y ago
      Kotlin was developed by JetBrains, not Google, as a 'better Java'.
      - pjmlp 6y ago
        So what? #KotlinFirst is being pushed by Google. Android is the only place where Kotlin actually matters.
Lammy 6y ago
Ruby 3.0 is a great time to get back into Ruby :)
dzonga 6y ago
Golang looks like that language. it would be my go to, but why they decided to have Nil Pointers, I don't know. Golang without Nil and also mostly pass by value, and only using pass by reference for people doing lower level stuff, would've been good. for now, staying with python. Golang is easy to get started with tooling and packaging is good. but then the code in the wild is littered with pointers for when you wouldn't need them.
reidrac 6y ago
Do you need to use all the features of a language all the time? I don't think you do. A language with a consistent design can have layers, and beginners can just do with the external bits without getting too deep initially, but with enough space to grow. IMHO Python is a good language on that regard.
the__alchemist 6y ago
I'd love a Python 4, or one by any other name, to be like the latest Python, but cleaned up, with no regards for backwards compatibility. For example: a trimmed standard library, and much of the alternate syntaxes removed. Better tooling and official-docs support; ie like Rust: A modern, official package manager, a built-in linter, formatter, binary-creator etc.
- japanuspus 6y ago
  I have a hunch that in five years, the global-state package manager built into python will be a feature because we will all be working exclusively in dev-containers. What does it matter to you if there are features in the standard library you don't use? The full python embedded distribution is only 8MB including runtime.
  - the__alchemist 6y ago
    I hope your hunch is wrong! I feel like containers are a symptom of situations like this Python one.
- kzrdude 6y ago
  Hehe, Python 4 will probably not happen after 2->3.
japanuspus 6y ago
> ... 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. ... But they tend to get ironed out over time. Python 3.9 adds parametrized generic type hints based directly on container types, alleviating the need for a parallel type-hint type system. i.e. `dict[str, list[int]]` over `typing.Dict[str,...]`
- pansa2 6y ago
  That’s exactly the feature that’s causing the problem in this article.
Blikkentrekker 6y ago
Python honestly did not learn from many things that were already well known when it was designed. It wasn't arcane at the time that using exceptions for decision logic, or letting loops run by assignment, rather than by creating a new scope, were not the most salient ideas. The following Python code contains a bug: list_of_adders = [] for x in iterator: list_of_adders.append(lambda y: y+x) Namely, since `x` is assigned with each iteration of the loop, rather than that a new scope is created, the `x` that the closure encloses is re-assigned with it, so all anonymous functions contain the value that `x` had in the last loop, which is almost certainly not what the programmer intended. In fact, if within the same scope, which is quite large, since Python does not like block scope, x ever be re-assigned, which is quite likely, as Python uses the same syntax for initialization and assignment, then all the closures collected in the list shall thenceon refer to the new value that x is assigned to. These are not design choices that many other programming languages at the time made; they were bad with the knowledge of the time, and continue to be bad now. There is no justification to have loops be implemented by assignment, and not create a new scope.
- pansa2 6y ago
  The justification for function-scope instead of block-scope is that only the former really works if you have implicit variable declarations. In turn, implicit variable declarations (using the same syntax for initialisation and assignment) are a reasonable choice for a language that aimed to be “executable pseudocode” and that supports mixing initialisation and assignment in a single statement (e.g. `a, b, self.c = foo()`).
  - Blikkentrekker 6y ago
    It could easily be written as `var a, var b, self.c = foo()`. Having the same syntax for initialization and assignment is quite quæstionable.
    - pansa2 6y ago
      That’s not a bad suggestion, but it’s quite verbose (it would require declaring multiple variables as `var x, var y, var z` instead of `var x, y, z`).
gypsyharlot 6y ago
I spent a few decades chasing "the next great language", and I regret it. I wish I had spent those hours learning about statistics or cryptography or algorightms. Things that are timeless. If you want to be a jack of all trades, master of none, by all means, chase the next great thing. I for one, think it's more likely that Python will evolve. The mathematicians and physicists, biologists, astronomers etc. that have finally gotten rid of C++/Fortran and learnt Python aren't going to change to anything with forced static typing any time soon...
- nmfisher 6y ago
  Not a mathematician/physicist/etc, but having literally dived into Julia today, I think you’d be surprised. It definitely seems like “Python 2.0” for numerical computing.
  - gypsyharlot 6y ago
    Julia is probably excellent. How large are the benefits to using Julia compared to Python? Are the benefits great enough to compensate for the time spent: - Training your entire team to use Julia instead of learning about other relevant things - Re-writing your Python-infrastructure (or dealing with Julia to Python-interoperability, which means new employees now have to learn or know both Python and Julia) - Replacing Jupyter and learning new, similar tools - All employees making their favorite IDEs function well with Julia - Figuring out how to make Julia talk to software that already has an existing Python API (Wireshark, AutoCAD, GNU Radio, ... just about everything you can think of)
    - nmfisher 6y ago
      Those are definitely problems for the corporate world (except for Jupyter, a Julia kernel already exists for that). Again, I’m not an academic so take what I say with a grain of salt - but I can see Julia paying dividends very very quickly in that sphere (once you’re over the admittedly steep learning curve).
    - kirill5pol 6y ago
rini17 6y ago
Learn Common Lisp and you'll find "the techniques & features learned in the past 2 decades" notion laughable. Or sad.
- higerordermap 6y ago
  Why does nobody talk about drawbacks of common lisp?
  - rini17 6y ago
    Because in this thread it would be off topic?
coldtea 6y ago
>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. I think that package managers or not, the "batteries included" approach is great, because it leads to most of the code for useful things already available, and also helps third party packages be smaller (since they can depend on things available in the standard lib). Imagine 3 different packages, for example, each bringing its own different json parser depedency -- as opposed to all leveraging the included json package. That's how you get no community standards but tons of packages for the same basic things in slightly different ways, each with 20%-30% adoption. That's also how you get 1GB node_modules folders. That's also how you have the "leftpad" situation.
nimmer 6y ago
Like a statically typed, compiled Python? With a more flexible approach to OO? That can compile to binary, javascript and other languages? That would be https://nim-lang.org/ https://nim-lang.org/
sai_c 6y ago
Rinse and repeat. Three hundred years later, we're at the original python again. Invented on the USS Enterprise. "To boldly create programming languages no man has created before."
yodelshady 6y ago
>A new, general-purpose, beginner-friendly language focused on readability Sounds great. What made Python so beginner-friendly and readable? Most of the "let's improve Python" gang I see can't begin to answer that - by their metrics, the language must be a failure. Beginners have the advantage of not thinking "this is the best way to do it because that's how C/C++/Java do it".
MaxBarraclough 6y ago
I agree Python has some frustrating imperfections, but it has a pretty great ecosystem, and a new language would presumably have to start over. I wish Python went with static typing from the offset, and I wish it had better parallelism, but with Python you can get a library for just about anything with a simple pip install, and that's worth a great deal. Need a WebSocket library? No problem. Need a cross-platform TUI library? No problem. Python's maturity means you can do a lot of things with little hassle. Some of the less mainstream programming languages are nowhere close to Python in this regard, even after many years.
Qem 6y ago
I think Python's batteries included approach still matters a lot, because many users (myself included) have to work from locked up workstations, with awful tech support, no local administrator privileges, and draconian policies forbidding installation of not previously vetted software. For example, not long ago a colleague requested a Orange (data mining software) install. Corporate IT took more than six months to validate it and fullfill the request. To avoid hassle like that, the most you can get from just the initial install, the better.
higerordermap 6y ago
> 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. With all these memory safe languages getting popular NSA needs more npms, not less.
N1H1L 6y ago
Julia in many ways was designed as the next Python. Their user base is growing steadily, and they may displace Python in many applications a decade from now.
knighthack 6y ago
I agree with you that Python now features some redundancy. Yet I do not agree with you that there is 'complexity', going by your examples. Notwithstanding the various ways of doing the same thing (which sometimes goes against the zen of Python), as of Python 3.6 there's been a constant trend towards f-strings above all else (barring maintenance and legacy code), and generally beginners have no need for anything beyond f-strings. If they'd like to go into the old string formatting techniques, they're welcome to, but they're not that complex. I don't understand how type annotations constitute a 'compromised design' - they've worked quite elegantly with Python's dynamic typing, they greatly assist linters and IDEs when you turn them off, and they can be disregarded when you don't need them, which is a far cry from the enforced typing of other languages. And I certainly do not agree that there is a need for a "next Python". Python does a lot of things very well - it's design is clear, the design patterns are methodical, the language is well-governed, the central packaging system is reliable (and not like the insane NPM and dependencies of JavaScript), there is a distinct idiom/style consistency amongst Pythonistas, a and a large gathering of minds behind the language. Further, Python reads very well, and can be even pseudocode without being pseudocode, which makes it very much suited for beginners who can stray as far as they want to into the language when they feel ready for it. Python is a great language for beginners, so I have no idea what you're talking about.

by yout2 6y ago

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.
  - BadInformatics 6y ago
    IMO the bundling and curation is the least interesting part of Conda. What's really nice are the build infrastructure, quality checks and proper dependency bounds (looking at you, PyPI). Something like R's CRAN already has those without bundling.
    - systemvoltage 6y ago
      Can poetry do that or that’s different?
      - nerdponx 6y ago
        Poetry is pretty much a Setuptools replacement, with optional features to help manage Python virtual environments. It's not a package manager and it does not provide any environment isolation of its own. Conda provides both of those things, and quite a bit more. They are totally different tools. Conda is more like Homebrew than Poetry. What Poetry and Conda have in common is a not-really-bad dependency resolver.
    - nerdponx 6y ago
      And now we have Mamba, which is just like Conda. Except it has a better-documented (and more open) tooling ecosystem. And it lacks the debilitatingly slow/unreliable dependency resolution of Conda. https://mamba.readthedocs.io/en/latest/ https://mamba.readthedocs.io/en/latest/
- mjmahone17 6y ago
  Most languages would probably benefit from having a “experimental for the standard lib” package that doesn’t guarantee perfection, and might get deprecated then abandoned before making it to the stdlib. But all new features go through that library first. That experimental library could even be backed by other packages, so you could iterate on the interface while allowing other packages to continue to improve the core. But the assumption is for any clearly solved problem, these “batteries” provide one recommended way to solve the problem, and as of now it’s either the only or at least not the worst way to do it.
  - roenxi 6y ago
    Language features either can, or cannot, be used. Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work. Because either it can or cannot be used, and if it can't be used it is a waste of time, if it can be used it must be supported. Once people use a library, there will be pressure to support it forever and the mindshare switch is a real cost. A language bleeds users every time it drops a feature. The Python namespace is still polluted by documentation and tutorials talking about how to do things in v2 too.
    - duckerude 6y ago
      Rust seems to handle it ok. Features can spend a long time being nightly-only gated behind feature flags, while nevertheless seeing real world usage from people willing to brave the risk and churn. But Python has a very different release schedule. Rust's nightly releases nightly and stable every six weeks, while Python only releases once a year. I don't think it could adopt the same model.
    - coldtea 6y ago
      >Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work Well, it can. That's what you get when there's no official package and you depend on third party packages that change all the time (e.g. common in the Node ecosystem, in GTK+ land, etc.), or are abandoned, etc. Compared to that, a scheduled, anticipated process for candidate packages to include in the language (or remove eventually) is much easier.
- pjmlp 6y ago
  Standard library works pretty much in every platform the language targets, a random package on a package manager might be available, with luck.
AtlasBarfed 6y ago
I would also like pip and packaging "fixed", which from my standpoint of a python software user is "broken". The three I rely on are in a constant cycle of breaking each other. ...although that might all be the fault of aws-cli. Which by the way doesn't install on a vanilla Ubuntu 20.04 ami via apt which is just... really really bad. Aws cli continues the inexplicably horrible aws interface that makes me shake my head at people lauding their might, along with their console. The console rewrite... anyway, pip seems to be a headache, certainly not as good as gems.
- EdwardDiego 6y ago
  I love how you can tell which parts of aws-cli were written by different teams because of how the inconsistencies are consistent within a certain domain.
- staticautomatic 6y ago
  For god’s sake at least let requirements install in order.
  - CraigJPerry 6y ago
    Are there scenarios where this doesn’t happen? I had a quick look in pip and install order is predicated on requirements order https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15dd06023f4daf2/src/pip/_internal/req/__init__.py#L58 https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15...
- CraigJPerry 6y ago
  I finally switched to poetry for python deps and happy ever since. It’s basically the gems approach applied to python.
deleted 6y ago
[deleted]
chillfox 6y ago
I would prefer a simple language with a giant stdlib. Every common protocol/algorithm should be in the stdlib.
- dietr1ch 6y ago
  This seems too hard to evolve. I'd instead aim for a language that supported interface/trait/typeclasses with a huge standard library of those that allowed writing uniform benchmarks and unit tests to every implementation that shipped simple implementations for some of those and made it easy to use different implementations and experiment with them. This seems like solving just dependency injection instead of trying to solve every library ever, which seems a much more realistic problem to solve correctly, or at least in a way better way.
- Mauricebranagh 6y ago
  Fortran then :-)
- 7952 6y ago
  I think a lot of the benefits can be achieved by making more sophisticated types a first class citizen in the language. So for example things like date/time, intervals, and geometries are just another type. And you use normal operators to interact with those types and invoke algorithms.
- ocdtrekkie 6y ago
  Visual Basic .NET is your perfect beginner language with a rich built in framework and standard library. Ironically, it likely fell for the same reason discussed in this article: It got a lot more complex over time.
- pas 6y ago
  It's not ... possible/viable at this time. Every common X means thousands of complex things. There are over 9000 RFCs (insert Vegita meme). Even more popular APIs, libs, algorithms, whatevers. Even basic support would be near impossible. A constant race between what constitutes basic and releasing it. (Plus upkeep/maintenance, as things continue to evolve at a rather fast pace.) And if the language enjoys at least a minimal level of successful then a lot of non-stdlib packages are likely to become standard by convention. It's no wonder that new languages nowadays start with minimal stdlibs. (I just noticed that there's an SMTP server in Python3! It's ... great, I guess. But there's no DNS resolver library. So either the SMTP client (and now server) packages do not handle anything related to DNSSEC / DANE / TLSA / MTA-STS / DKIM / DMARC and others, or they bundle it. Sure, maybe it's enough to outsource these to the upstream SMTP server and the SMTPd package is just for "testing" ... but, this just shows how arbitrary "commonness" is.)
at_a_remove 6y ago
I agree about the stdlib. There was a reason that xkcd had the "import gravity" joke. One of the reasons I ditched perl was having to evaluate so many different perl libraries, which would do anywhere from thirty to eighty percent of what I needed, and tended to come with some really exciting dependency chains. I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future). Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.
- CraigJPerry 6y ago
  Anecdotally, this approach has been replicated by go. The stdlib in go is surprisingly complete. I’ve seen several go developers cite this as an advantage, being able to write many apps without adding dependencies from external to the language runtime. I definitely think they’re onto something. Dependencies are a hard problem to solve. Modern build tools like gradle work great at resolving deps, until they don’t and at that point we’re in for a world of shock at just how complex dependency resolution can be in large projects.
orangetang 6y ago
How I dream of a future language with the power of rust, ease of python, and the ability to work in a browser.
- bbojan 6y ago
  Rustonscript :-)
  - deleted 6y ago
    [deleted]
- cb321 6y ago
  Sounds not far from https://nim-lang.org/ https://nim-lang.org/
atom_arranger 6y ago
I'm thinking ReasonML or OCaml might be able to take on this role. I was sad to hear about the change to ReScript though. ReasonML targeting the browser and native seemed nice to me, although I do agree the documentation situation and DX wasn't ideal.
- leonidasv 6y ago
  Hindley-Milner typing systems are a great way to introduce typing without making beginners afraid of it. The inference make things just work, the way a beginner may expect from the computer.
- deleted 6y ago
  [deleted]
Layke1123 6y ago
Is there a specific advantage to running in the browser versus running in everything at the OS level? I've always been a little confused why are abstractions went all the way up to the browsers. It seems that you could push a lot of browser functionality down the stack and simplify a lot or architectures and remove a lot of cruft we don't need.
- CraigJPerry 6y ago
  Deployment is easier. Upgrade is easier. Access control, restrictions, permissions; you don’t have to add a user account to namespace/sandbox a process in browser tab. The facilities provided by a browser are almost (but not quite) a complete superset of those provided by an OS. file io, peripheral io, etc. Can all be done via the browser. Additional facilities are provided too (security/sandboxing).
  - Layke1123 6y ago
    Right, but you could implement all of that at the OS level too, which to a large part of my understanding is what things like docker is built on. Changes to the kernel to allow sandboxing at the kernel level for instance versus doing it in user space (which browsers could theoretically implement with syscalls now?), and would reduce a lot of overhead no? Or are browsers faster because they stay in user space and avoid context switching?
    - CraigJPerry 6y ago
      I don’t think so - OS’s have been around much longer than browsers. People have been trying (without anywhere near the success of browsers) to do cross platform deploys for almost as long as OS’s have existed. Now a common model has arrived (dom + js) allowing multiple browsers to just run your app. I’m not sure browsers are faster (there was a thing called pepper api in chrome and nacpi or something in firefox - i’m not familiar with the space) that allowed native code to run. I’m not sure browsers are generally faster than native OS binaries, but they are an easy to deploy to environment that doesn’t need syscall emulation like freebsd can do for running linux binaries.
nerdponx 6y ago
I'm not sure I care about the "run this in a browser" part (unless someone developed a WASM backend for it). And FOSS would be a requirement for me. Given those criteria, I would gladly pay a recurring subscription or donation for such a language. For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche. What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc. The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery. edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis. edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
- raiph 6y ago
  > Raku ... lacks widespread adoption Right. It clearly doesn't have a strong enough offering at the moment to attract anyone beyond a few early adopters. > last I heard it fell significantly short of Perl 5 performance Likewise. I'm pretty sure Perl still roundly trounces it for a lot of operations, especially in regex processing. I think it will need to be significantly faster than Perl before it will have a chance at gaining significantly more adoption. > I'm not sure what kind of library ecosystem it has nowadays The raku.land directory has less than a thousand packages and many seem to be jokes, unloved, poorly tested and documented, version 0.x, or even 0.0.x. [0] The standard library is a different ballgame. It's generally well designed and very large, cutting out the usual blizzard of folk reinventing the wheel for basics. So that's good. > I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. I agree. > Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling. This is where I think Raku's strength lies. A lot of the effort that went into Raku was to build a platform that could just directly use tooling and libraries of other PLs while insulating developers from their downsides. That way you get to use Raku tooling, syntax and semantics at the surface level with other PLs' tooling and modules and performance. Kinda like using C code in a non-C PL, but generalized to using code from any other PL in Raku. The exemplar was supposed to be Perl, but it was also supposed to extend to many other PLs. Starting 7 years ago this became the Inline family.[1] Inline::Perl is the most mature. Imo it's remarkable. But it was always supposed to just be the first one to get the polish to demonstrate that the approach works and works great. About a year ago the author behind it said it was nearly time to do the same for Python modules. And now I see a GSOC proposal to do that.[2] The Inlines hide the warts (though you do have to read the modules' documentation to know what their API's are etc). I think the impact of Inline Python will be huge because it takes away the complaint about reading Perl documentation and code. Instead you read Python API docs but get the benefits of using Raku. (And, in the wings, there's Inline::Ruby, Inline::Lua, and so on.) [0] https://raku.land/ https://raku.land/ [1] https://raku.land/?q=inline https://raku.land/?q=inline [2] https://github.com/perl-foundation-outreach/gsoc-2021-ideas/blob/main/raku/Inline::Python-Update.md https://github.com/perl-foundation-outreach/gsoc-2021-ideas/...
didibus 6y ago
Aren't there plenty of languages that fit that description? Java, C#, TypeScript, Kotlin, Swift, et all ?
fnord123 6y ago
>Not some junkies slapping half-baked libs together. This is offensive. Whether the people who work hard to make and share (for free) half baked libraries are addicted to drugs is really not part of the main thrust of your argument. You could leave it out, save words, and not have distracting comments from people like me while still making your point.
- systemvoltage 6y ago
  Are you seriously taking this literally? I didn’t even think this deep when writing it. Honestly! Lighten up. No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. Come on. I am offended that you’re offended by this. Usually, I would apologize for saying something offensive, but I guess someone will get offended on the internet. If I said “Wild Wild West” then may be some Texan would be offended by it. Intention matters. Smile more and be tolerant, no offense :-)
  - fnord123 6y ago
    > No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. If you feel love, share love. xx
    - systemvoltage 6y ago
      Amen.
    - warlog 6y ago
      It's bringing love, don't let it get away! Break it's legs!
  - devoutsalsa 6y ago
    It’s 2021. The Earth is heating up, we have a cult member who believes in baby eating pedophiles in the USA government, and people are still dying from their inability to afford insulin. It’s not that name calling will be taken seriously by everyone, but thoughts like that are distractions we can no longer afford to think about. Put your energy towards ensuring there’s a future worth worrying about.
arethuza 6y ago
What about Microsoft's Blazor - compiling C# down to wasm: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
dvfjsdhgfv 6y ago
> There is so much calm and peace that comes with std libs. This, and library documentation. It's probably the single practica issue I have with D and Nim. They seem to have fairly robust standard libs but when I look for something specific it always turns out this feature is missing, outdated, or badly documented.
N1H1L 6y ago
Libraries in Python are hell. And Stackexchange can be almost pedantically useless in those things. For example let's take OpenCV bindings for Python. 3 separate libraries provide it, which all are called in as import cv2 Yes, Stack Exchange, I know OpenCV can do this for me, but integrating that into my package dependencies is time down the drain which I am never getting back.

xixixao 6y ago

Totally. What Rust is to C.

marmada 6y ago

I've been thinking for a while that it's about time a new (maybe jit compiled?) language hits the scene with: - A simplified/sounder natively integrated version of Typescript's type system - Javascript's easy notation for manipulating objects - None of Javascript's other baggage/cruft - Something akin to go routines Basically, something with the performance of Go/Java (so there would be no need to rewrite your code once it starts serving millions of people) but the elegance of Typescript. Not sure if this is similar to your vision of a "next Python" but it feels somewhat similar. Basically I think right now: C -> Zig C++ -> Rust Java -?-> Go Python/Javascript --> ??? With native typing we could get a language as fast as Java/Go but with the cleanliness of Typescript.

BadInformatics 6y ago
I remember a few years back when Nim was going to be the next big thing here, but unfortunately it never gained that level of traction. Still an interesting language even without bigco levels of support behind it.
deleted 6y ago
[deleted]
valenterry 6y ago
Scala comes very close to that.
- ledauphin 6y ago
  the JVM is an incredibly heavyweight runtime compared to CPython. I don't think we're going to find the next beginner-friendly language coming out of the most professional runtime in human history.
  - pbourke 6y ago
    > incredibly heavyweight runtime The apps may be heavyweight, but the runtime was designed to run on set-top boxes 25 years ago.

fnoof 6y ago

Keep the python brand and fix these things in a new backwards incompatible python release. Call it Python 4. I’m sure it’ll only take a couple of years for everyone to migrate

II2II 6y ago

Two pieces of advice: - Just learn the language with all of its quirks - If you are new, ignore the quirks until you are ready Creating a new language sounds ideal, but there are a whole slew of caveats. Python tends to be recommended as a beginner language since it is reasonably easy to learn and offers considerable room for growth By the time the Next Python reached that stage, we would have accumulated a new two decades of techniques and features that would leave Next Python in a similar position to Python today. That assumes that people would even agree upon which language would serve as Next Python as a standard recommendation. One of the advantages of having so many people agreeing upon Python as a starting point is it eliminates the first hurdle novices most novices face: figuring out where to start. As for the batteries being included, it is also a strength of Python. Choosing libraries can be difficult. That's true for the novice and it's true for anything but trivial projects. Lean standard libraries encourage fragmentation. We should have learned that from the shortcomings of C, yet many languages have followed in the same footsteps with similar results. We should have learned that large standard libraries can be useful, from the success of languages like Java and Python. Package managers don't change the degree of fragmentation, they only make it easier to deal with.

smitty1e 6y ago
> Creating a new language sounds ideal I seriously cannot think of anything I could do to exceed Python. Does it do everything? No. But name a tool with significantly greater overall reach. Some compete, but seriously. . .
- jimbob45 6y ago
  Better main method calling, better chaining, multiple constructors, and better reflection.
- jtdev 6y ago
  Agreed. I’ve always felt that the following sums up why Python is my preferred language: Python is the second-best language for everything.
  - 6y ago

belorn 6y ago

New languages need to have a distinct benefit in order to be enough encouraging for new people to learn it over picking something which is already well established. In python case it was something that replaced shell language for data administrators, and many of the quite complex languages used by data scientists. The one big selling point a future language could have would be inherent parallelization that uses all the 32+ cores of the developers machine, but that are as beginner-friendly as python. Such language does not exist. A dynamic, easy to use, and built from the ground up to always utilize all cores all the time without demanding that the programmer are handling side effects.

fulafel 6y ago
Using a lot of execution resources is not a direct benefit from the user POV. Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases. Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).
valenterry 6y ago
Such a language _can not_ exist, because it stops fulfilling the "beginner-friendly" criteria. As soon as you deal with concurrency, things either get hard to learn or get super messy. Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.
- jerf 6y ago
  Go minus concurrency actually is a good candidate for a solid beginner language. It has quirks, but no more so than any other choice, and fewer than most, for a beginner. However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later. The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.

bobbylarrybobby 6y ago

In terms of style, Swift feels like the next Python. And it’s starting to pick up a sizable standard library.

Redoubts 6y ago
Yeah, every time I’m playing with typing and mypy I start yearning for Swift’s type system instead.

deleted 6y ago

[deleted]

arthurcolle 6y ago

f-strings are amazing Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax. Yes please, and thank you

pansa2 6y ago
`str.format` can’t be removed completely - it’s necessary if you want to build format strings at runtime. But otherwise, yes - make f-strings the “one obvious way to do it” and use `format` only when necessary. And get rid of the old %-formatting. Also consider making f-strings the default: https://pyfound.blogspot.com/2020/04/all-strings-become-f-strings-python.html https://pyfound.blogspot.com/2020/04/all-strings-become-f-st...
woodruffw 6y ago
> Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax. `format` is still useful, particularly when working with pre-templatized strings. It's also a (relatively) new feature; Python 2 didn't have it at all. OTOH, I wouldn't cry if Python 3.X finally removed %-formatting. `format` does everything that `%` does, with a much nicer API (especially in 3.7+).
kortex 6y ago
Jokes on you, my coworker still obsessively uses % args syntax.
- roelschroeven 6y ago
  I can understand that, to a point. Not the so much the obsessive part, but I sometimes fall back to % formatting too since that uses the formatting syntax I'm familiar with from C and C++. The syntax used in f-strings and .format is probably better, but requires re-learning.
- CodeGlitch 6y ago
  Please tell me you correct them in the code reviews? Everytime someone uses %args inappropriately a baby seal dies.
6y ago

didibus 6y ago

Python 3 ? I feel like Python just went through that big shift. Doubt we need a other one of those. Also, I'd just look at Julia for some of what you're describing. It's basically going for a more focused approach with the learnings of Python in place.

MagicWishMonkey 6y ago

What's wrong with having a robust stdlib? Are those extra 50 megabytes really a problem?

yout2 6y ago
The issue is not the size of the stdlib but rather the process for how things get in there. IMHO Python's stdlib has a number of modules of sub-standard quality and design. It would be good to have a gradual process for inclusion in the stdlib, so that different 3rd party libraries could be vetted by the community before we bake one into the language.

jshen 6y ago

Please no, the migration from python 2 to 3 was a disaster and we’re finally on the other side of it.

a3n 6y ago

> I think the time is ideal for the "next Python". We could call it Python 6.

analog31 6y ago

Could something be added to the linter, to flag language features that you don't want to use? This would allow creation of a beginner mode, where all but the most primitive features are left out. It would also be a potentially useful way for us to impose consistency on our codes as they grow in size.

wryun 6y ago

Relatedly, I made a flake8 linter plugin for modern Python if you really feel like being constrained: https://pypi.org/project/flake8-simplicity/ https://pypi.org/project/flake8-simplicity/ https://github.com/wryun/flake8-simplicity/blob/master/flake8_simplicity.py#L7 https://github.com/wryun/flake8-simplicity/blob/master/flake...

nojito 6y ago

F# is that language and is rapidly gaining steam.

pansa2 6y ago

I don't think any single language will be the "next Python" for everybody. Many seem to be happy replacing Python with Go, to get better performance, parallelism and packaging support. However, for my uses I'd much rather replace it with another high-level scripting language, even if it's still slow and single-threaded.

tcbasche 6y ago
This is what I’ve done and it’s way easier from a packaging perspective but the thing that stings is Go misses out on all the data science stuff like pandas, numpy etc

dehrmann 6y ago

So a Kotlin for Python?

Too 6y ago
Yes, but the other way around :) Kotlin solved the syntax and language warts on top of a good runtime. For python the syntax is (mostly) good but the runtime and package management needs a rehaul.
- dehrmann 6y ago
  > mostly Bolted-on classes and types annotations, and missing real lambdas isn't awesome, and lack of proper variable scoping is error-prone. I agree that the runtime is a mess, but more in naming inconsistencies and how its organized than functionality.
- pjmlp 6y ago
  Kotlin solved Google's Android problem, on the JVM it is just another radar noise in the set of guest languages.
  - tpxl 6y ago
    Kotlin was developed by JetBrains, not Google, as a 'better Java'.
    - pjmlp 6y ago
      So what? #KotlinFirst is being pushed by Google. Android is the only place where Kotlin actually matters.

Lammy 6y ago

Ruby 3.0 is a great time to get back into Ruby :)

dzonga 6y ago

Golang looks like that language. it would be my go to, but why they decided to have Nil Pointers, I don't know. Golang without Nil and also mostly pass by value, and only using pass by reference for people doing lower level stuff, would've been good. for now, staying with python. Golang is easy to get started with tooling and packaging is good. but then the code in the wild is littered with pointers for when you wouldn't need them.

reidrac 6y ago

Do you need to use all the features of a language all the time? I don't think you do. A language with a consistent design can have layers, and beginners can just do with the external bits without getting too deep initially, but with enough space to grow. IMHO Python is a good language on that regard.

the__alchemist 6y ago

I'd love a Python 4, or one by any other name, to be like the latest Python, but cleaned up, with no regards for backwards compatibility. For example: a trimmed standard library, and much of the alternate syntaxes removed. Better tooling and official-docs support; ie like Rust: A modern, official package manager, a built-in linter, formatter, binary-creator etc.

japanuspus 6y ago
I have a hunch that in five years, the global-state package manager built into python will be a feature because we will all be working exclusively in dev-containers. What does it matter to you if there are features in the standard library you don't use? The full python embedded distribution is only 8MB including runtime.
- the__alchemist 6y ago
  I hope your hunch is wrong! I feel like containers are a symptom of situations like this Python one.
kzrdude 6y ago
Hehe, Python 4 will probably not happen after 2->3.

japanuspus 6y ago

> ... 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. ... But they tend to get ironed out over time. Python 3.9 adds parametrized generic type hints based directly on container types, alleviating the need for a parallel type-hint type system. i.e. `dict[str, list[int]]` over `typing.Dict[str,...]`

pansa2 6y ago
That’s exactly the feature that’s causing the problem in this article.

Blikkentrekker 6y ago

Python honestly did not learn from many things that were already well known when it was designed. It wasn't arcane at the time that using exceptions for decision logic, or letting loops run by assignment, rather than by creating a new scope, were not the most salient ideas. The following Python code contains a bug: list_of_adders = [] for x in iterator: list_of_adders.append(lambda y: y+x) Namely, since `x` is assigned with each iteration of the loop, rather than that a new scope is created, the `x` that the closure encloses is re-assigned with it, so all anonymous functions contain the value that `x` had in the last loop, which is almost certainly not what the programmer intended. In fact, if within the same scope, which is quite large, since Python does not like block scope, x ever be re-assigned, which is quite likely, as Python uses the same syntax for initialization and assignment, then all the closures collected in the list shall thenceon refer to the new value that x is assigned to. These are not design choices that many other programming languages at the time made; they were bad with the knowledge of the time, and continue to be bad now. There is no justification to have loops be implemented by assignment, and not create a new scope.

pansa2 6y ago
The justification for function-scope instead of block-scope is that only the former really works if you have implicit variable declarations. In turn, implicit variable declarations (using the same syntax for initialisation and assignment) are a reasonable choice for a language that aimed to be “executable pseudocode” and that supports mixing initialisation and assignment in a single statement (e.g. `a, b, self.c = foo()`).
- Blikkentrekker 6y ago
  It could easily be written as `var a, var b, self.c = foo()`. Having the same syntax for initialization and assignment is quite quæstionable.
  - pansa2 6y ago
    That’s not a bad suggestion, but it’s quite verbose (it would require declaring multiple variables as `var x, var y, var z` instead of `var x, y, z`).

gypsyharlot 6y ago

I spent a few decades chasing "the next great language", and I regret it. I wish I had spent those hours learning about statistics or cryptography or algorightms. Things that are timeless. If you want to be a jack of all trades, master of none, by all means, chase the next great thing. I for one, think it's more likely that Python will evolve. The mathematicians and physicists, biologists, astronomers etc. that have finally gotten rid of C++/Fortran and learnt Python aren't going to change to anything with forced static typing any time soon...

nmfisher 6y ago
Not a mathematician/physicist/etc, but having literally dived into Julia today, I think you’d be surprised. It definitely seems like “Python 2.0” for numerical computing.
- gypsyharlot 6y ago
  Julia is probably excellent. How large are the benefits to using Julia compared to Python? Are the benefits great enough to compensate for the time spent: - Training your entire team to use Julia instead of learning about other relevant things - Re-writing your Python-infrastructure (or dealing with Julia to Python-interoperability, which means new employees now have to learn or know both Python and Julia) - Replacing Jupyter and learning new, similar tools - All employees making their favorite IDEs function well with Julia - Figuring out how to make Julia talk to software that already has an existing Python API (Wireshark, AutoCAD, GNU Radio, ... just about everything you can think of)
  - nmfisher 6y ago
    Those are definitely problems for the corporate world (except for Jupyter, a Julia kernel already exists for that). Again, I’m not an academic so take what I say with a grain of salt - but I can see Julia paying dividends very very quickly in that sphere (once you’re over the admittedly steep learning curve).
  - kirill5pol 6y ago

rini17 6y ago

Learn Common Lisp and you'll find "the techniques & features learned in the past 2 decades" notion laughable. Or sad.

higerordermap 6y ago
Why does nobody talk about drawbacks of common lisp?
- rini17 6y ago
  Because in this thread it would be off topic?

coldtea 6y ago

>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. I think that package managers or not, the "batteries included" approach is great, because it leads to most of the code for useful things already available, and also helps third party packages be smaller (since they can depend on things available in the standard lib). Imagine 3 different packages, for example, each bringing its own different json parser depedency -- as opposed to all leveraging the included json package. That's how you get no community standards but tons of packages for the same basic things in slightly different ways, each with 20%-30% adoption. That's also how you get 1GB node_modules folders. That's also how you have the "leftpad" situation.

nimmer 6y ago

Like a statically typed, compiled Python? With a more flexible approach to OO? That can compile to binary, javascript and other languages? That would be https://nim-lang.org/ https://nim-lang.org/

sai_c 6y ago

Rinse and repeat. Three hundred years later, we're at the original python again. Invented on the USS Enterprise. "To boldly create programming languages no man has created before."

yodelshady 6y ago

>A new, general-purpose, beginner-friendly language focused on readability Sounds great. What made Python so beginner-friendly and readable? Most of the "let's improve Python" gang I see can't begin to answer that - by their metrics, the language must be a failure. Beginners have the advantage of not thinking "this is the best way to do it because that's how C/C++/Java do it".

MaxBarraclough 6y ago

I agree Python has some frustrating imperfections, but it has a pretty great ecosystem, and a new language would presumably have to start over. I wish Python went with static typing from the offset, and I wish it had better parallelism, but with Python you can get a library for just about anything with a simple pip install, and that's worth a great deal. Need a WebSocket library? No problem. Need a cross-platform TUI library? No problem. Python's maturity means you can do a lot of things with little hassle. Some of the less mainstream programming languages are nowhere close to Python in this regard, even after many years.

Qem 6y ago

I think Python's batteries included approach still matters a lot, because many users (myself included) have to work from locked up workstations, with awful tech support, no local administrator privileges, and draconian policies forbidding installation of not previously vetted software. For example, not long ago a colleague requested a Orange (data mining software) install. Corporate IT took more than six months to validate it and fullfill the request. To avoid hassle like that, the most you can get from just the initial install, the better.

higerordermap 6y ago

N1H1L 6y ago

Julia in many ways was designed as the next Python. Their user base is growing steadily, and they may displace Python in many applications a decade from now.

knighthack 6y ago

I agree with you that Python now features some redundancy. Yet I do not agree with you that there is 'complexity', going by your examples. Notwithstanding the various ways of doing the same thing (which sometimes goes against the zen of Python), as of Python 3.6 there's been a constant trend towards f-strings above all else (barring maintenance and legacy code), and generally beginners have no need for anything beyond f-strings. If they'd like to go into the old string formatting techniques, they're welcome to, but they're not that complex. I don't understand how type annotations constitute a 'compromised design' - they've worked quite elegantly with Python's dynamic typing, they greatly assist linters and IDEs when you turn them off, and they can be disregarded when you don't need them, which is a far cry from the enforced typing of other languages. And I certainly do not agree that there is a need for a "next Python". Python does a lot of things very well - it's design is clear, the design patterns are methodical, the language is well-governed, the central packaging system is reliable (and not like the insane NPM and dependencies of JavaScript), there is a distinct idiom/style consistency amongst Pythonistas, a and a large gathering of minds behind the language. Further, Python reads very well, and can be even pseudocode without being pseudocode, which makes it very much suited for beginners who can stray as far as they want to into the language when they feel ready for it. Python is a great language for beginners, so I have no idea what you're talking about.