dlab IRC 2017 October 29th

← Previous day: 2017-10-28 · Next day: 2017-10-30

#dlab logs for 2017-10-29

Current topic
A distributed laboratory. Everything which appears here is logged at https://rawl.es/dlab/irc/2017/
joeytwiddle^snr (Joey Clark)
[09:29:31Z] Hey. At one time I was also curious about "derived" variables like Adam mentioned, where some values are the result of calculations based on other values.
[09:29:47Z] I looked at three ways we might can implement the caching in existing languages:
[09:29:55Z] 1. Whenever a root variable changes, recalculate the derived values (can be wasteful if the root changes before we need the derived value).
[09:30:05Z] 2. Calculate the derived values on-demand, and cache them; mark the cache as invalid if a root value changes.
[09:30:13Z] 3. Use memoing, so if the roots change back to an earlier configuration, we may still be able to look up the derived value from the cache, without recalculating it.
[09:30:28Z] I considered putting the feature(s) into an actual language. In my mind, each strategy had pros and cons, so I was thinking of letting the developer choose which strategy to use at compile time, using some meta-attribute on the variable(s).
[09:30:30Z] Alternatively, an engine could decide at runtime which strategy to switch to.
rawles (Simon Rawles)
[09:42:26Z] Yeah, this is pretty much what I'm trying to do at the moment. I've chosen to do the second way but you can also set things up so that it works in the first way. With the third way, that might lead to more efficiency, but if there's a big chain of derived values, it might not be useful. Maybe the dependency maintainer/evaluator could be adaptive.
[09:42:51Z] What were you using this for?
[09:43:35Z] Or were you just curious about computing in this way?
joeytwiddle^snr
[09:46:38Z] I was inventing my own language. This was going to be one of the many amazing features that I thought it should have.
rawles
[09:50:03Z] Roughly speaking, it's the computational basis for empirical modelling - https://www2.warwick.ac.uk/fac/sci/dcs/research/em/ - and construals - http://construit.org/
[09:50:42Z] I'd like to try to bring that way of looking at computing and modelling the world into something that allows a more human approach to data mining.
[09:51:22Z] Was your language going to do anything like that? That is, for modelling the world, or simulation, or something like that?
[09:51:44Z] Or were you trying to capture what was missing in languages that are out there?
joeytwiddle^snr
[09:55:08Z] It was meant to be general purpose, and it would export to various popular languages. The idea of this feature was to DRY up a common pattern that we see repeated over and over in real-world code.
[09:56:35Z] Perhaps existing languages with sufficient pre-processing (Lisp, sweet.js) could DRY up that pattern using their own mechanisms. (And some languages, like Haskell, have memoing built in already.)
rawles
[10:02:43Z] So the thing you're trying not to repeat is the code which recomputes derived values? For appropriate settings, the language could just look in the variable and, because the dependency is understood, it'd just be there? If so, you'd be mixing variables whose values come from on spreadsheet-like depedencies from others with procedural execution?
[10:03:46Z] Not that that's a bad thing, as long as the difference between assignment and dependency is clear to the programmer, I guess.
[10:09:43Z] For some code, it might make it much shorter and clearer.
joeytwiddle^snr
[10:10:31Z] The programmer would explain how to calculate the derived variables, so he would never need to assign them, and would not be allowed to. For example: derived float halfWidth = width / 2
[10:11:03Z] assignment could be a compile time error
[10:19:05Z] Yes it would make shorter code. I suppose one concern is that the cost of assigning to one of the dependency variables ('width') is not obvious from looking at that variable's declaration. What looks like a cheap operation might cause "a lot" of recalculations when 'halfWidth' is next accessed.
rawles
[10:19:36Z] In (js)eden, which the empirical modellers use, you just write 'is'. Here's a four-minute demo video about making the pattern of interconnecting spirals found on sunflowers: https://www.youtube.com/watch?v=xa63K878zYc
[10:20:04Z] I guess an IDE could help with understanding the cost of that operation, though.
joeytwiddle^snr
[10:20:48Z] RIght. There are limits to analyzing code just by reading the text!
rawles
[10:36:12Z] How far did you get with your language?
[10:49:49Z] Did you put it up anywhere?
joeytwiddle^snr
[12:11:39Z] certainly not. I got stuck working on the parser :D
rawles
[12:38:05Z] What was the language written in?
joeytwiddle^snr
[12:51:50Z] the parser was in Java so my plan was to make some Java code spit out a working program in Javascript or Java or Haxe or C
rawles
[12:59:16Z] Did you write the parser yourself or use some library for it? I should really write the parser properly.
[13:51:26Z] I'm going to this today: http://www.fitzmuseum.cam.ac.uk/calendar/whatson/codebreakers-and-groundbreakers
joeytwiddle^snr
[13:54:18Z] well i wrote my parser myself but the structure it generated was not very easy to work with, so that would be the next thing it needs. https://github.com/joeytwiddle/code/blob/master/java/tools/parser/src/tools/parser/dlang.grm
[13:56:09Z] Have fun at the event. I've been enjoying this simple crypto game on Android: https://play.google.com/store/apps/details?id=com.pixplicity.cryptogram

All timestamps are in UTC. If you want to join in, channel information is available. This page is generated from raw logfile dlab-2017-10-28-175235.txt.