Hacker News Reader

Comment by chubot | Hacker News Reader

A big problem with Awk is that it lacks garbage collection (including ref counting), and that puts major limitations on the language. You can't return an associative array from a function:

    $ awk 'function f() { a[1]=2; return a } BEGIN { f() }' </dev/null
    awk: cmd. line:1: fatal: attempt to use array `a' in a scalar context

You also can't have nested associative arrays, i.e. recursive or cyclic data structures are not allowed.

As far as I can tell, this is because a stack frame owns everything allocated within it, and when a function returns the whole stack frame is cleaned up unconditionally. You can pass arrays down but not up. It's very naive memory management (by modern standards; it's probably better than BASIC).

So I'd say it's clearly not expressive enough for general purpose programming. There are Lisps in awk but they do weird tricks with text as far as I remember.

View on HN

> There are Lisps in awk but they do weird tricks with text as far as I remember.

Not quite -- https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/... was the first and used two global associative arrays, car[n] and cdr[n], where n is an integer which iirc had to have a particular tag modulo 4, as the type tag. (Much as you'd do it in a lower-level C implementation.) I used almost the same scheme in my later Lisp.

Yeah this is cool, I was thinking of the "normal" way of doing it where evaluating a Lisp function reinvokes the interpreter function. But there are obviously other ways to do it if you have global arrays, as awk does.

> it's clearly not expressive enough for general purpose programming

The problem of persisting arrays usually leads to handling them in bash.

Now you have two problems.[1]

[1] If you paraphrase Jamie Zawinski in an explanation, you then have two things to explain.

Not sure what you mean because bash has the same problem -- you can't return an array from a function.

And I still think Shell, Awk, and Make Should be Combined. In that world you'd still have one problem :)

https://www.oilshell.org/blog/tags.html?tag=awk#awk

Oil has recursive data structures, although I'm still working out how to compose shell-like "procs" and functions which could return an associative array. We could just add them both naively but I think it would cause many shell programs to be a lot messier.

You don't have to in bash because you can just declare that your array is global inside your function. In fact, this is the default behavior.

Sure but you can also declare global arrays in Awk. The point is that Awk and bash are the same in several respects, so you don't really gain anything by switching to one or the other:

    - they don't have any garbage collection or ref counting
    - they don't have recursive data structures
    - you can't return any kind of array from a function

In bash you also can't pass an array to a function, but in Awk you can.

Thank you. This comment alone is enough reason to never touch Awk if I can help it.

You definitely want to work with it if you can. I live much of my life in python, but there hasn't never been a week, and usually not a day, in the last 10+ years where I don't write a quick awk snippet to do something useful to data.

The advantage of awk over python is that it almost always takes < 60 seconds from the point at which you say, "I want to summarize, review, filters, report" on some columnar data to the point at which you have output in front of you.

I"m fast with python doing that - but it's usually a 3-4 minute set of steps.

The only exception being json, which awk is clumsy with. (jq is my goto tool for the simple queries, python for anything that requires more than a minute of thought.)

Also - it's almost always the case that I'm using awk in conjunction with a bunch of other tools, cut/sed/uniq/grep to get what I want.

Many BASICs had GC to clean up strings -- even on rinky-dink 8-bit micros.

Reply on news.ycombinator.com