How to design co-programs
patternsinfp.wordpress.com
How to design co-programs
1–10 of 23 posts
Re: How to design co-programs
#2Ads on the blog but you’re too cheap to move to your own TLD. I don’t know why I find great humor in this, but the advertisement “Casinos hate this site...” made me laugh (and hate your site -> and swipe back to HN).
Sorry, I’m away from my house and so there’s no pi-hole enabled.
Re: How to design co-programs
#3Ads on the blog but you’re too cheap to move to your own TLD. I don’t know why I find great humor in this, but the advertisement “Casinos hate this site...” made me laugh (and hate your site -> and swipe back to HN). Sorry, I’m away from my house and so there’s no pi-hole enabled.
As a follow-up, I think the humor is that I imagine this blog might have valuable information, but you’re turning off your target audience with low-brow ads.
Re: How to design co-programs
#4The intermediate representation of the binary tree for QuickSort in this article was a “eureka” moment for me. I think algorithm and data structure curriculums should take this approach.
Re: How to design co-programs
#5Ads on the blog but you’re too cheap to move to your own TLD. I don’t know why I find great humor in this, but the advertisement “Casinos hate this site...” made me laugh (and hate your site -> and swipe back to HN). Sorry, I’m away from my house and so there’s no pi-hole enabled.
I'm pretty sure the ads are not put up by the author by WordPress.com. According to their pricing page[1], they "sometimes" display ads on blogs to cover costs.
Re: How to design co-programs
#6A Mathematical Theory of Codesign: https://arxiv.org/pdf/1512.08055.pdf
Re: How to design co-programs
#7The intermediate representation of the binary tree for QuickSort in this article was a “eureka” moment for me. I think algorithm and data structure curriculums should take this approach.
No kidding. This is very nice. I might be taking some liberties here, but the point about the shape of the output driving the shape of the program reminds me of using schema information in SQL (think of declared foreign keys) to generate queries: the schema tells you the shape of the data in more ways than just tables and columns, and this in turn tells you about the queries you might want.
If you enrich a relational schema with more metadata, then you can generate even more queries. Think of declaring the set of all relations that define authorization data, not just group memberships, but access controls that refer to groups, define ownership, and so on.
So, for example, 'give me all the authorization-relevant entities "to the right" of this entity' might be a query that, given enough schema metadata, can generate a much more complex SQL query. But that abstract query itself becomes an obvious query given the shape of the data (i.e., the schema). A more concrete example is "what can this user do?" and "who can do what to this resource?", "what groups is this user a member of?", "what are all the members of this group?" (note: these are not trivial if groups nest) which are instantiations of "what are all the entities to the {left, right} of this entity, using the set {name} of relations?".
In terms of SQL these are all JOINs or LEFT JOINs (depending on declared relation NULLability, or relation cardinalities), with RECURSIVE queries using UNION (not UNION ALL, to avoid infinite recursion in the presence of circular relations) for "nesting" relations (from a table to itself, perhaps crossing relations on other tables in the process). SQL is extremely powerful and expressive, but we can make these queries pithier and more obvious with a more abstract language that takes advantage of schema metadata. Indeed, graph databases are such a language.
SQL needs a richer schema definition language (extensions will do) by which to formally describe more of the shape of the data.
Re: How to design co-programs
#8Funny how the author gave this talk in honor of Felleisen's on his 60th birthday. "Hi, to honor you I'll talk about how one of your better known works is incomplete and only shows half of the picture".
I started reading HTDP long ago but at the time I made the huge mistake of taking a detour to learn Racket, and later Scheme... HTDP provides small languages just to save students from the herculean effort of having to learn a whole programming language and environment. Way to miss the point.
Anyway, there's some associated documentation on the Racket site about a library called "2htdp/universe" [1]. The architecture described is very close to the so called "ELM architecture" [2] or even Redux [3]. Probably (maybe?) there's no relation though, since coming to this architecture appears to be really natural when working with functional programming languages.
1: https://docs.racket-lang.org/teachpack/2htdpuniverse.html#%2...
Re: How to design co-programs
#9Funny how the author gave this talk in honor of Felleisen's on his 60th birthday. "Hi, to honor you I'll talk about how one of your better known works is incomplete and only shows half of the picture". I started reading HTDP long ago but at the time I made the huge mistake of taking a detour to learn Racket, and later Scheme... HTDP provides small languages just to save students from the herculean effort of having to…
> "Hi, to honor you I'll talk about how one of your better known works is incomplete and only shows half of the picture".
...or, you know, that old "standing on the shoulders of giants" thing.
Re: How to design co-programs
#10The intermediate representation of the binary tree for QuickSort in this article was a “eureka” moment for me. I think algorithm and data structure curriculums should take this approach.
Something I've seen in most Xavier Leroy (of Ocaml) slides.
It makes things so clear to me.