AWK As A Major Systems Programming Language
===========================================
by Arnold Robbins, June, 2024

Preface
=======
I started this paper in 2013, and in 2015 sent it out for review to
the people listed later on. After incorporating comments, I sent it
to Rik Farrow, the editor of the USENIX magazine ;login: to see if he
would publish it. He declined to do so, for reasonably good reasons.

The paper languished, forgotten, until early 2018 when I came across
it and decided to polish it off, put it up on GitHub, and make it
available from my home page in HTML.

In 2024, I took a fresh look at it, and decided to polish it a little
bit more.

If you are interested in language design and evolution in general,
and in Awk in particular, I hope you will enjoy reading this paper.
If not, then why are you bothering looking at it now?

Arnold Robbins
Nof Ayalon, ISRAEL
June, 2024

1 Introduction
==============
At the March 1991 USENIX conference, Henry Spencer presented a paper
entitled AWK As A Major Systems Programming Language. In it, he
described his experiences using the original version of awk to write
two significant "systems" programs--a clone for a reasonable subset
of the nroff formatter [1], and a simple parser generator.

He described what awk did well, as well as what it didn't, and
presented a list of things that awk would need to acquire in order to
take the position of a reasonable alternative to C for systems
programming tasks on Unix systems.

In particular, awk lies about in the middle of the spectrum between
C, which is "close to the metal," and the shell, which is quite
high-level. A language at this level that is useful for doing systems
programming is very desirable.

This paper reviews Henry's wish list, and describes some of the
events that have occurred in the Unix/Linux world since 1991. It
presents a case that gawk--GNU Awk--fills most of the major needs
Henry listed way back in 1991, and then describes the author's
opinion as to why other languages have successfully filled the
systems programming role which awk did not. It discusses how the
current version of gawk may finally be able to join the ranks of
other popular, powerful, scripting languages in common use today, and
ends off with some counter-arguments and the author's responses to
them.

Acknowledgements
----------------
Thanks to Andrew Schorr, Henry Spencer, Nelson H.F. Beebe, and Brian
Kernighan for reviewing an earlier draft of this paper.

2 That Was Then ...
===================
In this section we review the state of the Unix world in 1991, as
well as the state of awk, and then list what Henry Spencer saw as
missing for awk.

* The Unix World in 1991
* What Awk Lacked In 1991

2.1 The Unix World in 1991
==========================
Undoubtedly, many readers of this paper were not using computers in
1991, so this section provides the context in which Henry's paper was
written. In March of 1991:

* Commercial Unix systems were the norm, with offerings from AT&T,
Digital Equipment Corporation, Hewlett Packard, IBM, Sun
Microsystems, and many others, all vying for market share.
Microsoft Windows existed, but was primarily a layer on top of
MS-DOS and was not taken seriously.
* Very few sites still ran the original Bell Labs or direct-from-UCB
variants of Unix; those did not keep up with the available hardware
and AT&T was itself trying to succeed in the Unix hardware market.
* GNU/Linux did not exist! Some unencumbered BSD variants were
available, but they were still under the cloud of the AT&T/UCB law
suit. [2]
* So-called "new" awk was about 2.5 years old. The book by Aho,
Weinberger and Kernighan was published in October of 1987, so most
people knew about new awk, but they just couldn't get it.

Who could? New awk was available to educational institutions from
the Bell Labs research group, and to those who had Unix source
licenses for System V Releases 3.1, 3.2, and 4. By this time,
source licensees were an extremely rare breed, since the cost for
commercial licenses had skyrocketed, and even for educational
licensees it had increased greatly. [3] If I recall correctly, an
educational license cost around US $1,000, considerably more than
the earlier Unix licenses.

* PERL [4] existed and was starting to gain in popularity. In 1991,
"PERL" most likely meant PERL 3 or a very early version of PERL 4.
The World Wide Web, which was one of the major reasons for PERL's
growth in popularity, had not yet really taken off.
* Other implementations of new awk were available:
+ MKS Awk for PC systems (MS-DOS).
+ GNU Awk was available and relatively stable, but could not be
called "solid."

The problem with the first of these is that source code was not
available. And the latter came with (to quote Henry) "troublesome
licenses." (Actually, Henry no longer remembers whether his
statement about "troublesome licenses" referred to the GPL, or to
the Bell Labs source licenses.)

* Michael Brennan's mawk (also GPL'ed) was not yet available. Version
1.0 was accepted for posting in comp.sources.reviewed on September
30, 1991, half a year after Henry's paper was published.

2.2 What Awk Lacked In 1991
===========================
Here is a summary of what was wrong with the awk picture in 1991.
These are in the same order as presented Henry's paper. We qualify
each issue in order to later discuss how it has been addressed over
time.

* New awk was not widely available. Most Unix vendors still shipped
only old awk. (Here is where he mentions that "the
independently-available implementations either cost substantial
amounts of money or come with troublesome [sic] licenses.") His
point then was that for portability, awk programs had to be
restricted to old awk.

This could be considered a quality of implementation issue,
although it's really a "lack of available implementation"
issue.

* There is no way to tell awk to start matching all its patterns over
again against the existing $0. This is a language design issue.
* There is no array assignment. (Language design issue.)
* Getting an error message out to standard error is difficult.
(Implementation issue.)
* There is no precise language specification for awk. This leads to
gratuitous portability problems. This too is thus a quality of
implementation issue, in that without a specification, it's
difficult to produce uniform, high quality implementations.
* The existing widely available implementation is slow; a much faster
implementation is needed and the best thing of all would be an
optimizing compiler. (Implementation issue.)
* There is no awk-level debugger. (Support tool or quality of
implementation issue.)
* There is no awk-level profiler. (Support tool or quality of
implementation issue.)

In private email, Henry added the following items, saying "there are
a couple more things I'd add now, in hindsight." These are direct
quotes:

* [I can't believe I didn't discuss this in the paper, because I was
certainly aware of it then!] Lack of any convenient mechanism for
adding libraries. When awk is being invoked from a shell file, the
shell file can do substitutions or use multiple -f options, but
those are mechanisms outside the language, and not very convenient
ones. What's really wanted is something like you get in Python
etc., where one little statement up near the top says "arrange for
this program to have the xyz library available when it runs."
* I think it was Rob Pike who later said (roughly): "It says
something bad about Awk that in a language with integrated regular
expressions, you end up using substr() so often." My paper did
allude to the difficulty of finding out where something matched in
old-awk programs, but even in new awk, what you get is a number
that you then have to feed to substr(). The language could really
use some more convenient way of dissecting a string using regexp
matching. [Caveat: I have not looked lately at Gawk to see if it
has one.]

The first of these is somewhere between a language design and a
language implementation issue. The latter is a language design issue.

3 ... And This Is Now
=====================
Fast forward to 2024. Where do things stand?

* What Awk Has Today
* And What GNU Awk Has Today
* So Where Does Awk Stand?

3.1 What Awk Has Today
======================
The state of the awk world is much better now. In the same order:

* New awk is the standard version of awk today on GNU/Linux, BSD, and
commercial Unix systems. The one notable exception is Solaris,
where /usr/bin/awk is still the old one; on all other systems,
plain awk is some version of new awk.
* There remains no way to tell awk to start matching all its patterns
over again against the existing $0. Furthermore, this is a feature
that has not been called for by the awk community, except in
Henry's paper. (We do acknowledge that this might be a useful
feature.)
* There continues to be no array assignment. However, this function
in gawk, which has arrays of arrays, can do the trick nicely. It is
also efficient, since gawk uses reference counted strings
internally:

Ben Collver <bencollver@tilde.pink> wrote or quoted:
>AWK As A Major Systems Programming Language

A systems programming language, in my book, is one you can
crank out device drivers in and tap into the platform ABI.

>In retrospect, it seems clear (at least to us!) that there are two
>major reasons that all of the previously mentioned languages have
>enjoyed significant popularity. The first is their extensibility. The
>second is namespace management.

That totally makes me think of the "Zen of Python":

|The Zen of Python, by Tim Peters
| |Beautiful is better than ugly.
|Explicit is better than implicit.
|Simple is better than complex.
|Complex is better than complicated.
|Flat is better than nested.
|Sparse is better than dense.
|Readability counts.
|Special cases aren't special enough to break the rules.
|Although practicality beats purity.
|Errors should never pass silently.
|Unless explicitly silenced.
|In the face of ambiguity, refuse the temptation to guess.
|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.
|Now is better than never.
|Although never is often better than *right* now.
|If the implementation is hard to explain, it's a bad idea.
|If the implementation is easy to explain, it may be a good idea.
|Namespaces are one honking great idea -- let's do more of those!
..

>I have worked for several years in Python. For string manipulation
>and processing records, you still have to write all the manual stuff:
>open the file, read lines in a loop, split them, etc. Awk does all
>this stuff for me.

On the flip side, you can peep it like this: Python's got a solid
set of statement types you can use for everything, making the code
hella readable. Meanwhile, awk's got its bag of tricks for special
cases like file and string processing. Just compare [1] with [2].

[1]

#!/usr/bin/awk -f

# This AWK script analyzes a simple CSV file containing book information:
# Title,Author,Year,Price

BEGIN {
FS = ","
print "Book Analysis Report"
print "===================="
}

{
if (NR > 1) { # Skip header row
total_price += $4
if ($3 < min_year || min_year == 0) min_year = $3
if ($3 > max_year) max_year = $3

author_count[$2]++
year_count[$3]++
}
}

END {
print "\nTotal number of books:", NR - 1
print "Average book price: $" sprintf("%.2f", total_price / (NR - 1))
print "Year range:", min_year, "to", max_year

print "\nBooks per author:"
for (author in author_count)
print author ":", author_count[author]

print "\nBooks per year:"
for (year in year_count)
print year ":", year_count[year]
}

[2]

#!/usr/bin/env python3

import csv
from dataclasses import dataclass
from collections import Counter
from typing import List, Dict, Tuple

@dataclass
class Book:
title: str
author: str
year: int
price: float

class BookAnalyzer:
def __init__(self, books: List[Book]):
self.books = books

def total_books(self) -> int:
return len(self.books)

def average_price(self) -> float:
return sum(book.price for book in self.books) / len(self.books)

def year_range(self) -> Tuple[int, int]:
years = [book.year for book in self.books]
return min(years), max(years)

def books_per_author(self) -> Dict[str, int]:
return Counter(book.author for book in self.books)

def books_per_year(self) -> Dict[int, int]:
return Counter(book.year for book in self.books)

def read_csv(filename: str) -> List[Book]:
with open(filename, 'r') as f:
reader = csv.reader(f)
next(reader) # Skip header row
return [Book(title, author, int(year), float(price))
for title, author, year, price in reader]

def print_report(analyzer: BookAnalyzer) -> None:
print("Book Analysis Report")
print("====================")
print(f"\nTotal number of books: {analyzer.total_books()}")
print(f"Average book price: ${analyzer.average_price():.2f}")
min_year, max_year = analyzer.year_range()
print(f"Year range: {min_year} to {max_year}")

print("\nBooks per author:")
for author, count in analyzer.books_per_author().items():
print(f"{author}: {count}")

print("\nBooks per year:")
for year, count in analyzer.books_per_year().items():
print(f"{year}: {count}")

def main() -> None:
books = read_csv("books.csv")
analyzer = BookAnalyzer(books)
print_report(analyzer)

if __name__ == "__main__":
main()

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>I have worked for several years in Python. For string manipulation
>>and processing records, you still have to write all the manual stuff:
>>open the file, read lines in a loop, split them, etc. Awk does all
>>this stuff for me.
>
> On the flip side, you can peep it like this: Python's got a solid
> set of statement types you can use for everything, making the code
> hella readable. Meanwhile, awk's got its bag of tricks for special
> cases like file and string processing. Just compare [1] with [2].
>
> [1]
[snip]

Weird, as someone who doesn't use much of Python or AWK, I look at
your examples as clearly demonstrating that the AWK version is much
easier to read. I wonder if the Python version is more complicated
than it needs to be actually.

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

On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:

> He described what awk did well, as well as what it didn't, and presented
> a list of things that awk would need to acquire in order to take the
> position of a reasonable alternative to C for systems programming tasks
> on Unix systems.

It was soon obsoleted by Perl, which did everything Awk did, just as
concisely, and more besides.

not@telling.you.invalid (Computer Nerd Kev) writes:
> Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> On the flip side, you can peep it like this: Python's got a solid set
>> of statement types you can use for everything, making the code hella
>> readable. Meanwhile, awk's got its bag of tricks for special cases
>> like file and string processing. Just compare [1] with [2].
>>
>> [1]
> [snip]
>
> Weird, as someone who doesn't use much of Python or AWK, I look at
> your examples as clearly demonstrating that the AWK version is much
> easier to read. I wonder if the Python version is more complicated
> than it needs to be actually.

Yes, you could do a direct translation from the Awk and end up with
something that looked quite similar, apart from the differences in
syntax.

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

Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:
>Yes, you could do a direct translation from the Awk and end up with
>something that looked quite similar, apart from the differences in
>syntax.

Trying to make that Python script more user-friendly for folks
who dig awk, then rolling out a sleeker version . . .

#!/usr/bin/env python3

import sys
import csv

# Initialize variables
total_price = 0
min_year = 0
max_year = 0
author_count = {}
year_count = {}

# Print the header of the report
print("Book Analysis Report")
print("====================")

# Read CSV data from standard input
reader = csv.reader(sys.stdin)
next(reader) # Skip the header row

# Process each row in the CSV
for row in reader:
title, author, year, price = row
year = int(year)
price = float(price)

# Accumulate total price
total_price += price

# Determine min and max year
if min_year == 0 or year < min_year:
min_year = year
if year > max_year:
max_year = year

# Count books per author
if author in author_count:
author_count[author] += 1
else:
author_count[author] = 1

# Count books per year
if year in year_count:
year_count[year] += 1
else:
year_count[year] = 1

# Calculate total number of books
total_books = sum(author_count.values())

# Print the report
print("\nTotal number of books:", total_books)
print("Average book price: $%.2f" % (total_price / total_books))
print("Year range:", min_year, "to", max_year)

print("\nBooks per author:")
for author, count in author_count.items():
print(author + ":", count)

print("\nBooks per year:")
for year, count in year_count.items():
print(str(year) + ":", count)

No need to make it such a big production, though . . .

import csv, sys
from collections import Counter

with open(sys.argv[1]) as f:
data = list(csv.reader(f))[1:]
prices = [float(row[3]) for row in data]
years = [int(row[2]) for row in data]
authors = [row[1] for row in data]

print("Book Analysis Report\n====================")
print(f"\nTotal number of books: {len(data)}")
print(f"Average book price: ${sum(prices) / len(prices):.2f}")
print(f"Year range: {min(years)} to {max(years)}")

print("\nBooks per author:")
for author, count in Counter(authors).items():
print(f"{author}: {count}")

print("\nBooks per year:")
for year, count in Counter(years).items():
print(f"{year}: {count}")

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Trying to make that Python script more user-friendly for folks
>who dig awk, then rolling out a sleeker version . . .

The setup with a class and a bunch of named functions had some perks,
though: The class and function names are like a cheat sheet, spilling
the beans on what the coder was up to. They keep things chill by
breaking up the work, each one zeroing in on just one part of the gig.
Plus, they give you a solid jumping-off point for unit tests.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>Trying to make that Python script more user-friendly for folks
>>who dig awk, then rolling out a sleeker version . . .
>
> The setup with a class and a bunch of named functions had some perks,
> though: The class and function names are like a cheat sheet, spilling
> the beans on what the coder was up to. They keep things chill by
> breaking up the work, each one zeroing in on just one part of the gig.
> Plus, they give you a solid jumping-off point for unit tests.

Yes, it’s not that it was a bad design as such, but if you’re trying to
do some kind of conciseness comparison with Awk, it wasn’t really
comparing like with like.

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

On Mon, 19 Aug 2024, Stefan Ram wrote:

> Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:
>> Yes, you could do a direct translation from the Awk and end up with
>> something that looked quite similar, apart from the differences in
>> syntax.
>
> Trying to make that Python script more user-friendly for folks
> who dig awk, then rolling out a sleeker version . . .

Looks pretty neat and understandable to me. =)

> #!/usr/bin/env python3
>
> import sys
> import csv
>
> # Initialize variables
> total_price = 0
> min_year = 0
> max_year = 0
> author_count = {}
> year_count = {}
>
> # Print the header of the report
> print("Book Analysis Report")
> print("====================")
>
> # Read CSV data from standard input
> reader = csv.reader(sys.stdin)
> next(reader) # Skip the header row
>
> # Process each row in the CSV
> for row in reader:
> title, author, year, price = row
> year = int(year)
> price = float(price)
>
> # Accumulate total price
> total_price += price
>
> # Determine min and max year
> if min_year == 0 or year < min_year:
> min_year = year
> if year > max_year:
> max_year = year
>
> # Count books per author
> if author in author_count:
> author_count[author] += 1
> else:
> author_count[author] = 1
>
> # Count books per year
> if year in year_count:
> year_count[year] += 1
> else:
> year_count[year] = 1
>
> # Calculate total number of books
> total_books = sum(author_count.values())
>
> # Print the report
> print("\nTotal number of books:", total_books)
> print("Average book price: $%.2f" % (total_price / total_books))
> print("Year range:", min_year, "to", max_year)
>
> print("\nBooks per author:")
> for author, count in author_count.items():
> print(author + ":", count)
>
> print("\nBooks per year:")
> for year, count in year_count.items():
> print(str(year) + ":", count)
>
> No need to make it such a big production, though . . .
>
> import csv, sys
> from collections import Counter
>
> with open(sys.argv[1]) as f:
> data = list(csv.reader(f))[1:]
> prices = [float(row[3]) for row in data]
> years = [int(row[2]) for row in data]
> authors = [row[1] for row in data]
>
> print("Book Analysis Report\n====================")
> print(f"\nTotal number of books: {len(data)}")
> print(f"Average book price: ${sum(prices) / len(prices):.2f}")
> print(f"Year range: {min(years)} to {max(years)}")
>
> print("\nBooks per author:")
> for author, count in Counter(authors).items():
> print(f"{author}: {count}")
>
> print("\nBooks per year:")
> for year, count in Counter(years).items():
> print(f"{year}: {count}")
>

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>Trying to make that Python script more user-friendly for folks
>>who dig awk, then rolling out a sleeker version . . .
>
> The setup with a class and a bunch of named functions had some perks,
> though: The class and function names are like a cheat sheet, spilling
> the beans on what the coder was up to. They keep things chill by
> breaking up the work, each one zeroing in on just one part of the gig.
> Plus, they give you a solid jumping-off point for unit tests.

I see your point. Depends on what you're trying to read too really
- what the script's author is trying to achieve, or what exactly
the script does. To achieve the latter there's more to parse in the
first version in order to see what's actually happening, and that's
what I was comparing to the AWK version.

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

Stefan Ram:

> |The Zen of Python, by Tim Peters
> |[...]
> |Flat is better than nested.
> [...]

Then why does Python lack the ultimate code flattener, the
`goto' operator, and mandates structural indentation?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Wed, 21 Aug 2024 19:18:08 +0300, Anton Shepelev wrote:

> Stefan Ram:
>
>> |The Zen of Python, by Tim Peters |[...]
>> |Flat is better than nested. [...]
>
> Then why does Python lack the ultimate code flattener, the `goto'
> operator, and mandates structural indentation?

I never took that “flat is better than nested” nonsense seriously, anyway.
If I need to nest in my Python code, I nest: statement nesting, function
nesting, class nesting, whatever makes sense.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>
>> He described what awk did well, as well as what it didn't, and presented
>> a list of things that awk would need to acquire in order to take the
>> position of a reasonable alternative to C for systems programming tasks
>> on Unix systems.
>
> It was soon obsoleted by Perl, which did everything Awk did, just as
> concisely, and more besides.

Funny---I gave up on Perl as soon as I discovered the existence of AWK.

Johanne Fairchild <jfairchild@tudado.org> writes:

> Funny---I gave up on Perl as soon as I discovered the existence of AWK.

\o/

--
I do not bite, I just want to play.

On Tue, 27 Aug 2024 19:43:28 -0300, Johanne Fairchild wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>>
>>> He described what awk did well, as well as what it didn't, and
>>> presented a list of things that awk would need to acquire in order to
>>> take the position of a reasonable alternative to C for systems
>>> programming tasks on Unix systems.
>>
>> It was soon obsoleted by Perl, which did everything Awk did, just as
>> concisely, and more besides.
>
> Funny---I gave up on Perl as soon as I discovered the existence of AWK.

Have you given up motor-cars in favour of horse-drawn transport as well?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 27 Aug 2024 19:43:28 -0300, Johanne Fairchild wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>>>
>>>> He described what awk did well, as well as what it didn't, and
>>>> presented a list of things that awk would need to acquire in order to
>>>> take the position of a reasonable alternative to C for systems
>>>> programming tasks on Unix systems.
>>>
>>> It was soon obsoleted by Perl, which did everything Awk did, just as
>>> concisely, and more besides.
>>
>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>
> Have you given up motor-cars in favour of horse-drawn transport as well?

I'm sure there are places where motor-cars are totally useless and a
horse is a blessing.

On Tue, 27 Aug 2024, Johanne Fairchild wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>>
>>> He described what awk did well, as well as what it didn't, and presented
>>> a list of things that awk would need to acquire in order to take the
>>> position of a reasonable alternative to C for systems programming tasks
>>> on Unix systems.
>>
>> It was soon obsoleted by Perl, which did everything Awk did, just as
>> concisely, and more besides.
>
> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>

Sometimes less is more. It's aesthetics for sure, but for me personally, I
do not like massive languages that try to do, and be, everything. For fun
I thought about to have a look at Lua, or possibly, go.

D:

> Sometimes less is more. It's aesthetics for sure, but for
> me personally, I do not like massive languages that try to
> do, and be, everything. For fun I thought about to have a
> look at Lua, or possibly, go.

Also, Hare: <https://harelang.org/> .

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

D <nospam@example.net> writes:

> On Tue, 27 Aug 2024, Johanne Fairchild wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>>>
>>>> He described what awk did well, as well as what it didn't, and presented
>>>> a list of things that awk would need to acquire in order to take the
>>>> position of a reasonable alternative to C for systems programming tasks
>>>> on Unix systems.
>>>
>>> It was soon obsoleted by Perl, which did everything Awk did, just as
>>> concisely, and more besides.
>>
>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.

Actually it was after I read ``The AWK Programming Language''.

> Sometimes less is more. It's aesthetics for sure, but for me
> personally, I do not like massive languages that try to do, and be,
> everything. For fun I thought about to have a look at Lua, or
> possibly, go.

Lua is a nice language, but it's really small.

On Fri, 30 Aug 2024, Johanne Fairchild wrote:

> D <nospam@example.net> writes:
>
>> On Tue, 27 Aug 2024, Johanne Fairchild wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Sun, 18 Aug 2024 00:28:21 -0000 (UTC), Ben Collver wrote:
>>>>
>>>>> He described what awk did well, as well as what it didn't, and presented
>>>>> a list of things that awk would need to acquire in order to take the
>>>>> position of a reasonable alternative to C for systems programming tasks
>>>>> on Unix systems.
>>>>
>>>> It was soon obsoleted by Perl, which did everything Awk did, just as
>>>> concisely, and more besides.
>>>
>>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>
> Actually it was after I read ``The AWK Programming Language''.
>
>> Sometimes less is more. It's aesthetics for sure, but for me
>> personally, I do not like massive languages that try to do, and be,
>> everything. For fun I thought about to have a look at Lua, or
>> possibly, go.
>
> Lua is a nice language, but it's really small.
>

Ah! So maybe Lua would be my next hobby language to learn. =)

D <nospam@example.net> writes:

[...]

>>>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>>
>> Actually it was after I read ``The AWK Programming Language''.
>>
>>> Sometimes less is more. It's aesthetics for sure, but for me
>>> personally, I do not like massive languages that try to do, and be,
>>> everything. For fun I thought about to have a look at Lua, or
>>> possibly, go.
>>
>> Lua is a nice language, but it's really small.
>>
>
> Ah! So maybe Lua would be my next hobby language to learn. =)

I don't know why people enjoy such small things so much. Sure, it feels
good to master something, but it's also good to have tools that can do a
lot for us. I used to be very minimalist, but following my heart
instead of my brain I found Common Lisp to be the nicest of them all.
But, sure, if I'm going to embed a language in my executable, Lua is a
candidate, though I'd probably go for a small Lisp.

On Sat, 31 Aug 2024, Johanne Fairchild wrote:

> D <nospam@example.net> writes:
>
> [...]
>
>>>>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>>>
>>> Actually it was after I read ``The AWK Programming Language''.
>>>
>>>> Sometimes less is more. It's aesthetics for sure, but for me
>>>> personally, I do not like massive languages that try to do, and be,
>>>> everything. For fun I thought about to have a look at Lua, or
>>>> possibly, go.
>>>
>>> Lua is a nice language, but it's really small.
>>>
>>
>> Ah! So maybe Lua would be my next hobby language to learn. =)
>
> I don't know why people enjoy such small things so much. Sure, it feels
> good to master something, but it's also good to have tools that can do a
> lot for us. I used to be very minimalist, but following my heart
> instead of my brain I found Common Lisp to be the nicest of them all.
> But, sure, if I'm going to embed a language in my executable, Lua is a
> candidate, though I'd probably go for a small Lisp.
>

In my case, it is because I am not working as a programmer, so I have not
requirements to be productive or to be able to generate any income of
programming.

That means, I can just have a go at what I find interesting and beautiful.
It also means that if I get bored, I can just stop, and have a look at any
other languange that catches my interest. =)

D <nospam@example.net> writes:

> On Sat, 31 Aug 2024, Johanne Fairchild wrote:
>
>> D <nospam@example.net> writes:
>>
>> [...]
>>
>>>>>> Funny---I gave up on Perl as soon as I discovered the existence of AWK.
>>>>
>>>> Actually it was after I read ``The AWK Programming Language''.
>>>>
>>>>> Sometimes less is more. It's aesthetics for sure, but for me
>>>>> personally, I do not like massive languages that try to do, and be,
>>>>> everything. For fun I thought about to have a look at Lua, or
>>>>> possibly, go.
>>>>
>>>> Lua is a nice language, but it's really small.
>>>>
>>>
>>> Ah! So maybe Lua would be my next hobby language to learn. =)
>>
>> I don't know why people enjoy such small things so much. Sure, it feels
>> good to master something, but it's also good to have tools that can do a
>> lot for us. I used to be very minimalist, but following my heart
>> instead of my brain I found Common Lisp to be the nicest of them all.
>> But, sure, if I'm going to embed a language in my executable, Lua is a
>> candidate, though I'd probably go for a small Lisp.
>>
>
> In my case, it is because I am not working as a programmer, so I have
> not requirements to be productive or to be able to generate any income
> of programming.

I am not programming for profit any longer. Thank God. I program for
beauty now. This change has been the hardest thing I had to do and it's
been so worth it.

> That means, I can just have a go at what I find interesting and
> beautiful. It also means that if I get bored, I can just stop, and
> have a look at any other languange that catches my interest. =)

:-)

When I felt comfortable with C, I decided to choose a higher-level
language that could be my main medium of expression. I choose Lisp.
It's been taking me lots and lots of years, but it's also been so worth
it. I came up with the Lisp idea observing Barry Margolin here on
USENET many years ago. It was his discussions on Lisp that brought the
language to my attention. I had no idea it existed and I felt it was
really strange that inteligent people would care so much about such an
old thing. Newbies.

On Sun, 01 Sep 2024 22:52:10 -0300, Johanne Fairchild wrote:

> I had no idea [Lisp] existed and I felt it was
> really strange that inteligent people would care so much about such an
> old thing.

It is a language that still looks advanced compared to the state of the
art today. Trouble is, there is no currently workable Lisp “standard” as
such: first of all there is the “Lisp-1” (e.g. Scheme) versus “Lisp-2”
(e.g. Common Lisp, Elisp) schism; secondly the closest thing to a Lisp
“standard” was Common Lisp, and that is really old and full of baggage
from the time when non-Posix-like operating systems were common. Even
Scheme seems to have become fragmented.

On Sun, 1 Sep 2024, Johanne Fairchild wrote:

>> In my case, it is because I am not working as a programmer, so I have
>> not requirements to be productive or to be able to generate any income
>> of programming.
>
> I am not programming for profit any longer. Thank God. I program for
> beauty now. This change has been the hardest thing I had to do and it's
> been so worth it.

Why? How was it to work as a programmer and what was it that you
didn't like about it? When I graduated from university, I wanted to
become a programmer, but at that time, only 10+ years of experience was
wanted on the job market, so life decided that I should work in
infrastructure/system administration instead.