On Tue, 20 Aug 2024 14:21:38 -0000 (UTC), Kalevi Kolttonen wrote:

> Even though his PhD thesis was
> something like 100-150 pages of strange-looking formulas, he said he had
> problems with C on the Amiga. For some reason, he was unable to remember
> what functions where provided as standard libraries, so he always ended
> up writing his own functions instead of using libraries.

Was he not able to keep some reference docs handy? For example, I rarely
get very far in working on Python code without having this page
<https://docs.python.org/3/library/> open in a browser.

On Mon, 19 Aug 2024 09:37:39 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote in <v9uso3$2pdrg$2@dont-email.me>:

> On the other hand you still cannot have decent gaming under Linux.

Modern proton has changed all that.

(That's why you have lovely devices like the SteamDeck on the market.)

This system runs Elite Dangerous Odyssey, Starfield, Borderlands 3,
and Tiny Tina's Wonderland using SteamPlay with proton.

--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.11.0-rc4 Release: Mint 21.3 Mem: 258G
"Oxymoron: Televised Hearings."

On 21 Aug 2024 06:10:03 GMT, vallor wrote:

> On Mon, 19 Aug 2024 09:37:39 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote in <v9uso3$2pdrg$2@dont-email.me>:
>
>> On the other hand you still cannot have decent gaming under Linux.
>
> Modern proton has changed all that.
>
> (That's why you have lovely devices like the SteamDeck on the market.)

The Steam Deck is turning PC gaming upside down. Even Microsoft is
struggling to compete.

On 20/08/2024 22:56, Kalevi Kolttonen wrote:
> In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>> No, you do not need your particular favourite out of the thousand and
>> one Linux programming books in order to program for Linux. You do not
>> need /any/ book in order to write useful and successful code for Linux.
>> Of course you need /some/ reference - and in the days before the
>> internet was so easily available and so full of information, I went
>> through a lot of programming books. Some were good, some less so, and
>> some have become famous. But none of them were /necessary/ in any way.
>
> Well, I am a quite bad programmer but I am interested enough in the
> Linux/UNIX workings so that reading the newest APUE and The Linux
> Programming Interface did not feel painful or unnecessary at all. On
> the contrary, it was a great pleasure to examine what kind of
> programming facilities my favourite OS offers.

I have no doubt that this could be interesting to read about, and the
book could be very well written (I don't know the book myself, so I'll
take your word for it). At least half the computing and programming
books I have read covered things that I have no use for personally, and
don't expect to use.

So I don't question that it is interesting, informative, or a pleasure
to read. I question that it is /necessary/. You simply cannot argue
that people who want to program for Linux /must/ read that book. There
is no justification for that claim. There is no justification for
claiming that people wanting to program for Linux need to read any books
on the topic at all, nor for claims that people need to "know POSIX" to
be able to write code for Linux and/or in C.

>
> Having these two books, or just one of them, is a great way to educate
> oneself about Linux/UNIX. I see that The Linux Programming Interface
> is available online as a free PDF, but I am not sure whether it is
> a pirated version.
>
> There is no better way to learn Linux/UNIX workings than these two
> books. Period.
>

That claim is not /wrong/ - it falls into the category of "not even wrong".

There are a thousand and one ways to learn about the workings of Linux -
and that's counting "reading books" as one way, regardless of /which/
books. You have personally tried one way - from that, you cannot
possibly conclude that it is the "best" way. All you can say is that
you liked those books, and found them informative and pleasant to read,
you learned a lot from them, and you can recommend them to others.
That's great. Leave it there, and stop making completely absurd,
exaggerated and unjustified claims beyond that.

And you don't need to know about the workings of Linux to program for Linux.

And you don't need to know anything about Linux, UNIX or POSIX to
program in C. I've programmed C for some 35 years, and almost none of
it has been for Linux or other *nix. I've used only a small fraction of
the standard library. Even the few programs I have written that run on
Linux had no POSIX-specific code. What you need to know about for any
programming task is the stuff appropriate for the task at hand - /not/
comprehensive knowledge of APIs and interfaces that you will never use,
and certainly not some ancient random book recommended by someone off
the internet.

On Tue, 20 Aug 2024 20:56:00 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>> No, you do not need your particular favourite out of the thousand and
>> one Linux programming books in order to program for Linux. You do not
>> need /any/ book in order to write useful and successful code for Linux.
>> Of course you need /some/ reference - and in the days before the
>> internet was so easily available and so full of information, I went
>> through a lot of programming books. Some were good, some less so, and
>> some have become famous. But none of them were /necessary/ in any way.
>
>Well, I am a quite bad programmer but I am interested enough in the
>Linux/UNIX workings so that reading the newest APUE and The Linux
>Programming Interface did not feel painful or unnecessary at all. On
>the contrary, it was a great pleasure to examine what kind of
>programming facilities my favourite OS offers.
>
>Having these two books, or just one of them, is a great way to educate
>oneself about Linux/UNIX. I see that The Linux Programming Interface
>is available online as a free PDF, but I am not sure whether it is
>a pirated version.
>
>There is no better way to learn Linux/UNIX workings than these two
>books. Period.

The advantage of books written by professionals is that the code and
explanations are usually much clearer and of better equality than the quickly
knocked up might-work-might-not crap you often find on stack overflow and
similar sites. Thats not to say good example code isn't out there but wading
through the rubbish can be a tedious business and IME its often quicker just
to reach for APUE or similar.

On Wed, 21 Aug 2024 09:26:41 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>So I don't question that it is interesting, informative, or a pleasure
>to read. I question that it is /necessary/. You simply cannot argue
>that people who want to program for Linux /must/ read that book. There
>is no justification for that claim. There is no justification for
>claiming that people wanting to program for Linux need to read any books
>on the topic at all, nor for claims that people need to "know POSIX" to
>be able to write code for Linux and/or in C.

Only knowing core C will severely limit what you can do on any OS. If
you're happy just coding up file processors or some self contained
mathematical algo and simply writing to stdout or a file then fine, but to do
anything more sophisticated you'll need to know the OS API whether its posix
+ X on *nix or Win32 on Windows.

>There are a thousand and one ways to learn about the workings of Linux -
>and that's counting "reading books" as one way, regardless of /which/

Linear learning is usually better than snippets from google. If you want
to learn a shakespear play you read the book, you don't google little bits
of it at a time.

On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:

> And you don't need to know anything about Linux, UNIX or POSIX to
> program in C.

I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...

On 2024-08-21 02:59, Lawrence D'Oliveiro wrote:
> On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
>
>> The question is sustainability in long term.
>
> In the long term, proprietary software is in retreat, while Free software
> is on the rise. So it’s quite clear which one is more “sustainable”.

I mean economic sustainability. Normally you cannot sustain a whole
branch of economy keeping it black.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 20 Aug 2024 14:21:38 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> Even though his PhD thesis was
>> something like 100-150 pages of strange-looking formulas, he said he had
>> problems with C on the Amiga. For some reason, he was unable to remember
>> what functions where provided as standard libraries, so he always ended
>> up writing his own functions instead of using libraries.
>
> Was he not able to keep some reference docs handy? For example, I rarely
> get very far in working on Python code without having this page
> <https://docs.python.org/3/library/> open in a browser.

Sorry, I don't know. I only know that he told me he was
unable to remember what the standard libraries on Amiga
offered. So he did much unnecessary duplication of code
writing the functions himself.

I have never owned Commodore Amiga and I have no
knowledge about its C compilers or the related
documentation.

br,
KK

On 21/08/2024 09:36, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 09:26:41 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> So I don't question that it is interesting, informative, or a pleasure
>> to read. I question that it is /necessary/. You simply cannot argue
>> that people who want to program for Linux /must/ read that book. There
>> is no justification for that claim. There is no justification for
>> claiming that people wanting to program for Linux need to read any books
>> on the topic at all, nor for claims that people need to "know POSIX" to
>> be able to write code for Linux and/or in C.
>
> Only knowing core C will severely limit what you can do on any OS. If
> you're happy just coding up file processors or some self contained
> mathematical algo and simply writing to stdout or a file then fine, but to do
> anything more sophisticated you'll need to know the OS API whether its posix
> + X on *nix or Win32 on Windows.

No, you do not.

Why is this so difficult for some people to understand? You need to
know about the parts relevant to the things you are doing. Modern OS's
are /huge/. It is meaningless to talk about "knowing the OS API",
because before you have learned 10% of it, major new versions will be
available and at least part of your knowledge may be outdated. By the
time you have learned /all/ of it, several versions have passed and
you've been fired from your job for pissing around for years learning
things that have no relevance to your task, and you've probably
forgotten at least half of it. And then you can start learning the
third-party libraries and APIs that are not part of the OS but useful
for the task.

If you are writing network software for Linux, how is it relevant to
learn about the sound API, or the more advanced filesystem API's ? If
you are writing a gui program with QT, why should you be interested in X
APIs or POSIX threading and file handling - you'll be using the QT
libraries and APIs for graphics, threading and file handling.

I have not suggested, or even hinted, that all you need is "core C" -
what you need is the knowledge that is relevant to the task at hand,
regardless of the OS, language, or whatever.

>
>> There are a thousand and one ways to learn about the workings of Linux -
>> and that's counting "reading books" as one way, regardless of /which/
>
> Linear learning is usually better than snippets from google. If you want
> to learn a shakespear play you read the book, you don't google little bits
> of it at a time.
>

When did I suggest that snippets from google was "the" way to learn?

I'd agree that reading a book or two is likely to be better than reading
nothing but "snippets from google". You now have another 999 strawmen
to go through.

On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
> On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
>
>> And you don't need to know anything about Linux, UNIX or POSIX to
>> program in C.
>
> I think the point has been made on comp.lang.c more than once, that C
> without POSIX can be a very dull language indeed ...

It was wrong on comp.lang.c, and it is wrong here. Proof by repeated
assertion is not valid.

On 21/08/2024 09:27, Muttley@dastardlyhq.com wrote:
> On Tue, 20 Aug 2024 20:56:00 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>> In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>>> No, you do not need your particular favourite out of the thousand and
>>> one Linux programming books in order to program for Linux. You do not
>>> need /any/ book in order to write useful and successful code for Linux.
>>> Of course you need /some/ reference - and in the days before the
>>> internet was so easily available and so full of information, I went
>>> through a lot of programming books. Some were good, some less so, and
>>> some have become famous. But none of them were /necessary/ in any way.
>>
>> Well, I am a quite bad programmer but I am interested enough in the
>> Linux/UNIX workings so that reading the newest APUE and The Linux
>> Programming Interface did not feel painful or unnecessary at all. On
>> the contrary, it was a great pleasure to examine what kind of
>> programming facilities my favourite OS offers.
>>
>> Having these two books, or just one of them, is a great way to educate
>> oneself about Linux/UNIX. I see that The Linux Programming Interface
>> is available online as a free PDF, but I am not sure whether it is
>> a pirated version.
>>
>> There is no better way to learn Linux/UNIX workings than these two
>> books. Period.
>
> The advantage of books written by professionals is that the code and
> explanations are usually much clearer and of better equality than the quickly
> knocked up might-work-might-not crap you often find on stack overflow and
> similar sites. Thats not to say good example code isn't out there but wading
> through the rubbish can be a tedious business and IME its often quicker just
> to reach for APUE or similar.
>

"Usually" suggests you have statistics to back that up.

The reality is that there are endless numbers of crap books with poor
explanations, buggy examples, and outdated information - as well as
their being books that are high quality, accurate, and keep enough
generality to be relevant for many years. Equally, there are lots of
posts on stack overflow and other such sites with top-quality code just
as there are posts with complete nonsense, or (worse) subtly wrong code
and answers.

The medium, or the price of getting the information, is at most only in
vague correlation with the quality of the information.

On Wed, 21 Aug 2024 11:10:53 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>If you are writing network software for Linux, how is it relevant to
>learn about the sound API, or the more advanced filesystem API's ? If

You don't, but the subsystems don't exist in isolation, there's a lot of
overlap. Eg network sockets use a lot of the same API functions as files
(eg: read, write, fcntl, ioctl) so understanding may well help to understand
the other.

>you are writing a gui program with QT, why should you be interested in X
>APIs or POSIX threading and file handling - you'll be using the QT
>libraries and APIs for graphics, threading and file handling.

Not necessarily.

>I have not suggested, or even hinted, that all you need is "core C" -
>what you need is the knowledge that is relevant to the task at hand,
>regardless of the OS, language, or whatever.

Its certainly the impression you gave.

On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 11:10:53 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> If you are writing network software for Linux, how is it relevant to
>> learn about the sound API, or the more advanced filesystem API's ? If
>
> You don't, but the subsystems don't exist in isolation, there's a lot of
> overlap. Eg network sockets use a lot of the same API functions as files
> (eg: read, write, fcntl, ioctl) so understanding may well help to understand
> the other.

Sure.

Of course understanding /some/ of this is essential for a lot of tasks.
And understanding a bit more can be /useful/. My argument is against
this idea that you need to learn it all.

Let's take an example. In my line of work, I use UARTs a lot - I've
probably used UART's on 20-30 different microcontroller families, as
well as external UART chips, bit-banging in software, with polling, DMA,
interrupts, RTOS abstractions, SDK routines. I've used them a /lot/.

Trying to understand the Linux documentation for UARTs is a nightmare.
They are horrendous - the APIs, structs, flag sets, etc., are a vast
jumble of crap for handling terminals that haven't been seen outside a
museum for 50 years, long before Linux was conceived. Trying to get the
right selection of API calls, struct setups, etc., simple raw UART
access to send and receive characters can take many days of studying
documentation of questionable standard, trial and error, and guesswork.
A good "Programming Linux" book /might/ help - but it might be out of
date. Snippets from googling, however, /does/ get the job done - you
can find examples, try them out and see what works, and in a few hours I
had everything running.

Even better, of course, is to ditch C and use Python - "pyserial" does
it all, simply and cleanly. (And the same code works on Windows, if
that happens to be useful - though Windows picks pseudo-random names for
serial ports and has nothing like udev rules.) But for this particular
customer, it had to be in C (well, C++, but that's a minor detail).

Would that task have been easier if I'd studied the details of fcntl,
ioctl, and other calls that were needed for the task? No, not at all.
Would "knowing POSIX" have helped? Would reading some old book on Linux
programming have helped? No. (I /have/ read books on Linux programming.)

But a rough idea of some of the concepts of Linux development was
useful. Knowing /something/ about the OS is helpful.

>
>> you are writing a gui program with QT, why should you be interested in X
>> APIs or POSIX threading and file handling - you'll be using the QT
>> libraries and APIs for graphics, threading and file handling.
>
> Not necessarily.
>
>> I have not suggested, or even hinted, that all you need is "core C" -
>> what you need is the knowledge that is relevant to the task at hand,
>> regardless of the OS, language, or whatever.
>
> Its certainly the impression you gave.
>

I can't imagine how you got that from my posts.

Yes, books can be wrong, and yes, community fora can have valuable
information - but there really is no substitute for a good manual, in
print or otherwise. StackOverflow is very useful for clearing up some
kinds of esoteric-yet-common questions, but if you just need to double-
check what the legal values for parameter X in function Y are, it's
much quicker (and usually less error-prone) to turn to a reference
guide than it is to go poking around looking for records of times in
history where someone else might've had the same question.

(Doubly so, now that Google is as friggin' useless as it's gotten the
last few years.)

On Wed, 21 Aug 2024 17:27:04 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
>Trying to understand the Linux documentation for UARTs is a nightmare.
>They are horrendous - the APIs, structs, flag sets, etc., are a vast
>jumble of crap for handling terminals that haven't been seen outside a
>museum for 50 years, long before Linux was conceived. Trying to get the

Unfortunately terminals are complex beasts with many permutations though
all that should be a higher level that what you were doing with a UART.

>Even better, of course, is to ditch C and use Python - "pyserial" does
>it all, simply and cleanly. (And the same code works on Windows, if

The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.

On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 17:27:04 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
>> Trying to understand the Linux documentation for UARTs is a nightmare.
>> They are horrendous - the APIs, structs, flag sets, etc., are a vast
>> jumble of crap for handling terminals that haven't been seen outside a
>> museum for 50 years, long before Linux was conceived. Trying to get the
>
> Unfortunately terminals are complex beasts with many permutations though
> all that should be a higher level that what you were doing with a UART.
>

Agreed. It is bad design to mix terminal handling with UART handling.

>> Even better, of course, is to ditch C and use Python - "pyserial" does
>> it all, simply and cleanly. (And the same code works on Windows, if
>
> The problem with pyserial is you have to use Python. Horrible language
> though like BASIC, useful for teaching kids to code.
>

Let's just say, opinions differ. Python /can/ be used for beginner
programmers - but it is also an excellent language for many real tasks.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.

On 21/08/2024 17:37, John Ames wrote:
> Yes, books can be wrong, and yes, community fora can have valuable
> information - but there really is no substitute for a good manual, in
> print or otherwise. StackOverflow is very useful for clearing up some
> kinds of esoteric-yet-common questions, but if you just need to double-
> check what the legal values for parameter X in function Y are, it's
> much quicker (and usually less error-prone) to turn to a reference
> guide than it is to go poking around looking for records of times in
> history where someone else might've had the same question.
>
> (Doubly so, now that Google is as friggin' useless as it's gotten the
> last few years.)
>

I do like a good manual, whether it be a physical book or an online
manual. So I am not objecting to reading them, learning from them, or
using them as references.

I am just objecting to the concept that reading particular books is
somehow "required" in order to write "useful C" or "program for Linux".
They are neither necessary nor sufficient, especially when picking one
or two particular books.

On Wed, 21 Aug 2024 10:07:47 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-21 02:59, Lawrence D'Oliveiro wrote:
>>
>> On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
>>
>>> The question is sustainability in long term.
>>
>> In the long term, proprietary software is in retreat, while Free
>> software is on the rise. So it’s quite clear which one is more
>> “sustainable”.
>
> I mean economic sustainability.

So did I.

On Wed, 21 Aug 2024 08:45:41 -0000 (UTC), Kalevi Kolttonen wrote:

> I have never owned Commodore Amiga and I have no knowledge about its C
> compilers or the related documentation.

The programming documentation was always readily available, as I recall.
Commodore’s number-one priority was to get developers to develop apps for
their platform.

On Wed, 21 Aug 2024 11:11:46 +0200, David Brown wrote:

> On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
>>
>>> And you don't need to know anything about Linux, UNIX or POSIX to
>>> program in C.
>>
>> I think the point has been made on comp.lang.c more than once, that C
>> without POSIX can be a very dull language indeed ...
>
> It was wrong on comp.lang.c, and it is wrong here. Proof by repeated
> assertion is not valid.

It came up repeatedly because of repeated examples where it was true.

On Wed, 21 Aug 2024 21:15:14 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>> The problem with pyserial is you have to use Python. Horrible language
>> though like BASIC, useful for teaching kids to code.
>>
>
>Let's just say, opinions differ. Python /can/ be used for beginner

Yes, its ultimately subjective. The reasons I don't like it are that I can't
stand dynamic typing in supposed "proper" languages and the syntatically
meaningful whitespace nonsense they took from Occam really grinds my gears.
In my current job I'm forced to use it but I'd never do it out of choice.

>programmers - but it is also an excellent language for many real tasks.
>Of course it has its weaknesses and disadvantages as well as its
>strengths, and aspects that will appeal to some programmers and not others.

IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
no.

On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:

> On Wed, 21 Aug 2024 21:15:14 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>>> The problem with pyserial is you have to use Python. Horrible language
>>> though like BASIC, useful for teaching kids to code.
>>>
>>
>> Let's just say, opinions differ. Python /can/ be used for beginner
>
> Yes, its ultimately subjective. The reasons I don't like it are that I can't
> stand dynamic typing in supposed "proper" languages and the syntatically
> meaningful whitespace nonsense they took from Occam really grinds my gears.
> In my current job I'm forced to use it but I'd never do it out of choice.
>
>> programmers - but it is also an excellent language for many real tasks.
>> Of course it has its weaknesses and disadvantages as well as its
>> strengths, and aspects that will appeal to some programmers and not others.
>
> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
> no.
>

I liked python in the beginning, but I find that over the years, it has
become worse. My biggest complaint is dependency management and that you
have to download so many things in order to get a modern project to work.

On the other hand, I'm not a programmer, so I'm probably doing it wrong or
not accordin to best practices by not using containers for all my python
stuff.

On 22/08/2024 09:42, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 21:15:14 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>>> The problem with pyserial is you have to use Python. Horrible language
>>> though like BASIC, useful for teaching kids to code.
>>>
>>
>> Let's just say, opinions differ. Python /can/ be used for beginner
>
> Yes, its ultimately subjective. The reasons I don't like it are that I can't
> stand dynamic typing in supposed "proper" languages and the syntatically
> meaningful whitespace nonsense they took from Occam really grinds my gears.
> In my current job I'm forced to use it but I'd never do it out of choice.
>

Dynamic typing has its advantages and disadvantages. You do lose a lot
of human checking and static checking when you have dynamic typing, but
you gain flexibility. Have you tried using type annotations in Python?
For some code it can give a reasonable compromise, letting you have at
least some control of types while also being flexible where you want.

I am a big fan of clear and consistent layout and indentation, which is
forced on you by Python (and Occam), but I too prefer explicit blocking.
It's harder to get things wrong with explicit blocking, and you are
never faced with space vs. tab conflicts causing semantic changes to the
code.

>> programmers - but it is also an excellent language for many real tasks.
>> Of course it has its weaknesses and disadvantages as well as its
>> strengths, and aspects that will appeal to some programmers and not others.
>
> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
> no.
>

Oh, it's fine for /far/ bigger programs than that. But it is excellent
for small scripts and utilities.

Like any language, you need discipline and to work in a way that suits
the language. If you approach Python coding as though it were C, or
vice versa, you'll make a mess.

On Thu, 22 Aug 2024 09:52:24 +0200
D <nospam@example.net> boringly babbled:
>On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
>>> programmers - but it is also an excellent language for many real tasks.
>>> Of course it has its weaknesses and disadvantages as well as its
>>> strengths, and aspects that will appeal to some programmers and not others.
>>
>> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
>> no.
>>
>
>I liked python in the beginning, but I find that over the years, it has
>become worse. My biggest complaint is dependency management and that you
>have to download so many things in order to get a modern project to work.

Yes, that appears to be a big issue these days. On a project I was working
on recently the version of Pandas (stupid name but thats python libs) had
some minor bug and to update Pandas we had to update just about everything
else as well.

>On the other hand, I'm not a programmer, so I'm probably doing it wrong or
>not accordin to best practices by not using containers for all my python
>stuff.

For a properly designed language a container shouldn't be required. Using
a container to prevent library hell is like seeing a mess on your floor but
instead of clearing the mess you sweep it into seperate piles depending on
the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH to use particular
shared object files but doing something similar with Python AFAIK is a hell of
a task.