Re: some 50 possible next topics to focus on for personal projects

gut reactions:

> * automatic dependency-driven recomputation
>
>     Summary: build a prototype of a rearchitecture of the personal
>     computer platform around the caching of computational results, as
>     described in
>     <http://lists.canonical.org/pipermail/kragen-tol/2012-July/ =

> 000963.html>.

As you mention (and as Bill Wadge's recent blog entries on Lucid  =

confirm) the biggest problem here seems to be cache eviction.
I've had some success in simplifying systems (which also seems to  =

have been the EE's approach to making systems faster than we software  =

people make them slower) by attempting to maintain clear phase  =

separations between stateful and stateless parts, minimizing the  =

former.  BCPL, the predecessor to C, had a VALOF/RESULTIS construct  =

that encapsulated stateful computation; this was thrown out in the  =

ruthless simplification towards C, but arguably AVRs are much closer  =

to what Thompson and Ritchie had to squeeze into than most modern  =

embedded environments, let alone phones.
Various database approaches may also be informative, as their basic  =

problem is computing with a cache that may be suddenly emptied at  =

inopportune moments.

> * free software is like owning your own home

=93Making the landlord and the tenant the same person has certain  =

advantages, as that the tenant pays no rent, while the landlord does  =

a little work.=94 - GK Chesterton

> * the user interface as a real-time program

Back in the day, we had "terminals" that ran independently of the  =

host; the difficulty here would seem to be providing a UI that is  =

*usefully* responsive when the underlying platform has gone into the  =

weeds.

> * a language for real-time programming

It seems reasonable that one can mechanically compile down an  =

algorithm written at a high level into a "machine" that does a fixed  =

amount of work/uses a fixed amount of space for each turn of the  =

crank.  Indeed, we do it all the time; the difficulty seems to be in  =

finding the boundary: targeting either the highest level machine that  =

sympathizes with the hardware, or the lowest level machine that  =

retains the advantages of software.  Matt Might looks like he's doing  =

work in this area.

> * natural language is a digital phenomenon

cf Hofstadter's "aperiodic crystal", which he seems to have nabbed  =

from Schr=F6dinger.
There's an abundance of work in the literature, mostly dealing with  =

the differences in the A2D between native- and acquired-language  =

speakers.

> * the colectivos app

One area where Switzerland's lower reliance on competition as a  =

unique regulatory force shines is the transit network.  When I toured  =

the supercomputer center in the italian part, they were computing a  =

schedule for the next year, subject to the constraints that it should  =

maximize smooth interconnection between the different companies, and  =

minimize changes that might disrupt the passengers' schedules.  As a  =

convenient side effect, I can send an SMS with two swiss addresses,  =

and get the next few connections between them.  In well-served areas,  =

this changes transit from something which needs to be planned to  =

something you can check shortly before leaving.

> * "pick activism tactics as if they might work"

Heh.  I'd say the most common failure for people attempting to deal  =

with horses is that they try to relate with them as if they were  =

common members of a high school clique, and not as members of not  =

only different cultures, but different species. Could it be that poor  =

activism is driven by people attempting to apply tactics that (seem  =

to) work in their personal lives, but don't scale (or even anti- =

scale) to broader contexts?

> * matchscheme
>
>     Summary: a Scheme that gets OO and conditionals from built-in
>     pattern-matching, in email with Darius Bacon.  Benefit: an
>     interesting bottom layer for a language stack.

Certainly a low layer; arguably there could be layers even lower.
This is definitely on the lines of what I have been playing around  =

with recently; there's a nice duality between the world of  =

expressions (where we synthesize an unnamed value from a bunch of  =

named ones) and the world of patterns (where we analyze an unnamed  =

value into a bunch of named ones)
Even in the very early days of languages (say the METAII period) you  =

see that people were groping towards this duality: the widespread  =

introduction of short-circuit logical operators in boolean contexts  =

are an example of feeling the need without seeing the reason.  I  =

believe Wirth's books (at least with the benefit of hindsight) have  =

distinct chapters on compiling expressions versus patterns.
I'm not sure, and it's a little difficult to ask now, but one  =

possible rationale for Dijkstra's Guarded Commands is that they are  =

not only amenable to proof, but the nondeterminism means they're also  =

amenable to instantiation in either hardware or software. (cf  =

"language for real-time programming")
If one is interested in how early these ideas entered (and were  =

subsequently ignored in) the literature, cf Burstall, "Proving  =

properties of programs by structural induction", Computer Journal Vol. =

12 #1 (Feb. 1969) pp. 41-48

> * backtracking HTML templating

I've since had reason to fix the kludge in my reply to one of your  =

earlier HTML templating mails, albeit in a different context.  Let me  =

know if it'd be useful to dig up (and apply, as I don't have a  =

"parser generator with code reuse" :-) the fix.

> * radix-sorting rational numbers
>
>     Summary: write up my algorithm for representing rational numbers
>     so they can be radix-sorted

If this algorithm allowed one to radix-sort general quotient types  =

(unevaluated terms) with less computation than first reducing to  =

canonical terms, then sorting, it might be more valuable than you  =

think.  But that seems like a big "if".

HTH
-Dave

-- =

To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss