/dpt/ - Daily Programming Thread

old thread: What are you working on, Sup Forums?

Other urls found in this thread:

hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor.html
wiki.libsdl.org/SDL_Point
m.youtube.com/watch?v=_hnc5PqipYs
youtube.com/watch?v=ame2PH67gnk
twitter.com/SFWRedditVideos

First for Guile

xth for statically typed languages

OpenDNS API integration

Yay CRUD

Static typing is obsolete, now that we have the processing power to make dynamic typing performant.

Dynamic typing causes runtime errors and unexpected results.

Compile-time errors > runtime errors

ACTUAL THREAD

kill yourself

In which situations would a *restrict pointer actually improve performance?

Kill yourself.

Just look at the python user from last thread.

He couldn't figure out why his function was returning void because dynamic weak typing was like "lol ok I'll just return None"

Interactive development helps avoid such errors, which are in any case a small fraction of the total errors encountered during software development. The rapid development of software that is enabled by dynamic typing more than makes up for the small increase in runtime errors during the development process.

stop spamming because your thread lost you autist

Worse than the Norway thread teebeeaitch

>small increase in runtime errors
It's nice that you think that, but notice the bigger issue: unexpected results that are not errors.

The worst thing that can happen in a massive codebase is something not working quite right and no errors being thrown, particularly when working with critical data or money.

wow i love c

Fixed a memory issue in my music player. Now it uses 17mbyte instead of 460mbyte.

Wew

What language, mummy?

T D D
D D
D D T

I'm not in the dynamic typing crowd, but a correct algorithm will yield correct result regardless of whether it has been type-validated or not: it's correctly typed by definition.

static typing seems bad only because of Java

When you have hindley milner inference, it's based

Even better when the langauge is expression based and type system is evolved past 1970

what? you forgot to free something?

Silent side effects can be just as devastating as (if not more so than) unexpected return values, and yet they are embraced by all mainstream statically typed languages. I think immutability and referential transparency are more important than static vs dynamic typing.

>lol just write every function perfectly without anyone on your team ever making a mistake
Meanwhile, in the real world...

C# master race

static by default
dynamic if I want it to be

managed code with GC by default
unsafe code if I want to use it

I'm repeating myself, but
T D D
D D
D D T

Not sayin you should write perfect code at all. Try again.

Tell me about how it can't implement functors

What is that diagram?

What even is this alphabet soup bullshit

Tdd, is that you?

Yes, have fun being a test monkey when you could eliminate 80% of your tests by using a proper type system

What is the use-case for a "functor"?

I've genuinely never heard of them.

>let me manually write all this testing boilerplate guaranteeing types when I could just use a sane language

Lots of file handles.

hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor.html

A use case is whenever you need one.

With it, you only need to implement fmap for a type and you get all the other functor methods for free.

No mateys: Tests supercede and deprecate Typing, don't tell me you don't write tests? Typing doesn't excuse you from testing, but testing does excuse you from typing. Get this reasoning or is this too complicated for you munchkins?

Sorry, I'm not going to pore over Hasklel documentation to determine what my own use-case would be.

If you'd like to give a real-world example, I'm all ears.

"Functors" are informally things you can map over. Examples:
λ> import Data.Char
λ> -- apply function to all the elements of a list
λ> fmap ord ['a', 'b', 'c']
[97,98,99]
λ> -- apply function to all the outputs of a function
λ> let f x = replicate 3 x
λ> f 'b'
"bbb"
λ> let g = fmap (fmap ord) f
λ> g 'b'
[98,98,98]
λ> g 'w'
[119,119,119]
λ>


It's not that you can't implement functors in C#, it's that you can't implement Functor in C#. That is, you can't make a class or interface or whatever that captures a "Functor".

No one said not to use tests, but adding a massive quantity of tests JUST for type verification when the language could do that part for you is a pain in the ass.

Dumb fucking faggot.

SDL_Point* point = new SDL_Point(x+10, y+10);

Why does this give me an error? It says: "new initializer expression list treated as compound expression."
x and y are both ints.

Of course you can write tests in statically-typed languages too. But you won't have to write the ones that are basically just typechecking, and it'll be better because you'll automatically have complete coverage for anything your types cover.

prolly because the arguments of SDL_Point are not ints

Found the college undergrad.

Why would a language not concerned with memory management support type inference?

Found the NEET

*I mean why would they NOT support type inference

They most certainly are.
wiki.libsdl.org/SDL_Point

yeh
>>> rev = lambda s: ' '.join(s.split()[::-1])
>>> rev('poo in loo')
'loo in poo'

Python lambdas are a joke, though.

why?

you can't just go on the internet and say "Python lambdas are a joke, though."

I just did.

"poo in loo".ReverseWords();

Types are straightforward and evident shit; if the type is wrong that means the value is wrong too, and by executing your test you'll catch that. Meanwhile, a wrong value of the right type can still typecheck, so you're still going to write the exact same tests (only with 10x more type bolierplate than code OLOLOLOLOLOL). I still think that proper testing can supercede type checking. I'm not arguing we should get right of typing because of that tho, it's just for the sake of the argument.

i want some methods do things and return a boolean value indicating if they did it correctly, but also to store information in an object passed as an argument when it goes incorrectly. what's the name for this technique?

i mean to do it in python specifically

so you have no arguments.

got it.

It's probably just some schemer memer

Much like everything else, it seems like more wankery.

Like you said, that series of functions is easily implemented in C#.

I'm not sure why anyone would care if it's called a 'Functor' or not.

Python's scoping makes them almost useless.

i'm working on a custom trie in c++.
i have it set up so each node has its own vector of nodes, which are its children

i want to be able to traverse the trie - but i'm not quite sure how i'd do that. does anyone have any suggestions?

Honestly, you'll understand the benefits of dynamic typing the first time you work on a real project. When there are actual consequences to the correctness of your code, you learn not to trust yourself to do the compiler's job.

provide some examples

I'll leave to you, I'm not very good at explaining things.

fn main() {
let rev = |s: &str| s.split_whitespace().rev().fold(String::new(), |r, a| r + " " + a);
println!("{}", rev("poo in loo"));
}

>you'll understand the benefits of dynamic typing the first time you work on a real project.
so, you'll use python and not C++?

what are some dynamically typed languages?

That's true, I don't like them myself but I still used a lambda instead of a regular function definition because I thought it fit the theme better but I absolutely agree that Python's lambda are garbage and pretty limited.

What language would that be?

No, it's what's known as a non-constructive proof.

stop posting. no one cares about your meme language

>When there are actual consequences to the correctness of your code, you learn not to trust yourself to do the compiler's job.
This is an argument in favor of static, strong typing.

The compiler does LESS in a dynamically-typed language, forcing you to do more of the manual testing labor.

Unless of course you meant "not to trust the compiler to do your job".

vomit/10

>What language would that be?
C#

>1+1 = 2
>prove it
>believe me bro!

I love that simply posting Rust code triggers people

Try this on for size, Python fans:

(uncurry (++)) . (filter (9 /=))

>forcing you to do more of the manual testing labor.
No you don't. You do the same quantity as you should, but you get more from it. Meanwhile, you don't have to clutter your code with self evident typing information, or the even more absurd "compiler, please infer this type for me" bs.

How would you test something that does IO?

>muh lambdas

I meant to say static typing.

A static compiler would have caught this error before I posted it.

Fucking hell, user.

You've gone and derailed the argument because your typos was THAT bad.

>or the even more absurd "compiler, please infer this type for me" bs
Now you're just fucking trolling.

m.youtube.com/watch?v=_hnc5PqipYs

youtube.com/watch?v=ame2PH67gnk

Seems like you missed the main & imports then, no? Both Haskell and Python solutions will work unto itself with no further additions.

Can Python curry functions?

maybe, but I know that Python and curry go hand-in-hand in India

yes.
def f(a):
def g(b):
def h(c):
def i(d):
def j(e):
print(a, b, c, d, e)
return j
return i
return h
return g

print f(1)(2)(3)(4)(5)

There are two reasons I can think of right now why you would want to make "Functor" a tangible thing in your language. As said, you don't have to reimplement functor-related shit for each type.

A related usage is when Functors are taken as input, not just simply existing. Admittedly, the only example I can take off the top of my head are Lenses (mainly used in Scala or Haskell), which are themselves sometimes called wankery. Without going into their details, a Lens is represented as a function, that must be able to have inputs and outputs that range over all Functors. Here is the type signature of a Lens:
type Lens s t a b = forall f. Functor f => (a -> f b) -> (s -> f t)

Here, this type signature needs to hold for every possible f that is a Functor. You can't even write this signature without having Functor be something you can range over (like a class or interface, or in Haskell, type classes). Lenses were originally made for updates and reads of parts of data structures. By switching out the f, you can implement a different operation with the same lens. The reason they don't simply use getters and setters is that you can compose different lenses together, and even compose lenses with things that aren't quite lenses, but are similar. This is enabled by the Lens (and friends) type being a synonym for functions, rather than a record containing a getter and a setter. I think this is out of scope of this post, since the usefulness of Lenses is not really established for my argument anyway, but I could go into it if you wanted me to. Or look through the variety of lens tutorials, since they would probably do a better job than me

I started screaming IRL when I realized what I'd done.

kek

No, I mean can you write a function in Python that takes an uncurried function as its argument, and returns a curried version of it?

Forgot to add, the "don't reimplement stuff" argument is much stronger with abstractions with more structure, such as Applicative and Monad. These have more to work with, so you can implement more complicated functions that operate on them, and save more time than Functor by not having to reimplement. But Functor is a prerequisite for both those examples, so you could still say it's important.

Fucking hell, user, I asked for a real-world example.

Imagine you're a living, breathing, normal human, rather than the turbo-autist you seem to be.

While you've been quite informative in your own way, you're still just wanking.

Give me an example of an actual problem that this would solve in a codebase. How does it relate to a sample of existing data?

>screaming IRL
Jesus user it's just a thread

Absolutely disgusting.

You could probably do it with functools.partial but I'm not sure.

I sometimes just close threads when I say something real stupid
I know we're all user, but I still can't handle the embarrassment

from functools import partial

def f(a, b, c, d):
print(a, b, c, d)

g = partial(partial(partial(f, 1), 2), 3)

g(4)

How is that even something that seems like a candidate for being a good argument to you? Have you ever seen a testing framework in your life? And I'm gentle in that I'm not asking you to provide an example of an IO-related function that has a hidden type issue that isn't revealed at test-time...

Here, let this bunny give you a hug.

Interesting, thanks. I wonder if there's any special machinery needed to make it immune to scoping issues.

I've seen mocking, abstracting over services etc and they're unsatisfactory.

Why in the fuck does Javascript refer to lists as arrays?

I just had a 30 minute argument with a front end dev pleb who was confused because of the terminology. Why has this not been changed yet?

>ever arguing with frontend fags
why

>lists
You mean vectors?

It's a buddy of mine. I was talking to him about javascript lists over lunch (I assumed they were called lists because you don't have to set a length) and he got butthurt.