Re: a sed question

On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:

Kenny McCormack schrieb:
>

Isn't this about the time where we give the caution about "Don't use sed
for anything beyond the s/foo/bar/g stage" ?

>
Simply because you cannot imagine how to use it? No!

He explained the "because", in the immediately following text that you snipped:

KMC> Seriously, the above looks like gobbledegook compared to the equivalent in                           
KMC> AWK (or some other normal scripting langugae).  "sed" looks like Intercal                            
KMC> (once you get beyond s/foo/bar/g).                                                                   
                                                                                                     
KMC> I'm sure that whatever it is that OP is trying to do, it could be easily                             
KMC> translated to (say) AWK and look much nicer. 

The reasoning doesn't quite match up with the characterization "can't imagine
how to use it". Kenny need not imagine; he has seen examples of how to
use Sed in ways beyond s/x/y/g, and has the above remarks about that.

Sed is one of the so-called "esolangs" which some people use for puzzling.
For instance, here is a kind of Lisp interpreter written in Sed:

https://github.com/shinh/sedlisp/blob/master/sedlisp.sed

The goal of writing in sed is not to solve the problem, and to communicate with
future users of the program so that they can adapt it to changing needs; the
goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"

Just like the goal of solving a Sudoku isn't to get 9 digits in every row,
colum and box. That's the ostensible goal within the puzzle. The actual goal
of the puzzler is to engage in puzzle solving.

The given text processing problem to be solved in Sed serves a similar purpose
to the 9 digit constraint rules in Sudoku: it just creates the pretext for
entertaining puzzle solving, and is not the actual goal.

People looking for solutions in their production workflow do not want
"hey, look, this can be done in Sed!" type stuff. While people /can/
ramp up on it and easily become proficient, the only ones ever to do so are
going to be engineers looking to waste time on puzzles.

Engineers not looking for puzzing won't ramp up on stuff like this because
it provides no value outside of puzzing. For production work, you need
a language which not only orchestrates the needed computation on the machine,
but also captures the requirements in a way that communicates to people.
Programming languages are a form of documentation!

Nobody wants to write cryptic gobbledygook just for shits and giggles, only to
then have to write an accompanying ream of boring to try to bring it up to the
same communication standard that comes from just writing nothing but code in an
expressive language.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca