Show HN: Metapict – TikZ like figures using Racket | Hacker News Reader

Show HN: Metapict – TikZ like figures using Racket

soegaard.github.io

71 pointssoegaard16 comments

We put Show HN on the title because the submitter is the author of this (cool!) project. Related URLs:

https://github.com/soegaard/metapict - code

https://soegaard.github.io/docs/metapict/metapict.html - docs

Remarkable that you can replicate tikz with what looks like more concise and readable code (i say "looks like" cause i have no experience with parenthesis-loving languages :-)

One advantage of tikz though is that you can directlt embed it in latex.

> Remarkable that you can replicate tikz with what looks like more concise and readable code (i say "looks like" cause i have no experience with parenthesis-loving languages :-)

Thanks for the compliment. It's not my first Racket macro :-)

> One advantage of tikz though is that you can directlt embed it in latex.

Its greatest strength and greatest weakness at the same time.

The "blog" consists of detailed examples of how to draw 2d figures using Metapict. Metapict is what I imagine Metapost and Tikz would have looked like, if they were written in Racket.

Sometimes I feel like the biggest "wrong turn" I made in my life was the discontinuation of Racket as my go to language.

I never quite made it to the perfect fluency I had in Ruby. And it lacks some of the raw power I feel when I write Rust. Still, perhaps it could be a good time to return.

It's hard to maintain perfect fluency in many languages at once, and it's also very valuable to learn multiple languages, so I'm somewhat torn.

Just looking at the clarity and brevity of these example drawings brings me back a sense of calm and collectedness I don't often feel anymore.

I've noticed a variation on this too, except I stuck with it too long. Scheme (once built out, like Racket and others have done) is easily one of the best languages, on technical merits, but I'm not using it lately, while aware of what I'm missing...

Since using Scheme/Racket heavily, I've used three major popular languages, and each has a lot of painful problems, that feel like regressions:

* Major Language X was obviously intended for much simpler needs, but kept getting extended to get closer to what was already known from other languages when it was created, the official docs often seem written as if with no awareness of a reader, and a Web search results are mostly maddening SEO by people who don't seem to understand much about the subject matter.

* Major Language Y has some merits, but a key DSL seems fundamentally wrong in execution, like a kludge that doesn't reflect what was already known decades ago, and they basically just didn't do documentation yet, and I had to do heroics to work around implementation and design flakiness in a key framework and an important library.

* Major Language Z actually shows a lot of positive signs, including cross-pollination in many small details, but at some point there was a breakdown of coherent design for a while, and some poor decisions made, which would be a lot easier to look past were it legacy from much longer ago than it was.

That said, Scheme and Racket also have their technical and community drawbacks. Also, more pragmatically, too often lately I've seen hiring situations where they really-really need some engineering magic done... but they're hung up on filtering resumes for ThisYearsPopularFramework2, and believe that's the most important qualification. So, lately, I also use the currently popular tools, even when it's incarnation #23 of something I've seen before (not done as well #4, #5, #7, and #16), and make it work despite/because I'm painfully aware of the weaknesses.

Hm, that may contain Go, Rust and C#?

I suppose it tells us something, when the same criticisms could apply to a lot of language platforms. :)

(I was speaking of specific language platforms, but not calling them out by name makes it easier to be candid about the kinds of problems I saw, which was the only point here.)

I have used Racket as my “go to” language a few times, perhaps for a month or two each time. For practical reasons, mostly which programming languages people are willing to pay me to use, I go back to Common Lisp or Python.

This blog material reminds me of the Beautiful Racket [1] writing system, even though it is of course different.

[1] https://beautifulracket.com/

> This blog material reminds me of the Beautiful Racket [1] writing system, even though it is of course different.

You have a sharp eye. Beatiful Racket was written with Butterick's own Pollen system. The Pollen system was inspired by `Scribble` which is used to produce the Racket documentation (among other things).

I am using my own `mathscribble` (better name is needed) also inspired by Scribble. I am using a different representation of both the decoded input text and of the produced html. It is geared towards texts with mathematical contents.

All systems use the at-expr syntax for the input.

I'd love to learn Racket. Only read a couple of things on it. I wonder if we could use ChatGPT to translate Ruby programs into Racket ones.

Metapict has come in very handy to generate SVGs for use with my AxiDraw plotter. Love seeing blog posts like this with pro-tips on how to compose the functions. I always learn a lot from practical examples.

I'd like to get into Racket as a Scheme user, but I have difficulty taking it seriously when its startup times are still so high:

  $ time racket -e '(display "hello")'
  hello
  real 0m0.721s
  user 0m0.598s
  sys 0m0.119s

This basically rules out using it for command line scripts, which is a major class of uses for me.

That command uses `#lang racket` which means it loads an awful lot of modules. Try an example with `racket/base` instead.

    $ time racket ~/tmp/bd.rkt
    hello

Times:

    0.12s user 0.04s system 94% cpu 0.176 total

The file used

    $ cat ~/tmp/bd.rkt    
    #lang racket/base
    (displayln "hello")

Also use `raco make` to compile your scripts before running them.

That gets things down to 0.183s, which is certainly an improvement. But Python manages 0.033s and Guile manages 0.022s, neither of which need a precompile step. I feel like Racket needs to spend some time optimising this.

My understanding is that Racket has been doing a lot of work on overhauling its interpreter and internals recently, so I'm hopeful this will improve somehow, but it's unclear to me if they're aware of this issue or consider it a problem.

The compiler was rewritten and now Chez Scheme is used as part of the pipeline from Racket to assembler. With respect to improving the startup time, the low hanging fruit has already been picked.

If I understand correctly part of the problem is the number of modules that needs to be loaded from disk at startup. On my computer the first run is slower than subsequent runs due to caching. Maybe an "compile several modules into a single file" approach might improve things - but it's not trivial project.

Reply on news.ycombinator.com