Python is the new Basic(log.schemescape.com)
log.schemescape.com
Python is the new Basic
https://log.schemescape.com/posts/programming-languages/python-as-a-modern-basic.html
86 comments
>It's actually a very complex language hiding behind pleasant syntax.
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.
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.
This sort of thing makes me think Python is very complex:
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.
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.
> Python is just... complex, like every real world language is.
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.
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.
Scheme is famous for being "simple" where "simple" means that it takes a programmer only a few hours to learn it well enough that he can tell what a code snippet will do without running it.
> at the expense of making difficult things even more difficult.
Can you elaborate on this?
Can you elaborate on this?
Compared to other languages, Python's biggest shortcomings are in the areas of packaging, performance, and parallelism. Large, complex projects are likely to run into issues with those things that could have been avoided by using a different language.
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.
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.
Yup.
I've said multiple times that Python's superpower is in progressive disclosure of complexity.
If it has better dependency story you could go a long while without being overburdened by complexity because you always learn a little more here and a little more there.
> It's heavily used by non-programmers not because it's simple but because it's easy, which isn't the same thing
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.
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.
>It's actually a very complex language hiding behind pleasant syntax
What are some actual simple modern languages then?
What are some actual simple modern languages then?
Lua. Go (especially pre-generics). Even JavaScript is simple, compared to Python.
I'd put Python in the second tier of complexity - below C++, but on par with languages like Rust and Swift.
I'd put Python in the second tier of complexity - below C++, but on par with languages like Rust and Swift.
Clojure, Scheme, CL, Haskell, Lean, Janet...
An argument could be made for Go, although personally I don't find it simple in the ways that matter most.
An argument could be made for Go, although personally I don't find it simple in the ways that matter most.
>"Today, there's a different language with ugly historical baggage that enjoys a strong following, *notably amongst people that don't identify as programmers*. *That language is Python*."
>"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.
>"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.
> 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.
Lazarus with FreePascal is pretty close with its drag and drop way of creating GUIs and it generates executables.
its a lot harder to learn. I just commented on another discussion agreeing with someone who made the same point.
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.
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.
also Gambas3 (https://gambas.sourceforge.net), among others.
does not support the OS with the most users.
> As a Python fan, I consider this hate speech.
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.
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.
I'm pretty sure there was a /s missing.
I agree, this is a trash post full of hot stinky air :
- name-calling without any actual examples
- no actual comparison with Basic, the extremely simplistic "popular" sticker covers massive differences in use, users, functional coverage of libraries, and so on
- non-programmers that program use python? this is leveraging python's value as a teaching language in the most derogatory way possible
- "ugly historical baggage" ? sure, show me a better designed language, show me the baggage
“Hate speech” is usually reserved for speech involving people… can’t tell if it’s sarcasm.
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.
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.
> over half the programs wouldn’t run ( missing libraries/ tab space indenting mis match).
That is the main problem with python. Basic didn't have "indenting issues"
That is the main problem with python. Basic didn't have "indenting issues"
> I don't actually like Python. [...] I find the syntax ugly (format strings
Format strings being the first supporting reason for not liking a language is so funny to me.
Format strings being the first supporting reason for not liking a language is so funny to me.
Agreed that this is one of the worse reasons to dislike it. Format strings are pretty decent, especially for casual printf debugging, even if they are crippled compared to what could have been (PEP 501) and is hardly ideal for generating arbitrary-grammar languages.
i beg to differ. IMO Python is slowly becoming - or already became - the new Java - and is being used as such. i am programming with it for 25y, and it still allows things to be as simple as they were long time ago (attribute access is single well-defined thing, which means: simple), but overall mass use is not simple anymore..
Actually, Go is the new Java:
- 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
- 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
One thing I was waiting for the article to mention is that basic has a REPL.
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.
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.
Everything is by value.
Passing by reference means this is possible:
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.
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.
> even if the value happens to be a reference to an heap allocated object
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.
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.
You are correct. (I'd be surprised if other implementations passed immutable objects by value, partly because representing an "object" coherently requires several words of memory and partly because of the importance of certain object identity semantics.) Python uses pass-by-value (if you prefer, pass-by-assignment) of variables which have reference semantics. Just like non-primitive types in Java, or class types in C#.
> I'd be surprised if other implementations passed immutable objects 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`.
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`.
You can do that if the parameter is a list:
def change(l):
def change(l):
l[1] = 'x'
>>> foo = [1,2,3]
>>> foo
[1, 2, 3]
>>> changel(foo)
>>> foo
[1, 'x', 3]This does a fundamentally different thing with similar syntax. Assignment in Python is fundamentally a rebinding operation; slice assignment rebinds a reference internal to the object, whereas ordinary assignment rebinds the name.
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.
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.
You can't change which list `foo` refers to, though. Only the contents of that list.
`foo` is a reference to a list, and that reference is passed by value.
`foo` is a reference to a list, and that reference is passed by value.
Now make foo point to another list, not change contents of the list foo points to.
Passing by reference requires changing the variable itself, used on the call site.
Passing by reference requires changing the variable itself, used on the call site.
> like understanding which objects pass by value and which by reference
Isn't that true for almost every "mainstream" language?
Isn't that true for almost every "mainstream" language?
I'm on a quest to find a statically typed Python with pattern matching, overloading, and friends BUT will allow me to use either PyTorch or Tensorflow (or JAX).
I think Nim is close, but every attempt to wrap PyTorch dies a miserable death somewhere along the line.
I think Nim is close, but every attempt to wrap PyTorch dies a miserable death somewhere along the line.
Sounds like you're looking for... Python?
It has tools for checking static types (and the language community strongly encourages their use). Pattern matching was added in version 3.10.
It has tools for checking static types (and the language community strongly encourages their use). Pattern matching was added in version 3.10.
Have a look at Swift, it's practically that. There even used to be official TensorFlow bindings (they wanted to make it their default language) although that got cancelled.
Sounds like Mojo
QBasic is actually still a great first language for children, particularly non-native English speakers. In this case, the syntax is really easy to grasp, simple UPPERCASE commands with lowercase arguments. No need to wrestle with getting closures right, etc.
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.
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.
> One parting thought: how long will Python's reign last?
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.
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.
Counterpoint: Python is tempting to non-programmers, because it is heavily used in industry and there are libraries for everything. A language designed for non-programmers won't have thousands of useful libraries and blog posts about every topic possible.
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.
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.
A non-programmer programming language would be one that helps solve particular needs. I have an inkling that this is VBA...
> 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.
non-programmers using the language will almost certainly not use type hints.
I suspect most Python code out there does not.
non-programmers using the language will almost certainly not use type hints.
I suspect most Python code out there does not.
https://log.schemescape.com/posts/programming-languages/comp...
"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.
"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.
.NET SDK: 235 MB for Windows x64 + whatever space VS Code and base C# or F# (Ionide) extensions take. Visual Studio is optional.
Another way in which Python is the new BASIC is that it's preinstalled on the vast majority of Linux systems that have a terminal. Once it passed that threshold its popularity for utilities and scripts is a self-fulfilling prophecy.
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.
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.
Unfortunately, while this is a fine way to start experimenting with Python, the Linux system installation of Python is really not suitable for development in general, aside from developing software meant for your local use as part of the system.
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).
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).
The point is to be conservative enough that you stick to packages in distro repos, so that you don't need to pull in externally managed code.
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?
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?
>The point is to be conservative enough that you stick to packages in distro repos, so that you don't need to pull in externally managed code.
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-...).
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-...).
> And it's fine for power users, not so much for developers.
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.
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.
>What's behind this distinction?
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.
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.
People really underestimate just how important this property can be for a scripting language. It's happened multiple times in my career that, due to regulatory burdens, we aren't allowed to install anything new on a given machine without going through due process - in those situations, you gotta be able to work with what you got.
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.
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.
> Another way in which Python is the new BASIC is that it's preinstalled on the vast majority of Linux systems that have a terminal
Pyrhon 2 or Python 3 ? /s
Pyrhon 2 or Python 3 ? /s
https://log.schemescape.com/posts/programming-languages/futu...
"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."
"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."
Would have been great if the author reached out to community about .NET first instead of posting content that they did.
Anyway
I guess it's too challenging to browse the docs...
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...
In the last week I have been working with python, JavaScript and C++. Not sure any of them would win a beauty contest.
Agreed. Whilst we should aspire to language beauty, it's usually trumped by practicality. Python is massively practical:
- 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
- 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
I guess it depends on the field you're working in. When manipulating strings, await db calls, sort arrays, JavaScript (TypeScript actually) feels very intuitive and concise. But going more low level I can see it breaking apart.
JavaScript is a better Python than Python. But then, Lua is a better JavaScript than JavaScript.
Is the brick more important than the building? each level of abstraction has its use case and its advantages (and disadvantages). Better not to criticize the level of abstraction but to try to improve it. Even from the bottom with better bricks if possible.
>BASIC was designed to be usable by anyone--not just experienced programmers. Python is the new BASIC
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.
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.
I think it’s parallel's to basic is that it’s not commonly used for a gui interface the way basic always never made that jump in a universal way unless you bought the Microsoft product.
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.
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.
BASIC experience:
1) Turn computer on
2) Wait 2 seconds
3) Start programming
Python is not BASIC.
1) Turn computer on
2) Wait 2 seconds
3) Start programming
Python is not BASIC.
1) Turn on computer
2) open your preferred CLI/shell, type "python"
3) start programming
2) open your preferred CLI/shell, type "python"
3) start programming
Write your python, run script, find missing import.
Install missing import, find that you actually need a different version of python as the import does not understand the latest version yet.
Find that the import depends on various other imports, which python and the package manager, does not tell you it needs.
Downgrade your local python. (and lets not discuss managing multiple versions.)
Import library again and find you need to install a C compiler.
Install a c compiler.
Later find that the library is not compatible with your systems version of openssl.
And it turns out you now need a version of python that has some extra static code linked into it, because you need to display a simple GUI.
But you still need the GUI library as well.
I don't like to respond to people who directly reply to my comments to avoid flame wars. But, about your comment: THIS.
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".
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".
Yeah, but did BASIC have an SSL library?
The bar for "basic" programming these days is much higher in many cases.
The bar for "basic" programming these days is much higher in many cases.
There is no question Python is a lot more useful and relevant to modern software development. Arguably a better language for many use 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 :)
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 :)
>The question is whether someone learning fundamental programming needs to use a language with SQL support.
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.
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.
>Write your python, run script, find missing import.
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.
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.
Well I was describing what I actually experienced last week.
I did get my script to work after hours of faffing around, your article may have been one of the articles I read, in any event thanks for writing it.
There is no way I would describe the package installation process I experienced as automatic, since pip had no idea what requirement was missing.
Python was in an environment, a package used by an import statement required it to be downgraded so I had to downgrade it, by finding installing and setting up an older version. I then ran into other problems I described.
Once python is set up and working it seems fine.
Everything new I do in python seems way harder than it should be.
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.
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.
What packages were you trying to install, on what platform?
I needed transformers to talk to a local copy of Qwen, and a GUI, using tkinter on macos intel ventura.
It all worked eventually.
I have not got the AMD GPU to work yet.
I don't hold python in anyway responsible for the GPU problem. There was some issue with urllib, and it still complains that my numpy is the wrong version.
Its all ok.
Step 2 unnecessary.
https://xon.sh/
https://xon.sh/
in that view, micropython on an esp32 could fit
I don't recall BASIC having a dozen different package management ecosystems...
Python has two public ecosystems that count: PyPI and conda-forge (for those using Conda).
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.
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.
[deleted]
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.
[0] https://www.youtube.com/watch?v=SxdOUGdseq4