/dpt/ - Daily Programming Thread

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

Other urls found in this thread:

wiki.haskell.org/Haskell_in_industry
en.wikipedia.org/wiki/Type_system#Static_type_checking
github.com/baku89/Subete-ga-F-ni-naru-ED
wiki.theory.org/YourLanguageSucks
automatetheboringstuff.com/)
amazon.com/dp/1590282752/)
amazon.com/dp/0262529629/)
thesis.haverford.edu/dspace/bitstream/handle/10066/624/2004RushtonM.pdf?sequence=2
twitter.com/NSFWRedditVideo

Don't use go

Second for that feel when all your well crafted posts in your old thread just die and nobody will appreciate them.

rolling

wiki.haskell.org/Haskell_in_industry

post that shit elsewhere, you fucking retard

Please stop the anime shit

Anime characters don't program

So how do i progress trough python? I wanna learn more but not sure where to read up and such. I can complete easy tasks but probably pretty dirty and not too good, any suggestions?

You progress by not using Python, and forgetting everything you ever learned about it. Learn Scheme and OCaml.

>it's 100% an implementation detail
No its a language feature.
I suggest you try spending 10 seconds (for cute little me please :3) and read this.
en.wikipedia.org/wiki/Type_system#Static_type_checking
Then tell me if that Wikipedia article is wrong or not.
Perhaps I can encourage you to edit the article and spend some time in the talk pages getting educated.

>for cute little me please :3
are you a sockposter?

Static types are pointless because you always end up needing to subvert them. Even Haskell has unsafeCoerce.

playing with elixir...I don't know what to think

defmodule Fizzbuzz do
defp fizz?(x) when (rem(x, 3) == 0), do: true
defp fizz?(_), do: false

defp buzz?(x) when (rem(x, 5) == 0), do: true
defp buzz?(_), do: false

def start() do
Enum.map(
Enum.map(1..100, fn(x) -> [x, fizz?(x), buzz?(x)] end),
fn(t) ->
cond do
tl(t) == [false, false] -> IO.puts(hd(t))
tl(t) == [true, false] -> IO.puts("fizz")
tl(t) == [false, true] -> IO.puts("buzz")
tl(t) == [true, true] -> IO.puts("fizzbuzz")
end
end)
end
end

>No its a language feature.
Yes it is. Every sane person already knows that.

>en.wikipedia.org/wiki/Type_system#Static_type_checking
I read it
How does this prove that this is not an implementation detail? The link is absolutely irrelevant to the topic.

I think he's accepted that he's wrong. But he's salty about it so he's going down the route of "I was trolling all along"

Nice meme.

An implementation that doesnt follow the spec isn't an implementation. It's a, fork I guess would be the word.

Don't you have anything better to do other than shitposting? Such as you know, making actual constructive arguments?

If the language doesn't enforce compile time type checking it's not a statically typed language.
>yes it is, every sane person knows that
Except you just 1 post ago called it an implementation detail. Meaning it's up for the compiler author to decide. It may be mentioned in the language spec, but not as a requirement or (loss of words here) forbidden feature.
Perhaps. I'm not one to assume malicious intent over ignorance.

The constructive arguments have been made. Static typing has been defined for you. You are arguing a position that is objectively and demonstrably wrong.

I'm kinda sad the interesting part of the argument about dynamic vs static type checking was lost because someone didn't know what they are.
But that's the general case with that discussion I suppose.

If your language cannot define and implement traverse_, then you shouldn't use it.

Any spec of any language should not be able to define the way the implementations handle type errors. This should clearly be decided by the implementation.
Anyhow, it seems like you are backpedalling since at the start you claimed that it is always part of the language, while now you say that it is up to the language only if it is in the spec and up to the implementation only if it is not.

>If the language doesn't enforce compile time type checking it's not a statically typed language.
We now know that C is not a statically typed language, just like for any other language that does not dictate the way the implementations handle the errors, right?
We also just learned that we can't use an interpreter for statically typed languages. Yeah no.

>Perhaps. I'm not one to assume malicious intent over ignorance.
Nice circle-jerk

>you must implement specific keyword
Well you're really putting yourself in a rather limited space of languages.
And I suspect you've removed yourself from languages capable of producing quality software.

>The constructive arguments have been made
Not by (you) at least.

>Static typing has been defined for you
Yes, I asked the definition that a certain person used and I got a reply to it. I also argued why such a definition is retarded.

>You are arguing a position that is objectively and demonstrably wrong.
I am still waiting for it to be proven wrong.

I don't code or anything, but I've got a post for you today.
>At work, doing my job, work as a butcher in a supermarket. Cute girl I know from another department comes into my stock room (we share one of our rooms with the oven fresh chicken), talks about how she's going to uni
>I ask her what she's going to study
>Programming
>Oh yeah? Any particular language or just generally going to learn and decide on one later?
I fucking kid you not, this is as close to her exact words as I can recall, and I'm pretty certain its 100% exact spot on.
>"Oh yeah. I know HTML, CSS. I've tried Java, but I found it a bit too complex. I can build a website if I've got someone else's framework, but I can't do it from scratch."
>So, you're going for webdev eh? Are you thinking of doing front end or back end?
>"Uh... what? I don't really know (giggles). I'm just gonna learn whatever."
...She has no chance of learning shit. She's cute, but she's a halfwit. I mean, shit guys, I thought uni was for the people who already knew their shit and wanted to progress even further? HTML & CSS is fucking kiddie shit.
Hell, my fucking niece is learning some really basic programming at the age of 6 (right now) at school.

But you know what? She'll undoubtedly get a semi-decent job somewhere purely on the fact she's a woman and the government tells companies they need equal (or close to equal) amounts of men:women.
Fucking sad.

You can't really say a language is either statically or dynamically typed. There's a big spectrum. A couple of illustrative examples:
1. Lots of languages are called statically typed even though you need runtime checks for e.g. ensuring an index is within the bounds of an array. Yet this invariant is possible to encode in a dependently-typed language as a type. Does that make it a dynamic type check in the non-dependently-typed language?
2. Dynamic types can be encoded in a statically-typed dependently-typed language. A value of "dynamic type" is just a value of a sigma-type where the first element is the RTTI and the second is a value of a type depending on what the RTTI means.

It's not a keyword, it's the name of a function. Its full signature is:

traverse_ :: (Foldable t, Applicative f) => (a -> f b) -> t a -> f ()

If I'm putting myself in a rather limited space of languages, then that can only be because most languages are terrible and should not be used.

>c and errors
It does dictate a large deal about errors and warnings
>cannot use an interpreter
Well it's not spec compliant. Just like how you could mess with C++'s vtables, but it's not spec compliant.

I'm not sure your perspective on languages is all that clear.
And I doubt this was the argument you had intended to have to begin with.

Can anyone recommend the best online course to learn algorithm design? How to calculate complexity, proofs, etc.

I just started my MSc but it's been 5 years since I graduated and I've forgotten most of the academic stuff.

Any course in 'algorithm design' is likely meaningless.

>It does dictate a large deal about errors and warnings
It does not force type errors to be at the time of the compilation.
Also C allows the use of interpreters.
Are you claiming that C is not a statically typed language?

I don't know any elixir, but why don't you define:
defp fizz?(x) do: rem(x, 3) == 0
defp buzz?(x) do: rem(x, 5) == 0
For that matter, why not:
defp divides?(d, n) do: rem(n, d) != 0
?

Sup Forums, i'm pretty new to coding and whatever

i'm trying to create a program that makes a random number, and then it adds the random number to your input

srand (time(0));
cout a;

cout

This is one of the reasons why this distinction is retarded.

Write a program that averages (no memes, just take care of overflows) a random, run time determined set of integers and tell me when you've reached less than 1.5cycles per integer.

Because that was my 10 minute implementation in C++ (regrettably) and if your language can't do that then I'd consider it too slow to be usable for any serious task. As a simple two instruction algorithm is such an easy case and so core to what you do in programming that your compiled code will run far too slow in real situations that it's simply unacceptable.

It's not that there's no distinction, it's that there isn't a single meaning of "statically typed" and a single meaning of "dynamically typed". However, you can describe languages as having the capability to check certain things statically as opposed to at run time.

C has the capability to check certain type invariants statically. It doesn't have to, by the spec.

The second time you call rand() it generates another random number, it doesn't reuse the one from before

>I don't code or anything
Then don't post.

I don't think that there is something from stopping python from doing the same.

Stop me. Go ahead.

I have no doubt that Haskell can do that, with judicious use of the ST monad.

You know that 'real world' software is more complex than averaging a set of integers, though. Haskell code is a hell of a lot more maintainable than C++ code, and so far better suited for most 'real world' software.

It forces type errors to be errors at the time of compilation (it's just true that they're errors at that time) while in dynamically typed languages they're not necessarily errors because circumstance in the program may lead them to not being so.

Is this really that hard to get?

Oh, no, there definitely is. Type inference for a language as expressive as Python is undecidable, hence you need type annotations, which it does not have.

>It forces type errors to be errors at the time of compilation
Please do not talk about topics that you have any idea about. C does not "force type errors to be errors at the time of compilation", this is simply wrong.
Read the standard.

Sup Forums - My Blog

>i have no doubt haskell can do that
Do it. Its a very simple task by design so you could do it trivially right now.
>real software is more complex
Yes, but any real software you haven't made arbitrarily complicated will have a set of operations that actually transform data. If that's too slow (because if it's a well constructed program it's a large part of the program, since transforming data is all programs really do) then your program is too slow.

Very few languages are capable of this.

I can't do it right now, I don't have a Haskell compiler on my phone.

oh

is there another way i can do this?

>Type inference for a language as expressive as Python is undecidable
What can you do in python that you can't do in OCaml or F# as easily?

>read the standard
Understand what an error is.
user you're just dodging at this point. Go ask someone you trust in knowing C.
I'm not gonna try anymore. You've been given plenty of evidence that supports all the claims I made before, you moved the goalposts to a place where you don't fully grasp the language (in the spec, not C as a whole, though one implies you don't get the other). And now we're arguing semantics.

So no this is over user. If you really want to know there's good sources.

Get a job

>Lots of languages are called statically typed even though you need runtime checks
Static typing only refers to compile time type checking. it has nothing to do with runtime.

>which it does not have
There was a RFC by guido on that topic where he actually proposed type annotations. I doubt that it will be added any time soon however.

>Type inference for a language as expressive as Python is undecidable
I will have to doubt that. Until I see a better explained reasoning at least.

Store the result of rand in a variable and reference that instead.

Fair enough. My issue with haskell is mainly that the benchmarks I see are horrible and my (fairly limited use) has shown me that they're very hard to optimise for.
Very few languages are good enough to write good software in then. And that's a shame. I agree its rare. Its why I use C and C++. Its not because I particularly like them all that much.

You have not given any evidence, instead you keep posting bullshit with nothing backing it up.
As I said, C does not "force type errors to be errors at the time of compilation", the standard does not force that, this is all. What is so difficult to understand?
I have given plenty of arguments to you however I have yet to see you actually trying to dispute them with reasonable replies.

Well, expressive in the sense that you can write code for which type inference is undecidable, since the syntax is not as restrictive.

How about you finish reading?

It's not hard to make inference undecidable. Python allows you to write code that you'd need dependent types to statically type. Complete type inference for dependent types involves higher order unification, which is undecidable.

>You can't pattern match on types in Haskell.

Is this true?

This was one of the few reasons I gave Haskell the benefit of the doubt in some small portion of my mind.

Sure, it's easier to write a well-performing C++ program than a well-performing equivalent Haskell program, but for both languages you need expertise in order to eke out maximal performance.

In the field I work, Haskell's performance (when written well, but not going over the top with optimizations) is acceptable, because we don't have real-time requirements. Haskell's other benefits (faster development time, easier refactoring, better code reuse) are more useful than the performance benefit we would get by switching to C++. From your posts I assume the cost/benefit analysis works out differently for the work you do.

Well, you can, with type families; this makes a type-level function, essentially.

You cannot match on types in the body of a regular function. You can use type classes for ad hoc polymorphism, but the point is that it is open and not closed. If you want something like "closed ad hoc polymorphism", you can use algebraic data types.

I need a little clarification. Say I want a python script that receives input from a remote user in the form of a youtube link and runs it through youtube-dl, how would I best do this? Download locally, upload to a temporary file hosting service like MyAirBridge, and then purge from local system?

Would this be more webdev/IT territory at this point?

Yes, it's true. Being able to do that would destroy parametricity.

github.com/baku89/Subete-ga-F-ni-naru-ED
they do :3

>How about you finish reading?
i did.

So what do you think about the rest of the bullet point?
>...for e.g. ensuring an index is within the bounds of an array. Yet this invariant is possible to encode in a dependently-typed language as a type. Does that make it a dynamic type check in the non-dependently-typed language?

Not to mention that it would require RTTI overhead.

But but Java generics are shit because C# did them differently who even cares about free theorems and correctness lol academic ivory tower nonsense is triggering me you're uninvited from my conference.

I think you replied to the wrong person.

All statically typed language allow you to do dynamic typing. You can cast shit to whatever you like, and that only get's checked at runtime. Static Typing does not mean all code is verified to be valid at compile time. It just checks the types are consistent.

Don't listen to them. Python is an amazing language. It's a hell of a lot more flexible than C/C++ and fuck Ruby.
Learn Python the Hard Way
Codecademy

Practice polymorphism, read and experiment a lot.

I'm banning you from posting any comments containing the letter e because you violated my code of conduct

There's a difference between the ability to do dynamic typing, and whether the language would be considered by the majority of reasonable, informed persons to be "dynamically typed".

Python fucking sucks, stop trying to destroy his brain with it.

>You progress by not using Python, and forgetting everything you ever learned about it.
Okay, I'm with you.
>Learn Scheme and OCaml.
Aaaaaaand you lost me.

>All statically typed language allow you to do dynamic typing. You can cast shit to whatever you like, and that only get's checked at runtime.
All of them? That's a hefty claim.

>Static Typing does not mean all code is verified to be valid at compile time. It just checks the types are consistent.
Sure, but propositions are types and vice versa. X language can enforce something with its type system while Y can only do it at run time. That's all that matters.

And why does Python suck?
Let me guess, you use a low level language such as C, even though C is a complete waste of time unless you're writing drivers or kernel source code or other low level code.
wiki.theory.org/YourLanguageSucks

Your guess is wrong. I haven't used C in years.

I completely agree. Almost all statically typed language can do dynamic typing. But when dynamic typing is all a language can do, then it is broadly considered to be dynamically typed.

Are there any sites I can use to find remote work? I have a lot of downtime but I've never been all that good at freelancing

Okay. Well, no language is perfect. You still haven't given any reasons as to why Python sucks.

>It's a hell of a lot more flexible than C/C++
Wat.
I like Python generally user, but I'm not sure what this is supposed to mean.

Yes it does. From what I've seen of haskell performance would simply not be a concern for it to make sense.
But considering how easy that solution was in C++ i don't think you need expertise. That's probably what attracts me the most to it. If I could reach the same results in haskell (and other people don't really do that in benchmarks), I'm not confident it'd be a win simply because it'd be a lot of effort.
The gains I see in development speed. Yeah they can be quite large, but only when you don't care about performance to my knowledge. You hope that haskell is fast enough. Because obviously you don't accept software that takes an eon to run.

But I've also never seen any real issues with just implementing something. Its always the constraints that get to you.

Dynamic typing.
Absurd scoping.
Its lambdas are toys.
The GIL.
The version split.

>Some development teams actually connect sirens and flashing red lights to their test systems, so that it is impossible to ignore a failing test. They then search out the programmer who caused the failure and make her pay for coffee for the next week.

Really?

In C if I have the following code:
if(expr1 && expr2 && expr3)

are all expressions evaluated first or are they evaluated one by one. If expr1 is false, wil expr2 be evaluated?

>Pros of python
* Easy to import libraries
* Well established within certain circles
* Can often make small (and often hacky) modifications to code to 'just get something to work'
* Multiparadigm
* Reflection and introspection (this is genuinely quite huge)
>pros of codeacademy
* Gets a person going with programming due to friendly interface and achievements
* pretty interface

Ask me for cons

I disagree that you don't need expertise for C++. For anything non-trivial in C++ you need to know a lot about the many parts of the language and how they interact with each other. Any time I have to think about exceptions and RAII together I get very nervous. Not to mention the various different constructors, move semantics, and what-not. It's a very powerful language, sure, but it's not at all easy.

In contrast, I find programming in Haskell much more intuitive. Perhaps it's because I learned a functional language before I learned C++.

Haskell normally is fast enough for the things I use it for. If it ever isn't? Well, I guess I'll discover how good its C FFI is.

Low level languages in general are more verbose and become unnecessary for most tasks. For the most part in C there is a right and a wrong way, with Python I can achieve the same result in a plethora of different way. It's flexibility is one of my favorite aspects.

>reason: it suks x-DDDD
>here learn these languages that aren't really applicable anymore because they'll magically teach you concepts you are still supposed to learn no matter what language you choose
This meme is actually the worst and it needs to stop.

>Learn Python the Hard Way
>Codecademy
You're not as bad as him but you sure are trying.

Just stick with Python if you're comfortable with it already. Use Automate the Boring Stuff for Python to start out (automatetheboringstuff.com/) and transition to more scholarly text. John Zelle (amazon.com/dp/1590282752/) and John Guttag (amazon.com/dp/0262529629/) are good once you move out of Automate.

From there most people usually head into C, Java, C#, or C++.

>Yes, I asked the definition that a certain person used and I got a reply to it
You were linked to the definition on wikipedia. While it's just wikipedia it's more than you've provided. Find a single credible source that suggests type systems work the way you think they do

ikr misgendering programmers is not cool

>her
No it doesn't happen
JOKES aside failing tests is what they're there for. Sirens for failing tests would be constant and counterproductive as it encourages avoiding effective programming where the safety net of tests let you go fast.

it follows the programming order of operations, but yes that is an optimization your compiler does for you

Besides GIL and maybe the version split all of those are completely subjective.
>Stop liking what I don't like

>You were linked to the definition on wikipedia
No, I was not.
Why are you lying user?

I still occasionally hear the monitor beeping sound that we had at my previous workplace, at night when I'm trying to sleep, even though it's not actually there.

>All of them?
Almost all. Except for meme ones.

>X language can enforce something with its type system while Y can only do it at run time. That's all that matters.
That was my point. X is statically typed if it can enforce it at compile time, and Y is dynamic.

thesis.haverford.edu/dspace/bitstream/handle/10066/624/2004RushtonM.pdf?sequence=2

Any other thesis or paper on the subject will give the same definitions. You're out of this world levels of wrong

I assume it's only during code reviews, not just compiling any random program (in which case you'd throw errors to avoid that anyways)