p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Subjunctive posted:

the most common issue there in JS is probably accidental stringification. if something inadvertently ends up as a string, you can apply addition to it, but also array operations like subscripting and .length. and it's all too easy to end up with a string when working with DOM.

(.length on a number in JS will evaluate to undefined, rather than throw, because primitives are automatically boxed when properties are accessed)

yeah earlier i was complaining about the fact that most dynamically typed languages are also weakly typed, when i wish they weren't. you can lay a lot of the blame on that over the dynamic typing

(also that was a bad example, trying to use a method that doesn't exist will get you an error though)

# ? Aug 27, 2014 03:50

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 04:00

tef: May 30, 2004; -> some l-system crap ->

HappyHippo posted:

you can lay a lot of the blame on that over the dynamic typing

i dunno, implicit type coercion happens in a lot of languages

# ? Aug 27, 2014 03:57

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

well weak versus strong is usually a matter of degree not one or the other. the plangs are definitely on one end of that scale though

# ? Aug 27, 2014 04:13

Notorious b.s.d.: Jan 25, 2003; by Reene

HappyHippo posted:

yeah that's what im saying. my point is the cases where they're compatible to the type system but semantically different i don't find come up that often.

we've reached a tautology. you don't find type systems useful because you don't take advantage of type systems.

in the degenerate case, two floating point numbers that have important semantic differences, you can't see the point of a type system. that's kinda ruling out type systems as a tool

# ? Aug 27, 2014 05:49

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

i think this is the most productive three pages in the thread so far, gj guys

# ? Aug 27, 2014 07:22

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

Notorious b.s.d. posted:

catching the distinction between two types with compatible internal implementations is the hairy thing that i want a smart compiler for in the first place

in contrast sometimes you don't care about these distinctions!

:tinsley:

d-d-dduck typing! :tinsley:

# ? Aug 27, 2014 07:33

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

re: option types for error handling. i originally liked to use options in places where one kind of error is much more common than all the others (like trying to get the first element in an empty array), with exceptions taking care of any 'rare' error. nowadays i think that any advantage options have over either types in terms of brevity/clarity aren't worth it vs having a consistent, Either based exception model.

# ? Aug 27, 2014 07:59

ahmeni: May 1, 2005; It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.; Grimey Drawer

Vanadium posted:

Does it help that you can specify versions, git branches/tags/revisions, etc? And that it's not part of the language?

some idiots GitHub account is not goddamn infrastructure

# ? Aug 27, 2014 09:05

cowboy beepboop: Feb 24, 2001

can one of you pom.xml lovers go and fix rust before it hits 1.0 thanks

# ? Aug 27, 2014 09:18

Soricidus: Oct 21, 2010; freedom-hating statist shill

static type checking is kind of equivalent to a test suite, except:

it always exists with 100% coverage of the things that are expressed in types, unlike test suites which in practice are often half-assed or exist only in the future
the typechecker is robust and well-tested due to being constantly used by millions of people. who tests your bespoke artisanal test suite for correctness?
it runs constantly as i edit code with instant feedback (ok this one's an ide feature but it still rules)
it tells me exactly where the problem is and how to fix it, instead of just going "i guess something's broken somewhere in this test, or one of the methods it calls, or one of the methods they call, etc. enjoy tracking it down!"

basically it's a tool that makes my job easier, and therefore good.

# ? Aug 27, 2014 10:23

ahmeni: May 1, 2005; It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.; Grimey Drawer

Soricidus posted:

static type checking is kind of equivalent to a test suite, except:

it always exists with 100% coverage of the things that are expressed in types, unlike test suites which in practice are often half-assed or exist only in the future

the typechecker is robust and well-tested due to being constantly used by millions of people. who tests your bespoke artisanal test suite for correctness?

it runs constantly as i edit code with instant feedback (ok this one's an ide feature but it still rules)

it tells me exactly where the problem is and how to fix it, instead of just going "i guess something's broken somewhere in this test, or one of the methods it calls, or one of the methods they call, etc. enjoy tracking it down!"
basically it's a tool that makes my job easier, and therefore good.

this is a bad comparison and you should feel bad for both posting it and not understanding what tests are for

# ? Aug 27, 2014 10:40

Workaday Wizard: Oct 23, 2009; by Pragmatica

i taught myself vba using the object browser

# ? Aug 27, 2014 11:14

Workaday Wizard: Oct 23, 2009; by Pragmatica

imagine if i had to guess the interactions or trust some halfassed doc

# ? Aug 27, 2014 11:16

fart simpson: Jul 2, 2005; DEATH TO AMERICA

i used to write python and like writing lots of unit tests, but since switching to haskell i still write tests but i write fewer of them because a lot of the types of tests i'd write in python are unnecessary because haskell

# ? Aug 27, 2014 11:59

MononcQc: May 29, 2007

fwiw there's a reason Haskell had to develop more classic exceptions than Either/Maybe when it's in its IO monad -- there is a class of exceptions that happens when doing parallelism or specific tasks with the outside world are asynchronous, which can't very well be represented in a synchronous mechanism (like function returns).

They're really neat to have, but there are cases where they'll be insufficient to cover all the stuff that actually exists. You need more stuff :toot:

# ? Aug 27, 2014 12:26

Workaday Wizard: Oct 23, 2009; by Pragmatica

concurrency is a bitch

# ? Aug 27, 2014 12:33

Cybernetic Vermin: Apr 18, 2005

typed cascading nulls is still underappreciated, get on it lazy language designers.

# ? Aug 27, 2014 14:28

gonadic io: Feb 16, 2011; >>=

Cybernetic Vermin posted:

typed cascading nulls is still underappreciated, get on it lazy language designers.

but haskell already has those!

# ? Aug 27, 2014 14:38

gonadic io: Feb 16, 2011; >>=

for real though:

code:

> listToMaybe [1,2,3]
Just 1

> listToMaybe []
Nothing

> listToMaybe [Just 1, Just 2]
Just (Just 1)

> listToMaybe [Nothing, Just 2]
Just Nothing

# ? Aug 27, 2014 14:43

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

MononcQc posted:

fwiw there's a reason Haskell had to develop more classic exceptions than Either/Maybe when it's in its IO monad -- there is a class of exceptions that happens when doing parallelism or specific tasks with the outside world are asynchronous, which can't very well be represented in a synchronous mechanism (like function returns).

They're really neat to have, but there are cases where they'll be insufficient to cover all the stuff that actually exists. You need more stuff

async exceptions in Haskell are a great way to kill yourself

# ? Aug 27, 2014 14:59

MononcQc: May 29, 2007

Malcolm XML posted:

async exceptions in Haskell are a great way to kill yourself

The world is a dangerous place.

Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell

p29 posted:

The next member of the Awkward Squad is robustness and error recovery. A robust program should not collapse if something unexpected happens. Of course, one tries to write programs in such a way that they will not fail, but this approach alone is insufficient. Firstly, programmers are fallible and, secondly, some failures simply cannot be avoided by careful programming.

Our web server, for example, should not cease to work if

A file write fails because the disk is full.

A client requests a seldom-used service, and that code takes the head of an empty list or divides by
zero.

A client vanishes, so the client-service thread should time out and log an error.

An error in one thread makes it go into an infinite recursion and grow its stack without limit.

All these events are (hopefully) rare, but they are all unpredictable. In each case, though, we would like our web server to recover from the error, and continue to offer service to existing and new clients.

We cannot offer this level of robustness with the facilities we have described so far. We could check for failure on every file operation, though that would be rather tedious. We could try to avoid dividing by zero � but we will never know that we have found every bug. And timeouts and loops are entirely inaccessible.

This is, of course, exactly what exceptions were invented for. An exception handler can enclose an arbitrarily large body of code, and guarantee to give the programmer a chance to recover from errors arising anywhere in that code.

Also:

p30 posted:

The Haskell 98 design falls short in two ways:

It does not handle things that might go wrong in purely-functional code, because an exception can only be raised in the IO monad. A pattern-match failure, or division by zero, brings the entire program to a halt. We address this problem in Section 5.2

It does not deal with asynchronous exceptions. A synchronous exception arises as a direct result of
executing some piece of code � opening a non-existent file, for example. Synchronous exceptions can be raised only at well-defined places. An asynchronous exception, in contrast, is raised by something in the thread�s environment: a timeout or user interrupt is an asynchronous exception. It is useful to treat resource exhaustion, such as stack overflow, in the same way. An asynchronous exception can strike at any time, and this makes them much harder to deal with than their synchronous cousins.

the gist of it is (if I got it right): when it comes to threading (which happens in an IO monad among others), it may be desirable to send exceptions across threads, or from events that are more or less global to the environment. These exceptions are asynchronous and not really a thing that you can handle in a functional workflow, and therefore require capabilities that are above monadic error management (which is purely synchronous and based on the current code flow) as far as I can tell.

Exceptions with a catch can deal with this async flow, so they make sense to have. However, restricting them to the IO monad also makes sense from the functional point of view, where order of evaluation with the lazy language and whatnot is more complex semantically (p31).

# ? Aug 27, 2014 15:25

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

Subjunctive posted:

the most common issue there in JS is probably accidental stringification. if something inadvertently ends up as a string, you can apply addition to it, but also array operations like subscripting and .length. and it's all too easy to end up with a string when working with DOM.

(.length on a number in JS will evaluate to undefined, rather than throw, because primitives are automatically boxed when properties are accessed)

rustchat: we've been looking at Rust internally as a systems language, because it should be pretty fast, pretty safe, be reasonable for doing concurrent stuff, and have a good FFI. pretty sure there isn't anything in production yet, though.

I've been looking at using it, but the fact that things are still so up in the air with the language has stopped me. hopefully they can decide what they want in the language as a part of 1.0 and get it done

what have they said they are targeting performance wise?

# ? Aug 27, 2014 15:45

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

haskell seems p. cool but there's a lot of built in functions that are hard to remember if you dont use it a lot (head tail last init reverse take fst snd zip takeWhile filter foldl foldr...). is there like a haskell cheetsheet out there?

Notorious b.s.d. posted:

we've reached a tautology. you don't find type systems useful because you don't take advantage of type systems.

in the degenerate case, two floating point numbers that have important semantic differences, you can't see the point of a type system. that's kinda ruling out type systems as a tool

you arent really reading what i said

# ? Aug 27, 2014 16:31

Corla Plankun: May 8, 2007; improve the lives of everyone

HappyHippo posted:

you arent really reading what i said

lol if you are just figuring that out now after 5 pages of notbsd telling noone in particular over and over again that it is the language's fault that he cannot let go of irrelevant idioms from elsewhere when programming in a new language

# ? Aug 27, 2014 16:48

gonadic io: Feb 16, 2011; >>=

HappyHippo posted:

haskell seems p. cool but there's a lot of built in functions that are hard to remember if you dont use it a lot (head tail last init reverse take fst snd zip takeWhile filter foldl foldr...). is there like a haskell cheetsheet out there?

for syntax there are a few, but that doesn't answer your question about using libraries

one thing that can be useful is Hoogle which lets you search for type signatures, names or modules. also search through the respective modules' documentation, i.e. if your function fucks with lists then your function will probably be found in Data.List, dummy. a third problem is discovering that these modules exist in the first place - Data.Traversable is pretty obscure but it turns out can simplify a lot array or vector code. this is mostly a matter of reading about - the later chapters of Learn You A Haskell are a good place to start.

finally, for lens you can't really do any of these things so the only way to get into that is pick the one out of a dozen tutorials which was written by the author and is good, rather than the other 11 written by somebody saying "oh i get this now I'm so smart i'm going to write a guide" (known as the Monad-Burrito fallacy).

really finally, there are a bunch of talks on all of these topics available online but nobody searching for help would ever watch an hour long talk so these are mostly ignored

# ? Aug 27, 2014 16:49

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

thanks man thats helpful

# ? Aug 27, 2014 18:21

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Notorious b.s.d. posted:

so, yeah, we don't have languages with great primitives to express lengthy, unsignalled halts in computation to functions with point-in-time values

we do have languages with great primitives to mark whether a thing is meters or inches, and people itt are unironically arguing that that's not useful

I think it's reasonable to argue that the classes of problems you encounter in most programs are closer to "checking certificate correctness" than "converting centigrade to farenheit"

having worked for the last several years primarily in Python, I really like the idea of stronger type systems, but I do wonder how often you'd actually be able to match the kinds of types described here to actual business logic in actual business code.

# ? Aug 27, 2014 19:11

b0lt: Apr 29, 2005

PleasingFungus posted:

I think it's reasonable to argue that the classes of problems you encounter in most programs are closer to "checking certificate correctness" than "converting centigrade to farenheit"

having worked for the last several years primarily in Python, I really like the idea of stronger type systems, but I do wonder how often you'd actually be able to match the kinds of types described here to actual business logic in actual business code.

string escaping is a good example that's the same as certificate correctness, but a lot more relatable for plang-using webdevs

# ? Aug 27, 2014 19:15

FamDav: Mar 29, 2008

Max Facetime posted:

while I agree, I do see the point. going back to the certificate validation example, we might say that a certificate is safe for use if a bunch of mathematical relations hold and also that it won't expire in the next 5 minutes. so our algorithms establishes these invariants, we declare the certificate Valid...

... and the battery in the laptop malfunctions causing the OS to think it has been completely drained. the OS performs an emergency hibernation to try to minimize data loss...

... 10 minutes later we have finally found a compatible wall-charger but it's too late; the certificate has expired in the meantime. oh no! we tremble as the laptop starts to boot...

this isn't just an issue with type checking missing some errors, though. an invariant that can cease to hold on its own without any computation having taken place goes against pretty much everything that CS stands for. or mathematics

just because an invariant (this cert is only valid for five minutes from creation) cant be encoded in a type system doesnt mean we cant use the type system to enforce an invariant. you can enforce the 5 minute deadline by constraining how certs are created and used, like so.

code:

data Cert m = Cert m (Certificate, Time)

genCert :: x0 -> x1 -> x2 -> Cert IO

withCert :: Cert IO -> (Certificate -> IO b) -> EitherT IO CertificateError b

not that you couldn't create the same constraints in a dynamic language, but i would think a lot of devs would not do the extra work and just wing it :/

FamDav fucked around with this message at 19:45 on Aug 27, 2014

# ? Aug 27, 2014 19:42

Notorious b.s.d.: Jan 25, 2003; by Reene

PleasingFungus posted:

I think it's reasonable to argue that the classes of problems you encounter in most programs are closer to "checking certificate correctness" than "converting centigrade to farenheit"

converting centigrade to fahrenheit is the easiest possible example: tag two floating point numbers with two "kinds" to automate conversions and prevent fuckups. it's the degenerate case.

a couple people in this thread rejected that as too much work, which is how we have bad type systems in scripting languages.

PleasingFungus posted:

having worked for the last several years primarily in Python, I really like the idea of stronger type systems, but I do wonder how often you'd actually be able to match the kinds of types described here to actual business logic in actual business code.

your business logic is probably not going to be expressed in the type system

invariant properties of business objects probably will be. for example, a purchase order is not the same kind of thing as a sales order, even if they are structured almost identically and share storage

Notorious b.s.d. fucked around with this message at 19:49 on Aug 27, 2014

# ? Aug 27, 2014 19:47

Notorious b.s.d.: Jan 25, 2003; by Reene

Corla Plankun posted:

lol if you are just figuring that out now after 5 pages of notbsd telling noone in particular over and over again that it is the language's fault that he cannot let go of irrelevant idioms from elsewhere when programming in a new language

i've been writing ruby on and off for thirteen years. i am pretty sure "moving to a new language" isn't the issue here.

it's just that scripting languages are bad tools for my current problems

# ? Aug 27, 2014 19:48

MeruFM: Jul 27, 2010

sounds like the biggest problem with a type system is every developer gotta remember what types to use and not stick data into the wrong types

# ? Aug 27, 2014 19:50

JewKiller 3000: Nov 28, 2006; by Lowtax

Notorious b.s.d. posted:

it's just that scripting languages are bad tools

# ? Aug 27, 2014 20:51

Soricidus: Oct 21, 2010; freedom-hating statist shill

MeruFM posted:

sounds like the biggest problem with a type system is every developer gotta remember what types to use and not stick data into the wrong types

the biggest advantage of static typing is that if they get it wrong, you'll get an error message immediately pointing out exactly where they got it wrong, not buried in some test results or silently just doing the wrong thing at runtime.

sometimes, at least. but that's a drat sight better than nothing.

# ? Aug 27, 2014 21:02

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

b0lt posted:

string escaping is a good example that's the same as certificate correctness, but a lot more relatable for plang-using webdevs

Notorious b.s.d. posted:

invariant properties of business objects probably will be. for example, a purchase order is not the same kind of thing as a sales order, even if they are structured almost identically and share storage

aight, works for me

# ? Aug 27, 2014 21:05

Notorious b.s.d.: Jan 25, 2003; by Reene

MeruFM posted:

sounds like the biggest problem with a type system is every developer gotta remember what types to use and not stick data into the wrong types

this is the biggest issue in computing, period, not just type systems.

the two hardest problems in computer science are naming things, caching, and off-by-one-errors.

# ? Aug 27, 2014 21:35

raminasi: Jan 25, 2005; a last drink with no ice

i want a lightweight little config file thing that will have lists in it. is there something better than yaml?

# ? Aug 27, 2014 21:36

qntm: Jun 17, 2009

Off-by-one errors are super simple, though.

# ? Aug 27, 2014 21:42

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

qntm posted:

Off-by-one errors are super simple, though.

only because dereferencing uninitialized memory isnt something most programmers have to worry about any more

# ? Aug 27, 2014 21:49

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 04:00

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

qntm posted:

Off-by-one errors are super simple, though.

lol off by one errors are stupidly hard to find when bit fiddling

# ? Aug 27, 2014 22:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »