/dpt/ - Daily Programming Thread

What are you working on my dudes?

D edition

Other urls found in this thread:

hastebin.com/ofufilexew.py.
glslsandbox.com/e#35009.0
test.meguca.org/g/282
twitter.com/SFWRedditGifs

First for D

They're both garbage. You don't need a "system" to decouple data from behaviour, that's just procedural programming with structs.

First for monads

>unironic Haskell use

ohoho

...

Which big companies actually use Haslel?

Oh that's right, none of them!

>implying it's Haskell

>implying it's not Haskell

Not an argument

Facebook

And Simon Peyton Jones works at MS Research

He said major company, not micro company

#rekt

procedural programming with structs as conceived in e.g. C/C++ has some serious deficiencies that are widely recognized

the simplest and most grokkable is that arrays-of-structs (a vector of xyz positions) and structs-of-arrays (a struct containing 3 distinct xyz vectors) are not compatible despite representing the exact same data (in row-store vs. column-store form). the rows of the column-stored data are not easily recognizable as structs/classes in C/C++ because structs and classes must be stored contiguously. decoupling the Object data and Object behavior makes it possible to write systems where the data layout is handled by a platform-appropriate manager (for example, the PS3 vastly preferred columns because if its streaming semantics)

this has tremendous performance implications and the Intel compiler for example actually provides extensions to handle this transformation implicitly. these are the same concerns seen in databases and ECS systems strongly resemble databases, whereas first-class programming language data constructs do not (but they really should)

>decoupling the Object data and Object behavior makes it possible to write systems where the data layout is handled by a platform-appropriate manager (for example, the PS3 vastly preferred columns because if its streaming semantics)
struct Position;
struct Velocity;
struct Sprite;

void move(Position *, Velocity);
void draw(Position, Sprite);

You can structure the entities however you want and the actual meat of it (above) doesn't have to change.
AoS:
// doesn't have to be the only entity type, just an example
struct Actor {
Position p;
Velocity v;
Sprite s;
} entities[100];

// can reduce boilerplate with a map function
for(int i = 0; i < 100; ++i) {
move(&entities[i].p, entities[i].v);
}
for(int i = 0; i < 100; ++i) {
draw(entities[i].p, entities[i].s);
}

SoA:
struct Entities {
Position p[100];
Velocity v[100];
Sprite s[100];
} entities;

for(int i = 0; i < 100; ++i) {
move(entities.p + i, entities.v[i]);
}
for(int i = 0; i < 100; ++i) {
draw(entities.p[i], entities.s[i]);
}

I just posed the following question to one of my classmates:

Write a function which takes the following list as input [1, 2, 3, 4, 5] and returns the list [3, 5, 7, 9, 11] by means of recursion.

He could not solve it, even though it is pretty simple hastebin.com/ofufilexew.py. Are people working in the field this retarded?

>no anime image

do you even program bro

Do you guys know of any books to get started with modular arithmetic?

He is like a little baby
Watch this
fun :: [Int] -> [Int]
fun xs = map (\n -> 2*n + 1) xs

Haskell is anime

>D edition
>2000px-Haskell-Logo.svg.png
niggawatt

>by means of recursion

Will playing TIS-100 help me later to learn assembly? It's for embedded systems.

This game shouldn't be as fun as it is.

Retard.
fun = map $ \n -> 2*n + 1

map's doing the recursing for me
desu I'm still learning Haskell and still can't get $ to work properly for me ;_;

map $ (+1) . (2*)

Just scrolling through the wikipedia list of algorithms, stopping at everything that looks interesting.

>Haskel-logo
>D edition
okay mate

f $ n = f n

e.g.
f $ a + b
= f (a + b)

True, but point-free has diminishing returns of brevity as a tradeoff for clarity.

In that case, it's equivalent to:
fun = map (\n -> 2*n + 1)

The bigger thing is that you can leave out the xs parameter there entirely due to currying.

I guess it'll get you into the general assembly mindset, but it won't necessarily teach you it since every assembly is different

lmao


def twoplusone(lst):
if len(lst) == 1:
return [2*lst[0]+1]
return [2*lst[0]+1] + twoplusone(lst[1:])

See, I would try something like
fun xs = map $ \n -> 2*n + 1 xs

and it would throw an error every time, but I think I understand now why it wasn't working

ugly as sin
what is this god awful language

1. your actor/entity independent move and draw code (which operates directly on components rather than actors/entities typed "with" those components) is a big chunk of all that an ECS really is. you have a move behavior that's decoupled from the actor data, you don't call actor.move(), you call move(actor.data). that's decoupled.

2. the part that you are missing is that that the way you get data differs between the two cases (entities[i].v versus entities.v[i]), which means if you change the data layout you have to change every accessor. an ECS would abstract this, so you don't have to know the layout

3. systems are game-specific and so game designers are implementors of systems. however, in an out-of-the-box game engine some systems and components associated with them need to be provided (like the render engine, which depends on position data). these preexisting components need to be made accessible to users in a manner independent of their internal implementation

tl;dr all an ECS does is wrap database-like concerns behind a uniform abstraction so that system implementors (who are the users of the game engine) don't depend on them. here is another really hard, database-like concern: some data components are sparse and should be stored in sparse arrays, whereas others are dense and should be stored in dense arrays. this is the kind of thing a system implementor shouldn't have to know about a component to access it (and god forbid you need to join on sparse/dense arrays of components because your system requires "all components with a position and a sprite")

imagine you'd written
map $ (\n -> 2*n + 1) xs

now the compiler sees
map ((\n -> 2*n + 1) xs)

now the compiler tries to apply xs to (\n -> 2*n + 1)
(not what you wanted)

python

fucking sneks
why do they still post here

def map_recurse(function, inp):

h = function(inp[0])
t = inp[1:]

if len(inp) == 1:
return [h]
return [h] + map_recurse(function, t)

a bit cleaner

that's just as fucking ugly

Which is almost the same solution posted in the link at

>2. the part that you are missing is that that the way you get data differs between the two cases (entities[i].v versus entities.v[i]), which means if you change the data layout you have to change every accessor. an ECS would abstract this, so you don't have to know the layout
You can abstract it more (typically with templates or macros) without delving into something doing it for you with runtime overhead.

>3. systems are game-specific and so game designers are implementors of systems. however, in an out-of-the-box game engine some systems and components associated with them need to be provided (like the render engine, which depends on position data). these preexisting components need to be made accessible to users in a manner independent of their internal implementation
No reason to couple that stuff to any sort of entity representation.

>here is another really hard, database-like concern: some data components are sparse and should be stored in sparse arrays, whereas others are dense and should be stored in dense arrays. this is the kind of thing a system implementor shouldn't have to know about a component to access it
This is just a generic abstraction issue, nothing to do with the provision of a built-in "ECS".

>and god forbid you need to join on sparse/dense arrays of components because your system requires "all components with a position and a sprite
The "systems" (presuming you're talking about the procedures) don't know about entities at all, they just take components.

plus this won't work for an empty list

I see, yes that solution is better.

Nice. Works for me. I know the language from TIS is not assembly per se.

Is it bad to learn Python 2 over Python 3?

It's bad to learn Python at all

Playing with some GLSL. Wonder how long till they remove it.

Forgot link: glslsandbox.com/e#35009.0

...

Why not just have a cute anime girl?

>>>/cuck/

I don't know how to do it in GLSL.

What is your rationale for learning 2 over 3? Python 3 is a big improvement to the language in terms of consistency and expression. The fact that Python 3 uses UTF-8 also reduces the number of potential headaches with the language.

this

Oh, I thought the Swastika was a background for your editor or something, I wasn't looking close enough

D shillers are multiplying...

Why would one choose D over something like C++ or Rust?

Warehouse System

No, it's a GLSL shader.
D is superior to C++ and I haven't used Rust, but it looks weird.

You guys forgot the input values..

(1..5).map {|i| i*2+1}

Because you don't have a job so things like a stable API aren't important to you

Live shitposting engine. Still beta-ish. test.meguca.org/g/282

He said write a function to do it, not do it

glsl looks like total shit

Why? It looks mostly like C.

needs js ;_;

this

Is there anything to learn DX9 HLSL like in those glsl sandbox sites?

Because it's not C. They could just make a few extensions on top of C and keep it backwards compatible but they didn't.
void main? wtf

>asking a question
>answering it yourself

Why would you learn DirectX at all?
Why not OpenGL?
Why not Vulkan?
And why the fuck would you learn obsolete version of DirectX?

why not

>implying C looks bad
Why would GLSL be backwards compatible with C?

this
directx is literally a perpetuated meme that microsoft won't let die
if we got rid of directx we could all be using opengl and nobody would have any issues

>Why would GLSL be backwards compatible with C?
Because it could easily be?
Because C was made as a portable language and they made changes that were not needed?

1. It's proprietary Microsoft API that only works on Microsoft products.
2. The competition (OpenGL and Vulkan) works on all major desktop OSes, game consoles, mobile phones and in web browsers.
3. It's more ugly (it has tons of functions taking structures with typedefs 100 characters long).
4. It's obsolete.

OH MY GOD this completely aesthetic revision which has no impact on performance and a negative impact on readability is SO MUCH BETTER

why are husklel users such little faggots? all they care about is that their code looks pretty

C lets you do a lot of things that are not possible on the GPU, certainly not when GLSL was introduced.

Hi Chris.

>wanting ugly code
you must be an ugly person

WASM soon, but otherwise there is no other way to implement this right now. Not that statically typed JS without any framework memes is slow by any margin and the code is FOSS and source-mapped, if you are concerned about spying or something.

There's nothing wrong with Python

Hello

>negative impact on readability
Maybe if you don't know the language, and why should I care if you don't?

>C lets you do a lot of things that are not possible on the GPU, certainly not when GLSL was introduced.
Such as?

you are the definition of a code monkey

off yourself

>Because it could easily be?
Not really, it couldn't.
Sharers don't manipulate pointers. Shaders don't manipulate character arrays. Originally, GLSL didn't even fully support integers.
Both languages have different scopes.
>Because C was made as a portable language and they made changes that were not needed?
What changes that weren't needed? Like new functions useful in shaders? Like vector types to gain access to SIMD on GPUs?

...

He's right though, map (\x -> 2*x + 1) is better than map $ \x -> 2*x + 1


*antonym

Well yeah, it's going to be unreadable if you don't know the language.
hey bby

>1. It's proprietary Microsoft API that only works on Microsoft products.
This is wrong, the api is public and there are multiple free implementations of it.

>2. The competition (OpenGL and Vulkan) works on all major desktop OSes, game consoles, mobile phones
Just like Direct3d

>and in web browsers.
Doubtful for Vulkan, did they actually try it?

>3. It's more ugly (it has tons of functions taking structures with typedefs 100 characters long).
Have you actually tried OpenGL? It's worse. Also, you included vulkan, where you have to type 10x the amount of code to do the same thing.

>*antonym

code monkeys worry about code, programmers and computer scientists worry about data structures and algorithms

the gpu hardware is very different to cpus, the language has to be far more restricted than C

dx9 is deprecated as fuck, if anything you'd use dx11/12 but you'd be better off with modern opengl or vulkan

>Also, you included vulkan, where you have to type 10x the amount of code to do the same thing.
Same as D3D12, but if you don't understand the reason for this you need to kill yourself.

>Sharers don't manipulate pointers
And?

>Shaders don't manipulate character arrays
They do manipulate arrays however.

>Originally, GLSL didn't even fully support integers.
Citation needed.

>What changes that weren't needed?
Many, such as the lack of goto or void main.

Does not really help.

quit hatin bro haskell code looks awesome on my riced out desktop LOL

C has pointers as an integral feature. GLSL has no need for pointers as GPUs cannot utilize them.

>code monkeys worry about code
No, they don't. That's why they're code monkeys. They just stream out endless wastes of mindless characters.

gpus have limited support for branching

>the gpu hardware is very different to cpus, the language has to be far more restricted than C
How so? I am pretty sure that every feature that C requires in a freestanding environment can be implemented on GPUs.

>C has pointers as an integral feature
Yes, and?

> GLSL has no need for pointers as GPUs cannot utilize them.
I fear that you do not understand how pointers work. You do not need to access random addresses, you would only need to be able to access certain objects that you defined, something that could be implemented.

>This is wrong, the api is public
I haven't said it's not publicly available, but that it's proprietary.
>and there are multiple free implementations of it.
Such as?
>Just like Direct3d
What? Direc3D only works on Windows (doesn't on GNU/Linux, OS X and FreeBSD), and Xbox (not on Sony's or Nintendo's consoles), only on Windows Phone (that's like 5% of smartphones) and probably on Ie/Edge (Not Firefox or Chrome or Safari).
>Doubtful for Vulkan, did they actually try it?
I don't know, not yet probably.
>Have you actually tried OpenGL?
Yes.
>It's worse.
Not really.
>Also, you included vulkan, where you have to type 10x the amount of code to do the same thing.
I could be wrong, but the same is with OGL 3.1+ and D3D 11+. Lower level APIs mean higher performance but harder to code directly.