On 3/29/22 5:31 AM, Dan Espen wrote:
> The stuff I've read so far shows python "import"ing a bunch of
> libraries specific to the raspberry, like usb access and access to
> the sensors that surround the circuit board. You don't just need
> the language to work, you need access to device features.

There are many different libraries (in support of different things) for
a number of languages.

I've seen indications of such libraries for a number of languages; C,
Ruby, and I believe Perl. -- There are probably many more that I'm not
aware of.

> Python seems to be the preferred language.

Yes, Python is very much in vogue currently.

--
Grant. . . .
unix || die

On Mon, 28 Mar 2022 23:18:28 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> I'm just reading about these credit card size computers like the
> rasberry pi. These tiny little things run linux and
> are programmed in python.
>
> I think the odds of finding bash might be slightly higher than finding
> python but not significantly different.

I'm running Mageia 8 linux on an rpi 4b. Other then python being used by some
of the programs included in the distro, the installation on an aarch64 cpu
based system doesn't use python any more than a x86_64 installation does.

The kernel and bulk of the programs are written in c and c++, with some
components in other languages like rust, and most scripts using bash.

Most of the Mageia specific applications are written in perl.

While I personally prefer python over perl, every programming language used
has it's appropriate place in a system.

Regards, Dave Hodgins

On 29/03/2022 17:11, Grant Taylor wrote:
> On 3/29/22 5:31 AM, Dan Espen wrote:
>> The stuff I've read so far shows python "import"ing a bunch of
>> libraries specific to the raspberry, like usb access and access to the
>> sensors that surround the circuit board.  You don't just need the
>> language to work, you need access to device features.
>
> There are many different libraries (in support of different things) for
> a number of languages.
>
> I've seen indications of such libraries for a number of languages; C,
> Ruby, and I believe Perl.  --  There are probably many more that I'm not
> aware of.
>
>> Python seems to be the preferred language.
>
> Yes, Python is very much in vogue currently.
>
>
>
Its very much the BASIC replacement - easy to hack and supports a more
structured approach.

Without the massive learning curve of C++

--
“it should be clear by now to everyone that activist environmentalism
(or environmental activism) is becoming a general ideology about humans,
about their freedom, about the relationship between the individual and
the state, and about the manipulation of people under the guise of a
'noble' idea. It is not an honest pursuit of 'sustainable development,'
a matter of elementary environmental protection, or a search for
rational mechanisms designed to achieve a healthy environment. Yet
things do occur that make you shake your head and remind yourself that
you live neither in Joseph Stalin’s Communist era, nor in the Orwellian
utopia of 1984.”

Vaclav Klaus

On 3/29/22 12:20 PM, The Natural Philosopher wrote:
> Its very much the BASIC replacement - easy to hack and supports a more
> structured approach.

LOL

I actually /like/ that comparison. A lot more than I probably should.

> Without the massive learning curve of C++

;-)

--
Grant. . . .
unix || die

On 3/29/22 7:03 AM, Richard Kettlewell wrote:
> The half-arsed approach to error handling goes back to the start.

Please elaborate on what you mean by "half-arsed approach to error
handling".

Please elaborate on what you would consider to be "full-arsed approach
to error handling" or better "full approach to error handling".

I'm asking from a theoretical perspective, not any specific language
implementation.

As in if you want to do $TASK, and what that task is doesn't really
matter. It can be run a command, add two numbers, print something to
the screen, etc.

Take it that you get some sort of feedback as to success or failure.
Knock yourself out as to what that feedback is.

> Acceptable for interactive use but it’s never been particularly
> practical to write anything reliable in it.

Please expound on your statement, particularly in light of how you
answer things above.

--
Grant. . . .
unix || die

Grant Taylor schrieb am 28.03.22:

> On 3/28/22 2:21 PM, Gerald Gruner wrote:
>> With one difference: The syntax of bash shell scripts is more of a
>> practical joke that for some strange reasons made it to reality.
>
> Have you seen m4?

???
Whatever that might mean...

MfG
Gerald

--
I am for truth, no matter who tells it. - Malcolm X

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 3/29/22 7:03 AM, Richard Kettlewell wrote:
>> The half-arsed approach to error handling goes back to the start.
>
> Please elaborate on what you mean by "half-arsed approach to error
> handling".

It’s well-covered in the various links posted so far in this thread and
I’m not going to repeat it.

--
https://www.greenend.org.uk/rjk/

On 3/29/22 3:21 PM, Gerald Gruner wrote:
> ???
> Whatever that might mean...

Link - m4 (computer language) - Wikipedia
- https://en.wikipedia.org/wiki/M4_(computer_language)

--
Grant. . . .
unix || die

On 2022-03-29, Dan Espen <dan1espen@gmail.com> wrote:
> I'm just reading about these credit card size computers like the
> rasberry pi. These tiny little things run linux and
> are programmed in python.
>
> I think the odds of finding bash might be slightly higher than finding
> python but not significantly different.

I've been doing shell scripts for over 40 years and don't have the time
or inclination to learn python. Even perl is too recent for me to bother
with.

--
------------------------------------------------------------------------------
18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
There is no "climate crisis" -- https://climatedepot.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

On 29/03/2022 15:59, Jim Jackson wrote:

>
> Not checking the returned status from a function/command call is VERY
> VERY common no matter what language! People who don't check the returned
> status are just bad programmers.
>
> It appears the guy who wrote the article was just saying bad programmers
> shouldn't write programs!
>

Not really.

Proper languages have had good exception handling, for the last 30 years.

I normally can't see the point of checking every return code for
exceptional failure, easier to catch, log and fall over, carry on
regardless, or restart (as the mood takes me).

On Mon, 28 Mar 2022 21:40:25 -0000 (UTC), Eli the Bearded wrote:

> In comp.os.linux.misc, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 3/28/22 2:47 PM, Jens Stuckelberger wrote:
>>> But, if you use python instead, everything> will be peachy
>> I question the veracity of that statement.
>
> I read Jens' statement as sarcasm.

That's the correct way to read it.

On 3/30/22 3:59 AM, Pancho wrote:
> I normally can't see the point of checking every return code for
> exceptional failure, easier to catch, log and fall over, carry on
> regardless, or restart (as the mood takes me).

Are you implying that you want the language / environment / framework to
detect that a command failed and to abort the entire process on your
behalf so that you don't have to explicitly check for command failure
yourself?

--
Grant. . . .
unix || die

On Wed, 30 Mar 2022 16:06:14 -0400, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> On 3/30/22 3:59 AM, Pancho wrote:
>> I normally can't see the point of checking every return code for
>> exceptional failure, easier to catch, log and fall over, carry on
>> regardless, or restart (as the mood takes me).
>
> Are you implying that you want the language / environment / framework to
> detect that a command failed and to abort the entire process on your
> behalf so that you don't have to explicitly check for command failure
> yourself?

It's a common method in many systems, such as signal trapping in bash. The
advantage of global exception handling is that it doesn't require writing extra
code for every situation that may cause the exception, and once set, ensures
it isn't missed later.

It's useless in many scenarios where a one size fits all approach to error handling
is not appropriate. For example, a file not being able to be opened may be considered
an error, or it may just mean defaults should be used, depending on which file is
involved.

Again, any statement that says "this method of doing something is always best", is
almost alway wrong. It may be true in some cases but there are almost always
exceptions that may need to be handled.

Regards, Dave Hodgins

Grant Taylor schrieb am 30.03.22:

> On 3/29/22 3:21 PM, Gerald Gruner wrote:
>> ???
>> Whatever that might mean...
>
> Link - m4 (computer language) - Wikipedia
> - https://en.wikipedia.org/wiki/M4_(computer_language)

OK,
then the answer is no, I have never seen it before...

MfG
Gerald

--
Ein Plan ersetzt Zufall durch Irrtum.

On 30/03/2022 21:19, David W. Hodgins wrote:
> On Wed, 30 Mar 2022 16:06:14 -0400, Grant Taylor
> <gtaylor@tnetconsulting.net> wrote:
>
>> On 3/30/22 3:59 AM, Pancho wrote:
>>> I normally can't see the point of checking every return code for
>>> exceptional failure, easier to catch, log and fall over, carry on
>>> regardless, or restart (as the mood takes me).
>>
>> Are you implying that you want the language / environment / framework to
>> detect that a command failed and to abort the entire process on your
>> behalf so that you don't have to explicitly check for command failure
>> yourself?

Pretty much, yes. Not abort the process necessarily, but revert to a
recoverable state. As I said, this is how "proper" programming languages
work, and have worked for decades.

>
> It's a common method in many systems, such as signal trapping in bash. The
> advantage of global exception handling is that it doesn't require
> writing extra
> code for every situation that may cause the exception, and once set,
> ensures
> it isn't missed later.
>

I just meant a normal try catch block provided by C#, Java, Python, C++,
JavaScript, Go, etc..., not a global exception handler. Even VBA has ON
ERROR GOTO.

> It's useless in many scenarios where a one size fits all approach to
> error handling
> is not appropriate. For example, a file not being able to be opened may
> be considered
> an error, or it may just mean defaults should be used, depending on
> which file is
> involved.
>
> Again, any statement that says "this method of doing something is always
> best", is
> almost alway wrong. It may be true in some cases but there are almost
> always
> exceptions that may need to be handled.
>

The point with good exception handling is that you don't have to check
errors thrown by *every* function call. However, it does not mean you
shouldn't check the return status of *any* function call.

A 1001 "if" statements saying: if this call fails, the program is
irredeemably lost just obscures readability. So check the function
errors that mean something, are recoverable, and just log the others and
revert to a sensible recoverable state. A good logger will give you a
stack trace of where the error occurred.

When your browser tells you "something went wrong" this is what it is doing.

On 3/30/22 4:11 PM, Pancho wrote:
> I just meant a normal try catch block provided by C#, Java, Python, C++,
> JavaScript, Go, etc..., not a global exception handler. Even VBA has ON
> ERROR GOTO.

I was going to ask how a try/catch is conceptually different than if/then.

> The point with good exception handling is that you don't have to check
> errors thrown by *every* function call. However, it does not mean you
> shouldn't check the return status of *any* function call.

But then you said this, which makes me think that you're suggesting that
the problem might be how many try/catch or if/then statements are needed
to be sufficient without also being overly verbose.

--
Grant. . . .
unix || die

On 2022-03-30, Pancho <Pancho.Dontmaileme@outlook.com> wrote:
> On 29/03/2022 15:59, Jim Jackson wrote:
>
>>
>> Not checking the returned status from a function/command call is VERY
>> VERY common no matter what language! People who don't check the returned
>> status are just bad programmers.
>>
>> It appears the guy who wrote the article was just saying bad programmers
>> shouldn't write programs!
>>
>
> Not really.
>
> Proper languages have had good exception handling, for the last 30 years.
>
> I normally can't see the point of checking every return code for
> exceptional failure, easier to catch, log and fall over, carry on
> regardless, or restart (as the mood takes me).

Irest my case mi'lud

On 3/29/22 7:36 PM, Roger Blake wrote:
> On 2022-03-29, Dan Espen <dan1espen@gmail.com> wrote:
>> I'm just reading about these credit card size computers like the
>> rasberry pi. These tiny little things run linux and
>> are programmed in python.
>>
>> I think the odds of finding bash might be slightly higher than finding
>> python but not significantly different.
>
> I've been doing shell scripts for over 40 years and don't have the time
> or inclination to learn python. Even perl is too recent for me to bother
> with.

Ah, a 'paradigm war' .......

Nothing wrong with Python(3) - it can (almost) do it all.
For what it can't do, use 'C'. You can easily call 'C'
programs from within Python and easily get the results.
Of course there's also 'csh' ....

That said, there's also nothing wrong with shell scripts.
They too can (almost) do it all and are well-developed,
well-documented. Python IS far easier to FOLLOW though.

I've recently re-written a bunch of automated backup
scripts, intended to thwart ransomware attacks. One
big one is in Python3, but the most important aspects
of that were also duplicated in some straight-up Bash
scripts on another box (with a couple of mini-services
in 'C' helping out for convenience). Bash and ksh
offer a "tcp device" which makes it kinda easy to
send commands to services and get data back. I've
taken advantage of that.

In the bigger picture I WOULD recommend Python3, it's
super-capable and much better at self-documentation.

Be it Bash or csh or whatever "traditional" shell
there ARE ways to do it- but it can involve REALLY
weird syntatic tricks which are in no way "self
documenting". It's a case or "we dreamed-up a way
to do it".

Python or the others, they are ALL interpreted script
languages - so six of one, half a dozen of the other
performance-wise.

There ARE Python compilers, Cython3/Nutika, which DO
speed up Python nicely though they are NOT as portable
between systems even if you tell them to include all
the libraries inside the exec. However it's not a huge
deal to adjust the compilation to suit the latest
Python releases. Bash/etc work all the time everywhere
so such scripts are more "future-proof".

Finally, on the "future-proofing" angle, those "old"
languages DO have a certain advantage BECAUSE they
are now fairly "fixed" - rather like why Latin is
still used in scientific circles. Python2 is now
rather "fixed", nobody is changing it anymore and
about all you may get are a few security fixes.
Of late I've done utilities in Bash, Pascal,
FORTRAN and even a little one in FORTH just
for fun (skip GNU, use a native compiler). Maybe
a speck of COBOL next month :-)

Haven't found an easy Modula2 compiler for Linux
yet though ... and the GNU one seems defective in
the current releases ........

Now a lot of people crave the newest-neatest ...
and I won't condemn them. However those languages
ARE in constant evolution. "Rust" today may not
compile/run a couple of years from now.

But, in the end, I'd rather write apps in 'C' or
Lazarus/FPC ..... I've converted numerous Python
programs, esp those with GUIs ......... Lazarus
really gets it done quick. For the web. straight-up
PHP is the most "future-proof".

So, there IS NO definitive answer here. It boils
down to a matter of "What You Need". Shell scripts
WILL persevere and Get It Done for a LONG time to
come. What you write today WILL work 5-10 years
from now. Hell, you CAN still write Winders BAT
files - and they DO work just like they did 20
years ago.

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 3/30/22 4:11 PM, Pancho wrote:
>> I just meant a normal try catch block provided by C#, Java, Python,
>> C++, JavaScript, Go, etc..., not a global exception handler. Even VBA
>> has ON ERROR GOTO.
>
> I was going to ask how a try/catch is conceptually different than if/then.
>
>> The point with good exception handling is that you don't have to
>> check errors thrown by *every* function call. However, it does not
>> mean you shouldn't check the return status of *any* function call.
>
> But then you said this, which makes me think that you're suggesting
> that the problem might be how many try/catch or if/then statements are
> needed to be sufficient without also being overly verbose.

The core issue with manual error handling is that all humans are
fallible. If every error condition has to be checked at every layer of a
call stack, mistakes are going to be made, resulting in bugs.

Bounds checking and memory management have the same issue. If they must
be done by a human programmer (as they usually are in C), then mistakes
are going to happen.

How serious these bugs are is situational; but it’s quite easy for them
to be vulnerabilities (Microsoft and Chrome estimate 70% of their
vulnerabilities are memory safety isues of some kind.)

No amount of saying that some category of programmers are lazy or
incompetent is going to prevent these mistakes. The fact is that if you
want to reduce the incidence of these bugs, then the only answer that
stands a chance of working is to get a computer to automate them away.

A language which uses exceptions to signal errors may result in programs
terminating with an ugly backtrace, but it won’t just blunder on past an
error, digging an ever-deeper hole, unless the programmer explicitly
chooses to ignore an exception.

A language which automates bounds checking may be a bit slower than an
otherwise similar one that doesn’t, but a whole class of bugs just
disappears. (And in reality for most applications you won’t notice a
significant performance difference.)

A language which automates memory management may use a bit more memory,
or run a little slower, than one that doesn’t, but it won’t crash (or
have a vulnerability) due to a use-after-free. (And it’s less likely to
have a memory leak...)

A lot of the software industry recognized these issues many years ago,
and this is reflected in the designs of languages from the last few
decades (and indeed in tooling for older languages). But the transition
away from these older languages is slow and difficult, even without
active resistance to learning anything invented after 1980.

--
https://www.greenend.org.uk/rjk/

25.BX944 <25BZ494@nada.net> wrote:
>
> Finally, on the "future-proofing" angle, those "old"
> languages DO have a certain advantage BECAUSE they
> are now fairly "fixed" - rather like why Latin is
> still used in scientific circles. Python2 is now
> rather "fixed", nobody is changing it anymore and
> about all you may get are a few security fixes.

No you won't, Python 2 is now unsupported so no more security
fixes.

That is my main objection to Python, you pick up a script from the
web and it might turn out to be Python 2 instead of Python 3 so it
doesn't work because Python 2 is no longer packaged for your distro
(and at some point in the future some dependency change will
probably break the build process if you want to compile it
yourself). You learnt Python 2, now you need to learn Python 3 and
convert all your existing scripts (albeit possibly using their
automated converter) if you're running them anywhere that security
is important.

Moreover besides incompatibilities in the major versions, I keep
grabbing Python scripts off the web that fail because they need a
feature change/addition introduced in one of the minor versions.
That suggests to me that Python is still evolving way too fast to
bother trying to learn.

Not that shells like Bash haven't kept new features trickling in as
well, only they maintain backward compatibility and authors of Bash
scripts published on the web don't seem nearly so eager to chase
the very latest new features. I tend to have much more luck running
shell scripts found on the web than Python, in fact I'm reluctant
to even bother trying to run Python scripts found on the web at
this point.

Youtube-dl has continued to run reliably though (albeit with high
CPU load), and still supports Python 2 as well as 3, so I take
that as evidence that well-written Python code is usable. Just the
stuff that most people publish doesn't seem to be. I may of course
just be very unlucky.

--
__ __
#_ < |\| |< _#

In comp.os.linux.misc, Computer Nerd Kev <not@telling.you.invalid> wrote:
> That is my main objection to Python, you pick up a script from the web
> and it might turn out to be Python 2 instead of Python 3 so it doesn't
> work because Python 2 is no longer packaged for your distro (and at
> some point in the future some dependency change will probably break
> the build process if you want to compile it yourself). You learnt
> Python 2, now you need to learn Python 3 and convert all your existing
> scripts (albeit possibly using their automated converter) if you're

This is the Perl 4 to Perl 5 transition problem, some twenty-five years
later.

> Moreover besides incompatibilities in the major versions, I keep
> grabbing Python scripts off the web that fail because they need a
> feature change/addition introduced in one of the minor versions.

This is why Perl normalized statements like "require 5.20.0;"

> That suggests to me that Python is still evolving way too fast to
> bother trying to learn.

Python hasn't given me that impression, but I've gotten that feeling
from Go. I have a perfectly good program from 2017, in source form, but
modifications to it are tricky to compile because Go has changed, the
libraries have changed with Go, and now I can't even easily figure out
what versions of older libraries are needed.

> Not that shells like Bash haven't kept new features trickling in as
> well, only they maintain backward compatibility and authors of Bash
> scripts published on the web don't seem nearly so eager to chase the
> very latest new features.

I generally try to write for standard Bourne shell in my scripts,
because I'm regularly switching between Linux and BSD, and don't want to
assume same version of anything is installed. Lately I've been doing
some work on Alpine with most common tools coming from busybox, which is
it's own set of slightly different.

> Youtube-dl has continued to run reliably though (albeit with high CPU
> load), and still supports Python 2 as well as 3, so I take that as
> evidence that well-written Python code is usable. Just the stuff that
> most people publish doesn't seem to be. I may of course just be very
> unlucky.

Yeah, 90% of everything is crap and all that. BTW, I've switched to
yt-dlp, a youtube-dl fork, because the original doesn't get timely
updates any more. :-(

Elijah
------
and recently ran into a video even yt-dlp couldn't download

In comp.os.linux.misc, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> I was going to ask how a try/catch is conceptually different than
> if/then.

Try/catch might be at a very superficial level similar to if/then, but
it allows catching errors far from where they appear. A low level
try/catch might retry on timeouts, and a higher level one might reprompt
for password on a 400 error.

> But then you said this, which makes me think that you're suggesting
> that the problem might be how many try/catch or if/then statements are
> needed to be sufficient without also being overly verbose.

Good programming requires so much error checking. But how few specific
errors do you need to deal with?

Elijah
------
at a certain point it's all branches in machine code

On 4/1/22 8:17 PM, Computer Nerd Kev wrote:
> 25.BX944 <25BZ494@nada.net> wrote:
>>
>> Finally, on the "future-proofing" angle, those "old"
>> languages DO have a certain advantage BECAUSE they
>> are now fairly "fixed" - rather like why Latin is
>> still used in scientific circles. Python2 is now
>> rather "fixed", nobody is changing it anymore and
>> about all you may get are a few security fixes.
>
> No you won't, Python 2 is now unsupported so no more security
> fixes.

Which may or may not be relevant depending on what
you're doing with it.

Most shell scripts are quite utilitarian. They aren't
trying to negotiate the latest hypersecurity features
of the net. As such Py2 can do the job quite nicely
and IS a lot more readable/debuggable.

The developer should be AWARE of when Py2 is or is
not appropriate to the task at hand.

If "security" features ARE important then use Py3
instead - or write something in a more traditional,
and updated, language like 'C','C++' and such. The
downside is that because Py3 is "evolving" your
script may not work properly in two, five, ten years.
The 'C'-spectrum progs stand a better chance.

Maybe you see that as "job security" ; I see it as
a ROYAL PAIN IN THE ASS. Stuff that works For Posterity
is what I aim for.

> That is my main objection to Python, you pick up a script from the
> web and it might turn out to be Python 2 instead of Python 3 so it
> doesn't work because Python 2 is no longer packaged for your distro
> (and at some point in the future some dependency change will
> probably break the build process if you want to compile it
> yourself). You learnt Python 2, now you need to learn Python 3 and
> convert all your existing scripts (albeit possibly using their
> automated converter) if you're running them anywhere that security
> is important.

99% of the incompatibility between Py2 and Py3 scripts you
pluck from the web revolve around the print() statement.

In short it's usually not a big deal. Py3 does add more
features, and does handle some esoteric stuff differently,
but again it's pretty easy to fix up.

I'm old enough to remember MANY languages that were hyped
to be THE Solution, THE Eternal Standard. They ALL faded
away. Hey, PROLOG was supposed to be The Future with all
its 'AI' aspects - how much PROLOG do you see these days ? :-)

I see a lot more COBOL actually ... a bud of mine HAD to
learn COBOL lately to get his new better job ... the company
had legacy COBOL programs That Just Worked Perfectly and
they were NOT gonna spend money replacing.

In any case, your bash/ksh/csh/etc scripts will always work
pretty damned well. The downside is the exotic syntax they
had to jam in there to make them do the 'modern' tricks.
They are NOT 'self documenting' in the least. Some of those
tricks are extremely opaque.

Bash and ksh have a faux TCP device that, with extremely
opaque code, can send commands to, and get data back from,
'C' services with very little code involved. I've used that
in a few places - but there's also 20 lines of comments
EXPLAINING the cryptic code so anyone who comes after
(including ME a couple of years from now) can service
the scripts.

> Moreover besides incompatibilities in the major versions, I keep
> grabbing Python scripts off the web that fail because they need a
> feature change/addition introduced in one of the minor versions.
> That suggests to me that Python is still evolving way too fast to
> bother trying to learn.

Which is why I advocated Py2 for certain applications.

Oh, and Python is NOT hard to learn. Some of the cute tricks
can be a pain, but you almost never NEED them. Me, I don't
like 'classes' and find ways to do stuff without them. I also
write very K&R style 'C' ... none of those ultra-compacted
statements that are mostly punctuation marks (it all compiles
the same in the end so why be obscure unless you want to
confound the Pointy-Haired Boss or those who come after ?).

I work in Python for awhile, the code just flies in there.
Then I need to do 'C' and after awhile the code just flies
in there. Then it's Pascal, and after awhile the code just
flies in there. Once in awhile I need to do microcontrollers
so it's lots of RISC assembler. So, basically, working in one
kinda erases memory of the others - so I have to RE-learn
whatever to a degree every month or two. If an Old Guy like
me can re-learn Python every few months then it shouldn't
be a huge deal for anyone else to learn once.

> Not that shells like Bash haven't kept new features trickling in as
> well, only they maintain backward compatibility and authors of Bash
> scripts published on the web don't seem nearly so eager to chase
> the very latest new features. I tend to have much more luck running
> shell scripts found on the web than Python, in fact I'm reluctant
> to even bother trying to run Python scripts found on the web at
> this point.
>
> Youtube-dl has continued to run reliably though (albeit with high
> CPU load), and still supports Python 2 as well as 3, so I take
> that as evidence that well-written Python code is usable. Just the
> stuff that most people publish doesn't seem to be. I may of course
> just be very unlucky.
>

Everyone has languages that, for whatever practical political
ideological or aesthetic reasons, they just HATE. That doesn't
make them BAD - just personally undesired. I don't do C# or
Java because I Just Don't LIKE Them, not because they're "bad".
And no I *never* liked PROLOG or LISP. Lambda WHAT ? WHY ???

Ok, ok, Java is like Stupid Overly-Wordy 'C' that runs at
interpreted speed ........ BUT, back in the old old days of
Bulletin Board Systems I was advocating something very much
LIKE Java as a fix so you could run GUIs/Graphics on
Atari/C64/BBC-Micro/Etc in a platform-independent fashion
(actually I was pushing for a generalized version of the
TexTronics graphics terminal command set ... with an
interpreter writ for each kind of platform - so maybe I
accidently contributed to the IDEA of Java :-)

On 4/4/22 8:46 PM, Eli the Bearded wrote:
> In comp.os.linux.misc, Computer Nerd Kev <not@telling.you.invalid> wrote:
>> That is my main objection to Python, you pick up a script from the web
>> and it might turn out to be Python 2 instead of Python 3 so it doesn't
>> work because Python 2 is no longer packaged for your distro (and at
>> some point in the future some dependency change will probably break
>> the build process if you want to compile it yourself). You learnt
>> Python 2, now you need to learn Python 3 and convert all your existing
>> scripts (albeit possibly using their automated converter) if you're
>
> This is the Perl 4 to Perl 5 transition problem, some twenty-five years
> later.

Perl - UGH ! - Why ??? :-)

Everybody thinks they have The Better Way. Mostly
they DON'T.

In any case the Py2 -> Py3 issue is usually quite
trivial. Don't bother with automated 'converters'.
99% of it will be the damned print() statements :-)

>> Moreover besides incompatibilities in the major versions, I keep
>> grabbing Python scripts off the web that fail because they need a
>> feature change/addition introduced in one of the minor versions.
>
> This is why Perl normalized statements like "require 5.20.0;"

Great ... what if you wind up with 5.19.9 or 5.20.1 on
a box ?

The VERSIONS problem is the bane of Linux/Unix at every
level. 5.20.1 may be perfectly compatible with 5.20.0
but the installers and other stuff WON'T WORK unless you
have an EXACT match - which, with rapid evolution, is
becoming increasingly impossible to achieve. I don't
really love compiling from source ......

>> That suggests to me that Python is still evolving way too fast to
>> bother trying to learn.
>
> Python hasn't given me that impression, but I've gotten that feeling
> from Go. I have a perfectly good program from 2017, in source form, but
> modifications to it are tricky to compile because Go has changed, the
> libraries have changed with Go, and now I can't even easily figure out
> what versions of older libraries are needed.

Py3 ... what you write today OUGHT to work tomorrow or
years from now. The trick is to avoid 'tricky'
new features. Almost all code can do that easily. So
it takes a whopping extra line or two - who cares ?

>> Not that shells like Bash haven't kept new features trickling in as
>> well, only they maintain backward compatibility and authors of Bash
>> scripts published on the web don't seem nearly so eager to chase the
>> very latest new features.
>
> I generally try to write for standard Bourne shell in my scripts,
> because I'm regularly switching between Linux and BSD, and don't want to
> assume same version of anything is installed. Lately I've been doing
> some work on Alpine with most common tools coming from busybox, which is
> it's own set of slightly different.

NOTHING is *completely* stable. Again, I've discovered that
avoiding the latest tricks - ie programming in a style a
couple of years behind the curve - solves almost all issues.

>> Youtube-dl has continued to run reliably though (albeit with high CPU
>> load), and still supports Python 2 as well as 3, so I take that as
>> evidence that well-written Python code is usable. Just the stuff that
>> most people publish doesn't seem to be. I may of course just be very
>> unlucky.
>
> Yeah, 90% of everything is crap and all that. BTW, I've switched to
> yt-dlp, a youtube-dl fork, because the original doesn't get timely
> updates any more. :-(
>
> Elijah
> ------
> and recently ran into a video even yt-dlp couldn't download

YT does this *deliberately* - ie it's intentional sabotage.
They REALLY don't want you to download - they want you in the
live interface so they can spit ADS at you and SPY on you.

In comp.os.linux.misc, 25.BX944 <25BZ494@nada.net> wrote:
> Perl - UGH ! - Why ??? :-)
>
> Everybody thinks they have The Better Way. Mostly
> they DON'T.

Perl was a great improvement over awk/sed/etc of varying degrees of
bugs. Making the syntax a weird amalgam of awk/sed/C proved to be a
point of contention.

> In any case the Py2 -> Py3 issue is usually quite
> trivial. Don't bother with automated 'converters'.
> 99% of it will be the damned print() statements :-)

Most issues I've run into have been over character encoding changes
between 2.x and 3.x.

[I wrote:]
>> This is why Perl normalized statements like "require 5.20.0;"
> Great ... what if you wind up with 5.19.9 or 5.20.1 on
> a box ?

That statemen is a requirement of _minimum_ version. 5.32.0 works for
"require 5.20.0;". And Perl can easily be installed as multiple
versions, although #! lines get complicated.

:r! ls /usr/local/bin/perl5*
/usr/local/bin/perl5
/usr/local/bin/perl5.00403
/usr/local/bin/perl5.00502
/usr/local/bin/perl5.00503
/usr/local/bin/perl5.10.1
/usr/local/bin/perl5.14
/usr/local/bin/perl5.14.1
/usr/local/bin/perl5.14.2
/usr/local/bin/perl5.14.4
/usr/local/bin/perl5.14.4-5.14.4
/usr/local/bin/perl5.20
/usr/local/bin/perl5.20.0
/usr/local/bin/perl5.20.2
/usr/local/bin/perl5.20.3
/usr/local/bin/perl5.20.3-5.20.3
/usr/local/bin/perl5.22
/usr/local/bin/perl5.22.1
/usr/local/bin/perl5.22.2
/usr/local/bin/perl5.22.3
/usr/local/bin/perl5.22.4
/usr/local/bin/perl5.22.4-5.22.4
/usr/local/bin/perl5.22.new
/usr/local/bin/perl5.24
/usr/local/bin/perl5.24.1
/usr/local/bin/perl5.24.1-5.24.1
/usr/local/bin/perl5.24.3
/usr/local/bin/perl5.24.3-5.24.3
/usr/local/bin/perl5.24.new
/usr/local/bin/perl5.6.0
/usr/local/bin/perl5.6.1
/usr/local/bin/perl5.8.8
/usr/local/bin/perl5.new

(Many of those are symlinks. There's only one 5.22.x installed, but for
#! lines previously installed names are kept.)

> 5.20.1 may be perfectly compatible with 5.20.0
> but the installers and other stuff WON'T WORK unless you
> have an EXACT match - which, with rapid evolution, is

Except it does work, mostly. I've had issues with 5.6.x code breaking on
newer Perl, but only ten plus years later.

> I don't really love compiling from source ......

I find package managed versions of code often work, except for stuff I
get from github that needs newer libraries. libharfbuzz has caused me a
lot of grief in recent years, due to older one being standard on the
Ubuntu I'm using and wanting tools that need newer versions.

> NOTHING is *completely* stable. Again, I've discovered that
> avoiding the latest tricks - ie programming in a style a couple of
> years behind the curve - solves almost all issues.

That's very true.

> YT does this *deliberately* - ie it's intentional sabotage. They
> REALLY don't want you to download - they want you in the live
> interface so they can spit ADS at you and SPY on you.

Yeah, I fully understand that. Which is why I really like having a
downloader that works.

Elijah
------
harfbuzz is used for font related code