|
tef posted:prolog hasn't had any significant influence beyond erlang (and just the syntax), or datalog (toned down matching), and it's kinda rotted as a research vehicle. There's Mercury for a logic language influenced by both Prolog and Haskell. Prolog had significant influence on Mercury, though I'm not sure that's the significance you were looking for.
|
#
?
Feb 5, 2013 16:41
|
|
|
|
| # ? Jun 2, 2024 20:54 |
|
|
MononcQc posted:There's Mercury for a logic language influenced by both Prolog and Haskell. Prolog had significant influence on Mercury, though I'm not sure that's the significance you were looking for. it's prolog with static typing. it does mean prolog goes incredibly fast.
|
|
#
?
Feb 5, 2013 16:49
|
|
|
Jonny 290 posted:*furiously bashes "Read More..." link* learn you some prolog
|
|
#
?
Feb 5, 2013 16:49
|
|
|
quote:If the new version of foo is going to throw a new exception that clients should think about handling, isn't their code broken just by the fact that they didn't expect that exception when they wrote the code? No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. this is the fundamental argument against checked exceptions and its totally wrong. I absolutely care about new exceptions IF they can be handled by my code (aka a checked exception). the assumption that people don't care is wrong and stupid and reeks of p-lang laziness. also the scalability issue isn't an actual issue since the "four or five" different exceptions probably all have similar meanings that are specific to their library. these can be abstracted into another exception and rethrown. this creates centralized exception handling without giving up on the possibility of handling them between the low level thrower and the global handler. MononcQc posted:I was under the general impression that what made expression handling truly bad is when you handle poo poo you don't know how to handle. I understand how checked exceptions help deal with stuff you might have forgotten, but I don't see how it helps you get the insight to deal with poo poo you don't know how to deal with. the point is that it gives you that exposure to problems that might occur that you otherwise wouldn't know about. handle the ones you can, rethrow the ones you cant. people can always handle exceptions wrong and lazy people will eat checked exceptions, but lazy people wouldn't handle unchecked exceptions either so its moot. tbh I would be fine with something in the middle that punts the requirement to check exceptions to the IDE. You would need to have base Exception and RuntimeExceptions as in java to differentiate them, but then you can leave it up to the IDE as to whether or not Exceptions should be checked. The compiler treats them the same. That's not ideal since you'll always have the idiot who turns it off, but it will let lazy people continue to be lazy.
|
|
#
?
Feb 5, 2013 16:59
|
|
|
i dont like java, but java does exceptions correctly and shaggar is right
|
|
|
#
?
Feb 5, 2013 17:05
|
|
|
also rethrowing exceptions in c# is a giant pain in the rear end cause if you partially handle one it eats the stack trace. its retarded.
|
|
#
?
Feb 5, 2013 17:08
|
|
|
"Exception safety is sort of like pregnancy...but hold that thought for a moment. We can't really talk reproduction until we've worked our way through courtship." - Scott Meyers
|
|
|
#
?
Feb 5, 2013 17:08
|
|
|
had prolog in the same class where we hosed with scheme and ml and it seemed pretty cool but it'd be nice to see some practical use of it
|
|
#
?
Feb 5, 2013 17:08
|
|
|
Shaggar posted:also rethrowing exceptions in c# is a giant pain in the rear end cause if you partially handle one it eats the stack trace. its retarded. to be honest, needing to rethrow exceptions largely sounds like there's a problem in the language's (or code base's) ability to match on exception and only capture what is intended. "I caught it but didn't mean to, woops"
|
|
#
?
Feb 5, 2013 17:11
|
|
|
that would require that it read the developers mind. also part of rethrowing in a proper exception model is to map exceptions you cant handle from low level exceptions to higher level exceptions. if you wanted to have this map be external to code rather than inline that would probably work and be pretty sw8. either way the developer has to tell the language what to do cause the association doesn't exist outside of they head.
|
|
#
?
Feb 5, 2013 17:17
|
|
|
he means the boilerplate where he catches a bunch of different exceptions in different hierarchies, and then throws a new one
|
|
#
?
Feb 5, 2013 17:18
|
|
|
OBAMA BIN LinkedIn posted:i dont like java, but java does exceptions correctly and shaggar is right like I said you kinda need to be writing software beyond hello world and database skins threaded together by xml to notice the problem. loving academics
|
|
#
?
Feb 5, 2013 17:20
|
|
|
i would read shaggar's blog
|
|
#
?
Feb 5, 2013 17:21
|
|
|
Shaggar posted:tbh I would be fine with something in the middle that punts the requirement to check exceptions to the IDE. this right here. I don't believe the estimate of eventually having to declare 40 or 80 checked exceptions per method but even then an IDE is well capable of keeping track of 80 import statements per class, so updating a list of 80 exception classes and folding of it out of sight shouldn't be any problem i blame all old text editors for this
|
|
#
?
Feb 5, 2013 17:23
|
|
|
if programming sucks, blame the people using old text editors to design new programming languages
|
|
#
?
Feb 5, 2013 17:27
|
|
|
tef posted:if declarative programming is neat, logic programming is crack. You can get almost the same high from a more 'useful' language with c#. LINQ plus the reactive extensions (especially as a way to compose async stuff - ie, an event that is only raised a single time) is great. Interleaving error logging and stuff makes it bloat a tiny bit, but it's still really nice. I had high hopes for handling UI the same way, but XAML just doesn't end up feeling quite as right. The CLR pays my bills so I'm probably biased, but I like the direction they've taken C# in. Shaggar posted:also rethrowing exceptions in c# is a giant pain in the rear end cause if you partially handle one it eats the stack trace. its retarded. catch(LowLevelException ex) { throw new HighLevelException("a bloo bloo", ex); }
|
|
#
?
Feb 5, 2013 17:29
|
|
|
reblog my tumblr, dude
|
|
#
?
Feb 5, 2013 17:29
|
|
|
Shaggar posted:tbh I would be fine with something in the middle that punts the requirement to check exceptions to the IDE. You would need to have base Exception and RuntimeExceptions as in java to differentiate them, but then you can leave it up to the IDE as to whether or not Exceptions should be checked. The compiler treats them the same. That's not ideal since you'll always have the idiot who turns it off, but it will let lazy people continue to be lazy. that's 100% better. don't make me write out all the exceptions that could potentially be thrown, just tell me about them if i ask MononcQc posted:to be honest, needing to rethrow exceptions largely sounds like there's a problem in the language's (or code base's) ability to match on exception and only capture what is intended. "I caught it but didn't mean to, woops" rethrowing is nice for appending extra information to the error message about the state of the program
|
|
#
?
Feb 5, 2013 17:30
|
|
|
hepatizon posted:rethrowing is nice for appending extra information to the error message about the state of the program What do you plan to do with that information, generally speaking? Use it to fix the exception? What makes it impossible to fix right away knowing that information? Log it? I guess I can see it could make sense to log upwards if you don't have nice ways to do logging, but it would sound lovely not to be able to log from pretty much anywhere as you need it. Or maybe grouping all the logs together I guess. What kind of additional information would you add, realistically speaking?
|
|
#
?
Feb 5, 2013 17:44
|
|
|
i kinda think exceptions encourage a micromanagement sort of coding, where you have things handling the details of code, way, way down the call stack. rethrowing is totally broken under checked exceptions, and trying to glue two different exception hierarchies together is painful. it basically punishes any code that wants to just pass on the error and tidy up. which should be almost all of your code. if an error needs to go up through the call stack, it probably doesn't need to be handled by anything but the outermost layer. on the other hand if it isn't such an exceptional error, but more run of the mill, it really shouldn't propagate implicitly. if the program can continue running after an exception, then isn't really an exceptional occurrence, but something the program can anticipate and handle explicitly. pretty much every good use case of checked exceptions can be replaced by option types + a match statement that isn't valid unless every case is handled. it's far less broken than the hodge-podge of null or exception for errors, where some implicitly propagate. when you're not wanting option types, you're really wanting a non-local exit. exceptions are a poor's call-cc, used to implement weird control flow by hijacking the error handling. by gluing together option types and non local exit you have created a monster. now instead of compiler checks, you have program labour. and you've still done nothing about nulls. all you have is a lot of boilerplate that is frequently circumvented, and no useful compiler checking. exceptions, checked and unchecked, are the comefrom of error handling. they are bad. checked exceptions takes a bad idea and makes it painful to use. the end.
|
|
#
?
Feb 5, 2013 17:48
|
|
|
Sneaking Mission posted:i would read shaggar's blog get a tumblr, works for me
|
|
#
?
Feb 5, 2013 17:48
|
|
|
Win8 Hetro Experie posted:if programming sucks, blame the people using old text editors to design new programming languages *make it a warning in the ide, no-one ever ignores those*
|
|
#
?
Feb 5, 2013 17:49
|
|
|
havelock posted:You can get almost the same high from a more 'useful' language with c#. LINQ plus the reactive extensions (especially as a way to compose async stuff - ie, an event that is only raised a single time) is great. Interleaving error logging and stuff makes it bloat a tiny bit, but it's still really nice. I had high hopes for handling UI the same way, but XAML just doesn't end up feeling quite as right. kinda, but not. the logic variables, unification and backtracking make for incredible pattern matching. those things you mention are still cool, but they're not prolog. reactive stuff is its own awesome world. quote:The CLR pays my bills so I'm probably biased, but I like the direction they've taken C# in. c# is quite neat
|
|
#
?
Feb 5, 2013 17:52
|
|
|
c# versus java
|
|
#
?
Feb 5, 2013 17:56
|
|
|
havelock posted:
this kills this stack trace. hepatizon posted:that's 100% better. don't make me write out all the exceptions that could potentially be thrown, just tell me about them if i ask you don't even need to do this in java, you just don't handle the exception yourself and the IDE appends that your method throws the exception. its super loving easy. so the only time you're gonna have a catch statement is when you're actually gonna A) handle the exception, B) try to handle the exception in certain cases and rethrow otherwise, C) wrap it in a high level exception cause u've reached a boundary in u're code. ugh. its just so loving lazy not to properly do exception handling cause you cant be assed to look at the exception handling logic.
|
|
#
?
Feb 5, 2013 17:57
|
|
|
no-one will ever have to read the autogenerated code. or maintain it. c.f that old loving joke about the programmer lifecycle starting off with something simple and getting more and more elaborate before becoming simple again. except, they write more and more code, so much so that that can't read or write code without special tools and editors. which in turn allows them to write more and more code until the editors choke. programming languages have become serialization exercises for ide macros. why don't you just your loving java code in xml and be done with it. oh.
|
|
#
?
Feb 5, 2013 18:02
|
|
|
Shaggar posted:this kills this stack trace. still available in .InnerException and becomes part of the string representation, too, with the default ToString implementation.
|
|
#
?
Feb 5, 2013 18:02
|
|
|
checked exceptions actually make exceptions less painful to use because they force the programmer to be aware of an error that is going to kill their program if they don't handle it in some way. what is loving garbage is the perl way of doing exceptions where a module can throw any random untyped exception so that the programmer has to know in advance what the error message is to pattern match on it, and then swallow anything else.
|
|
|
#
?
Feb 5, 2013 18:10
|
|
|
tef posted:i kinda think exceptions encourage a micromanagement sort of coding, where you have things handling the details of code, way, way down the call stack. rethrowing is totally broken under checked exceptions, and trying to glue two different exception hierarchies together is painful. it basically punishes any code that wants to just pass on the error and tidy up. quote:if the program can continue running after an exception, then isn't really an exceptional occurrence, but something the program can anticipate and handle explicitly. quote:pretty much every good use case of checked exceptions can be replaced by option types + a match statement that isn't valid unless every case is handled. it's far less broken than the hodge-podge of null or exception for errors, where some implicitly propagate. when you're not wanting option types, you're really wanting a non-local exit. exceptions are a poor's call-cc, used to implement weird control flow by hijacking the error handling. idk what weird world you live in where all errors are handled by the compiler. the compiler cant handle problems that exist at runtime without the programmers input and that's why exceptions exist.
|
|
#
?
Feb 5, 2013 18:13
|
|
|
Shaggar posted:you can always check for things like a file being there but nothing prevents the file from disappearing in the middle of your work and you need to handle that. handling it should not mean crashing. exceptions have nothing to do with this. check whether each call succeeds rather than stat-ing the file then stupidly assuming the rug hasn't been pulled out from under you. this technique has only been known to real programmers since, i don't know, 1970 or so, and is taught in every operating systems class ever
|
|
#
?
Feb 5, 2013 18:19
|
|
|
if the thing that's doing the IO can handle the exception all within itself then sure. sometimes it cant so you throw the exception.
|
|
#
?
Feb 5, 2013 18:22
|
|
|
Shaggar posted:idk what weird world you live in where all errors are handled by the compiler. the compiler cant handle problems that exist at runtime without the programmers input and that's why exceptions exist. a world where compilers are good enough to not need huge runtime xml suppositories to make working and flexible programs
|
|
#
?
Feb 5, 2013 18:28
|
|
|
shaggar, have you heard of 'option types' it's like this. instead of putting errors in the throws bit. you put it in the type signature. you know that bit that's actually about what a function does or returns. Option<String,Exception> output = some_method_that_normally_throws() match output { case String: ...... } // oh poo poo if it is not handled this is now an exception. all errors should be handled. // if you like, match can actually refuse to compile unless you handle each option. oh and i can return output to propagate it, or I can add a succsor like value() which throws. it's like someone has gone, i know what would be cool, let's specify one part of the return on each part of the method name. instead i kinda like putting the thing a function can return in the return type. i do not understand why you want a crazy language feature when you just need a loving switch statement
|
|
#
?
Feb 5, 2013 18:29
|
|
|
Shaggar posted:totally wrong. beyond wrong. dangerous wrong. you can always check for things like a file being there but nothing prevents the file from disappearing in the middle of your work and you need to handle that. handling it should not mean crashing. fwiw in reenux land, an unlinked file isn't really gone until its last fd is closed. If you successfully opened it and are holding it open, its still there. dunno what windows does for this though, I've gotten to where I just assume they just go with whatever behavior is most  where file access is concerned
|
|
#
?
Feb 5, 2013 18:31
|
|
|
if you're writing throws you're really saying 'i return a value or this error'. make it a return type you idiot.
|
|
#
?
Feb 5, 2013 18:33
|
|
|
Progressive JPEG posted:dunno what windows does for this though, I've gotten to where I just assume they just go with whatever behavior is most cf quantum tunneling. if you have a file, delete it and write it fresh, within a time window, you inherit the permissions.
|
|
#
?
Feb 5, 2013 18:34
|
|
|
tef posted:cf quantum tunneling. is this based on the same process/user or could you steal somebody else's file this way lol
|
|
#
?
Feb 5, 2013 18:36
|
|
|
Werthog 95 posted:had prolog in the same class where we hosed with scheme and ml and it seemed pretty cool but it'd be nice to see some practical use of it Same, our midterm was to solve 60 problems in all 3 languages 
|
|
#
?
Feb 5, 2013 18:40
|
|
|
tef posted:shaggar, have you heard of 'option types' so you check the result for the exception instead of the method call? and if its not a language feature now you're just eating errors so no one can see them, not even the runtime. that sounds really bad. atleast with rethrown exceptions if no one handles them they get back to the top of the stack and the runtime throws them for someone to know about. stuffing it into a return value that the programmer has to remember to check sounds like the worst way to do it. "lets hope everyone buys into our wacky artisanal exception handling!! no we cant just use exceptions, those work!"
|
|
#
?
Feb 5, 2013 18:44
|
|
|
|
| # ? Jun 2, 2024 20:54 |
|
|
Shaggar posted:so you check the result for the exception instead of the method call? and if its not a language feature now you're just eating errors so no one can see them, not even the runtime. that sounds really bad. atleast with rethrown exceptions if no one handles them they get back to the top of the stack and the runtime throws them for someone to know about. stuffing it into a return value that the programmer has to remember to check sounds like the worst way to do it. "lets hope everyone buys into our wacky artisanal exception handling!! no we cant just use exceptions, those work!" A return value you don't match on, depending on the type system and runtime system, will not compile (equivalent to your checked exceptions), or generate an exception (where it is truly exceptional).
|
|
#
?
Feb 5, 2013 18:46
|
|