4 ms·

The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub progra

The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial. In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal language is of course the assembly language of the target platform. However it's often more practical to use a language that compiles down to a target platform's instruction set with the fewest number of transformations (barring the presence of optimizations). Flub languages attempt to give programmers the tools to write programs which hold some provable invariant, provide denotational semantics, or some combination of these. The benefit of this is some reduced cognitive load, expressive power, and other "soft" features. This power is what lets small teams run circles around Blub programmers in the Blub/Flub paradox. However the utility of these features and whether they actually do allow small teams to get more work done in less time hasn't been proven to me yet. It may seem tedious to think to think of the statistically significant data-access pattern in a given operation and forming your data-structures and transformations to make that access pattern the fastest route for the target platform... but it has big wins in terms of execution speed of the programs and the maintainability of such programs. One still requires a significant amount of mathematical reasoning and understanding of what a compiler can and cannot do for you. I'm slowly coming to the opinion that there won't ever be a compiler or Flub language that will give you your cake and let you eat it too. In practice I've found re-usability to be a low-priority concern, generics to be a performance hindrance, and I've yet to find a convincing example of how type-safety is the future of mission-critical software (though there are some promising projects for sure). Thus in conclusion: I think Blub languages will continue to rule the roost. Flub will come and go and remain fashionable as the OP has alluded to. However I don't think it's the avenue worth pursuing in order to write better programs... too much abstraction makes it rather difficult to reason about what our programs are actually executing on the target platform and for many cases that can be critical. It always comes down to the data and at some-point one needs to consider the target platform anyway. Data-oriented design is one way to think of the data first and allows the programmer to choose the appropriate semantics for the necessary transformations to be expressed by their program. (I hope I'm making sense).

iopq 11y ago
Generics are not a performance hindrance unless you mean executable size or compile times. They run just as fast as code with potentially dangerous casts.
Dewie3 11y ago
Funny that you mention data oriented design when I coincidentally happened to mention research on types and data layout in my other comment in this post[1]. Maybe this won't turn out to be practical for data oriented design or for caring about memory layout in particular; maybe it won't or wouldn't give enough positive benefits, like being able to easily change the layout of the data structures without changing a lot of the calling code. But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme. Not to mention the idea that people that want more powerful languages are lazy and don't want to think about engineering considerations, instead preferring to put their fingers in their ears and deny reality; I don't think we will be able to simply send our specifications to the compiler and let it figure out everything for us. Thankfully there are a many more approaches that don't involve a black box like an omniscient compiler. Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS. [1] http://dl.acm.org/citation.cfm?id=604147 http://dl.acm.org/citation.cfm?id=604147
- agentultra 11y ago
  > But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme. Well I am not terribly hip to what's "played out," but I don't intend to disparage academic research. What I am concerned with is the idea that you can't have mathematical reasoning and correct programs in the absence of a VM and some combination of denotational semantics and program invariants and other features-du-jour. The trade-offs for "expressivity," are not zero and we throw them out rather casually these days. Other trade-offs such as "correctness" also have a cost and non-trivial trade offs for compile times, run-time support, etc. And it makes reasoning about these characteristics more difficult the more abstract Flub is from a real machine. > Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS. His work is pretty cool and I have been following it from a distance. The paper you linked to looks interesting. I wish I was an ACM member so I could read it!

iopq 11y ago

Generics are not a performance hindrance unless you mean executable size or compile times. They run just as fast as code with potentially dangerous casts.

Dewie3 11y ago

Funny that you mention data oriented design when I coincidentally happened to mention research on types and data layout in my other comment in this post[1]. Maybe this won't turn out to be practical for data oriented design or for caring about memory layout in particular; maybe it won't or wouldn't give enough positive benefits, like being able to easily change the layout of the data structures without changing a lot of the calling code. But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme. Not to mention the idea that people that want more powerful languages are lazy and don't want to think about engineering considerations, instead preferring to put their fingers in their ears and deny reality; I don't think we will be able to simply send our specifications to the compiler and let it figure out everything for us. Thankfully there are a many more approaches that don't involve a black box like an omniscient compiler. Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS. [1] http://dl.acm.org/citation.cfm?id=604147 http://dl.acm.org/citation.cfm?id=604147

agentultra 11y ago
> But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme. Well I am not terribly hip to what's "played out," but I don't intend to disparage academic research. What I am concerned with is the idea that you can't have mathematical reasoning and correct programs in the absence of a VM and some combination of denotational semantics and program invariants and other features-du-jour. The trade-offs for "expressivity," are not zero and we throw them out rather casually these days. Other trade-offs such as "correctness" also have a cost and non-trivial trade offs for compile times, run-time support, etc. And it makes reasoning about these characteristics more difficult the more abstract Flub is from a real machine. > Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS. His work is pretty cool and I have been following it from a distance. The paper you linked to looks interesting. I wish I was an ACM member so I could read it!