|
Shaggar posted:I mean seriously. whats the upside? you maybe kind of save some typing if you choose to ignore the problem? you're so thoroughly wrong here that the only reasonable response tef or anyone else can give you is "read a book"
|
#
?
Jul 24, 2013 01:21
|
|
|
|
| # ? May 8, 2024 06:55 |
|
|
so whats a good text on learning a java
|
|
#
?
Jul 24, 2013 01:32
|
|
|
deitel, deitel et. al
|
|
#
?
Jul 24, 2013 01:36
|
|
|
shaggar's gimmick is wearing on me I think
|
|
#
?
Jul 24, 2013 01:38
|
|
|
there's something to be said for option types wrapping up all kinds of failure in a monolithic None/Nothing/whatever but the answer to that isn't 'welp gently caress your control flow' it's Either and data MyError = Foo | Bar | Baz 
|
|
#
?
Jul 24, 2013 01:40
|
|
|
option types are great when you dgaf what the error is which is almost all the time tbh
|
|
#
?
Jul 24, 2013 01:43
|
|
|
idk I'd prefer to know what error occurred and why so I can inform the user of the problem and possibly log it. but maybe that's because I work in a language where calling a procedure with the wrong number of inputs or wrong types is a runtime error rather than a compiler error. 
|
|
#
?
Jul 24, 2013 02:04
|
|
|
Shaggar posted:also primary keys should be the natural primary key whenever possible. you should pretty much always have a surrogate key tho. Iquitos question about this. I have a haul, that holds a bucket of loads, should I have this? dbo.Haul Id [int] HaulUID [guid] HaulName [varchar] Dbo.Load Id [int] LoadUID [guid] HaulID [foreign key int] LoadName What is the point of a surrogate key?
|
|
#
?
Jul 24, 2013 02:08
|
|
|
Dirk Pitt posted:What is the point of a surrogate key? in case something hosed happens with the natural key
|
|
#
?
Jul 24, 2013 02:29
|
|
|
i haven't seen a shaggaring this good in a while, thanks tef. sometimes you forget and start thinking "shaggar was right" is for real, but its arguments like this that really gets the blood movin again.
|
|
#
?
Jul 24, 2013 02:30
|
|
|
get yourself shaggared at least once every three months for your health
|
|
#
?
Jul 24, 2013 02:31
|
|
|
Shaggar posted:text editor usage coincides w/ p-lang and Linux usage and is a clear sign of mental health issues i use notepad++ for python
|
|
#
?
Jul 24, 2013 02:33
|
|
|
Pendragon posted:idk I'd prefer to know what error occurred and why so I can inform the user of the problem and possibly log it. returning None is not an error. it's just a thing that happened. you went looking for Some(thing) and got None(thing) instead. if you have a real error, and the program cannot continue, use an exception. getting None out of an option probably wasn't such an error.
|
|
#
?
Jul 24, 2013 02:34
|
|
|
Cocoa Crispies posted:in case something hosed happens with the natural key So is the surrogate a Guid if the natural key is an autoincrementing int?
|
|
#
?
Jul 24, 2013 03:01
|
|
|
Notorious b.s.d. posted:returning None is not an error. it's just a thing that happened. ayup either you can continue or you can't. option types cover the first case and exceptions cover the second
|
|
#
?
Jul 24, 2013 03:06
|
|
|
ugh I try to stay out of this stupid wankery but this bugged me the last time w e had the dumb exceptions vs. option types argument so I have to just ask it is there any functional difference at all or is this just a case of you should do things my way and anyone who doesn't is an idiot. I mean is there something you can do with option types that you can't do with exceptions or vice versa. frankly it seems an awful lot to me like different syntax for the same concept.
|
|
#
?
Jul 24, 2013 04:01
|
|
|
HORATIO HORNBLOWER posted:ugh I try to stay out of this stupid wankery but this bugged me the last time w e had the dumb exceptions vs. option types argument so I have to just ask it they're actually pretty different! option types are a much more sophisticated variant on old c-style error codes. instead of returning a flag, you can return anything, within a list of predeclared possibilities for your function! but it's basically just a normal return; only the calling function is going to see it (unless they choose to pass it along), and if they don't explicitly examine the returned value, it's going to end up swallowed silently. exceptions, on the other hand, are very powerful. if uncaught, they'll blow upwards through potentially multiple functions, all the way to the top of the program, following which they crash it. when you call a function that can throw exceptions*, unless you have a try-catch-finally block around the call, control may well never return! *any function, in a language with exceptions, despite what Shaggar will claim  basically, there are two differences. one is the default response: returning an error option does nothing if the caller isn't looking for it, whereas exceptions travel upwards and (eventually) kill the program if the caller(s) aren't expecting it. two is the locality: option types preserve normal control flow, whereas exceptions violate it. they're definitely both attempts to solve (approximately) the same problem, but the end result is night and day.
|
|
#
?
Jul 24, 2013 04:23
|
|
|
Dirk Pitt posted:Iquitos question about this. Natural primary keys are keys that describe a unique version of the object outside the database. Like lets say you have a table of user logins. dbo.Users Id [int] auto-increment surrogate key Email [varchar] PK Firstname [varchar] Lastname [varchar] password [varchar(8)] (this is tbc's db) Email is your natural primary key. Multiple users cant have the same email address, however, they may want to change their email address without creating a new account. So we keep the surrogate key around in case they change it. Any time a user is referenced elsewhere in the db you use the surrogate key. Lets add some more stuff. dbo.Roles Id [int] auto-increment surrogate key Name [varchar] PK Description [varchar] dbo.UserRoles UserId [int] PK FK->UserId RoleId [int] PK FK->RoleId In UserRoles we map users to roles. The combination of User and Role is unique. Either the user has a role or they don't. We don't need a surrogate key to represent to relationship because it makes no sense. If either column changes, the relationship is a different entity. How about one more table. dbo.Address Id [int] auto-increment surrogate key Address1 [varchar] PK Address2 [varchar] PK City [varchar] PK State [varchar] PK ZIP [varchar] PK Address is an example of a multi column natural pk. The combination of all those fields is unique. Since multiple entities can be related to address we want to make sure when we do that relationship we do it to a unique address. Without the surrogate key, the unique relationship between objects and an address would be the entire address. That's gross! So instead we have a surrogate key that will be used whenever we reference the address in another table. Also this should maybe smell a little bit. State should probably be StateId and reference a States table so you can relate other data to a state. Also maybe city for the same reason. If you aren't gonna do that then its fine to have them as varchars. one more db. dbo.Customers Id [int] auto-increment PK Email [nullable! varchar] Firstname [varchar] Lastname [varchar] Phonenumber [varchar] AddressId [int] assume this is a fk to an address table In this case theres no way to have a natural primary key. Not every customer is gonna have an email, so we cant rely on it. Name and address cant be guaranteed to be unique, you could have 2 john smiths at the same place. You cant rely on name and phone number for the same reason, plus the customer could change their phone number and never tell you. So maybe they go to your webzone/store and create a new account cause their dumb, but their phone has changed so they just put in the new info and blam u've got a dupe. You'll never know its a dupe and you cant possibly reconcile it. People are really loving hard to create a natural primary key for if you aren't talking about internet only users (email rules as a pk for lots of reasons). About the only thing you can do (in the us atleast) is social security + dob, but most people aren't gonna give you their ss and you don't want to discriminate against illegals since they have loads of tax free income to spend. So instead we just use the auto-increment id as the PK. This really loving sucks cause it guarantees that without a natural constraint you're gonna get duplicate customers in ur table. Where bad design should smell, this kind of nothing-you-can-do should hurt, but you should understand why it cant be fixed. This pain will never go away. Going back to your example, if the HaulUID is generated by something external to the db then it can be your primary key. If you are generating it in the db its kind of a pointless dupe of the auto increment id. Since its a single column id AND its unlikely to change (Haul sounds like a single use object), you could probably get rid of the surrogate key. Surrogate keys are used when the primary for the entity can legitimately change (unlikely for a Haul) or when the primary key would otherwise be a pain to use as in a multi-column pk (doesn't apply to haul).
|
|
#
?
Jul 24, 2013 04:27
|
|
|
still thinking about the tef ethos for exceptions. tef, would it be fair to characterize your approach as follows? "if an error can be handled by a function's caller, return an error code. if it cannot, throw an exception. if the error can be handled more than one level above the caller, instead of catching the exception, split the program into two processes (one calling the other), exit with an error message (specified by the exception) in the lower process, and handle the error in the higher process." certainly clarifies control flow, but it seems like a pretty extreme approach to the problem; not to mention clunky to maintain. I imagine practically every function could end up as its own process. maybe I'm missing something. or maybe that's the idea? 'one function, one process' does sound pretty unix.
|
|
#
?
Jul 24, 2013 04:35
|
|
|
this is a real good post and I think I understand something new now. thanks!
|
|
#
?
Jul 24, 2013 04:37
|
|
|
PleasingFungus posted:they're actually pretty different! checked exceptions being the superior option since they require the developer to actively decide they want to try to handle it, throw it up the stack (potentially killing the app if everyone throws), or eat it (potentially putting the app in weird state). There are legitimate reasons for all 3, but checked exceptions ensure the developer makes the decision (right or wrong). With option types and runtime exceptions the developer must decide they want to seek out the error and try to deal with it. The default for an option type is then to put the app in a weird state on error. For runtime exceptions, the default on error is to crash the program. Neither are very good options. Also, only runtime exceptions violate control flow. Checked exceptions require that you decide if you want to continue locally or let someone else deal with it. Since runtime exceptions are generally caused by code flaws, there is usually no way to continue locally anyways. If there is you can purposefully check for the condition that would cause the problem (ex: nullpointer). If you're processing some data and a field is null, no amount of restarts is going to make that field not-null. You need to fix the data and then protect your code by checking for it in the future. Maybe by checking for it and throwing an appropriate checked exception with information about what field was null so someone further up the chain can hunt down and fix the data.
|
|
#
?
Jul 24, 2013 04:44
|
|
|
PleasingFungus posted:still thinking about the tef ethos for exceptions. tef, would it be fair to characterize your approach as follows? his point is that sometimes runtime errors will fix themselves if you reboot (which ironically is less likely to be true in functional programming), so let it crash the app.
|
|
#
?
Jul 24, 2013 04:53
|
|
|
the more complex a system becomes conceptually, the more moving pieces it contains, and the more transient state it accumulates (including live data over the wire), the more likely it is, statistically speaking, that some [possibly rare] bug rears its ugly head. Restarting part of the system to get back to a clean known state dramatically simplifies things and will fix many heisenbugs on its own, rather than propagating the bug's nasty side-effects to portions of the state still intact.
|
|
#
?
Jul 24, 2013 05:08
|
|
|
PleasingFungus posted:they're actually pretty different! no, I'm not stupid, I understand that how they actually work is different, but when the argument is made that option types are "better" i'm curious if that's based on something real or just an arbitrary preference and it looks like the latter
|
|
#
?
Jul 24, 2013 05:22
|
|
|
Shaggar posted:checked exceptions being the superior option since they require the developer to actively decide they want to try to handle it, throw it up the stack (potentially killing the app if everyone throws), or eat it (potentially putting the app in weird state). There are legitimate reasons for all 3, but checked exceptions ensure the developer makes the decision (right or wrong). With option types and runtime exceptions the developer must decide they want to seek out the error and try to deal with it. The default for an option type is then to put the app in a weird state on error. For runtime exceptions, the default on error is to crash the program. Neither are very good options. Also, only runtime exceptions violate control flow. Checked exceptions require that you decide if you want to continue locally or let someone else deal with it. Since runtime exceptions are generally caused by code flaws, there is usually no way to continue locally anyways. If there is you can purposefully check for the condition that would cause the problem (ex: nullpointer). If you're processing some data and a field is null, no amount of restarts is going to make that field not-null. You need to fix the data and then protect your code by checking for it in the future. Maybe by checking for it and throwing an appropriate checked exception with information about what field was null so someone further up the chain can hunt down and fix the data. every java function implicitly [throws NullPointerException], among others. the checked exception model is both ideologically inconsistent and ineffective in practice. (ref.: any piece of production java code.) MononcQc posted:the more complex a system becomes conceptually, the more moving pieces it contains, and the more transient state it accumulates (including live data over the wire), the more likely it is, statistically speaking, that some [possibly rare] bug rears its ugly head. Restarting part of the system to get back to a clean known state dramatically simplifies things and will fix many heisenbugs on its own, rather than propagating the bug's nasty side-effects to portions of the state still intact. mm. I feel like your response (& shaggar's) is an answer to a different question than the one I was asking. (I asked a question about control flow; you gave a response about lingering state.) it may or may not be a valid point, but it wasn't really what I was talking about! I'm a big fan of loosely coupled systems but I feel like that's kind of tangential to the question of 'error handling'. I guess with sufficiently distributed systems, the problems converge?
|
|
#
?
Jul 24, 2013 05:22
|
|
|
HORATIO HORNBLOWER posted:no, I'm not stupid, I understand that how they actually work is different, but when the argument is made that option types are "better" i'm curious if that's based on something real or just an arbitrary preference and it looks like the latter well, literally the rest of the conversation was tef's argument that they're better (and shaggar disagreeing with him). tef wasn't arguing very hard (because he was mainly arguing against shaggar, i.e., futilely and/or for his own amusement), but the core of his argument was this: tef posted:java's attempt at checked exceptions on the other hand wasn't really thought out, and such an experimental feature has no place in a production language yet. c# will probably adopt some form of checked exceptions when they mature as a feature, and don't cause so much api breakage, and won't drive most programmers to work around them, but for now they haven't found a good way to make them work in practice. it's not that the idea is bad, but the implementation doesn't live up to it. option types, fail fast isolated processes, and supervision make for far better and robust ways to handle errors. you may disagree with his premises or conclusions (I do!), but I wouldn't say that anything about the reasoning is "arbitrary".
|
|
#
?
Jul 24, 2013 05:29
|
|
|
The benefits of maybe/either types vs. exceptions to me are 1) no special syntax for exception handling, and thus no special behavior just for exceptions 2) by using maybe/either, you are embedding the behavior of the function in its type, and not as an additional side effect. i always love embedding constructs in types 3) how i can handle errors with monads makes more sense to me than throwing exceptions. by splitting up what errors are returned from how they are handled, that means i can drag and drop my own bespoke monad for handling errors. 4) because the possibility to error is in the return type, at a certain a point I will have to handle it or crash, and if I fail to take care of that case then my compiler will warn me.
|
|
#
?
Jul 24, 2013 05:30
|
|
|
FamDav posted:The benefits of maybe/either types vs. exceptions to me are 1) yes. the biggest and most obvious benefit. (also shared with c return codes!  )2) no; this is the same as checked exceptions. 3) no; exactly the kind of reasoning H.H. was complaining about. 4) yes. this is both cool and funny because it is exactly the feature of option types that shaggar either fails or refuses to understand. I really need to do more stuff with functional languages.
|
|
#
?
Jul 24, 2013 05:38
|
|
|
PleasingFungus posted:1) yes. well i would say 4 is more like what checked exceptions are like, and 2 is just a better way of expressing that instead of void f(dilz,butt,rod) throws NullPointerException or however it is represented in java. why is that dude complaining about number 3? i much prefer the idea of being able to write functions whose return types possibly include errors and having a separate handler which defines how to propagate and/or rectify these errors. all of this code lives in userland; there is nothing special jumping over bits of code, calling destructors as it does so, and then blowing up the stack. i like that. which, i need to learn for job related reasons so whats a good book you guys FamDav fucked around with this message at 05:49 on Jul 24, 2013 |
|
#
?
Jul 24, 2013 05:43
|
|
|
PleasingFungus posted:every java function implicitly [throws NullPointerException], among others. the checked exception model is both ideologically inconsistent and ineffective in practice. (ref.: any piece of production java code.) it's hard to accept the argument that stupid programmers will do stupid things as a reason why something is bad or an alternative is better. I mean, in response to me you said "one [difference] is the default response: returning an error option does nothing if the caller isn't looking for it, whereas exceptions travel upwards and (eventually) kill the program if the caller(s) aren't expecting it." so if the default response to an error option is to ignore it, how is that much different from catch(Exception e) {} in java which is widely regarded as a poor practice? you can't say that option types are good because they allow you to easily ignore errors and at the same time say checked exceptions are bad because they encourage lazy programmers to ignore errors. error recovery isn't trivial and oughtn't be blow off, which is my objection to the bad code snippets I posted earlier: it isn't even directly related to the concept of exceptions themselves. the problem is that the people writing the code literally didn't put a single second of thought into what errors might occur and how, why, when, or if they should be handled. java happens to have checked exceptions and they went with the laziest approach that could "work" in that scenario. if java had option types instead you can bet they would have ignored any and all error options that got returned and just plowed on through. it isn't clear to me what happens in that scenario. this is a web app so any uncaught/rethrown exceptions end up getting percolated back to the servlet container which returns a 500 response to the client and ends the request. that isn't exactly like killing the process/restarting the system but for our purposes it's awfully close. I agree 100% with this comment you made: PleasingFungus posted:whether or not an error is 'recoverable' is a system-level property, not one that's visible at the point the error is encountered. for a file-handling library, a missing or corrupt file is a unrecoverable error. for an application using that same library to read a config file, a missing file just means you log an error message & load some defaults. a huge part of the premise of exceptions is that you can delegate responsibility for determining the response to an error upwards. this is the fundamental flaw of c-style thinking. most errors shouldn't be considered either fatal or non-fatal by the code that generates them if we follow a principle of least responsibility; an individual function/method generally doesn't have a broad enough view of the system to know "how fatal" a particular error should be or what the proper recovery procedure should be. the semantics of checked exceptions embody this approach: when an error happens I can either handle it myself (though I probably shouldn't) or pass it up to my caller, who likely has a broader view of the system than I do and can make a better decision about how to proceed. it's a common error for programmers to think every exception has to be handled where it is raised, but again, I don't count "idiots are stupid" as a point against something. PleasingFungus posted:you may disagree with his premises or conclusions (I do!), but I wouldn't say that anything about the reasoning is "arbitrary". frankly I think it is arbitrary. it's typical tef handwaving. thing is bad, it could be better, I won't say how except in the vaguest possible terms. I agree with shaggar that it was a mistake for c# to leave out checked exceptions. I've seen c# codebases on par with the java one I work on; they have no exception handling at all. you can say that's good, because it means they "fail fast"--every exception generated will be fatal because nothing is handling them. but in reality it's the exact same problem as in java: the programmers haven't put any thought into what their error handling strategy is. if you want to turn off checked exceptions in java it's easy as pie. do what my predecessors did and declare every single method as "throws Exception." you'll never have to try/catch anything and you'll get the default top-level response, whether that's killing the process or closing the connection. "fail fast" is robust in the sense that it's the least likely to impact other users or to get the system in a persistently confused state, but i'd argue that a truly robust system should make a best-effort attempt to service each individual request without giving up and starting over. it isn't possible to do that without taking a hard look at the potential error conditions, and I think checked exceptions do a good job of advertising what those are.
|
|
#
?
Jul 24, 2013 06:04
|
|
|
im gonna buy javascript the good parts
|
|
#
?
Jul 24, 2013 06:33
|
|
|
PleasingFungus posted:1) yes. the biggest and most obvious benefit. (also shared with c return codes! 
|
|
#
?
Jul 24, 2013 06:35
|
|
|
this has been some pretty shameful straw man poo poo. Literal pages of arguments against a position no one took Option types are a not a replacement for exceptions. They are a way to express "I didn't find your thing, what do you want to do?" in a predictable, type-safe way. Using exception handling to accomplish the same task is technically possible but ugly and slow. I don't even want to think about how to replace exceptions with options. That poo poo would suck.
|
|
#
?
Jul 24, 2013 06:43
|
|
|
If I were on my desktop I would just paste some code
|
|
#
?
Jul 24, 2013 06:44
|
|
|
Notorious b.s.d. posted:this has been some pretty shameful straw man poo poo. Literal pages of arguments against a position no one took i think your confusing maybe types with option types
|
|
#
?
Jul 24, 2013 06:52
|
|
|
Notorious b.s.d. posted:this has been some pretty shameful straw man poo poo. Literal pages of arguments against a position no one took HRESULT
|
|
#
?
Jul 24, 2013 06:53
|
|
|
vapid cutlery posted:HRESULT I googled that and I'm sorry I did
|
|
#
?
Jul 24, 2013 06:57
|
|
|
Suspicious Dish posted:i think your confusing maybe types with option types um what do you think an option type is vs. maybe type? Maybe is the name for the type in Haskell. In most other functional languages it is option. Maybe a = Just a | Nothing option 'a = Some 'a | None the alternative which allows you to return either a valid result or an error is Either, i.e Either a b = Left a | Right b While both a and b are allowed to vary, since a monad takes a type constructor with one type variable, we fix the error type and allow the return type to vary.
|
|
#
?
Jul 24, 2013 06:57
|
|
|
FamDav posted:um what do you think an option type is vs. maybe type? can't wait to use this to write some software. just kidding.
|
|
#
?
Jul 24, 2013 06:59
|
|
|
|
| # ? May 8, 2024 06:55 |
|
|
now i will explain type reasoning to you. don't mind my hot onion breath
|
|
#
?
Jul 24, 2013 06:59
|
|