xonix

But how would POSIX shell be available? Wouldn’t it be compiled from C?

Re: TCO

Does the language give any guarantee that TCO was applied? In other words can it give you an error that the recursion is not of tail call form? Because I imagine a probability of writing a recursion and relying on it being TCO-optimized, where it's not. I would prefer if a language had some form of explicit TCO modifier for a function. Is there any language that has this?

Reminded me of bytebeats (though I admit it's a different thing): https://bytebeat.demozoo.org/#t=0&e=0&s=44100&bb=5d00000100f...

Long time ago I was obsessed with Prolog. I found that if you bend it enough you could implement imperative code (a-la JavaScript) evaluation, still being valid Prolog:

https://github.com/xonixx/prolog-experiments/blob/main/Prolo...

This was super funny, but obviously absolutely useless

No AWK?

You could also like my tool: https://makesure.dev/

https://maximullaris.com/makesure-vs-make.html

https://maximullaris.com/makesure-vs-just.html

My take on this is that it's not always the best idea to abstract-out SQL. You see, the SQL itself is too valuable abstraction, and also a very "wide" one. Any attempt to hide it behind another abstraction layer will face these problems:

- need to learn secondary API which still doesn't cover the whole scope of SQL

- abstraction which is guaranteed to leak, because any time you'll need to optimize - you'll need to start reason in terms of SQL and try to force the ORM produce SQL you need.

- performance

- deceptive simplicity, when it's super-easy to start on simple examples, but it's getting increasingly hard as you go. But at the point you realize it doesn't work (well) - you already produced tons of code which business will disallow you to simply rewrite

(knowledge based on my own hard experiences)

Right, this is not the problem par se. To me this is a rather philosophical question. Related to the motivation behind the project.

If someone has some particular domain problem to which they need to introduce the new programming language, then, probably, it should look somehow different to all existing languages, otherwise they would be used.

Alternatively, the motivation could be: OK I need ExistingLanguageX(-alike) but in the domain/environment where it's not present yet, for example, WASM.

The motivation question is always of interest to me since it allows to judje for the long-term perspectives of the project.

However don't take this as a discouragement rant, learning case is a good motivation/raison d'être too.

It's funny to watch how often new programming languages resemble visually (and conceptually) the language they are written in. You can put it the other way: just look at a syntax sample and try to guess the implementation language.

I can see some problem here. Probably, it means the author is under heavy influence of the implementation language, that limits their thinking and creativity scope to the concepts of that language.

  email:string( regex(".*@.*\\..*") )

Or makesure: https://makesure.dev/

You can also implement includes in couple (tens) of lines of AWK: https://maximullaris.com/revamp_define.html#mglwnafh

Nice.

Once I did some experiments at programming in Java using only sun.misc.Unsafe for a memory access: https://github.com/xonixx/gc_less. I was able to implement this way basic data structures (array, array list, hash table). I even explicitely set a very small heap and used Epsilon GC to make sure I don't allocate in heap.

Just recently I decided to check if it still works in the latest Java (23) and to my surprise it appears - it is. Now, apparently, this is going to change.

You can also program in Python just in list comprehensions: https://maximullaris.com/abusing_python.html

makesure, a similar tool (https://maximullaris.com/makesure-vs-just.html) I'm developing, doesn't require installation in the traditional sense: https://github.com/xonixx/makesure#installation.

Also, I was considering adding the same feature (generating the equivalent shell script) to my tool, but after doing some analysis decided not to pursue this idea for the following reasons: https://github.com/xonixx/makesure/issues/83#issuecomment-98....

It has: https://github.com/xonixx/gron.awk/blob/e5040a7b1384c5839dca...

Strange, should be much less failures: https://github.com/xonixx/gron.awk/blob/e5040a7b1384c5839dca...

Could you please file a bug with the details?

My pure-AWK variant: https://github.com/xonixx/gron.awk (features complete JSON parser in AWK).

True. Probably, only AWK is an exception.

I've just turned off all the Feed filters to show empty feed. This way it's more useful, than with it's "new content". I've bookmarked the direct link to https://github.com/dashboard-feed, unfortunatelly on mobile the font is too small.

For me the most relevant selling point of GraalVM is beeing able to compile to native self-contained executable. But on the other hand, Golang delivers on this aspect much better (or at least much faster).

Correct me if I'm wrong, but to me passing the access token in the GET URL is not a good security practice. This increases the probability of unintentionally exposing the token. The URLs can be logged by proxy servers, application logs. Simply, user can accidentally send the link with token in chat, etc.

Usually in REST APIs the auth token is passed via some HTTP header.

This reminded me the idea of compilers bootstrapping (https://news.ycombinator.com/item?id=35714194). That is, now you can code in SectorC some slightly more advanced version of C capable of compiling TCC (https://bellard.org/tcc/), and then with TCC you can go forward to GCC and so on.

This sounds reasonable. When the GoAWK creator tried to add Unicode support through UTF-8 he discovered that this had drastic performance implications (rendering some algorithms to be O(N^2) instead of O(N)), if done naive https://github.com/benhoyt/goawk/issues/35. Therefore the change was reverted till the more efficient implementation can be found.

Btw, the GNU awk is also considerably faster (due to bytecode) than awk bundled with BSD & Mac (usually, "one true awk").

When at some point I decided to learn AWK better, I was surprised to find that it had some very Perl-ish features, like `print` is the same as `print $0` or `if(/abc/){}` as shorthand for `if($0 ~ /abc/){}`, etc. Later I learned that Perl was designed as an AWK-on-steroids by Larry Wall.

No doubt Perl is much more powerful than AWK. But from other side it’s astonishing that such succinct and clear language as AWK was turned into a monstrosity called Perl.

Therefore, for me when it goes to text processing/manipulation I prefer AWK much better than Perl. Cleaner syntax, better portability, absolute minimalism. Now, thanks to GoAWK [0] CSV-processing with AWK is a piece of cake too.

I personally see no reason nowadays for me to write any Perl code, but I’m totally fine to use the software written in it.

[0] https://news.ycombinator.com/item?id=31350550

Since AWK is DSL for text processing it can be (and usually is) much more elegant and efficient for (surprise!) text processing tasks, than general purpose languages like Python.

Not long ago I was really fascinated by this example I came across: https://pmitev.github.io/to-awk-or-not/Python_vs_awk/.

There's tons of incompatible dialects. I think that shows the problem with what you're saying.

To my knowledge the major dialects in use are:

- One True Awk (aka bwk) (https://github.com/onetrueawk/awk) - this one is bundled in all *BSD/macOS

- Gawk (https://www.gnu.org/software/gawk/) - this one is bundled in most Linux

- mawk (https://invisible-island.net/mawk/) - bundled in some Linux distros (?), known as the fastest byte-code compiled implementation.

All three have very good compatibility, but Gawk is super-set over POSIX standard. I have some evidence here, since I regularly test [1] against these implementations and even some others, like GoAWK.

[1] https://github.com/xonixx/makesure/actions/runs/1830978431

I would kindly disagree here.

I myself been dedidacted Python lover in past for many years now came to a conclusion that what can be scripted with AWK, should be scripted in AWK (over Python, Ruby, Perl, etc.). I'm not saying that you should write big apps though, but for small scripts AWK is absolutely fine alternative to major scripting languages with lots of benefits. Been universally available (as part of POSIX) and very compliant (language standard is almost unchanged for over 30 years now). As they say: "Good programmer chooses the most powerful tool for the job, best programmer chooses the least powerful tool for the job". Also see [1].

There is absolutely nothing wrong in learning AWK. It's very small language you can grasp fully in hours or days, and be sure you know it all, since it's very unlikely it chanages any time soon. Besides the classical book [2] by A., W., K. is absolute pleasure to read. Amazing, but it's still totally relevant, despite been published in 1988.

Shameless plug. I'm the author of a task/command runner [3] implemented almost 100% in AWK and I still think this was perfect choice of a language for this project.

[1] https://en.wikipedia.org/wiki/Rule_of_least_power

[2] https://archive.org/download/pdfy-MgN0H1joIoDVoIC7/The_AWK_P...

[3] https://github.com/xonixx/makesure

Idempotence is achievable elegantly with makesure tool [1] using @reached_if directive [2]. Full disclosure - I’m the author of the tool.

[1] https://github.com/xonixx/makesure

[2] https://github.com/xonixx/makesure#reached_if

There is Awk - fascinating mini-language almost unchanged for decades. Therefore very portable. You can learn it once and be sure you know it all.