/dpt

true but too bad you have to write
>let
>let
>let
everytime instead of just indenting code

Catch all cases are dangerous except when absolutely needed. If you include them you might as well say bye bye to the safety that pattern matching gives you. Usually they are harmful unless for recursion when you sometimes do want a catch all match

how the fuck do i make a new mbedtls bignum and load my own 128 bit integer into it? i can't see any function in the mbedtls docs that tells me how to load a number

Javascript rocks

Where is the teaching C++ part OP? Suck a fucking dick

I like the let syntax. I always found it unsettling not to lead declarations with a keyword, but that's subjective.

This is from the official f# documentation, but I agree. Usually I do
_ -> failwith "couldn't match"

Contracts are just tests. Dependent types let you write propositions or predicates which must be proven. In the wise words of Dijkstra, tests can only prove the presence, not the absence, of bugs.

>using streams

Attached: 550.png (207x243, 6K)

I disagree. In the matrix example they are doing the same thing.
A matrix n m taking a matrix n m as argument is also a test in a way. It’s saying if this is equal to that, proceed. How’s that not a test?
A matrix taking another matrix and then a contract checking if the rows and columns are the same is to me the same thing.
They are both running at compile time and asking the same thing.

The term "contract" is overwhelmingly used to describe something that is checked at run time. If you expand that to include compile time, then no, dependent types are just a way of writing contracts.

Actually, dependent types are not limited to compile time because you can just branch at run time and either fail or get a value (proof) of a refined type, but for all intents and purposes the magic happens at compile time.

you're making excellent progress user

>Contracts are just tests
You can write a type system that has actual contracts that are verified with a solver. Read Advanced Topics in Types and Programming Languages!

Haskell has case ... of ... which is basically the same

Right, I get it. So a contract is usually not used to refer to a compile time check. good to know.
Idris sounds really neat, I’m just trying to understand how to apply those concepts in less advanced languages

post some c++ tips nigger

what is the type of failwith?

>a contract is usually not used to refer to a compile time check
Exactly. You'll often get people trying to conflate compile time and runtime, though.

Refined types?

See

OOP and unit tests both conflate writing code with being productive. They achieve the former but not the latter.

not necessarily
read ATiTAPL

yeah, I wish people would use that more. I really dislike the repeated function name.
sayMe :: (Integral a) => a -> String
sayMe 1 = "One!"
sayMe 2 = "Two!"
sayMe 3 = "Three!"
sayMe 4 = "Four!"
sayMe 5 = "Five!"
sayMe x = "Not between 1 and 5"

It's a function that generates an exception. Not sure how it works behind the scenes. It might just be a regular old exception because of its C# heritage.

>read ATiTAPL
>read muh textbook which we can already tell is wrong or misunderstood by you

I guarantee I have read more literature about types and formal verification than you.

>It's a function that generates an exception
What type is failwith, though?

No idea

Attached: robot will feed you tomatoes as you run.png (540x480, 318K)

He sounds like another dynamic language shill trying to conflate contracts and static types.

Its type is forall a. String -> a, isn't it?

post more switch/case syntax abominations I need my daily laughs

Attached: dennis-at-penn.jpg (437x500, 58K)

I fucking hate you brainlets.

Yeah, string -> 'a

How disappointing.

streams are great

I think from an ideal standpoint it makes sense to call statically checked properties contracts, but it's simply not how the term is used, for whatever reason. Same as how dependent types can be used without proving everything ahead of time - you can still obtain (existential) proofs from run time tests.

I prefer rivers

Sorry bro

It's okay. I'm used to programming languages disappointing me.

H
O
L
Y

C
O
W

HAHAHAHA

That was a funny comment!

I guess that it's because contracts are often used in distributed scenarios where you can't necessarily trust every node and therefore are forced into run time checks.

>it's simply not how the term is used
Contracts does not inherently mean runtime checks. It's more comparable to refinement types with hoare logic.

en.wikipedia.org/wiki/Design_by_contract

They're often added to dynamic languages in response to criticism about them being unable to check anything statically. In my experience the author often keeps very quiet about the fact that there's still no static checking.

It's just an OCaml knockoff.

nenecchi ni nakadashitai

as long as it doesn't have GIL there's nothing wrong with that

What would you like it to be?

But you can use all of the .NET ecosystem from it! If you take leave of your senses and think that would be a good thing.

> It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.
Even this page you've given (which is in no way an authority on using the word contract) doesn't contradict static verification

I'd like type systems without escape hatches.

>Just finished a twelve week internship at "That One Search Engine Company"
>First internship, so it was kinda rough
>Made a server
>Basically had to learn Angular and make a working frontend alone
>Despite all this, my boss still said I wasn't meeting expectations.
Why is it so hard bros. I don't think I'm gonna make it in the real world.

Attached: The SOS brigade is not pleased by this revelation.jpg (363x494, 28K)

>That One Search Engine Company
DuckDuckGo?

>frontend dev
ewwwwww

>Many programming languages have facilities to make assertions like these. However, DbC considers these contracts to be so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first. Contracts can be written by code comments, enforced by a test suite, or both, even if there is no special language support for contracts.

>When using contracts, a supplier should not try to verify that the contract conditions are satisfied; the general idea is that code should "fail hard", with contract verification being the safety net. DbC's "fail hard" property simplifies the debugging of contract behavior, as the intended behaviour of each routine is clearly specified.

>Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract checks are disabled to maximize performance.

>Design by contract does not replace regular testing strategies, such as unit testing, integration testing and system testing. Rather, it complements external testing with internal self-tests that can be activated both for isolated tests and in production code during a test-phase. The advantage of internal self-tests is that they can detect errors before they manifest themselves as invalid results observed by the client. This leads to earlier and more specific error detection.

Then just go through the list of languages and frameworks that it cites and see how many of those involve static checking.

Go to the web development general, brainlet. Don't come back.

>Angular
>frontend

all frontends should be using Elm, desu.

std::cout

Contracts are just fancy runtime asserts.

In general, when you see "specification" it means proving ahead of time, whereas "contract" means asserting just in time. That's just how it is. At face value, they really mean the same thing, but they're used differently in practice.

It was just as painful as you think it was.
The previous intern that made the frontend didn't even bother to make it look right (and had invalid HTML too).
They didn't even add buttons. All they did was have text and call functions when the text was clicked.
I made the backend work. I'm not a frontend baby. Some of us have to do frontend whether we like it or not.

Thanks for the birds man. They're my favorite animal.

>Elm
Haven't heard anything about this... Any resources you recommend for learning about it?
I'd do anything short of going to Nine-Ball Island to avoid doing JS again.

Again, this is literally
>look at all these run-time examples
There are examples in type systems literature of static verification of contracts, and ATiTAPL is one of them. It is in no way a bad or wrong use of the word contract. Run-time tests are not tied to the concept or essence of contracts, they're simply an extremely easy way of doing some sort of checking that many people from a non-formal background might use.

I think you mean PureScript

Please, just go to the wdg. It's where you belong, breh.

teach me C++, faggot

You're a JS dev. Want some seeds?

who are you talking to

>Any resources you recommend for learning about it?
the site has a tutorial of sorts written by the language author.
guide.elm-lang.org/
There's also Elm In Action, which is currently being written by a prominent guy in the Elm community who's employer is also using and funding Elm.
manning.com/books/elm-in-action
You can probably find it on libgen

Depends... What seeds?
I'm looking for either peach or straberry seeds at the moment.

I don't actually know what a seed is in this context.

NEW /DPT/ RULES:

>(A)GPL3 only
>no Windows
>no Nvidia
>no OO

Bird seed

Jesus christ get over yourselves

I hope nenecchi follows the rule of 5

Pre-emptive multitasking was a mistake.

Ive been writing Elm for a living for 2 and a half years now.

I love it. I dont know how I could be a software engineer without it.

As far as learning about it just google "Elm guide", the first two results are good. Also, the Elm slack channel is the friendliest programming community out there, so if you have any questions just go there and they will help you out.

Co-operative multitasking instead?

Still kind of lost...What do bird seeds have to do with JS?

Is this one of those jokes about me being Sugandese?

id rather figure out C++ memory reference errors than deal with the node 10/angluar 6 shit im working on right now... this crap has tons more artifical complexity, cryptic error messages and non descritive debugging than im willing to tolerate

Attached: 1466757919360s_u18chan.jpg (294x300, 25K)

JS is a language for parrots. You used it, so you must be a parrot. Most parrots like seeds.

Yeah.

You must be fun to be around

Hi

Attached: Joshua 'cuck' Bloch.jpg (250x375, 12K)

Want a cracker instead?

I'm not the guy you were talking to, I just had to dive in to tell you you're an ass

I just checked in the mirror and I'm definitely not an ass. You are misinformed.

Oh yeah....
That wasn't clear at all... Try getting better jokes.

In any case, I got a chance to finish the project, so I'd still call that a win.
Last time I checked, I wasn't growing any feathers, so I'm probably not turning into a parrot today.

JS developers are crap.... they have crappy documentation... half their libraries would never work without stack overflow as their documentation fails to mention many options or interaction functions needed for certain jobs (most of their documentation entails simple examples of a main functions and no indepth explanation or proper class usage manuals)

Attached: 04yoOWp.jpg (700x526, 56K)

>Last time I checked, I wasn't growing any feathers
Oh, you poor thing! You've been plucking, haven't you? Eventually they stop growing back. The internship must have been very stressful.

>dynamically typed language has poorly documented library
Who could have foreseen this occurrence?

What's up with this validation bs in compiling an XML document? It's been giving me constant headaches.

static types are the best documentation. never goes out of date, never wrong