Lambda the Ultimate

Are good abstractions really going to arise out of building an example and then abstracting some variables? There have recently been studies in the news reporting that technology in the classroom is correlated with lower standardized test scores, and I personally find that my most important advances are made away from the computer. I suspect that the big ideas about modeling and algorithms are going to continue to be this way (or, at least, with focused thought in front of the computer rather than feedback oriented). Better feedback and tooling seems important as a constant factor improvement in building software rather than a change in the Big-Oh.

Wasn't it dijkstra who said students were spoiled by using interactive terminals rather than thinking about their programs carefully before they entered them onto punchcards? How would you rate the move from punchcards to interactive terminals in making programming "better"? A constant factor?

But it's not really related to this topic. One could imagine an app on the computer that was separate from the programming environment that was useful in brainstorming, note taking, writing presentation, writing papers, sketching wire frames, and such. Computer assisted thinking is already here, it just isn't very deep into our programming environments for some reason. Many programmers for some odd reason tend to be anti-computer in this respect.

because they'd have made better tools. not because they would stick with really crappy ones.

a genius is probably going to be even better with a great tool than with an old crappy one, even if they can out-do us all even with the crappy one.

etc.

so yeah people need to know how to think first, that is a great valid point worth stressing. but i don't think that should somehow then prove we never need better regular tooling.

the BEST tooling would be toward helping the THINKING of course!

In the words of the famous computer scientist Obi-Wan, "Use the Force, Luke." He then turned off his targeting computer and was met with "Luke, you switched off your targeting computer! What's wrong?" Using a computer to hit a target is for woosies. And it worked too! Link.

But in the real world, I bet the targeting computer would have been more useful, and anyways there are no midichlorians to give us special psi powers. Cybernetically enhanced thinking and problem solving is probably our future.

In the real world they dance upon the surface of the caffeine molecule, and those who are receptive can channel their advice through copious amounts of strong coffee.

Caffeine, nicotine, LSD, ... are all wrong ways to intellectual enlightenment ("wrong" in varying degrees of course). Interfacing with a computer can be much healthier.

But... caffeine and nicotine are two of the steps on the eight-fold path to releasing your programs from the samsara of debugging.

I think the graphics people have been out front on this for awhile: they have a domain that is incredibly visual, so can provide good feedback, and also have much more need for tweaking and tuning (and nice scrubable values to get there!).

I've had some success with the subsumption architecture, but it does have its limitations, especially when you aren't controlling a bunch of robots or virtual robots (as in a game). Chris Granger mentioned that they tried it out as well.

Yes, I would definitely not claim that subsumption is a good universal model for how to author software. It is uniquely beneficial when you have something that you know *should* be a pure function ("what voltage should I send to these motors given the sensor input I see right now, and the state I've recorded?"), but actually writing a closed-form function a priori is intractably difficult. When just writing the closed-form function is tractable, it will typically be faster to just do it; you wouldn't want to use subsumption to write quicksort.

(Aside: machine learning is starting to provide another viable approach in this space (e.g., deep convolutional neural nets), with the down-side that they are not currently easy to debug or fine-tune.)

To be clear, though, my goal wasn't as much to argue for subsumption (although it is *really* useful in my domain), but for thinking more overtly about space-time rates (stages/phases/worlds/what-have-you).

I like that your model includes where and when aspects, because a good result requires planning context of computation. Is it mainly a matter of efficient resource scheduling? I guess also because deliverables have a time target after which they get stale.

The main reason anybody uses a GPU is for performance. Sometimes this is a soft or hard real-time constraint (e.g., virtual reality) so that, as you say, an answer delivered too late is stale, and cannot be used.

As a result, in graphics we will often prefer to make approximations (give a "wrong" answer) rather than take a longer time to give the "right" answer. The decision of where to run something in the pipeline (e.g., per-vertex vs. per-pixel) is usually a performance-vs-quality decision, since a triangle of 3 vertices will typically cover many more than 3 pixels, so per-pixel evaluation gives a more dense sampling (more expensive, but higher quality).

Has someone done a functional modeling of the render pipeline that can be compiled to efficient GPU code? e.g. a model is a set of triangles with some associated material property functions. When you try to render such a model in some context, those functions end up getting invoked per fragment. This render context would itself be modeled functionally. Shifting between "rates" would be modeled by specifying data at one set of indicies in terms of another (e.g. lirp between vertex data to get fragment data). This is how I imagine wanting a GL to work and you seem like a good person to ask.

I don't understand. The render pipeline was functional and still mostly is.

Or maybe you are looking for hull shaders?

There's a lot of work that has attempted stuff in this basic direction.

Conal Elliot's Vertigo ("Programming Graphics Processors Functionally") is a very clean and well-reasoned formulation, as you might expect. It is primarily aimed at procedural effects, so it would require extensions to apply to more general cases (e.g., it requires geometry to be parametric surfaces, rather than arbitrary triangle meshes).

Chad Austin's Renaissance ("Renaissance: a Functional Shading Language") uses a ML/Haskell style purely functional language for describing shaders. It is based on the idea that computations are per-fragment by default, but the compiler is allowed to hoist certain computations to the vertex stage (e.g., linear math).

The GPipe package for Haskell models the graphics pipeline fairly closely (e.g., there is a "rasterize" function that maps a stream of primitives to a stream of fragments). The fragment stream type is a functor, and thus shaders are defined by mapping operations over it.

My own system was called Spark, and while it wasn't trying to be functional, the top layer of the language is declarative, and can sort of be seen as a simple (first-order) functional language. Transitioning data between rates was modeled explicitly as "plumbing operators" which could do exactly the kind of things you ask for (describe that a value at one rate should be computed by linearly interpolated values from another rate). Plumbing operators could be either system- or user-defined, and could be applied either explicit, or implicitly (when qualified with a Scala-like "implicit" keyword).

At the risk of tooting my own horn: the main novelty of my system was that by modeling inter-rate conversion more explicitly, I was able to target the more complicated stages of the pipeline (tessellation and geometry shaders) that most research systems hadn't (and still don't) tackle.

as seen previously on LtU, Nile tries to 'reduce' (in a good way) a graphics pipeline to a mathy language.

Thanks for the overview. GPipe and Spark sound the closest to what I was imagining. I've already read some of your thesis. Looks interesting.

I actually had some discussion with Conal about targeting geometry shaders functionally. The big problem there, however, is that geometry shaders are not functional, they are the first stage of the graphics pipeline that is overtly procedural. Tessellation is again functional, would it be really hard to support them in something like Vertigo?

I think you are right on both counts.

So long as you are modeling the pipeline stages as explicit functions, you could add tessellation to Vertigo without too much overt complexity. In that sense you'd have tessellation exposed no better/worse than HLSL, GLSL, etc.

My statements should have been more narrowly scoped to systems that use rates/streams/staging/what-have-you to allow developers to easily write programs that operate across or abstract over multiple pipeline stages (that is: systems that start from the assumption that the HLSL/GLSL approach isn't good enough).

At what point would you just be using a compute shader anyways to define your own pipeline?

The point where this is practical (from a raw performance standpoint) for a 1080p game at 30 or 60fps may be upon us soon. One of the big moments for game dev folks at SIGGRAPH was when Media Molecule talked about their almost entirely compute-based rendering system for their upcoming game Dreams.

The catch is that, all other factors being equal, a renderer that makes good use of the fixed-function bits of the pipeline should always be more power-efficient than one that only uses the general-purpose compute parts.

This same logic should apply to any case where an SoC architecture includes fixed-function or specialized hardware for particular tasks. Graphics is just one example.

That is quite interesting since we've already gone from fixed function to programmable function but fixed pipeline. It just seems that we'll eventually figure out how to have programmable function and programmable pipeline without such a big cost.

https://duckduckgo.com/?q=microservices+vertical+decomposition

That insight about global structure seems quite valuable. (Suddenly you're very interesting.) You remind me of my biggest peeve about missing minimal code docs to explain anticipated context characterizing situations expected to obtain when it will matter what code does in response. Code says what it does, but doesn't say what facts you believe are true elsewhere such that it matters what code does. Important relationships with code elsewhere seldom get called out as important to grasp motivation for local effects. Code can operate like falling dominoes, where it's hard to perceive how parts hit each other in sequence, and where the trail is going.

Very interesting, thanks.

The connection to version-control seems rather powerful and interesting. The fact that it comes with a proposed invariant (that removing a feature passes the non-feature-related tests) is helpful.

I'm not that convinced in the specific, aspect-oriented-ish interface you propose. I find that I would rather have the whole program in view, with enough annotation to understand (for humans and computers) the layering, and ability to fold/hide unrelated features for program comprehension purposes. To harp on the version-control analogy, rather than manipulating an empowered patch series, I would rather be supported by an empowered blame tool.

There is more to be said about which invariants the system should respect, than just "removing a feature should not break the unrelated tests". What is the nature of the dependencies between features? Intuitively I would like to be able to claim that two features are independent, and have static checks / linting warn me if a change in one of the layer affects another that is not related. This reminds me of the work on using dependency analysis to detect semantic merge conflicts, furthering the version-control correspondence.

> I would rather have the whole program in view, with enough annotation to understand (for humans and computers) the layering..

Yes, the current system has some tools to inspect the output of tangling because I have found it useful on occasion. It's on the roadmap to provide that ability in a nice way in the UI as well.

By the same token I spend a lot of time providing a nice way to "uncoil" a static program in a specific scenario and see the trace of actions it performs. Both are analogous abilities, and yet conventional stacks tend to deemphasize logging. For example, we build huge infrastructure for interactively stepping through programs and nothing to augment debug-by-print. I think it's a pervasive blind spot.

You never actually have the whole program in view, you only have a tiny peephole with which to probe at it, and you have to choose what groups of features you permit to show up on the peephole together. We're conditioned to think that "code inside a function" is the ground truth of a program, but that's not always the best approach.

> I would like to be able to claim that two features are independent, and have static checks / linting warn me if a change in one of the layer affects another that is not related.

Avoiding explicit dependencies between layers was basically a pragmatic decision to avoid the combinatorial explosion of testing all possible combinations of layers. Perhaps someone with different skills than me will come up with the perfect type system for this without causing combinatorial explosion. But even just testing layers 1, 1+2, 1+2+3 and so on is strictly superior to the current approach, where we only test all the layers together.

---

In general, my bias is to spend less time worrying about how the code looks to the reader and instead assume/design a tactile interactive scaffolding around it that will help provide something akin to depth perception feedback. Your visual cortext doesn't work nearly as well if your head is fixed in place and you can't make the slight movements to exclude many possible segmentations of a scene. But it doesn't have to work well in that situation because you almost always can move your head.

If two features are totally unrelated you can put each one in its own module, and that enforces the separation syntactically. Or is that not what you want?

I suspect that most of our approach to software development is so bad that just statically enforcing syntactic separation is probably insufficient.

I wish we were better at / had better ways to express equivalence classes. Dependent types? Things like QuickCheck are to me of that mindset. As are edge case tests, fuzz tests, acceptance tests (if they are done well, and that is not easy).

I'm doing job interviews (see what is going on in the rest of the world) and one of the take-homes is to do some small "service manager" stuff, and support plugins, and invoking them concurrently, and make the code as "ideal" as possible (where "ideal" is probably a bit of a roarchach test).

Given the problem I can see that I should require 2 different thread pools. One would be sized by my code to avoid starving anybody, the other would be up to the caller to decide how they want to size it.

It all feels a little bit like voodoo and chicken blood when it comes to e.g. oh it worked on my machine, perhaps. You set the thread pool to be MAXINT size?! etc.

It would be great if we had 'language' to help reify these kinds of ways of looking at and designing code. Being able to only resort to doxygen stuff is an indictment.

I suppose ideal means you avoid making sloppy choices that over-specify something (actual usage will only look like this, not that). So: kinda abstract clean api, maybe with a shim near OS api that turns calls into actual native types.

I guess reserving a pool for private infrastructure sounds good to ensure you cannot run out of essential service capacity, when you plan how it will receive load and know you keep some capacity available.

Things that can block need their own thread, if it would otherwise make requests wait that can run independently. It's common to try writing services with as little blocking code as possible, with non-blocking sockets etc, so multiplexing connections can be done in userspace, within just one thread. The way it's done might be secret sauce in a company. (But secret does not require pretty.) Probably there's an open source way to do it, but I haven't looked, planning my own instead.

There's a way to host many fibers in one thread, servicing non-blocking i/o as traffic shows up in a trickle in just a few ports at any given time, so exhausting cpu is not easy to do unless you go nuts with encryption. But you can't easily use any code that blocks from a library that would otherwise be nice to re-use, developed by someone else.

To actually perform a blocking operation from such a context, you can make an async call serviced by another local thread pool devoted to executing code expected to block. But making code async in many languages is awkward, as you normally need to organize your code around it, often resulting in callback hell of some kind. But if you transpile to continuation passing style (CPS), you can manage to write source that looks like normal calls, appearing to block synchronously, that gets rewritten to async to do a lateral handoff to a thread pool (which awakens a fiber continuation on reply).

You could come up with a posix api that does that, but you'd need a reference implementation for others to port if they hoped to always be able to use it. Part of language to do that must include a model to keep in mind, with words people use to discuss detail. You end up with conventions like threads are native (which block) while fibers are lightweight userspace things (which park), and stuff like that.

I'm glad you like the topic. Probably other folks merely tolerate my fuzzy, informal, exploratory posts because they seem to lack focus in a hard-driving dog-eat-dog sense of academic competition. Broad things are possible, but mostly we talk about narrow stuff. I didn't mean to go on a thread/fiber tangent, and isn't needed to talk about the idea of alternate models.

To test out ideas, I've been imagining something like HyperCard running in one or more daemons, but it gets really messy when not single-threaded. That might be understatement: maybe more insanely hairy when event handlers can run in parallel, and can avoid terminating when plausible looking code is written. So I've been wondering about alternate ways to think about what's happening. While my own use cases are narrow, what if you told folks they could aim to do whatever they wanted? You can't really stop people from making messes, so I wondered what the messes would be like, if you casually strung things together without thinking much. Even if you put in lots of safety mechanisms to stop things from running out of bounds, it would be easy to turn off all the checks by making limits big. Anyway, the idea is to guide folks away from gibberish and toward bounded orderly models of some kind.

Those are places I like to hear about, even if I never get to go there in person. Things like parallel skeletons, or actually theoretically correct approaches to eventual consistency are all possibly good straight jackets akin to strong poetical structure, in my mind. The Right Abstractions.

I like your suggestion, and I want this to sound positive, but it's hard to run with, because Kay's material has been familiar to me since the 90's. (Actually the late 80's, but perhaps it took me a few years to hear it over and over and have bias fall from my eyes.) So I have trouble mustering a new-ish response that doesn't sound trite. I can give you a lateral-thinking reaction, though, based on associating some old things with each other, which might be interesting but seem stale.

I noticed the recent HN discussion of mythz's 2013 post (first discussed on HN in 2013), which is what I assume prompted your comment. Since I'm going to make a remark about Rick Meyers, you might want to see my longer 2006 post here on LtU, with headline smalltalk hindsight, where I provide more context than I should here.

By 1990 my favorite languages were Smalltalk, C++, and Scheme in that order. But I had not coded professionally in Smalltalk when I went to work at Apple full time in C++, on Pink, where they hated dynamic languages as a matter of policy and you could get sarcastic remarks about Objective-C at the drop of a hat, apparently because dynamic dispatch by selector was considered an artifact of toy languages. (They were pretty sure NeXT was going to crash and burn.) When I objected and asked what the problem was, all I got was eyeball-rolling. I like the extreme late binding Kay talks about. I wrote a lisp in the late 80's, and a smalltalk in the early 90's that also had some hybrid stuff from lisp.

Nearly every quote in mythz's post is old to me, but most seem far from a central concept needing pursuit, except perhaps the part about instant interactive feedback when exploring an idea. In the 90's I tested my C++ with an interactive Lisp interface (using tools I wrote entirely myself), usually in an environment like MPW (Macintosh Programmers Workshop), which was the text-oriented shell at Apple that simulated a Unix-style environment as a single Mac process that ran tools in pipelines that were actually (roughly speaking) coroutines scheduled in MPW like you would via userspace code in Linux. I believe the general MPW architecture was due to Rick Meyers, though Dan Smith (now Dan Keller) wrote the shell application.

(Meyers and Keller worked on Pink's development environment, and we used MPW in the build system, but text-oriented interfaces were met with extreme hostility by many Pink devs because everything was supposed to be direct manipulation, due to a "graphical UI rules" religion. To enjoy text-based language tools was tantamount to advocating the use of CP/M or DOS command lines, which was heresy of the worst kind. So MPW was regarded a necessary but temporary evil.)

I loved HyperCard's ability to open up a widget and show the script that runs when an event was received by that widget. I have always wanted this for every UI widget, so users can inspect how things work. (At Netscape this idea was met with typical hostility toward the idea; I think undiscoverable UI was considered cool at that time.) When I pitch this idea, typically I'm told it's "impossible" because a dev cannot imagine how binding would work, to relate what appears in a script to what runs in a backend in response. Not many devs seem to get the idea of how compilers and interpreters work, it seems, or else one cannot explain the cannot-be-done reaction.

I would like to have something that's like a bizarre hybrid of HyperCard, MPW, Unix shell, and web browser, so the answer to "what can happen?" is whatever you want. Unfortunately, some of the things you can do with that are horrific, like distributed denial of service scripts that would be hard to stop from spreading virally, unless you don't let users control how permission works (and I want to allow everything). So you can see where I get some "yes of course" attitude when reading Kay quotes like that.

Is there a specific Kay quote you want to talk about? Or a particular tool you want to hear riffs about? I could have just asked that alone, without all the rest above, but you wouldn't be able to guess where I was coming from. I need narrowing to make a topic discussible instead of broadening.