|
Dessert Rose posted:perhaps thats because they did not in fact follow the programming guide to the letter misra can never fail, only be failed
|
#
?
Dec 7, 2013 05:10
|
|
|
|
| # ? May 20, 2024 05:23 |
|
|
Tiny Bug Child posted:i want my compiler to error out if my program has any warnings if C++, then this is proper coding and not sperg at all
|
|
#
?
Dec 7, 2013 05:49
|
|
|
Ator posted:C++ Ator posted:not sperg at all hmm yes i agree
|
|
#
?
Dec 7, 2013 05:51
|
|
|
http://kingjamesprogramming.tumblr.com/ a markov chain trained on the king james bible and SICP quote:And Satan stood up against them in that day, and leap for joy: for, behold, your reward is great in heaven: for he maketh his sun to rise on the evil and on the role of procedures in program design.
|
|
#
?
Dec 7, 2013 13:35
|
|
|
Opinion Haver posted:one complaint i hear a lot is that bootstrap makes sites look same-y because customizing it is hard. apparently this is supposed to be easier with bootstrap 3 that was my problem with 2, and 3 has been much easier to work with. bourbon/neat is still better.
|
|
#
?
Dec 7, 2013 13:52
|
|
|
coffeetable posted:http://kingjamesprogramming.tumblr.com/ welcome back, temple os guy!
|
|
#
?
Dec 7, 2013 15:17
|
|
|
Narcissistic Design - Stuart Halloway
|
|
#
?
Dec 8, 2013 16:15
|
|
|
thanks to this, i have spent the afternoon readin up on good unit testing practice b/c yeah my tests are often harder to maintain than the code itself
|
|
#
?
Dec 8, 2013 20:59
|
|
|
type error directed programming is so useful, how the hell do people working in dynamic languages get anything like that done? and don't say tests, because if you reject static typing and then try to replicate its behavior with tests, you're doing it very wrong uhh i guess i'll grep for calls to this function and hope for the best???
|
|
#
?
Dec 8, 2013 21:19
|
|
|
JewKiller 3000 posted:type error directed programming is so useful, how the hell do people working in dynamic languages get anything like that done? i think the point is that errors don't really have types (behaviors!). they have different values. so who cares if you can't distinguish between an EastAfricanFartBonerException and a SouthernEuropeanFartBonerException
|
|
#
?
Dec 8, 2013 21:49
|
|
|
JewKiller 3000 posted:type error directed programming is so useful, how the hell do people working in dynamic languages get anything like that done? this is one of the things that java gets perfect, its type system. rich enough to easily do things like locate all usages of a method without the pedantic idiocy of haskell-style typing
|
|
#
?
Dec 8, 2013 21:51
|
|
|
I feel one of the problems highlighted in the type-based discussion were grievances that people tend not to have with polymorphic types -- stuff you see in Hindley-Milner type systems. That works for code itself, but hardly for all kinds of APIs and larger systems (i.e. distributed) where the error type isn't necessarily what you care about. Then there's the friction of an API being very active into pushing its implementation language's semantics to the public, which is, in a way, a leaky abstraction. I mean, you care to know that the data format you're shoveling around is wrong so that it can be fixed, but the error itself doesn't ever prescribe how you should behave in case of failure, what to do once the contract is broken, or a connection. The type system tells you "well duh it's broken", but not how to react to that or other kinds of problems. I'd have to listen to it more with more attention again though. MononcQc fucked around with this message at 22:06 on Dec 8, 2013 |
|
#
?
Dec 8, 2013 22:03
|
|
|
java knows what to do in case of failure, too: throw an exception. too bad that catch blocks exist
|
|
#
?
Dec 8, 2013 22:07
|
|
|
Brain Candy posted:who cares if you can't this is not a phrase i should have to hear when the problem is already solved except for bad/lazy programmers MononcQc posted:Hindley-Milner type systems 
|
|
#
?
Dec 8, 2013 22:07
|
|
|
Brain Candy posted:i think the point is that errors don't really have types (behaviors!). they have different values. so who cares if you can't distinguish between an EastAfricanFartBonerException and a SouthernEuropeanFartBonerException dependent types to the rescue
|
|
#
?
Dec 8, 2013 22:09
|
|
|
Nomnom Cookie posted:java knows what to do in case of failure, too: throw an exception. too bad that catch blocks exist I'll quote an old post I made in this thread: MononcQc posted:The general principles for fault tolerance require Separation of Concerns vis. Error Encapsulation (make sure that the contagion doesn't spread), Fault Detection (make sure that you know that someone is infected), and Fault Identification (you have ebola, son). I still stand by these ideas, and "lol throw an exception" is a very lovely way to handle all errors no matter what. Seeing them all as the same is bad, seeing them all as individual snowflakes isn't guaranteed to give you good results either.
|
|
#
?
Dec 8, 2013 22:14
|
|
|
it's like the other side of Rich Hickey's "Simple Made Easy"
|
|
#
?
Dec 8, 2013 22:16
|
|
|
i assumed that was just Rich in a wig or something
|
|
#
?
Dec 8, 2013 22:26
|
|
|
i really like go's error handling mechanisms, actually. you can return an error object, which is up to the caller to handle, or you can panic, which kills the goroutine. in my experience this covers almost all error conditions...what i like to see in java code is for each task to concentrate on the happy path and bail from it by throwing, with error handling higher on the call stack. thats about the closest java will come to doing things the go way what i get to work with is usually a series of try/catch blocks that weave the happy and sad paths together. its not fun
|
|
#
?
Dec 8, 2013 22:30
|
|
|
Go doesn't cover poo poo like goroutine A depends on goroutine B, and B dies, so what does A do? There's also no way for a goroutine to interrupt/kill another one. Which is some of the most basic poo poo you need in many cases. I guess you need to do it by hand with special dedicated channels and global variables, but it's not there as a base mechanism.
|
|
#
?
Dec 8, 2013 22:32
|
|
|
MononcQc posted:Go doesn't cover poo poo like goroutine A depends on goroutine B, and B dies, so what does A do? There's also no way for a goroutine to interrupt/kill another one. to me, either the task is expected to die, in which case you should be able to handle it, or its not, in which case case kill the process
|
|
#
?
Dec 8, 2013 22:44
|
|
|
JewKiller 3000 posted:this is not a phrase i should have to hear when the problem is already solved except for bad/lazy programmers who is left when you take those out
|
|
#
?
Dec 8, 2013 22:54
|
|
|
whats a good book to learn ruby i am a bad programmer
|
|
#
?
Dec 8, 2013 22:57
|
|
|
Nomnom Cookie posted:to me, either the task is expected to die, in which case you should be able to handle it, or its not, in which case case kill the process what do you do about blocking i/o other than not use it?
|
|
#
?
Dec 8, 2013 22:59
|
|
|
MononcQc posted:Go doesn't cover poo poo like goroutine A depends on goroutine B, and B dies, so what does A do? There's also no way for a goroutine to interrupt/kill another one. The rust people are super afraid of killing other tasks at arbitrary points, probably not least because they only have hopeful type system separation between them and are worried about their locks and destructors. 
|
|
#
?
Dec 8, 2013 23:03
|
|
|
yeah p sure his types beef was with error propogation and tight coupling of message types through distributed systems. in haskell you use libraries which sit on top of the loosely coupled services and give you all the hugbox static typing you could want. he's not arguing against, he's just saying don't force your bespoke types on me because now your forcing me to play by your language semantics.
|
|
#
?
Dec 8, 2013 23:04
|
|
|
Vanadium posted:The rust people are super afraid of killing other tasks at arbitrary points, probably not least because they only have hopeful type system separation between them and are worried about their locks and destructors. java strongly discourages Thread.terminate() because of locking problems. if a thread gets killed while holding a lock then whatever it was messing with can be left in an inconsistent state. its also very rude Brain Candy posted:what do you do about blocking i/o other than not use it? I don't know, what DO you do about blocking i/o? what do you do when a thread is stuck in D state forever because of a hardware problem? use a thread pool or smth w/e idc
|
|
#
?
Dec 9, 2013 00:05
|
|
|
jooky posted:whats a good book to learn ruby use one of the many fre eonline tutorials to get a hang of the language (it's pretty easy), and just do stuff
|
|
#
?
Dec 9, 2013 00:26
|
|
|
ah yeah I forgot about y'all people's shared memory things. Killing procs randomly should be doable only if you get a kind of 'on kill' callable -- a defer for panics, for example, should be definable for that in go if you were yo allow that.
|
|
#
?
Dec 9, 2013 00:36
|
|
|
blowing away a process is fine, thats what finally blocks are for. blowing away a thread is a whole of kettle different bugs synchronization
|
|
#
?
Dec 9, 2013 00:42
|
|
|
Nomnom Cookie posted:java strongly discourages Thread.terminate() because of locking problems. if a thread gets killed while holding a lock then whatever it was messing with can be left in an inconsistent state. its also very rude this isn't an intrinsic problem, it's implementation http://docs.oracle.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
|
|
#
?
Dec 9, 2013 00:56
|
|
|
Brain Candy posted:this isn't an intrinsic problem, it's implementation are you suggesting that Thread.stop() should schedule the thread to be stopped when it releases the outermost lock?
|
|
#
?
Dec 9, 2013 01:01
|
|
|
Nomnom Cookie posted:thread … bugs … synchronization lol
|
|
#
?
Dec 9, 2013 01:03
|
|
|
you can politely get rid of threads by telling them to kill themselves (the secret of blocking is that blocking without timeouts is a bad plan)
|
|
#
?
Dec 9, 2013 01:06
|
|
|
Nomnom Cookie posted:are you suggesting that Thread.stop() should schedule the thread to be stopped when it releases the outermost lock? if your thread touches a lock other than for a queue you have already failed
|
|
#
?
Dec 9, 2013 01:08
|
|
|
Brain Candy posted:you can politely get rid of threads by telling them to kill themselves shame it doesn't apply to posters.
|
|
#
?
Dec 9, 2013 01:11
|
|
|
jooky posted:whats a good book to learn ruby but i repeat myself
|
|
#
?
Dec 9, 2013 01:38
|
|
|
Brain Candy posted:if your thread touches a lock other than for a queue you have already failed i tend to agree, but java has synchronized blocks and Thread.stop() has to deal with them. there's no good way to immediately kill a thread while it's holding a lock. how is this not an intrinsic problem? the semantics of java practically guarantee that anything recognizably similar to Thread.stop() will be either broken or useless
|
|
#
?
Dec 9, 2013 02:33
|
|
|
Brain Candy posted:you can politely get rid of threads by telling them to kill themselves work uses NIO to get read timeouts...but its still thread per connection. apparently nowadays you can easily solve the c10k problem by creating 10000 threads
|
|
#
?
Dec 9, 2013 02:36
|
|
|
|
| # ? May 20, 2024 05:23 |
|
|
Service reminder that everyone should read lauer & needhams duality paper
|
|
#
?
Dec 9, 2013 02:51
|
|