Python is the new Basic
log.schemescape.com
log.schemescape.com
I'm glad that caveat is there, because "Python is simple" is one of the biggest misconceptions about the language. It's actually a very complex language hiding behind pleasant syntax.
It's heavily used by non-programmers not because it's simple but because it's easy, which isn't the same thing [0]. More specifically, Python makes easy things very easy, at the expense of making difficult things even more difficult.
I'm not sure emphasis on very is justified. C++ is a very complex language. Python is just... complex, like every real world language is.
What `instance.foobar` actually does: https://blog.ionelmc.ro/2015/02/09/understanding-python-meta...
Unless `instance` is actually a class, in which case it does: https://blog.ionelmc.ro/2015/02/09/understanding-python-meta...
Unless it's looking up a special method (`__add__` etc), in which case it does something different again.
This is much more complex than say, Ruby, which does the same thing in all three cases.
No, there are many examples of extremely simple languages. A modern lisp like Clojure would be near the top of my list. Even Haskell, with all of its warts, is much simpler than python.
Can you elaborate on this?
Also, IMO Python's type system isn't robust enough for complex projects. Simple scripts manage fine with dynamic typing and/or ad-hoc type hints, but as a project grows there becomes a point where even `mypy --strict` is not enough and a proper statically-typed language would be a better choice.
What are some actual simple modern languages then?
An argument could be made for Go, although personally I don't find it simple in the ways that matter most.
I'd put Python in the second tier of complexity - below C++, but on par with languages like Rust and Swift.
I burned myself with Micropython. Sometimes the syntax was wrong but the worst was that reading an input did not gave the desired result. You had to run it twice.
>"Python is the new BASIC because *Python is the language that non-programmers always seem to use*"
>"If even a *Python-hater like me* defaults to using Python, then I think it's pretty clear that Python has taken over the world, just as BASIC once did."
1) As a Python fan, I consider this hate speech.
2) I have yet to encounter a software development kit like Visual Basic that makes it easy to write executable files with a GUI.
Lazarus with FreePascal is pretty close with its drag and drop way of creating GUIs and it generates executables.
If you already know Pascal its probably great, but if you do not its going to take a lot longer to to learn to use it.
I use python, I don’t love it. Don’t really hate it either. You use it because it solves a problem or has a library that makes solving problems easy.
It’s ok for people to have different opinions about what languages they like.
There is a video where someone asked for people to submit python scripts to control his Christmas lights. It was fun but slightly annoying because over half the programs wouldn’t run ( missing libraries/ tab space indenting mis match). He said we would but he tried to install one of the packages on the fly. It installed, he got the same missing package error on rerun. Sort of matched my experience using python trying to get others peoples code to run.
That is the main problem with python. Basic didn't have "indenting issues"
You know, I am not actually much of free speech absolutist, but this is the kind of statement that makes me more sympathetic to them. When they sometimes express the worry that the category of "hate speech" is going to be stretched to cover any sort of dislike or disagreement, I think this is the kind of thing they have in mind.
Format strings being the first supporting reason for not liking a language is so funny to me.
- garbage-collected
- opinionated design meant for easy adoption by inexperienced coders
- static type system that is primitive to the point of being stifling
- dearth of abstract, generic language constructs
- lots of boilerplate, especially around error handling
- heavy reliance on code generation
I started on Atari basic in the 80s and having a REPL, even though I didn't know to call it that, was revelatory. Writing a line of code or a little for loop and drawing lines on the screen was a very tight learning experience.
Python approaches that with its REPL and notebooks but doesn't quite match the pedagogical ergonomics I enjoyed 35 years ago with that basic cartridge.
For beginners, python also has some confusing foot guns too, like understanding which objects pass by value and which by reference. It's all part of learning, but when a beginner is still trying to get a handle on variables and functions, it can confound the fundamentals.
Passing by reference means this is possible:
def change_param(ab):
ab = 768
x = 12
print(x)
change_param(x)
print(x)
Otherwise it is always a value, even if the value happens to be a reference to an heap allocated object.
Python has no mechanism to change the contents of the x variable used as parameter on call site.
def change(l):
l[1] = 'x'
>>> foo = [1,2,3]
>>> foo
[1, 2, 3]
>>> changel(foo)
>>> foo
[1, 'x', 3]`foo` is a reference to a list, and that reference is passed by value.
Passing by reference requires changing the variable itself, used on the call site.
The classic test: in Python you cannot write a generic "swap function" - you could only possibly write a function to swap the internal states of the arguments, presuming them to be compatible.
IIRC in CPython, the value is always a reference to an object. Other implementations might pass immutable objects directly by value, but the semantics is the same as passing a reference to the object by value.
I'm thinking of MicroPython here - it supports several pointer-tagging schemes, in which "references" might be actual pointers or might instead be immutable values stored directly.
For example, using the NaN-boxing scheme, MicroPython references might actually be inline `float`s, small `int`s, or constants like `None`, `True` or `False`.
Isn't that true for almost every "mainstream" language?
I think Nim is close, but every attempt to wrap PyTorch dies a miserable death somewhere along the line.
It has tools for checking static types (and the language community strongly encourages their use). Pattern matching was added in version 3.10.
I had quite a bit of success digging QBasic with our son (10yo back then), using this great tutorial which I translated to our language: http://tedfelix.com/qbasic/
Eventually, though, the son dropped his QBasic explorations (I consider it "my fault", since I got burdened with other stuff and couldn't help him as much as I wanted to). And - he dropped it in order to first take up Scratch and then dig straight into - duh! - Python. There ya go. I do think he will need some time to get closures etc intuitively right; in this regard, QBasic was, IMO, indeed, easier to grasp.
I was happy to find a great children-friendly IDE for Python, though - Mu: https://codewith.mu/
Not as "immersive" as the excellent (!) QBasic IDE and its blue screen, but still great. No bloat. F5 for launching the program, etc - and our son started to notice and carefully analyze the interpreter's error messages from first try all by himself. So, all in all, really happy with Mu.
Python doesn't really target non-programmers (IIRC the Steering Council is composed entirely of professional developers, who steer the language towards fulfilling their own needs).
Therefore I expect Python's reign as a language for non-programmers will be ended by a language that targets that audience specifically.
But what might such a language look like? For example, I imagine it will unashamedly dynamically-typed, or maybe have a simple (Go-like?) static type system - rather than the complexity of Python's Mypy/Pytype/Pyright/Pyre.
Maybe the "non-programmer friendly" language could add some kind of FFI to use libraries from another language, but then someone who wants to use it needs to understand caveats of two languages, not just one.
And mypy/pyright etc is not that bad imo - Python is fully dynamically typed, mypy just tries to help when it "knows" something is wrong, but user may ignore it. But I don't know, I've used python for so long that I may be blind to it's caveats.
non-programmers using the language will almost certainly not use type hints.
I suspect most Python code out there does not.
"A good way to discourage me from testing out your software is to require a gigabyte (or more) download (and no, providing an installer that obscures the massive download is not a solution).
The chief offender of inexplicably enormous downloads is, unfortunately, anything related to compiling software for Windows. Want to use the free edition of Microsoft Visual C? That will be at least 3 GB. How about a more modern language like C#? That's 5 GB. Even non-Visual Studio C/C++ compilers tend to be hundreds of megabytes."
The Microsoft practice of burying relatively small executables and libraries inside mega- and now giga- sized downloads dates back to at least the early 90s.
It's common that I'd prefer Ruby but pick Python because it can be expected to run out of the box pretty much anywhere as long as you're conservative with syntax and dependencies (and have automated compat tests).
Its only real interpreted competitors there are Bash, POSIX shell, and Perl, I think.
Pyrhon 2 or Python 3 ? /s
In particular, if you're based on Debian, the system Python likely lacks several pieces by default that the Python team considers standard: `venv` (https://software.codidact.com/posts/291789) and `tkinter` (https://software.codidact.com/posts/291791) standard libraries, and Pip (not part of the standard library, but has privileged status - https://software.codidact.com/posts/291787). You'll also run into problems (especially with Python 3.11 onward - https://software.codidact.com/posts/291839) trying to install third-party libraries without making a separate environment first (which you should do anyway).
But if you insist or the use-case demands, at least python3-venv is an apt/yum/apk/pacman away so you shouldnt need to --break-system-packages or manually install in any case?
Yes, that's the idea. And it's fine for power users, not so much for developers.
And yes, of course developers have easy access to doing things the right way for developers. But a lot of people who are just starting out as developers seem to really resent the fact that they might have to actually learn something at this step. It gets even worse once they're asked to make a choice of tooling, and to have the knowledge necessary to make an informed choice based on their needs and preferences.
I don't have a lot of sympathy for that attitude, as I covered on my blog (https://zahlman.github.io/posts/2024/12/24/python-packaging-...).
What's behind this distinction? I would say the opposite, if anything...
"Power user" to me indicates you are only messing around with your own machines. Pull down the world if you want!
"Developer" to me implies writing software intended for others. Stakes and expectations are higher. You need to vet the code you pull in, consider supply-chain security, resource-usage, etc...
For beginners, sure, I get you, but it sounds strange to dismiss the idea you would otgerwise agree with just because you don't think it's attractive to many casual coders, beginners, or non-programmers? Sounds like a weird sort of defeatism if you let it impact your own code.
As a "power user", I don't write code at all, beyond simple automation scripts for personal use. If I'm automating things for personal use on my own computer, then I may want to use libraries that the system provided for me because they're useful in that environment.
In my case, on a Linux Mint machine, the system Python provides GNOME-specific libraries (gi.repository) that I can use to interact with other installed GUI programs. I could theoretically get those packages from PyPI (https://pypi.org/project/PyGObject/), but they don't even bother mentioning that in their own documentation (https://pygobject.gnome.org/getting_started.html) unless I look at the instructions for doing development on the project. If I did try that, I'd have to build from source which requires setting up a heavyweight build system and then making sure that Pip uses that environment to build the sdist. They won't give me a pre-built install-anywhere version, but they'll happily just install it ahead of time in my system.
I trust the distro to maintain specific packages that work on my system; if I install something optional, they haven't just checked dependencies (and basically pre-solved for versions that will work no matter what subset of optional packages I want), but applied their own patches. On the other hand, they've deliberately omitted things that they feel are a risk for compromising their own package management system. (They've also omitted Tkinter, but I think that's because they want to steer you towards making your GUI in GTK instead.)
As a "developer", I write software that isn't intended for just my own environment and my own distro. No, this doesn't involve any of that security stuff. If it did, there would be orders of magnitude fewer packages on PyPI, and the Node ecosystem wouldn't exist. "Software intended for others" is frequently bloated, inefficient and everything else. The "developers" you describe don't exist in my world.
> but it sounds strange to dismiss the idea you would otgerwise agree with just because you don't think it's attractive to many casual coders, beginners, or non-programmers? Sounds like a weird sort of defeatism if you let it impact your own code.
The point is not just that the system environment is missing pieces by default, but that you are supposed to use the system package manager to update it, which does not make everything available. `apt search tensorflow` only shows me a virtual package that seems to be for typing information. `apt-cache pkgnames | wc -l` reports to me about 1/8 as many packages as PyPI has, and that's counting packages for every programming language.
Unsurprisingly, Python is the language I have the most experience with by far, followed by Bash and PowerShell if you count those. All because they're actually accessible from the getgo on the system.
"Future-proof programming languages, part 3
March 3, 2023
SDK size (measured on x86_64 Alpine Linux), as a proxy for simplicity
Just looking at SDK size, Rust is an outlier. Even compared to a similarly complex language like C++, the Rust SDK is absolutely huge.
Even after allowing for a build tool, custom linker, and standard library, the Rust SDK is disappointingly heavy.
The other languages show some interesting results: JavaScript and C# appear to be the most bloated, closely followed by SBCL (a Common Lisp implementation).
If I'm just looking for a simple and fast language, that would leave C, Go, and Zig.
C is almost certainly future-proof for another decade or two and the SDK is reasonably sized.
I don't like Python."
Anyway
# JIT-based build
dotnet publish -o {folder} -r linux-musl-arm64 -p:PublishSingleFile=true -p:PublishTrimmed=true
# Native binary build
dotnet publish -o {folder} -r linux-musl-arm64 -p:PublishAot=true
I guess it's too challenging to browse the docs...
- the easy on-ramp (often reads like English, indentation is something beginners can innately pick up)
- batteries included: with the rise in the internet+ the shift to packages, it's really about having enough places you can find workable solutions, and Python's dominance helps here
- integration with other languages has been a key part of Python since the beginning, so you are rarely held back
It does largely fulfill that but there's more! Python is used for a lot of serious stuff in a way that BASIC never really was. ChatGPT is written in Python, the most popular language used by scientists is Python, the CERN accelerator is controlled by Python and so on.
It often seems to function as a bit of a user interface to control more serious code written in C, C++, CUDA or whatever.
But to be fair basically everything can be installed easily and is everywhere these days. Python isn’t everywhere and has to be installed on a Mac or a pc and doesn’t come with it. You could say the same of node or go or anything else that can be installed with a few clicks.
1) Turn computer on
2) Wait 2 seconds
3) Start programming
Python is not BASIC.
2) open your preferred CLI/shell, type "python"
3) start programming
Python can be convenient, but often isn't. Just setting the path on my last install was annoying because Python got automatically installed by windows in a hard-to-find folder.
BASIC "just worked".
The bar for "basic" programming these days is much higher in many cases.
The question is whether someone learning fundamental programming needs to use a language with SQL support. I think that BBC basic or quick basic are better choices for learning, but that's me. Also, BASIC has gorilla.bas :)
They aren't going to run into any of the issues you describe, either, because they won't need third-party libraries and should be learning fundamentals of programming before trying to make a GUI. But in the cases where someone reaches that point and is trying to use, say, the system Python on a Debian-based Linux distro, the solution is generally an Apt invocation away.
This is not a reasonable comparison, because in the ROM BASIC days there was nothing available to import in the first place. (Nor were you going to be making a GUI, and this was around 15 years before the first public release of OpenSSL. Nor was your language implementation versioned, therefore it never got any new functionality.)
The rest is FUD.
You don't "install imports" in the first place; you install packages - and they absolutely do tell you what their dependencies are. Encountering issues caused by the python version is relatively rare, especially because relatively few people are proactively upgrading Python to the latest version anyway. There is no such thing as "the package manager"; you have options. The default package installer automatically resolves dependencies, and so do its alternatives. Python installations don't generally upgrade or downgrade; you're meant to install multiple versions, and managing multiple versions is easy. You just have to understand environments, which you have to do in order to do any serious development in any programming language ecosystem where you're dependent on versioned third-party packages. Importing a library would never be the cue that you "need to install a C compiler"; you would find that out from a failed attempt by the package installer to automatically build the package for you. When you find yourself in that position, the default workflow is to go politely bug the package maintainers to prebuild it, or at least try to find out why your system is so special that they can't prebuild it. If you're having OpenSSL compatibility issues, you're probably either trying to run a version of Python that's no longer supported, or trying to run current Python on a system that's no longer supported. If you're having issues with TKinter, please read https://stackoverflow.com/questions/76105218 (I am the author). It's completely reasonable that you need both the C and Python parts of TKinter to make it work, because the entire point of the Python part is to interface to the C for you so that you don't need to understand the C FFI. But also, having this code automatically is the norm.
As for basic in ROM, I am not advocating BASIC, but many versions of BASIC (not in rom) have had built in support for GUIs for decades.
There are several package managers available, because people have wildly varying views of what "package management" includes for Python development, and wildly varying needs for those tools. But all of these involve managing the same set of packages, which overwhelmingly are available on PyPI.
It's also perfectly possible to participate in the ecosystem without anything that could reasonably be called a package manager.