/dpt/ - Daily Programming Thread

JavaScript rocks!

Attached: js-rocks.png (1000x494, 369K)

are you saying the next big language is going to be stack overflow?
yup.thats nothing compared to my computer networks professor who thinks acoustic waves belong to the same spectrum as em

It's here for the long haul, and I have mixed feelings about it. On one hand, there is a legitimate need for a language that enables rapid development. If I want to automate a build system, for example, there's no way in hell I'm doing that shit in C. Or, if I need some rudimentary OCR capabilities, but I just need it to work and have little interest in learning the nitty-gritty details of Tesseract, I'll just use pytesseract.
On the other hand, Python is a poorly designed language. Its static analysis should be checking for out-of-scope variable use instead of throwing runtime exceptions. Type hinting should be used for static analysis, as well. It should also have some kind of implicit type system- no arbitrary reassigning of variable names to completely different types.

>JavaScript rocks!
did you meant stones?

Attached: stoning.jpg (215x234, 12K)

That's working out the hypotenuse of a rectangular prism.
But you can also work that out in two steps by doing it with x and y, and then separately again with z.
I really can't be fucked doing the algebra to prove that, though.

I don't think so.
hypot(x, hypot(y, z)
= root(x^2 + hypot(y, z)^2)
= root(x^2 + root(y^2 + z^2)^2)
= root(x^2 + y^2 + z^2)

Oh yeah, you're right.

It's confusing enough that it made me seriously doubt myself. It becomes a little more "obvious" if you can see a diagram like describes

Attached: 1524493936105.jpg (588x594, 39K)

Lisp is the most powerful programming language.

Inheritance inherently sucks because it breaks encapsulation

>Liskov was a woman
Color me surprised

>Liskov was a jew
You shouldn't have trusted OOP from the start.

Interface inheritance doesn't, and that's the kind of inheritance OOPfags recommend you use preferentially.

But then inheritance is just a more awkward kind of trait.

I'm curious about this. Can you explain more?

>thinks acoustic waves are EMR
I have trouble believing you. But my brother did have a physics teacher in high school who thought you couldn't split the atom.
This was after 1945, to be perfectly clear.

Python is pretty solidified. Its hit the perfect sweet spot between being very high level and pragmatic without trying to facilitate retards like meme languages like Ruby

>3 yuno threads in a row
Truly a great time to be alive.

Attached: hs8.jpg (451x541, 58K)

I wasn't the last OP, but I thought I'd follow the trend.

Attached: 1543220845606.gif (1050x850, 1.97M)

if you are using exceptions to do anything but crash to desktop you're doing it wrong

encapsulation was a mistake

>programming in C for a game
>making structs and procedures
>hm, would be nice if i could put those procedures inside the struct and make it "one thing" TM.
>*looks at C++*
>NO, shoo c++, go away.

Does haskell stay based or does it turn to shit once you use it in The Real World?

computers are not functional, so no, it stays dead

catch (Exception e) {
//this page is intentionally left blank
}

>>hm, would be nice if i could put those procedures inside the struct and make it "one thing" TM.
No that's dumb and fucks with optimisations. You shouldn't use function pointers without a good reason to.
struct thing {
...
}

void thing_do_whatever(struct thing *t);
is the best way.

OOP methods aren't function pointers, unless they're virtual

Why do you want to make it one thing?

Just use UFCS syntax sugar in BetterC.

>pointer
Is there a better abstraction for referencing that doesn't pin values in memory as easily?

references

>pin values in memory as easily
Why would you care? If you're going to need to realloc the struct in the function, pass a **.

depends on the application lad.
Despite the shitposters REEing, haskell has found an overwhelming success in a lot of fields.

Currently I am doing this
struct thing;
struct things[MAX_THINGS];
void do_something(int i){
// thing[i]
}

shitposting on /dpt/ isn't a field

That's bad.

fuck should be
struct thing things[MAX_THINGS];
//things[i];

you should pass in a pointer to a thing

wiki.haskell.org/Haskell_in_industry
github.com/erkmos/haskell-companies
>inb4 "lmao none of those count"

why?

global state is always bad, it makes your code difficult to refactor if you ever need to use a struct that isn't part of that array.

lmao none of those count

because if you want to access a field of thing you have to first get the thing at i, then the field at thing
pass in the pointer to the thing and you only have to dereference once instead of twice to work with it

>global state is bad
oh no-no-no-no... how fucked am I? (358 lines of globals) #include DATA.H

Attached: header_with_all_globals.png (152x594, 19K)

>how fucked am I?
super fucked. globals give your computer viruses. you're lucky yours still works

Using an array like that doesn't require an extra dereference.
But yes, it's smarter to use a pointer to the type and not have a bunch of needless global state.

nice thumbnail

>Using an array like that doesn't require an extra dereference.
yeah it does, you have to get the thing at i before you do anything to it

From the blurry microscopic image that looks like constant data, that's fine.

*(things + i) is the thing right?
I just
do stuff like
things[i].big_guy = 4U

Is this some sort of picture for ants?
It's fine only if it's const, because there it doesn't actually count as state.

The compiler is just going to access it as offsets from the start of the array.
Basically *(array_base + index * elem_size + member_offset), which is only a single dereference

should have said another operation, it needs to offset aswell as deference instead of just deference, which is more expensive

I cant upload a 20000 pixels long whatever

One more add instruction isn't gonna cost very much.

I would seriously hope the compiler only does the main offset value and keep it.
But this is getting to the point of talking about actually useless micro-optimisations.

I know.

>20000 pixels long
That's one hell of a monitor you've got, kind of jealous.

so what the fuck do you propose?

I *have* to iterate over my things
for(int i = 0; i < MAX_THINGS; ++i){
thing* ptr_to_thing = things[i];
do_something(ptr_to_thing)
}

this is the same crap right?
do you want me to store it like this?
thing thing0;
thing thing1;
thing thing2;
...........
thing thing9123;

struct thing array[n];

for (int i = 0; i < n; ++i)
do_thing(&array[i]);

it would need to cache it somewhere, which means using extra memory against your orders which compilers generally don't do
although in the assembly I've done instructions allow you to include offsets along with the instruction, so it might just be no cost
but it's better practise just to pass the pointer so you're sure

>extra memory
It would be a register, which you'd need to use when passing the argument anyway.

that example is fine

Most of what you see is static const
I dont know if the static does shit for me tho
Its like putting const in front of auto-storage (temporary) variables inside a function, it does ABSOLUTELY NOTHING optimization wise.

Attached: header_with_all_globals.png (285x750, 30K)

and??
getting the adress is the same is it not?
you still create a pointer to &array[i] and pass that, it needs to happen,

the only argument i see here is

array[i].member1 = 123123
array[i].member2 = 123123123

this is bad because i fetch array[i] twice?

>this is bad because i fetch array[i] twice?
yes
its redundant

OK. so I could literally do
do_something_with_thing(int i){
thing* ptr = &thing[i];
ptr.member1 = 213123
ptr.member2 = 2131238
}
and just pass an int and it would be the same right?

yes but it doesn't make sense because why are you accessing global state from within a function

>why are you accessing global state
because the array of things is stored globally for easy access?

>Uhh... you realize that this:
>b ? ((b % 1000) ? (b % 1000)/100 : 0) : 0;
>Is equivalent to this:
>(b % 1000)/100;
>Right...?

I initially wrote the latter but i thought that if b is ever 0 it would give me a floating point exception.
Upon further inspection it seems that is not the case....

Attached: eeb161ed0103676b8657f90a21f519e8.png (451x619, 428K)

one of the princples of good programming is to reduce dependencies. Your function is now dependent on that array for absolutely no reason. There's no reason why you can't just pass the thing in on its own

So it's because I might change the name of the array or how I store the things? It's better programming because its less changes to be made?

exactly
thats how you build large programs without it collapsing under its own weight

If it's just for fun, PNG has a pretty neat file format.

What about this then? My things have a member that is a function pointer
(void)(*update)(int i);

I do this so I that when I iterate over my things they know who they are
for(int i = 0, ...)
thing[i].update(i);

void update_func1(int i){
things[i].member1 = 1823182;
//etc.
}

should I change it to take a pointer to?

yes

I also have a method that grabs things that are free, like in a free list. This is implemented using stack so its natural to have indices here. I mean if I were to pass a pointer to freesprite it would have to calculate what index in the array it is in. These functions basically need access to global state to do anything at all

Attached: globals_everywhere.png (412x278, 14K)

hmm.. But the same argument could be said if I change the name of the type of the thing? Now I have to go around changing the name of all the pointers. I wouldnt have to do that if I just gave it an index

I guess but you change variable names much more frequently than type names

Name of book please

The idea that the function he provides
sqrt(x**2 + y**2 + z**2)

obviously boils down to the following
sqrt(x**2 + sqrt(y**2 + z**2)**2)

Then, if there is a function like such
hypot = lambda a, b: sqrt(a**2 + b**2)

Then you can use it to turn the above into
hypot(x, hypot(y, z))

I think I will do a hybrid for now because of the free-stack thing. So pass an integer but create a temporary pointer for the sprite so I only have to derefence it once.

It does lead to another question though.
My sprites has several members that are also structs
typedef struct Sprite{
Pos position;
Tex texture;
....
} Sprite;

Would it then be faster to have these just stored directly since I don't have to do this?
sprite->Position.x

and instead could do
sprite->x

?

no
-> is a deference, which is a runtime operation, but .x is already known at compile time so it's basically free
at least from what i recall, i don't use c

arxiv.org/abs/1502.05767 on page 17

I mean if the function is supposed to modify global state, what is the point of not just writing it there?
I could of course create a pointer to the global state data and then send the pointer, would that be better practice?

Attached: Commissar_closeup.jpg (1210x801, 269K)

The idea of functions is they're supposed to be generic and reusable. If your function does something to a thing, there is no reason to only have it modify specific things stored in a global array when it could just modify any thing. The latter you can use anywhere, the former only operates on that one array

so send a pointer to the global data as well?

Sure. Or send a pointer to something allocated in main or elsewhere in the stack.

I dont know what you're trying to do
If your function just need a thing, pass a pointer to a thing

Should I learn Haskell?

learn erlang

assert girl(male);

Attached: 1536729500614.png (804x637, 64K)

So move all my non-constant globals into main,
create them there,
and then pass pointers to them
because justbetter TM?

no you should understand why minimal dependencies are good and make decisions appropriately, don't do something if someone tells you its better
If you have a function that changes some global state you dont neccessarly need to bother passing it in as a pointer

Why
I want to learn functional programming, that's why I was interested in Haskell