/dpt/ - Daily Programming Thread

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

Attached: 1543156373486.jpg (621x909, 268K)

Other urls found in this thread:

codeup.com/
pdfbox.apache.org/
opensource.google.com/projects/pdfium
twitter.com/NSFWRedditGif

nth for nim! (and yuno)

first for python :333

time to choose, yuno: haskell or lisp?

Attached: dpt.png (553x493, 50K)

>What are you working on, Jow Forums?
Today is learn spacemacs day.

haskell

i really love python3

i like lua

haskell

JavaScript rocks!

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

Help me, (You)nos. I've got the following doubly-linked list:
data DList a = DLNode (DList a) a (DList a)

As far as I see, it's basically impossible to implement a insert :: a -> DList a -> DList a without extending the type to contain some sort of node index.
Do you see any other way of doing this?

JavaScript rocks!

Attached: javascript rocks.png (1000x494, 134K)

Are intensive coding bootcamps useful? I'm a HS graduate who failed out of college. I just want to get out of minwage cucking. No experience.

codeup.com/

This is the program I'm looking at.

Attached: 1542878327506.png (337x372, 17K)

erlang

>Are intensive coding bootcamps useful?
No.
>Le sad reddit meme man
You also should probably consider suicide.

Attached: 1406803019377.jpg (1280x720, 103K)

>le tranny anime girl

You'll kill yourself before me.

How do functional languages handle large data structures? If you have a large tree, and a function that changes a nodes value, naively the function would just copy the entire tree and change the value, then return the new tree, but that doesn't seem practical at all.

M E N T I O N E D

You have to insert at the head of the list for constant time, otherwise it will be linear time if you insert it somewhere else within the list.

but how would I know when to stop iterating? without a node index, there's no end to the iteration.

>>le tranny anime girl
>You'll kill yourself before me.

Attached: 1540461425580.jpg (275x183, 5K)

>Comes into /dpt/ and insult its mascot
>Directly insults the cutest animu gril to have ever existed
Seriously, fuck off and kill yourself.

Attached: 1412742862372.png (674x752, 629K)

>tranny
>anime
I have some news for you

You use persistent data structures. Since data doesn't mutate in a pure language you can reuse as much of the old structure as you like.

i just wanted to thank that user from yesteday, i got the mingw compiler working, i just had to set the PATH again (apparently it got reset) you are probably american since i posted late last night, you know who (you) are

and laziness

Not really, since it's a doubly-linked list, all elements would need to be re-created (i.e a new prev with the link to the new head, and a new prev prev to the new prev, etc...; and same for all next links). The problem is how to re-tie the knot like the original DList did.

Only the second element has a link back to the head,
if you insert a new head its O(n) because the list just changes the pointer to the first element to the new head and thats it.

The new head points to the next element then of course.

*meant O(1)

I think your problem is thinking the problem the wrong way. You see, in your list you want the left side of the list to depend on the value of the right side of the list. But since the right side also depends on the value of the left side, you can never reach a conclusion. It's infinite recursion. All in all, it makes no sense to have the other end of the same list in both ends. So if you need access to both ends you should probably use some kind of a pointer type to reference to the other end of the list, instead of pure values.

by definition the last element's next points also to the head
-- next links
last -> head -> second
-- prev links
last

this
it's like trying to insert an element in a cyclic list (cycle :: [a] -> [a]), it's impossible, unless you still have the finite list, and remake it cyclic after insertion

I forgot that, but since the old first element has a link back to the last element the operation will still be constant O(1), without the need of iterating.

No, since the last element must point to the new head, a new last element is needed. And since a new last element is needed, a new last of last element, etc.

I agree, however it was surprising to me that we could create such recursive structures but not modify them afterwards. I think is the essence of it.
Like you say, a reference would probably work:
type Node = Int
data DNode = DNode Node Node
data DList a = DList [DNode] [a]

I meant that is the essence of the problem.

thanks for correcting yourself and giving me my rightful (You)

Attached: 1516648854467.jpg (2480x3496, 1.6M)

There is no need for new last element at all, you address the last element via the pointer of the last head element.
Then you change the pointer of the last element that points to the first element so it points now to the new first element.

How is that not a constant operation?

>Then you change the pointer
how is that pure?

why not just use a sentry that also contains pointers to the head and the tail
the sentry itself will never move and it's the size of two memory addresses
there literally all problems solved

Perhaps I wasn't clear in my question, but I'm stating the problem for immutable structures. You cannot mutate the last element (i.e. "change the pointer"); instead a new last element must be created.

Nevermind I didn't saw it is for haskell. Can't you not simply change the reference of the element or something?

reminder computers aren't lamda calculus machines and even "pure" functional langs aren't actually pure in reality

look dude why do you even bother with this? we all know you're just gonna pretend that computers are more similar to the C virtual machine than to any hypothetical functional language

okay

reality and mathematics also aren't pure
pureness is a spook

Mathematics actually is pure.

You fucking retard. Why the fuck did you waste my time? I shouldn't have fucking replied you dumbass fuck.

I think you're the only one i ever heard say that

Attached: 1_mL04Mh-tDosU6_OlqexwyQ.jpg (720x511, 69K)

nobody cares nerd

you can
but that's not what we want
it also comes with other problems

"Pureness" and originality are fucking memes

Originality died centuries ago anons

Attached: 800px_COLOURBOX8416047.jpg (800x800, 157K)

Majority of people are too dumb for JS. You should have seen the last thread.

>Majority of people are too dumb for JS.

Attached: 1512290877628.png (778x640, 164K)

>Wojack edit #15246745785674556
Fuck off, redditor.

>majority of people are too dumb for JS
I hope not but I could believe it. It's still shit though.
brainless wojak is a based and redpilled meme friendo, not like that gay frog

Attached: 1547816204146.jpg (1280x720, 356K)

>(x == y || x < y) == (x

if x or y are side effecting expressions, this can fail in C too

I don't know what's supposedly based about beating the same dead horse of a "joke" over and over again, despite it never being even remotely funny or endearing in the first place.
That's straight up the reddit mindset.

Assume x and y are simple veriables, or direct values.

that's wrong, some of the worst trash was made by people desperately wanting it to be unique
meanwhile plenty of good Jow Forums posts have been relatively unoriginal

>still not too dumb to understand === is the equality operator
Please refer to

Go ahead and replace == with ===, still won't fix the problem.

There was a second sentence as well.
lt/gt operators are number coercing operators, with exception being strings for both operand, loose equality follows different rules. Also you should only be using == to compare to null for bottom value checking, for every other case you should be using ===.

When will JS get an ==== operator?

What would it be used for that isn't already covered by ===?

That's still entirely your own fault for using equality operators on some arcane shit instead of numbers. Which is something that never happens in practice, unless you wish to again refer to

> x = []
Array []
> y = []
Array []
> (x === y || x < y) === (x

When will JS get a 8==D~ operator?

equal reference maybe

>x === y
false because different objects
>x < y
false because 0 isn't less than 0
>x that isn't already covered by ===

>tfw too smart for types

> (^-^) n = take (6 * n) $ cycle "(^-^) "
> (^-^) 8
"(^-^) (^-^) (^-^) (^-^) (^-^) (^-^) (^-^) (^-^) "


step it up other languages

with PostfixOperators you can do (8 ^-^)

with mixfix operators you can do anything

not a haskell extension, also muh lexer

haskell is shit, also lex deez nuts

no_u_

Please, write an Haskell code bigger than 1000 loc and explain it's time complexity.

>it's time complexity
that's like piss easy, space complexity is like way hard to determine due to laziness

I want to remind you that GHC developers need 10 years to prove time complexity of the sort function.

Anyone has any experience with parsing PDFs ?

I am trying to convert my credit card statement into json data I can easily process but it's a fucking nightmare.

Best tool I could find is tabula, which worked wonders, but went to shit when I tried parsing for a slightly different layout)

write your own parser
use llvm as a backend, i can't imagine .pdfs are more complicated than a language like C++ which is several standards of two separate programming languages + several standards of C
i suppose if the C preprocessor is turing complete it'd technically make it a parser of several standards of four individual programming languages

>use llvm as a backend
>to parse pdf into json
This better be a joke

Haskell is a useless, shitty, ugly, and inefficient language, but if I had to choice between it and Lisp I'll choose Haskell.

My VirtualBox ran fine and smooth yesterday. Why does it run so slow today?

Use PhysicalBox instead

only partially

So you're partially retarded

there is a need for a good modern native pdf library that can handle all of the standard, afaik there is none
llvm might be overkill but it doesn't change that fact

We shouldn't use pdf to transfer data.

PDF is a pretty complex format. Use a library
pdfbox.apache.org/
opensource.google.com/projects/pdfium

Why on EARTH do you think LLVM will help? Why on Earth do you not think using LLVM for this will make everything a LOT more complicated? Are you fucking retarded or something?
Fucking look up what the fuck LLVM actually is and revise your reply kudasai.

Why the FUCK do you think the topic is about data transfer? Get a fucking brain and fucking USE it before hitting the reply button, fucktard.

take a chill pill my dudes

I'll take a chill pill when some fuck tards over there start taking not-be-fucking-retarded pills.

>uses curly brackets
>uses ";"
>uses "main"
>horrible syntax
>can't return arrays
>requires you to declare every single fucking thing
>horribly awkward use of pointers
>excruciatingly painful input/output commands
Why is this piece of shit language shilled so much, when it has absolutely no redeeming qualities, apart from speed and portability?

Attached: c.png (125x133, 3K)

Is this how brainlets cope?

Because it has speed, portability, simplicity, discipline, historical interest, interop functionality, heritage, etc.

>>uses curly brackets
braces*
and this is a good thing
>>uses ";"
Another good thing
>>uses "main"
Another good thing
>>requires you to declare every single fucking thing
Another good thing
>>horribly awkward use of pointers
You mean use of pointers

Everything else are valid complaints and the reason why C is shit is because no support for good efficient abstractions.
The problem you have is that you have shit taste in programming languages.

>>uses curly brackets
so?
>>uses ";"
so?
>>uses "main"
so?
>>horrible syntax
no
>>can't return arrays
wrong
>>requires you to declare every single fucking thing
so?
>>horribly awkward use of pointers
for you
>>excruciatingly painful input/output commands
for you