^i unironically agree with the output stream man on this one

ai companies go bankrupt en-masse and the space is dominated by the myriad lobotomized distillations of their now dead abominations running on cursed ex-mining racks on life support with hosting payed for in hourly redditor blood sacrifice as an alternative to water cooling.

there is a satirical crossbreed of lovecraft and cyperpunk somewhere in there i think.

anyway training is kind of a prohibitively expensive bottleneck, maybe we should've figured that one out first. backup the shitty results you got cuz you aint getting many more out in this fucking economy. i remember back in forever ago there was this talk among techy fuckbois, that big leaps in hardware that would make running massive neural nets cheap, viable, sus tain(t)able, all that snake-oil peddling clown jizz was right around the corner. well who's laughing now josh, you're asscrack deep in the red.

tl;dr it's collapsing on itself, the saviour isn't second coming to rescue your gooning machines. god bless.

@AlgoRythm that is a superb example of why functional languages are both good and bad: syntax designed for brevity, but you have to do weird things like recursing when you actually mean to loop -- it's not as much succinct as it is obscuring the very semantics from which you could better infer programmer intent.

and though this intention is not at all obscured once you're used to reading this kind of code (i kind of am from second-hand smoking), it introduces a deeper problem in that what you write is not really what you're asking the computer to do; i cannot just effortlessly peek at the assembly through my mind's eye when i look at this, and that means i don't know what i'm *actually* doing.

but that's a problem of high-level programming languages in general, save for those closer to pure C. ironically, they pay for abstraction with disconnect from the underlying machine they are talking to. functional stands apart in that it inevitably deepens this effect.

@3dgoosee dude its *literally* in the bible

{And when he had apprehended him, he put him in prison, and delivered him to four QUATERNIONS of soldiers to keep him; intending after Easter to bring him forth to the people.}

ima rant a lot ok

in C, i'd want a binary format so i can parse it with structs and minimal logic, rather than parsing text which is way more annoying. inspecting/editing files in a more human-readable form would then be done in some utility program maybe

also no spatial partition means floating point precision is gonna fuck you in the ass. i'd say break the scene into cells and plot them in a graph or whatever, then arrange the nodes within each cell hierarchically

yes, you *could* use doubles for coordinates instead to push the problem into the heat death of the universe. but your future self will thank you if you do some form of partition anyway to make annoying-to-code bits like pathfinding and culling less stupid. algorithms that rely on "spatial awareness" so to speak can become a big fucking problem if the data isn't sorted for it

also 3dgoodes Y U NO QUATERNIONS

forgot question but still giving answer uuh mystery of universe

@AlgoRythm the academic circle jerk does indeed breed higher forms of degeneracy.

but more on topic i vaguely recall trying both ocaml and haskell at one point out of curiosity forever ago, wanted to see what the fuzz was about. my lasting impression is that functional languages were specifically designed for mathematicians to cosplay as programmers, i really do get that vibe.

as i see it, strict FP makes nearly everything more complicated than it needs to be for no benefit, save a vague sense of correctness that i find to be more illusory than anything else. akin to writing an abstract class for the first time, not quite right but feels like it if you think hard enough. i can't stand the hyperfocus on theory rather than practice is what i'm getting at.

anyway, learn haskell, 0/10 it's the last thing i would recommend to a sentient being. but if you want to learn functional it'll do the trick.

@12bitfloat yes. retoori wanted to gotcha you with trick question, but phrased it in a way that makes the surprise response fall flat. she is internet fren so i play along.

> both have indentation as syntax

sacrilege

i didn't even college lmaoooo

anyway whats the name of that stupid site where people solve trivial coding problems with no practical application for internet points that mean jackshit?

thats what nerds are good at, and thats what a lotta companies design interviews after. put two and two together.

in general i consider it a mark of ineptitude. if you've taken the time to be that good at solving math class style problems then you ain't ready for the real world, i'm afraid.

also downvoting for smap~

@YourMom to godot's credit, they at least let you use C++. i only riff on godot becuass i have beef with arch altright clickbait man and tinfoil brigade commander acedragon who is a godot fanboy. wow. much lore. such expanded universe.

@retoor googled video to give punitive dislike~

this message is written in a declarative programming language because of homosapiens brain interpret.

inb4 godot user suggests html is a programming language~

@whimsical no, cannot drop. need bedtime stori.

@Hazarth take pity on poor ceo he need more yacht for bahamas~

@whimsical i am the mike

@Liebranca oh noes too late to edit. where it says "usage patterns (...)" it should say "stack usage patterns (...)"

@whimsical yes i have the good shit on speed dial https://gist.github.com/Liebranca/...

the OS owns all physical memory that the BIOS doesn't reserve for hardware. stack is part of the *virtual* memory given to your process by the OS at startup. heap is the exact same thing, just given at a later date.

the real difference -- and cause of overhead -- is two-fold: one, that usage patterns plus contiguity and frequent reuse is much more cache efficient. and two, that in nearly every scenario you have an involved mechanism to manage the heap, keeping track of occupied/freed blocks to enable checking for reusable space before asking the OS to allocate more pages to the process.

if you dynamically allocate a large block and set it as the stack you've eliminated the overhead. because memory is just memory. but we could also say it's just stack allocation with extra steps :)

but retoori, the *right* question is 'what is faster, stack or heap?'

i mean for real, who even std::cout << "does it like this." << std::endl.

@12bitfloat perl is more or less bash on steroids. it's very convenient for string processing, and surprisingly fast at it too, so i tend to use it a lot. but 95% of this virtual machine stuff i actually shouldn't be doing in perl like at all lmao.

@whimsical reviewing that would be such a nightmare that i think i like my chances better with a straight-up rewrite.

@12bitfloat mainly? i like writing assembly, and spent a good time doing it, so it's kinda easy for me to generate assembly. i then just designed the vm to be similar enough to make it viable, and that was that, pretty much.

here's that 'complex' memory operand getting decoded https://github.com/Liebranca/... the 'seg' part is from back when i was doing segmented memory, which isn't actually the case anymore. anyway, it's actually like what... 40 SLOC? :)

ok im cheating because it's perl. i should rewrite it in C to be honest. but i'll use my preprocessor, which does let me use perl inside C macros. hehe.

but anyway defining your own ISA kinda helps, which is what i did here. you just take the instructions you actually care about and the rest...

EDIT: oooh my bad, i read the operand wrong. anyway, it's just swapping out what is multiplied by the scale.

@12bitfloat my backend is flat assembler lmao. i compile first to bytecode, and then transpile that into fasm, with the big-brain idea being oh i can eventually support more than one architecture if i write more translators.

but my virtual machine is *kind of* like an x86, and what i output has to be valid x86_64 assembly code for it to work, so wink wink, not all *that* different.

@12bitfloat maybe i derailed this conversation but interesting nonetheless.

you have some way of knowing what to bother preserving from the caller's context, right? you don't just blindly push everything on each call.

well then, you don't need a fixed convention because you have access to that information. there's but a handful of exceptions: recursion, function pointers, and extern/system calls. in *those* cases it's mandatory.

but if i have an internal symbol, which isn't recursive, calling any externals/indirect calls, and is not itself used for indirect calls, then i can do whatever i want. unadvisable if i was handrolling assembly, of course, because i'd just lose track of things. but that's not what we're doing here is it.

you can pass arguments or return results in non-standard locations when it's convenient, and if you're juggling registers, it usually is. but my brain is tortellini right now so i'll leave it as homework for the reader to figure out the rest.

@whimsical retoori do you realize you are opening the gates of hell i will never shut up

@12bitfloat not implying but "little moving parts" can sometimes also mean "blocks that could've been isolate have cthulu as umbilical cord". is it *really* an absolute necessity?

since you're talking about the abi, guess i'll give you a related example. suppose i respect the calling convention even when i'm not inside main, nor making syscalls, nor inside a symbol that is exported for use by other programs. why ain't i such a boy scout. but i'd be following an interfacing rule for non-interfacing code, which i don't *have* to do. and then extra work that i could've handled only in very specific cases would instead be propagated to the entire codebase for no benefit.

now, that itself is a non issue, but if you're keeping more than seven or so concerns like that in mind at the same time, all the time... not to sound like uncle bob but that's liquid.

holdup more comment.

@retoor constant time is a lie. relativeteey!

@12bitfloat are you:

[A] doubtful it gets easier

[B] despairing at the prospect of starting over

[C] both

either case, it's an iterative process at heart. chars to tokens to expressions to blocks to instructions and then to value if const: it really is a chain of maps.

the odd part is that the flow isn't linear due to the "value if const" bit making recursion inevitable. which raises the question: must i be able to execute the instructions *while* compiling? to which the answer is yes, you do, and if you don't design around this you're gonna have a bad time. whether you prefer to think about it as such or not, you're still inevitably building a virtual machine.

point being: once you have a clear mental model of the system (and what it does) it becomes much easier to implement. but to achieve that, you have to reduce complexity, which relates to **relationships between layers**, not necessarily size; it'll still take time, obviously.

i could go on but comment size.

writing a compiler is easy, but only after you've done it a *few* times at least :)

@YourMom nothing like smoking a fuck* after a good camel.

@DubbaThony to become a señor developer you must channel your inner jirafales. obviously.

but to answer your question more directly: six hundred years of microsoft experience.

nabataean fuck riders