Some thoughts after meetup.Users are humans. They evolved from monkeys not so long ago.
That's why today's UI uses shades, smooth animation, tries to look Material: this way UI reminds real world that we evolved against.
That's why one of the most effective ways to comprehend math is to rely on geometry, visual thinking.
We may think about programming environments (languages) as an UI for program design.
Maybe this programming UI should also be limited to only those abstractions that fit well into human brain.
Those abstractions and ideas that can be experienced in everyday monkey life.Abstractions and ideas that fit well: - idea of immutable data. Most objects in real world most of the time stay unchanged. Just like we have many identical pieces of paper (or rocks) that we modify, we have many copies of same immutable data, that used to produce something new.
- idea that objects behave differently in different contexts (partial application of pure function as context update?). Objects in real world behave differently when they are places in different context: warm, cold, light, dark.
- idea that actions can be undone by traversing routes backwards. That what we do, when we lost our keys in the middle of the route. We try to remember where exactly we walked, and walk backwards. Once we found the keys, we create new branch of walk.
- idea of separation for reliable actions, and unreliable actions that may have unpredictable outcome. If you work with static objects (or objects that move linearly), you can be sure that you can walk, jump, catch, run pretty much unconsciously with desired results. If you engage with another actor: a moving object, you need to calculate, negotiate, and it's much harder.
In real world reducing number of moving objects, using as many static objects as possible makes life easier.
Same in programming: keeping as many things immutable as possible, reduce number of dependencies that can change behavior without your explicit command -- makes life easier.Abstractions and ideas that don't fit well: - closure function that captured IO interface (tcp socket, db connection). Basically what you get, is special kind of object that may behave totally differently, regardless of your input. It has implicit invisible dependency that change its behavior. It is not an object under your control, but rather an independent actor that you need to negotiate with (just like another human being).
- objects that can arbitrarily modify their own behavior. We have that kind of objects in languages with metaprogramming (e.g. Lisp), but we rarely see anything similar in everyday life. Most of the time objects are changed explicitly from outside.
- idea that object can implicitly change context, global state. If there change, it's always visible and explicit.
I finally got round to listening to "The Edges of Representation" podcast ep. @stevekrouse, you were asking about papers on notations and 'Cognitive Dimensions' came up. A paper in a similar vein that I've found useful is Daniel Moody's 'The “Physics” of Notations: Towards a Scientific Basis for Constructing Visual Notations in Software Engineeringhttp://www.cs.uu.nl/docs/vakken/arm/literature/Moody2009-DesignScience.pdfQuoting PoN as to where it fits in the literature:"The Physics of Notations incorporates both a Type IV theory (Section 3) and a Type V theory (Section 4), which are higher evolutionary forms than the CDs framework (Type I). However it should not be seen as a direct competitor for the CDs frame-work as its scope is much more modest (visual notations rather than cognitive artifacts). Instead, it should be seen as complementary: it provides exactly the type of detailed, domain-specific analysis that the authors of the CDs framework argued was necessary to supplement the “broad brush” analysis provided by CDs"Type 1: Theory for analyzing
Type 4: Theory for predicting and explaining
Type 5: Theory for design and action_(Aside: while trying to find the PDF for this again, I came across a paper looking at using it directly for visual programming language analysis: Towards an Operationalization of the “Physics of Notations” for the Analysis of Visual Languages (Storrle & Fish) https://pdfs.semanticscholar.org/d4bc/b466b1390295354d0cc897ab02058f2f8cad.pdf)_I used PoN when writing my undergrad dissertation on improving the notation for a human factors tool/diagramming thing (somewhat similar to UML) representing human tasks. Some crossover, although not exactly the same as your likely use. IIRC it illustrates putting PoN to use. I can probably dig it up if you're interested?
The stereotypes of UI/UX-focused and performance-focused programmers tend to be somewhat at odds, but I'm starting to optimistically think that they may not be so diametrically opposed...
I just finished reading the book 'Data Oriented Design: Software Engineering for Limited Resources and Short Schedules' (of which the author has a free online copy here: http://www.dataorienteddesign.com/dodbook/) and I was struck by a few of his recommendations related to this group (there's definitely more, but these are the things at the top of my head atm):0) (for a bunch of performance reasons, data are better considered as collections rather than single objects - or even objects at all)
1) Despite their initial appeal, the paradigm of 'objects' falls short in a number of ways. 'Relations' map more consistently between human concepts and computer implementation, are simpler (and so are easier to debug), and typically faster to do computations with.
2) Relatedly, it's generally a good idea to lay out data similar to a normalized relational database - this kept making me think of Eve (@ibdknox were you at all aware of/influenced by the DOD 'movement'/approach?)
3) 'Existence-based' programming (see the chapter of a similar name) reduces a lot of boilerplate noise and eliminates-by-design the possibility of a few classes of errors
4) A mixture of queues and hook/subscription/reactions slot in nicely with the paradigm. This leads to easy concurrency with effective immutability without the mental and CPU overhead of mutexes.
GraphQL seems to be a more expressive/high level query language than SQL (and things like relationships, sorting, filtering, are left up to the interpretation implementation) so I'd imagine something like that might be more likely. I think with the right type representations things like program synthesis can at least stumble upon valid wirings, and the problem gets shifted back to the specification of desired outcomes
3 years ago
I was creating a demo that involved "no code" from my point of view, but it had 2 KSQL queries, they could have been built with a query builder but they would still be there, then I thought, is this "no code" or is it code? should it be an objective to find a better way to express and "surface" what this sql is doing here?
3 years ago
"Theres not enough real estate on a laptop for modern development." <- which direction should we go, should we be able to compute in any screen size? should we require specific environment? should the environment adapt to the available devices? is computing on a smartphone a goal?
3 years ago
also, I was about to write "coding" but it felt too tied to writing text on a text editor, instead I used "compute" mainly inspired by