The ring's source code in particular had to be transcribed from an actual shader I made (https://www.shadertoy.com/view/msd3R2). I didn't have the patience to write it directly in CSS. It's neither the right semantic nor the medium for it (which does make you wonder what CSS' medium was supposed to be).
Perhaps unsurprisingly, it runs at full 120fps on a decent laptop (it's just 21*21 JS style setting really). I've tried to make a half-JS, half-CSS version, and the speed is somewhere in-between. Basically, CSS variables are _extremely_ slow across all browsers, and I don't believe I've hit some particular edge-case. They're not used idiomatically here, but still, we shouldn't hit this drastic of slowdowns when updating 441 styles. They're also pretty hard to read the moment the calculation isn't some trivial basic arithmetics; and even then...
The true shader version runs at basically infinite fps =)
Yeah I was only talking about quantities. Equivalently, assume that it's a linear algorithm in the child and a linear one in the parent. Ultimately it ends up as O(nm) being some big number, but when people do runtime analysis in the real world, they don't tend to consider the composition of these blackboxes since there'd be too many combinations. (Composition of two polynomial runtimes would be even worse, yeah.)
Basically, performance doesn't compose well under current paradigms, and you can see Casey's methods as starting from the assumption of wanting to preserve performance (the cycles count is just an example, although it might not appeal to some crowds), and working backward toward a paradigm.
There was a good quote that programming should be more like physics than math.
It's more than that. The way black box composition is done in modern software, your n=100 code (say, a component) gets reused into a another thing somewhere above, and now you're being iterated through m=100 times. Oops, now n=10k
Generally, Casey seems to preach holistic thinking, finding the right mental model and just write the most straightforward code (which is harder than it looks; people get distracted in the gigantic state space of solutions all the time). However this requires 1. a small team of 2. good engineers. Folks argue that this isn't always feasible, which is true, but the point of these presentations is to spread the coding patterns & knowledge to train the next gen of engineers to be more aware of these issues and work toward said smaller team & better engineers direction, knowing that we might never reach it. Most modern patterns (and org structures) don't incentivize these 2 qualities.
Quite a few APIs use a pair of `{start, length}` instead, which in the context of the post's example, is even clearer. Empty interval would be `length == 0`, time interval would be a single array of `starts`, etc. Fewer subtractions (to get length) usually end up nicer too.
Personally I feel that Cappuccino is one of the last frameworks that still cared about a kind of interaction design that’s no longer discussed on the web, replaced mostly by more devops/abstraction-oriented discussions.
I manage a web UI programming language in my free time, and the juxtaposition of folks claiming FP ergonomics benefits, then upon my request, showing a static, interaction-less end result whose improved version would obviate their pristine architecture, is pretty staggering. The typical defense is "hey we're not designers" but if you zoom out a bit you realize the whole environment doesn't foster engineers to care about design concerns anymore (barring a niche but valuable vertical of optimizing for payload size). This in turn puts pressure back onto designers who come to expect less and less of what they care about on the web.
Just the other day a newcomer shipped an animated row transition after fighting her framework for 3 weeks. The designer was delighted, but the manager didn't even get the point because he matured in whichever era of JS framework that de-emphasized acquiring taste in interactions.
I myself come from a Flash background, so rather than seeing an upward trend, I see a decline in UX concerns, followed by an incline of devops-related concerns in UI frameworks (accompanied by HN comments saying that in both cases the web should have stayed as a document format, only to end up with an awkward mix of document + app architecture their desktop apps through Electron anyway).
If I were to categorize these "eras", I'd rather take the perspective of wondering at which point, and why, framework process ended up more important than the product. Heck, a similar thing is happening on native too, unfortunately. Where did all the interaction designers go?
Maybe AR would nudge more folks to learn and focus on rendering, gestures, transitions, framerate, intent and the rest.
Some upcoming languages like Zig and Jai have features to allow you to easily switch from array-of-structures to structure-of-arrays at writing time (https://www.youtube.com/watch?v=zgoqZtu15kI). Some edge cases also require rather unique ways of chopping up data, that wouldn't lend themselves well to be shoehorned in one of the canned categories of transforms.
Although constraint declaration is orthogonal to data-oriented development, I'd say that the philosophy of using generic constraint solvers (or other overly generalized CS ideas) goes against the spirit of DOD, which is to "just simply do the work". It is after all reacting against object-orientation (and even modern FP) which tended to think too much in the abstract and worrying too much about some form of taxonomy, as opposed to coding against plain data.
I help maintain ReScript (https://rescript-lang.org) and we've been rolling without an import statement for years now (basically OCaml's module system). The default is to just write `MyModule.doThis` at callsites. Sometime you do wildcard open (`open MyModule`) within the right scope. Sometime you do it at the top level for convenience (e.g. stdlib), but folks try to be judicious. And yes, you can alias a module path, e.g. `module Student = School.Class.Student`. Worth noting: the reason why fully qualified `MyModule.doThis` can be the default, is that we _usually_ dictate filenames to be unique within a project, so there's no verbose path issue nor refactoring issues (and yes this works fine... Facebook does it too).
Static analysis-wise (which is what most of the blog post's about), things are basically the same. The tradeoffs are mostly just in terms of readability. I used to be ambivalent about this myself, but looking at the growing body of GitHub TypeScript code with mountains of imports automated by VSCode, imo we've landed on a decent enough design space.
Jai is, imo, doing it right! For custom iteration one really _just_ wants it to be a little syntax sugar over a regular loop. Most other languages end up constructing some paradigm for iteration that drags in OO, FP, some interface concepts, generics, etc. Never mind that some edge-case async generator iteration can't leverage the `for` syntax; they deserve to stand out and be examined anyway. Especially in the case of Jai, where you'd want assurance that the for loop isn't incurring some weird function, allocation and other hidden overhead. No sufficiently smart compiler needed.
Compare that to e.g. Swift's iteration, with corners of undefined behaviors, potential allocations, and a collection types hierarchy that feels more like doing taxonomy than just looping.
Though to be fair, Jai's loop is rather intense in its usage of a macro system's features.
...So none of these typical hand-wavy dismissals apply:
1. "Is it really faster for edge cases"
2. "He probably didn't implement certain features like Arabic and Chinese"
3. "Businesses just wants enough"
4. "Businesses just wants enough"
5. "It probably makes some closed-world assumption"
The performance of RefTerm didn't come from some big tradeoff; it came from using the right perspective and keeping things simple.
Sure, past a certain complexity threshold, you'd have to work for extra perf, but from my observations, folks who immediately jump to the wrong implicit conclusion that "good perf must have required compromises" got conditioned to think this way because the software they work on are already (often unnecessarily) complex.
Oh for sure, build is the main point and SoA isn't. The SoA feature discussions probably came from its deprecated interesting approach.
Collapsing into a single layer is great. As an aside, another language notorious for doing so would be Smalltalk, which is on the complete opposite end of the spectrum in terms of paradigm. It's kinda interesting to see the horseshoe theory in action in software philosophy.
Tldr SoA isn't a single transformation. Depending on your data access pattern, you might want to shape the structure differently. Kinda like GPU. So first-classing a particular pattern of AoS->SoA conversion (the one we often see in tutorials) wouldn't have been enough. In this case, a little bit of tasteful usage of macros covers the variations well enough.
There’s a much vaster gulf between a truck driver and a truck engineer, vs a Java programmer and a programmer one layer below. Per your analogy, the truck driver is the program user here, not the program maintainer.
You're right; the medium definitely shaped the message here. I've worked with and near many native and web teams, and have observed the engineering conversations of the folks from entry level to senior level. The difference in perspective and execution is notable each time. More interestingly, a transition transition from one side to another also changes perspective and conversation.
The community culture obviously also influences these discourse, but a surprisingly large chunk of the regard or disregard for UI/UX comes from using the tools you're provided by the platform, so much that unfortunately (or fortunately, if you've chosen the right platform), these factors influence one's learning and result much more so than even hard work and talent. A change of perspective is worth 80 IQ points, like Alan Kay said.
I help maintain ReScript. That it _seems_ to change the way code is approached is an artifact of an early community excited to try FP concepts in it. Nothing wrong with that; however, the ReScript team (me included) don't really approach things this way. Our goal, outlined at (https://rescript-lang.org/docs/manual/latest/introduction), is to provide:
- a more solid type system
- and a much faster compilation speed (a growing pain in TS projects)
- to write mainstream code
- for products (as opposed to a focus on intermediate FP libraries)
The fact that it leverages some FP concepts here and there is just a mean, not the end.
The marketing of this is really hard, because FP usually attracts the crowd you'd expect, at the expense of several of the above emphasis. But we're still working toward it.
Having seen some ReScript codebases in the wild, I definitely know where your team comes from. We do try to approach it with the "different TypeScript" angle, but understandably userland doesn't always write code the way we'd like to recommend.
I happened to have read many of VPRI’s papers and some domain expertise in a few of their topics, or know close friends with such domain expertise. Btw, my collection of their links are at https://news.ycombinator.com/item?id=19844088
The goal is a noble one; though it's unclear to me if their research is the right way to go.
Alan Kay's gang's research's end result are often great, but their implementations are usually more geared toward prototyping rather than production. For example, the GUI innovation is great, whereas its implementation using Smalltalk is clearly geared toward faster iteration and not meant to be as competitive as a production language (let's not enter into this debate as this is another rabbit hole. Plenty of other HN threads on this). But I think so far these implementations have gotten a pass because the end result is futuristic enough for someone else to come along and implement e.g. the GUI in more production-oriented languages.
In the context of VPRI, however, the goal wasn't to create more futuristic end results, but to recreate existing result using hopefully drastically more concise paradigms and DSLs. In this case, the implementation itself is the thing we should examine, and imo they kinda fall short.
For example:
- Yes, it's very appealing that Nile can reduce the antialiasing logic by so much. Is it resilient to real world requirement changes though? Unclear (and the Nile paper still isn't out as the author seems busy with some startup).
- The OMeta parser tool is cool until you encounter more complex grammar and proper error messages (most non-hand-rolled parser tools' error messages and error recoveries are treated as secondary concerns).
- Reusing the same state machine from OMeta (afaik) for TCP is clever, theoretically sound, but likely also not shippable in production the moment you want to tweak some low-level details.
- The dynamic language used for the final product, they baked in some pretty hardcore first-class features but..., this is too long to explain, though experienced folks who read this probably know what'd happen to such language in production.
- The bulk of the final line count reduction wouldn't come from some language-related line count reduction, but from VPRI's rehash of OpenDoc, aka the end product is a Word/PowerPoint hybrid put together by massively (over)reused component. The moment such app hits the real world and a component needs to deviate from its use-case in other callsites, that amount of reuse is gonna decrease quickly. HN has plenty of comments regarding OpenDoc so we can check history here. The final use-case being an OpenDoc rehash is also slightly cheating imo. Demo a game. The line count there is a better stress test.
- Real-world perf requirements are gonna increase the line count by a lot. I understand they're employing he classic PARC strategy to "iterate as if you have the supercomputer of tomorrow, today", but plenty of languages today can already reduce their line count by a lot if perf wasn't considered.
All in all, I'm not sure VPRI's respectable goal can concretize through their method. I am however extremely on board with their goal (of shrinking the code size to be understandable by as few people as possible). Here's an alternative take on the same goal: https://www.youtube.com/watch?v=kZRE7HIO3vk and of course Casey's friend Jon Blow whose language Jai so far obsoleted a bunch of other DSLs he'd have usually needed in his workflow (https://www.youtube.com/watch?v=uZgbKrDEzAs). Now that's a more realistic way of shrinking code and simplify, imo. Between:
- a great language that can demonstrably do low to high level coding and with an in-language metaprogrammmming facility that removes the need for DSLs, and
- VPRI's opposite direction of proliferating many DSLs (which in real world are gonna cause nontrivial accidental complexities),
No good generalized solution for this it seems. The best you can do is to specialize per situation and leverage all the assumptions you can while being cautious not to leverage the assumptions you can’t.
This problem contains lots of incidental complexity and it doesn’t help that folks do the opposite of the above and add a ton of accidental complexity on top. For example, for a situation with a crossfade or morphing set of 2 buttons you should:
- leverage the assumption that there are only 2, and static, buttons.
- not assume that there are only 1 button present at any time.
Some end up inclined to create some “reusable” abstraction on top and end up doing the opposite:
- generalize to handling n dynamic buttons. Without realizing that some important properties of that specific situation would have been lost.
- (usually due to the lack of experience/focus/interest on the problem) oversimplify and assume there’s only 1 button present at any time.