mariusae
1) Staying on top of my kid's school obligations, homework, etc. School Learning Management Systems are a hot mess, and I use agents to consolidate and collate, to keep track of the homework that has been done, what needs to be done, and even pre-grade homework to give feedback (most of the work is done on digital platforms too). It's been immensely time saving for these kinds of things. 2) Multiple instances of watching things passively: hotel room prices, availability of tickets, finding the best place to sell things online. In general things that require a lot of browsing, collating, and watching. These are the kinds of things that specialized software products could do as well, but with an agent they are just a prompt away, and you get exactly what you want. (More or less.)
Citation needed.
Journey of an industry OSDI paper: global capacity management for 10^6 servers
[1] https://github.com/grailbio/bigslice/ [2] https://github.com/grailbio/bigmachine
Diffuse complexity is exponentially worse than concentrated complexity
I'd encourage you to look at Reflow [1] which takes a different approach: it's entirely self-managing: you run Reflow like you would a normal programming language interpreter ("reflow run myjob.rf") and Reflow creates ephemeral nodes that scale elastically and that tear themselves down, only for the purpose of running the program.
> has extensive observability (monitoring, tracing)
Reflow includes a good amount of observability tools out of the box; we're also working on integrating tracing facilities (e.g., reporting progress to Amazon x-ray).
> has a full API, and maybe some clear way to test workflows.
Reflow's approach to testing is exactly like any other programming language: you write modules that can either be used in a "main" program, or else be used in tests.
Reflow: a language and runtime for distributed, incremental data processing
Hints for writing Unix tools
SOSP 2013 trip report, and a note on systems research
CUFP ’13: Call for Participation
You may be surprised (amazed?) to learn that, internally, 100% of composition happens in this manner. We have a massive code base, and we've not seen this be an issue.
Further, we've worked with the Scala community to standardize the idea of an "execution context" which helps make these ideas portable, the particular of the implementation transparent to arbitrary producers and consumers of futures, so long as they comply to the standard Scala future API. (Twitter futures will when we migrate to Scala 2.10.)
[1] https://github.com/twitter/util/blob/master/util-core/src/ma... [2] https://github.com/twitter/util/blob/master/util-core/src/ma...
http://www.read.seas.harvard.edu/~kohler/latex.htmlParticipate in CUFP this year
Futures aren’t ersatz threads
The Long Strange Trip to Java (1996)
Scala.util.Try (or, Thar be Trolls)
the scala school is mostly intended to be used in conjunction with a course we teach.
we're working on moving it towards being more self-contained, independent from the accompanying lectures.
CUFP 2011 (Tokyo, Japan) Call For Presentations
Commercial Users of Functional Programming Workshop (CUFP) 2011 Call for PresentationsSponsored by SIGPLAN Co-located with ICFP 2011Tokyo, Japan Sep 22-24Proposal Submission Deadline 15 June 2011Functional programming languages have been a hot topic of academic research for over 35 years, and they have seen an ever larger practical impact in settings ranging from tech startups to financial...