Carp: A statically typed Lisp, without a GC, for real-time applications.

This looks rather good.
Carp: A statically typed lisp, without a GC, for real-time applications.
It is what it says. It’s a Lisp, with some inspiration from Clojure in terms of syntax, that’s designed for writing fast native code like games and … (w00t!) audio applications. Etc.
It actually compiles into C.
It takes some syntactic inspiration from Clojure (so it looks like Clojure and Clojure editors should handle it fine)
But it also takes inspiration from ML.
It has an ML-style type-system with type-inference. And the best way of representing type information in a Lisp program that I’ve seen.
Using a form called “the“.
So you write something like
[cc lang=”clojure”]
(the Int sexp)
This declares that the sexp needs to evaluate to the type Int.
Because it has type-inference, the type of much of the rest of the code can be deduced just from a few of these explicit specifications.
Carp also (allegedly) has an ML style module system. I have no idea what that means because I’ve not used ML. But it is something I hear a lot of people raving about.
However, Carp is a low-level language designed as a C-level language. It has the usual Lisp-style dynamic lists, but only for use at compile-time. It also has macros executed at compile-time.
At run-time code, you only have more primitive types : Ints, Floats, etc. Plus data-structures including Arrays, some kind of map / dictionary, structs and Sum Types. So you get the power and type-safety of ML / Haskell algebraic data-types but at a C-level without depending on heap allocation.
It also has some kind of Rust-like “ownership semantics” for pointers. I haven’t quite understood this yet, but again it looks sensible.
In all, this looks a really tasteful and well thought out combination of good ideas from a number of places (much like Clojure itself) that will add up to a much nicer than C experience for writing the sorts of things that I usually write with C.
All I’ve done so far is installed it and run a couple of examples, but I can well see myself trying to use this to do the coding for some audio / VCVRack stuff.

Tablets for Content Creation

Source: Thread by @interstar: @msimoni @coreload I think the tablet COULD be a perfectly good device for content creation if people would just do the damned UI design wor…
Another part of the thread. Manuel Simoni (@msimoni) says :

But I don’t want a file system, I want Xanadu. But it should still be editable through a WIMP/desktop UI.

I reply :
Sure. We all want / work towards Xanadu 🙂 Though at the very least I want mine to run on a tablet, have swipe-able cards like Material Design, and allow me to write Prolog-like rules for making automatic inferences that generate new information / views.

Against Direct Manipulation

I’m debating on Twitter about Direct Manipulation.

Here’s the first part of my discussion unrolled. I’m asked why I think the Desktop Metaphor has held us back. My response in 6 tweets. (Note that there’s a lot more good discussion in further pushback I get)


Complicated for Twitter. Here’s what I think in summary.
Computing is about using language to tell computers to do things. Language enables grammatical composition and ever increasing levels of abstraction and expressivity \1
The great mistake and delusion in computer history, of which the desktop metaphor is just one major example, is “direct manipulation”.
People seem to love it and always fantasize about more of it … \2
But with DM you switch from finding more and more elegant ways to TELL the computer to do stuff, to just “doing it yourself”
And once there’s a DM metaphor for a task, rather than a linguistic instruction, it gets locked-in and evolution grinds to a halt. \3
Basically every time DM came to a paradigm of computing, the vocabulary froze at that point and at that level of abstraction.
Desktop metaphor for launching applications and WYSIWYG word-processors looks like the 70s. \4
File systems look like the Mac finder from the 80s.
Spreadsheets started as a promising mix of visual and linguistic, but have DEVOLVED into mere grid-drawing GUIs.
IDEs haven’t even changed their menu layout since the 90s \5
All progress in computer science depends on maintaining that gap between you telling the computer to do something, and what the computer does.
All the force multipliers live in that gap. Close it and progress stops. \end

Browsers Accessing the Local Disk

After writing Why isn’t browser based programming or browser based IDEs more popular? – Smart Disorganized I want to emphasize and ask again.
Why aren’t the browser makers offering us a way for web-apps to read and write from the local disk?
I know that it’s a mega security issue. But it should be possible to wrap it up. So that only web-apps opened in a special mode. Which ask three times and need you to sign in blood etc. etc. (Or better, add the public key of the web-app to your browser) get to write to the local disk.
But if just one browser maker made that happen, it would be the biggest revolution in application software development since the invention of the mobile app.
Suddenly all web-delivered applications would compete on a level playing field with locally installed apps. Browsers would be more important than ever. Surely there is a huge incentive for browser makers to do this.

Why isn’t browser based programming or browser based IDEs more popular?

My Quora answer :

Basically because most programmers use a bunch of other tools that are local, on their hard disk. These include compilers, libraries, source control, unit-testing frameworks, CI/CD pipelines etc. etc.

And browsers, because of their security model, are really bad at talking to the local disk.

So, if you want to use a browser-based / web-IDE all your other tools and resources have to be in the cloud too.

And the problem with that is you can’t mix and match your own custom configuration of those resources. You are basically stuck with the ones that your cloud IDE offers. Obviously most cloud IDEs are for-profit companies, and few of them have the resources to replicate the best of breed other tools you are using. Or to successfully integrate all the possible third-party options within their cloud.

So … cloud development IDEs should be a really obvious and cool win.

But … they aren’t because of the problem of bridging the cloud and the local disk.

I often wonder why browser makers haven’t solved this problem. Eg. why not have a special “mode” – just like “incognito mode” is a special mode – that allows web-applications to actually read and write to the disk just as native apps do. Of course it would need some extra security etc. But if they had it, we could do wonderful applications in the browser to compete with everything on the local file system. Including fantastic IDEs.

But until we bridge the cloud-local gap, web IDEs are stuck with whatever resources the cloud offers but also the downsides of latency, limited tools, less control and flexibility for the users etc.

Source: Why isn’t browser based programming or browser based IDEs more popular? Why do you not like or use one? – Quora

Backlinks in Cardigan Bay

People seem to be very excited about Roam Research at the moment. I’m sure it has many qualities. But I’m slightly surprised to realize that one thing that fans seem to find very useful (and almost miraculous) is the automatic back-linking. Ie, the ability to see what pages link to the page you are currently on.

Bill Seitz has always been a fan of this feature, ensuring that it’s prominent on his WebSeitz engine. While, I confess, I’ve always thought that links that people bother to make explicitly are more interesting and should be valued more highly than links that are implicit.

So, my current Python-based ThoughtStorms engine, following on from UseMod etc. lets you search for “pages that reference this one” with the usual text search, simply by clicking the page name, but it doesn’t automatically give backlinks to you on each page.

But on ThoughtStorms you’ll see I do often explicitly put something like  “Context : BlahPage, AnotherPage” at the top of pages where I think context is important.

Nevertheless, automatic backlinks are clearly the fashion. And as I’m working on Cardigan-bay: A new wiki engine in Clojure I figured I might as well add this feature.

So, one of the main ideas in Cardigan Bay is that it keeps an internal database of meta-data about the wiki, including which pages link to which, using core.logic, Clojure’s standard miniKanren library.

So adding the backlinks feature is as simple as adding a core.logic query to this database.

(defn links-to [target]
  (pldb/with-db @facts
    (logic/run* [p q]
      (link p q)
      (page p)
      (page q)
      (logic/== target q)

That’s basically it. The logic query tests that there’s a link relation between p and q, that both p and q are actual  existing pages, and that q is equal to the target argument to the Clojure function.

This is pretty obvious and straightforward. So then I just create a card containing this data and attach it automatically to each page.

Took basically less than an hour to write the whole thing.

And if you get the source from GitHub, it’s now there.

However, right now this is fine for small wikis with a few pages. On the actual ThoughtStorms data (as you see in the screen shot above), which has over 4000 pages and an order of magnitude more links, it’s way too slow. So I’m going to have to figure out how (and more importantly, where) I’m going to cache the results. And when I have to recalculate them, etc.

Nevertheless, automatic backlinks are now added to Cardigan Bay.

Update :

I just did a quick experiment where I took out the (page p) and (page q) clauses from the query. And it’s now much faster.

Testing that the two pages exist doesn’t really matter much. There’s no real way we’re going to get a (link p q) clause if p doesn’t exist. And while there can be broken links ie. a (link p q) where q doesn’t exist, there’s no way we’ll actually be asking the backlink query about a q that doesn’t exist. So no need to join these extra clauses in. That makes this now a single match query on a single relation and much more tractable.

Android : Extended SurfaceView's onDraw() method never called

This has just resolved something I’ve been beating my head against the wall over for the last several days.
Source: android – Extended SurfaceView’s onDraw() method never called – Stack Overflow
WHY? Android?
Why are you so convoluted and perverse?
So … yeah … subclass the SurfaceView class … and you’d expect to be able to custom draw by over-riding its onDraw method, right?
I mean, that’s not an unreasonable assumption to make.
Turns out … no. You have to do some weird black magic. Because by default the onDraw isn’t called for “efficiency” reasons.  The StackOverflow answer sort of explains. But doesn’t really.
Why is Android so convoluted and perverse? Why isn’t there a better API to this?

PS : please take care and stay safe in this time of COVID19. I’m self isolating as far as possible. And I recommend you do too. The more we can slow its spread, the fewer people will die. It’s that simple.

Mind Traffic Control : Site Going Down

I’m going to close down the Mind Traffic Control site on Google App Engine.
The online app has been dead for some time. While I’m very happy with my command-line version which I’m using every day.
The only reason the site is still up on GAE is for any old users to export their data. As that’s been the case for the last couple of years, I’m assuming that if this includes you, you’ve either exported your data or don’t care.
If you haven’t, and still want it, get it soon. (And drop me a comment here) Because you will soon lose the opportunity.
The MTC domain isn’t going anywhere. But will be refocused on my two ongoing projects : the command-line version of MTC and Cardigan Bay. And whatever integration I finally figure out between them.
Both of these projects are written in Clojure. And I’m excited about them.

PS : please take care and stay safe in this time of COVID19. I’m self isolating as far as possible. And I recommend you do too. The more we can slow its spread, the fewer people will die. It’s that simple.

Welcome to Cardigan Bay

Cardigan Bay is my new wiki-engine written in Clojure / ClojureScript.
I’ve been working on it for about three months, and it’s a long way from finished, but now interesting enough for people to start playing with (and hopefully giving me some feedback on).
The goal is for this to be the new engine behind ThoughtStorms, my personal wiki notebooks, and other sites. It will supersede Project ThoughtStorms (the Python codebase), SdiDesk, OWL etc. though hopefully incorporate the best features of those.
It is a major move in my plan to unify much of my software in a single app and code-base. Though it doesn’t, so far, fully merge into Mind Traffic Control.
I’ll be talking more about it over the next few posts. For now, the best overview is the readme page of the project, which you can find on one of these repo-hosting sites :