Having a mental picture of the DAG of any execution is the sort of spatial intuition that we're generally good at, I agree, it's the "implicit" graph we tend to build by association. I've very little experience with C/C++ (intro level at best) but from the Go angle I can see how reactive programming is required to avoid huge compilation times.
> I wish for a computation system that would work with cyclic graphs.
It is baffling to me that we haven't such a paradigm available. I don't know much about academic CS but I'm fairly sure there's one among a gazillion formal languages that describes circular spaces.
Intuitively, I'd think it would have interesting applications for the programming (modeling, computation, reasoning) of oscillatory phenomenons notably.
I totally agree with you in 'practice', though I've tested literally none of it even on paper. The basis paradigm, in a best-effort thinking-aloud, is that any statement execution is a loop in itself; which fundamentally gives objects a 'thickness' in time, a time dimension; thus some φ or θ property (angular-whatever you want to measure, some periodicity expressed in a common clock).
Based on this, circularity is not a problem but a feature, and this would define some Fourier of a "program", a system of elementary executions — its periodicity in time, how "big" the loop.
I don't know, it's really interesting to think about such a paradigm of representation, of programming 'models' and 'problems', behaviors.
About O(n^x), I guess I was trying to be as general as possible. Indeed, that was exactly "dumb things"! Retrospectively I'd argue it's possibly by going everywhere including into the dumb that you really get a "feel" for a particular problem/solution space. Like flawed DAGs ;-)
When you naively translate ideas into computations (like a recipe to game something optimally), it may end up looking more like
# a bunch of discrete values,
# may be n-dim with indexes, table lookups...
Column 1: x = [1, 2, 3,..., xn]
Column 2: y = [10, 20, 30,..., yn]
Column 3: z = [(x+y), 2*(x+y), 3*(x+y),..., zn]
# programming horror
Columns 4, 5, 6...:
for i in x:
for j in y:
for k in z:
{unefficientImplementationOf f(i,j,k)}
# 200-char highly redundant Excel formula
# games have "levels" (for all objects potentially)
# levels change rules: recursion down to L1 to compute
Sheet 2: # "level 2", new indexes x, y, z, w...
# calls L1 every single cell
In effect that last block (new sheets) creates new 'real' dimensions (with weird metrics) over the first 2D arrangement (sheet 1). Just a very not smooth surface, actually not even fully coherent in many cases (lots of exceptions).
And when you don't optimize because you'd rather copy numbers (monkey brain who can't make educated guesses) than find the actual functions (which must be stupidly simple because games can't perform complex computations, but admittedly made to be hard to retro-engineer). Basically, Excel as a numerical emulator for some game space, some system to be gamified (empirical optimization baesd on axiomatic rules).
I sure have fond memories of trying to crack these problems. High success rate (like physics, it's real world so you approximate all that needs to be). I was one of those guys making turn-key "calculators" e.g. for items or progression in games like WoW, tools to solve complexity. The most interesting were social tools, e.g. for players to "fairly" distribute some resource (positive 'reward' or negative 'work') based on some KPI — how ethics, values translate into numerical models is quite the challenging but satisfying problem I find.
About Lisp, I assume you mean the programming language? That's indeed probably #1 in my list of "different things" to try. I've read people who literally grew up in Lisp, in the 1980s iirc, and how that changes one's perspective, actually much beyond mere programming. I've probably read the wiki page and a few articles along the years. But right now I've just committed to doing a Lisp-trip (training + small personal project) this year — yours was the straw that broke the procrastination back.
(To be honest, I've a weird history with programming, I started before 10 with BASIC but I'm just taking it professionally now (career change), some 30 years later. Go figure. Life.)
Thank you for elaborating and all the good advice / perspective.
> I wish for a computation system that would work with cyclic graphs.
It is baffling to me that we haven't such a paradigm available. I don't know much about academic CS but I'm fairly sure there's one among a gazillion formal languages that describes circular spaces.
Intuitively, I'd think it would have interesting applications for the programming (modeling, computation, reasoning) of oscillatory phenomenons notably.
I totally agree with you in 'practice', though I've tested literally none of it even on paper. The basis paradigm, in a best-effort thinking-aloud, is that any statement execution is a loop in itself; which fundamentally gives objects a 'thickness' in time, a time dimension; thus some φ or θ property (angular-whatever you want to measure, some periodicity expressed in a common clock).
Based on this, circularity is not a problem but a feature, and this would define some Fourier of a "program", a system of elementary executions — its periodicity in time, how "big" the loop.
I don't know, it's really interesting to think about such a paradigm of representation, of programming 'models' and 'problems', behaviors.
About O(n^x), I guess I was trying to be as general as possible. Indeed, that was exactly "dumb things"! Retrospectively I'd argue it's possibly by going everywhere including into the dumb that you really get a "feel" for a particular problem/solution space. Like flawed DAGs ;-)
When you naively translate ideas into computations (like a recipe to game something optimally), it may end up looking more like
In effect that last block (new sheets) creates new 'real' dimensions (with weird metrics) over the first 2D arrangement (sheet 1). Just a very not smooth surface, actually not even fully coherent in many cases (lots of exceptions).And when you don't optimize because you'd rather copy numbers (monkey brain who can't make educated guesses) than find the actual functions (which must be stupidly simple because games can't perform complex computations, but admittedly made to be hard to retro-engineer). Basically, Excel as a numerical emulator for some game space, some system to be gamified (empirical optimization baesd on axiomatic rules).
I sure have fond memories of trying to crack these problems. High success rate (like physics, it's real world so you approximate all that needs to be). I was one of those guys making turn-key "calculators" e.g. for items or progression in games like WoW, tools to solve complexity. The most interesting were social tools, e.g. for players to "fairly" distribute some resource (positive 'reward' or negative 'work') based on some KPI — how ethics, values translate into numerical models is quite the challenging but satisfying problem I find.
About Lisp, I assume you mean the programming language? That's indeed probably #1 in my list of "different things" to try. I've read people who literally grew up in Lisp, in the 1980s iirc, and how that changes one's perspective, actually much beyond mere programming. I've probably read the wiki page and a few articles along the years. But right now I've just committed to doing a Lisp-trip (training + small personal project) this year — yours was the straw that broke the procrastination back.
(To be honest, I've a weird history with programming, I started before 10 with BASIC but I'm just taking it professionally now (career change), some 30 years later. Go figure. Life.)
Thank you for elaborating and all the good advice / perspective.