Ben Hoyt, a software developer, writes about Python, Go, AWK, performance comparisons, security practices and small-scale web design.
HN commenters engage with his word-counting benchmarks, one of whom criticizes the problem constraints as weak benchmarking, and with his AWK interpreter and other posts.
Often whole program generation in a prog.lang (& ecosystem!) that you already know can substitute for a new prog.lang. Python even has eval. You may be interested in: https://github.com/c-blake/bu/blob/main/doc/rp.md
You can actually get pretty far depending upon boundaries with the always implicit command-option language (when launched from the shell language, anyway). For example, Ben's example can be adapted to:
rp -m^\[A-Za-z\] 'echo nr," ",s[1]'
which is only 5 more characters and only 3 more key downs (less SHIFT-ing) than the space-optimized version of his `awk`.
{ key downs are, of course, just a start to a deep rabbit hole on HCI ergonometrics ending in heatmaps, finger reach/strain/keyboard layouts, left-right hand switching dynamics, etc., but they seem the most portable idea. }
Nim is not Python - it is actually a bit more concise while also being statically typed and can be compiled to code which runs as fast as the best C/C++ (at more expense than one usually wants for 1-liner interactive iteration, though unless you need to test on very large data). That said, I find it roughly "as easy" to enter `rp` commands as `awk`.
If doing this in Python tickles your fancy, Ben actually has an interesting on these ideas: https://benhoyt.com/writings/prig/ you might also find interesting.
EDIT: and while I was typing in a sibling @networked mentions a bunch more examples, but I think my comment here remains non-redundant. I'm not sure even one of those…
Using C would tie the run-time/compiled implimentation to specific set of platforms/hardware. aka each hardware platform would have it's own specific compiled C quirks/issues to deal with. aka big endian / little endian; 16/32 bit; etc.
A virutal machine is typically what is used when not targeting an actual machine/hardware. aka runtime environment.
Transpiling the language to java or webassembly would provide for wider range of hardware/platform support without requiring specific knowlege compiled C platform quirks -- big endian/little endian machine. Although, transpiling to awk with system() & named pipes/netcat, perl, javascript, and/or creating an excell 16 bit cpu[7]/virtual pc could work too.
"1st class"[0] concept implies there are no restrictions on where given language construct/concept can be used. for example: which side of the assignment operator a programming language concept/construct can be used.
"type inference"[1] is typically an interpreted/virtual machine language feature. aka C++ run time type inference (rtti) is done via instance of a virtual machine.
namespace / scoping is important aspect of modularity / avoiding code coloring issues / automatic translation between formats / 'reactivity'[2]
XL[3], oils/ysh[4], unicorn[5]/unicorn.js[6], awkgo[8], pawk[9] might be of interest.
Would suggest using ' JS/Ocaml/Rust' implimented/running under python (and/or bindings to ocaml/rust).
A related example/demo of this approach would be awk running…
> recursively filter all POST/GET input for example). You can do it in the controller with filter_input etc...
This is what many do and it's extremely bad practice. I wrote a pretty detailed comment here on HN explaining this before but can't find it easily now so here's a similar looking article I found instead: https://benhoyt.com/writings/dont-sanitize-do-escape/
it doesn't need to be a part of the framework, I'd like to leave it up to the developers
You're right, "need" is a strong word, it's a suggestion for a useful feature. Leaving it up to developers does in practice tend to lead to insecure code most of the time though: it can sometimes be nice to help developers write better apps.
If you need raw html output the best approach is to batch DOMSanitize it and cache it to be served raw: in these cases it's usually an exception so turning output escaping off for 1 or 2 exceptions isn't a huge ask (and focused the scope of your attack surface area when you're auditing).
There is a whole lot more to this than just whether content creators or publishes should get paid, and whether there should be ad blockers (and whether they get paid).
There are people who have been fed up by this because they remembered how the web was like in the late 90s, before social media pushes became the dominant experience. People have formulated ideas around the Small Web (https://benhoyt.com/writings/the-small-web-is-beautiful/), or even opted out of the browser ecosystem entirely with Gemini (https://geminiprotocol.net/) or keep the torch burning for Gopher (https://hackaday.com/2021/09/28/gopher-the-competing-standard-to-www-in-the-90s-is-still-worth-checking-out/)
From there, it is also a short hop and skip away to folks working on local-first (https://localfirstweb.dev/), decentralization, collapse computing (https://100r.co/site/philosophy.html and http://collapseos.org/)
This is the article I link my developers whenever I see them making this mistake "Don’t try to sanitize input. Escape output." https://benhoyt.com/writings/dont-sanitize-do-escape/
Its been fairly effective at making them realize the fundamental mistake they are making. Quoting the key part:
> The only code that knows what characters are dangerous is the code that’s outputting in a given context.
> So the better approach is to store whatever name the user enters verbatim, and then have the template system HTML-escape when outputting HTML, or properly escape JSON when outputting JSON and JavaScript.
> And of course use your SQL engine’s parameterized query features so it properly escapes variables when building SQL
One of my favourite computer games was written in Turbo Pascal: ZZT, written by Tim Sweeney of Epic Megagames. It was a quircky text-mode game with puzzles, shooting, and so on. It had a built-in game editor that came even with the free shareware version, and it even had a little programming language called ZZT-OOP.
ZZT's original source code was lost. Years later, Adrian Siekierka painstakingly reverse-engineered the original Pascal code till -- when compiled with the original version of Turbo Pascal -- produced a byte-for-byte identical executable. Amazing! Read more:
- https://blog.asie.pl/2020/08/reconstructing-zzt/
- https://news.ycombinator.com/item?id=22609474
- https://benhoyt.com/writings/zzt-in-go/