We look at three remarkable resources, today, though not all are remarkable in the same (or good) ways.

A Remarkably Mediocre Song

The old school “infosec hermit” in me tends to only let a tiny fraction of the corpus of personal human preferences be known to the cold, cruel world we all inhabit. Sharing such details is made difficult primarly due to having been trained to use all the “tells” and leaked predilections of other humans against said humans (for the side of the angels). So, while you likely know I use a Peloton for exercise, like using Apple products (but kind of hate Apple as a company), wish I could have met Peter Falk when he was alive, and am enthralled with The Expanse novels, you probably have no idea, say, what types of music I listen to.

Well, you get a peek at that last category in today's Drop since I can bridge a ChatGPT pseudo-smackdown section with one of my favorite bands of all time, The Decemberists. During the height of the COVID lockdowns, it was delightful seeing so many folks finally latching on to sea shanties (a strong suit of this band), and I could listen to their creative sesquipedalian folk twangs pretty much all day.

Colin Meloy is The Decemberists's lead signer/songwriter and he has a pretty cool Substack, and recently posted his experience having everyone's favorite AI punching bag write a song for him. Here's how it starts:

Imagine a future, if you will, in which us songwriters don’t have to sit around in our drafty garrets, plumbing the depths of our pain and misery for the public’s entertainment and enjoyment. A future where creative inspiration is at our very fingertips, right past our keyboards on our laptop screens, where we creatives can sit back and let robots do all the heavy emotional lifting for us.

Well, ladies and gentlemen, that future is now.

He went on to ask ChatGPT to “Write me a song that Colin Meloy of the Decemberists might have written.”

ChatGPT obliged and did, in fact, compose a Decemberists-y song, replite with sailors and lighthouses and battles at sea.

The world's most expensive AI automaton only, initially, dropped some verses on Sir Malloy, so he asked it to also whip up some chords, which it did! This caused him to remark:

Not only can this AI write out a convincing-looking song lyric, but it can put together chords that, at least at first glance, kind of work. I mean, the verse progression’s got the classic pattern: the root chord, the 4 and the 5. It’s got the minor fall and the major lift.

It even obeyed when he asked it to pair the chord progressions with the lyrics.

However, the results were as mediocre as the AI-generated title (which was “Sailor's Song”).

For the record, this is a remarkably mediocre song. I wouldn’t say it’s a terrible song, though it really flirts with terribleness. No, it’s got some basics down: it (mostly) rhymes in all the right places (though that last couplet is a real doozy), it uses a chord progression (I-V-vi-IV) that is enshrined in more hits from the western pop canon than I care to count. But I think you’d agree that there’s something lacking, beyond the little obvious glitches — the missed or repeated rhymes, the grammatical mistakes, the overall banality of the content.

I'll let you hit up the (free) post for the full conclusion and the song itself, but I'll spend a few blather credits before closing up this section.

At one point in the post, Colin called ChatGPT “the creator”, and kind of stuck with that framing. ChatGPT does not really “create”. I'm 100% on board with the (derogatory) “stochastic parrot” term folks have coined for this and other, similar models. It does an OK job guessing at what bits and phrases likely belong together, but it's not creating. That does not mean what it generates is useless. In fact, though Colin didn't take the thought to a conclusion, I think ChatGPT (and its visually diffused counterparts) does and will have a place to help true creatives create, just like many other technological advancements before it.

To steal a bit from Colin's closer: alas, alack, looks like I’ll be writing my own Drops for the foreseeable future…

Share

A Remarkable Future For Document Machinations

If you do much work in the Markdown format, there is no way you do not know about Pandoc [GH]. While it humbly calls itself a mere “universal document converter”, it is that and so much more. It is used daily — usually behind the scenes — in more “data science” workflows than even the best data scientist can work up a probabilistic model for. It powers blogs, publications, presentations, and critical business processes in enterprises across the globe.

This highly customizable and extendable tool set is powered by the Haskell language and ecosystem. Haskell has been around in various forms since 1990 (“after thirty-three years of deployments and nonstop 24/7 workloads, look as good as Haskell you will not”), and was named after a clever logician. The language has pretty grokable syntax as seen in this familiar “hey world”:

module Main (main) where 
main :: IO ()
main = putStrLn "Hey, World. 'Sup?"

The core implementation is known as the Glasgow Haskell Compile (GHC), and I remember building Haskell from source (back in the day) and also building Pandoc with it. On those older systems, this was neither a quick nor painless exercise, but modern compute environments and Haskell pair well together.

GHC supports multiple backend code generators. As they note, this is the part of the compiler responsible for taking the last intermediate representation that GHC uses (a form called Cmm that is a simple, C like language) and compiling it to executable code. GHC can crank out executables on its own (hi Pandoc!), generate the intermediary code for LLVM to process, even chunk out C and JavaScript.

Tweag is a software innovation lab that “helps deep tech startups quickly scale their engineering performance and execute on high-risk, high-reward projects.” Those clever folks have been working on a GHC WebAssembly backend, and has successfully passed the merge gauntlet!

There are some very neat aspects of this work, which I'll let Tweag describe:

[GHC wasm output] doesn’t need any companion JavaScript code, and runs on a variety of wasm engines that support wasi, including but not limited to: wasmtime, wasmedge, wasmer and wasm3. Compared to the legacy asterius project, there are also a few other serious benefits:

• The killer feature is being able to use GHC’s own RTS code for garbage collection and other runtime functionality. The GHC RTS is way more robust, feature-complete and performant than asterius’s legacy JavaScript runtime. Lots of Haskell features that never worked in asterius (e.g. STM or profiling) now work out of the box.

• It has proper support for compiling and linking C/C++ code. Terms and conditions apply here, but there’s still a high chance the cbits in your packages will work out of the box.

• Since it uses LLVM for linking, the linking step is orders of magnitudes faster than asterius, which uses a custom object format and linking logic.

• GHC CI tests a program that uses the GHC API to parse a Haskell module. ghc is a big package and depends on everything in the boot libraries, so even having only a part of GHC frontend working in pure wasm is already pretty cool, and it certainly provides more assurance than a simple “hello world”. asterius never had ghc in its boot libraries.

Given the other backend outputs, it should be no surprise to anyone somewhat familiar with WASM that there already is a Pandoc wasm port [GH].

Tweag's work means that pandoc will be able to run on every modern/popular wasm runtime. Additional work is underway to incorporate functionality from one of Tweag's previous projects; this includes adding rich JavaScript FFI support, “allowing one to import JavaScript functions into Haskell, pass arbitrary JavaScript values as first-class Haskell values, and export Haskell functions to be called by JavaScript. Furthermore, the JavaScript async functions worked naturally with the Haskell threading system, so that when a Haskell thread is blocked on an async JavaScript call, the runtime executes other threads instead of blocking completely.”

Once that is in place, Pandoc in the browser (or any WASM context) will open up tons of possibilities and likely fuel some serious innovation.

If you live in the Pandoc world, keep an eye on this, and start pondering what you might be able to do with “Pandoc everywhere”.

reMarkable (2)

The previous sections were a bit long. While I’m not shilling anything in this one (nor will I ever do such a thing), it seemed appropriate — given the theme — to include a link to an, er, remarkable tablet. Now, you may have heard of it already, but I’m including it here as part of the aforementioned “no assumptions” rule.

The reMarkable 2 is a “digital notebook as close to paper as it gets”. It works for writing (standard or cursive), drawing and just reading (if you have an open format document). The company cares about FOSS and has a vibrant open-source community that have come up with very clever hacks/extensions, such as syncing with Notion (and plenty of other services). The company-proper is also about to launch a desktop ↔ tablet companion app/service of their own.

Sadly, meatspace writing/drawing instruments of any kind are nigh useless to these hands that literally failed kindergarten handwriting class (if there are any Kindergarten teachers in the mix, here, mebbe don't shame your students in the same way?).

If you're seeking a cheaper alternative to Apple or Microsoft offerings, and want more functionality than a Kobo or Kindle, this tablet is definitely something to consider.

FIN

In other news: the DuckDB 0.7.0 Preview Release is also pretty darned spiffy.

And, it turns out that my sensitive sensibilities might be the root cause as to why I write such terrible code. ☮

Leave a comment