XPost: comp.unix.shell, comp.unix.programmer

In article <uvbe3m$2cun7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

I've programmed in Perl but I'm no Perl-programmer notwithstanding.

That's like saying "Yeah, I've had sex with men, but that don't make gay..."

--
I don't do things wrong.
I do things right.

I'm a legitimate person.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2024-04-12, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <uvbe3m$2cun7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

I've programmed in Perl but I'm no Perl-programmer notwithstanding.

That's like saying "Yeah, I've had sex with men, but that don't make gay..."

I've programmed so little in Perl in such distant nineties, that
it's analogous to only having seen the shower scene in /Midnight Express/.

I programmed in Perl to filter log files, but then I got to The AWK
Programming Language book. Sadly, I never wrote another Perl. I don't
think I do very well with sophisticated languages. I feel I need a
single reasonable way of doing things.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

I programmed in Perl to filter log files, but then I got to The AWK >Programming Language book. Sadly, I never wrote another Perl. I don't
think I do very well with sophisticated languages. I feel I need a
single reasonable way of doing things.

Perl:

The motto of the Perl community is, "There's More Than One Way
To Do It," or TMTOWDI (pronounced "Tim Toady").

Python:

There should be one - and preferably only one - obvious way
to do it. Although that way may not be obvious at first unless
you're Dutch.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted: >ram@zedat.fu-berlin.de (Stefan Ram) writes:

There should be one - and preferably only one - obvious way
to do it. Although that way may not be obvious at first unless
you're Dutch.

Why Dutch? Unless I understand Guido van Rossum very well? :)

Sometimes, there seem to be some choices how to do something in
Python.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

I programmed in Perl to filter log files, but then I got to The AWK

Programming Language book. Sadly, I never wrote another Perl. I

don't
think I do very well with sophisticated languages. I feel I need a
single reasonable way of doing things.

Perl:

The motto of the Perl community is, "There's More Than One Way
To Do It," or TMTOWDI (pronounced "Tim Toady").

Python:

There should be one - and preferably only one - obvious way
to do it. Although that way may not be obvious at first unless
you're Dutch.

Why Dutch? Unless I understand Guido van Rossum very well? :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

In comp.unix.shell Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

I've programmed in Perl but I'm no Perl-programmer notwithstanding.
Some more or less obvious reasons I see...
Abstraction of diverse Unix utilities' interfaces.
(...)
Supporting data structures (beyond primitive arrays).
Less quirks than Shell. (I'm saying that as an experienced Shell programmer.)

I find perl much more quirky. Among many other things, it lacks an straightforward support of nested data structures (you neeed to use
something called references), as it flattens nested arrays automatically.
That was an erroneous early design decission.

$ clisp <<< "(print '(1 2 3 (4 5)))"
...
(1 2 3 (4 5))

$ python3 <<< "print((1,2,3,(4,5)))"
(1, 2, 3, (4, 5))

$ perl -e "use Data::Dumper; @a=(1,2,3,(4,5)); print Dumper(\@a)"
$VAR1 = [
1,
2,
3,
4,
5
];

That being said, no other language comes close in conciseness when it
comes to text processing and interacting with the OS (filesystem, pipes, etc). Any other language is too verbose for those tasks.

https://wiki.c2.com/?WhyLovePerl

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On Sun, 14 Apr 2024 20:41:28 +0000, Javier wrote:

I find perl much more quirky. Among many other things, it lacks an straightforward support of nested data structures (you neeed to use
something called references), as it flattens nested arrays
automatically. That was an erroneous early design decission.

Is *that* where PHP got that stupid idea from? Only its attempt to patch
them up with “references” just created a new mess.

That being said, no other language comes close in conciseness when
it comes to text processing and interacting with the OS (filesystem,
pipes, etc). Any other language is too verbose for those tasks.

Other languages can offer more expressive facilities, though. This can
make the code easier to follow.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

Javier wrote:

That being said, no other language comes close in conciseness when it
comes to text processing and interacting with the OS (filesystem, pipes, etc).
Any other language is too verbose for those tasks.

Perhaps no other language, but i could imagine e.g. a library for a
language getting there.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
As always.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On Mon, 15 Apr 2024 12:43:56 -0000 (UTC), Blue-Maned_Hawk wrote:

.. i could imagine e.g. a library for a language getting there.

Especially a language that is particularly versatile and adaptable to
defining DSLs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On Mon, 15 Apr 2024 15:29:51 -0700, John Ames wrote:

On Mon, 15 Apr 2024 22:12:23 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

Especially a language that is particularly versatile and adaptable to
defining DSLs.

*waits for a Forth-head to chime in*

Forth? Not a chance. That’s only fit for a museum. Whatever interesting features it might have had were carried over to PostScript, which took
things to the next level.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On 16/04/2024 00:58, Lawrence D'Oliveiro wrote:

On Mon, 15 Apr 2024 15:29:51 -0700, John Ames wrote:

On Mon, 15 Apr 2024 22:12:23 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

Especially a language that is particularly versatile and adaptable to
defining DSLs.

*waits for a Forth-head to chime in*

What about Scala? I don't the language myself, but I believe it is
popular as a basis for DSL's.

Forth? Not a chance. That’s only fit for a museum. Whatever interesting features it might have had were carried over to PostScript, which took
things to the next level.

Forth is alive and well, albeit not very common. It is used in embedded systems - it is almost certainly the smallest language and run-time
system where you can have a extendable high-level language, and runs
directly on even very small microcontrollers. Within the same language,
you can glide between higher level words and Forth-style assembly for
low-level code. And you can pretty much freely choose where you draw
the line between pre-compiled code for maximal efficiency and
interpreted code for maximal convenience and development speed. I've
even seen a system with a soft processor (i.e., one made in a hardware
design language for use in FPGA's or gate array ASICs) written in Forth,
where you can move the boundaries between the parts that are implemented
in hardware and the parts in software.

Forth is also the basis for the assembly and code for most stack-based processors, which are used whenever the smallest die area is needed. In particular, 4-bit microcontroller programming is dominated by Forth.
You don't normally see such chips, because they are hidden inside
devices and these days only found within other chips (the last
general-purpose easily available 4-bit microcontroller line was
discontinued about a decade ago).

New Forth-native hardware has been made in recent times, such as the
GreenArray chips.

The latest Forth standard is from 2012, I believe.

Forth is certainly old, and certainly a very unusual language that is
hard for outsiders to comprehend, and certainly not a particularly
popular language, but it is equally certainly still used.

(I am not a "Forth-head", and know only a little of the language, but
happen to have learned a bit from real Forth-heads.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On Tue, 16 Apr 2024 10:14:38 +0200
David Brown <david.brown@hesbynett.no> wrote:

Forth is also the basis for the assembly and code for most stack-based >processors, which are used whenever the smallest die area is needed. In >particular, 4-bit microcontroller programming is dominated by Forth.
You don't normally see such chips, because they are hidden inside
devices and these days only found within other chips (the last >general-purpose easily available 4-bit microcontroller line was
discontinued about a decade ago).

Old style digital watches maybe?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

On 16/04/2024 10:35, Muttley@dastardlyhq.com wrote:

On Tue, 16 Apr 2024 10:14:38 +0200
David Brown <david.brown@hesbynett.no> wrote:

Forth is also the basis for the assembly and code for most stack-based
processors, which are used whenever the smallest die area is needed. In
particular, 4-bit microcontroller programming is dominated by Forth.
You don't normally see such chips, because they are hidden inside
devices and these days only found within other chips (the last
general-purpose easily available 4-bit microcontroller line was
discontinued about a decade ago).

Old style digital watches maybe?

Sure. And calculators, remote controls, microwave ovens, wireless keys
(cars, garages, etc.), and vast numbers of other devices. 4-bit
stack-based microcontrollers were a tiny fraction of the die size (and therefore cost) of even 8-bit devices, and used a tiny fraction of the
power (and therefore could have battery lifetimes of a decade or more).

Stand-alone 4-bit microcontrollers are a thing of the past, but you
still get them inside other chips as sequencers and handling things like startups or calibration sequences.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.unix.shell, comp.unix.programmer

In comp.unix.programmer Stefan Ram <ram@zedat.fu-berlin.de> wrote:

Sometimes, there seem to be some choices how to do something in
Python.

Of course. The slogan is just, well, a slogan, not to
be taken 100% literally. For example, there are almost
always some choices to be made whether to use
object-oriented features or not.

Some years ago I wrote a simple but useful Python
script for searching eBay items. It is so
simple that no classes are really necessary, one
could use just dictionaries/hashes instead. But for
some sanity, I think I used a class or two to
make things a bit better organized and self-documenting.

The last I checked, the O'Reilly Python book is just
absolutely *MASSIVE*. The language has a huge number
of features now and it is pretty obvious that choosing
which ones to use can be a matter of preference. So
there is no "One True Way" to choose.

I guess this is not much different from C++ which proclaims
to be multi-paradigm, but nobody ever uses the immense
full feature set. I've been told that all serious
C++ programming teams stick to a subset of features
that are allowed to be used.

br,
KK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)