The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I was hoping (and still am) that this was going to be a 'well, ironically, having made an attempt at writing a HAL in Python, the kiddies have discovered that they can't do it, and have come to me cap in hand to help them'
having made an attempt at writing a HAL in Python, the kiddies have discovered that they can't do it, and have come to me cap in hand to help them'
First part happened, second part has not.
Now they're writing it in F#, because one of the kiddies as a Haskell background.
The irony here is:
1) very few people actually know F#, so the code will undoubtedly be thrown away by the next iteration of kiddies, if not sooner.
2) it's like reading imperative code with match statements instead of switch and type instead of enum, and everything is mutable.
3) FP is just the wrong approach for this kind of work because you're dealing with a lot of struct stuff for the hardware, a lot of mutable data from the I/O, and possibly the need to maintain some sort of state information, like is the hardware up or down since the last time we checked.
4) from what I've seen so far, no logging, no exception handling, no modularity, and a lot of hard coded constants and strings, but hey, "we're ahead of schedule!" is pronounced loudly and proudly at every stand up.
Oh nice, give the old bastard who has spent years being nitpicked by QA a shot at your first UI
I must admit, I took great sadistic pleasure in the process.
Mycroft Holmes wrote:
but what a bunch of pedantic, anally retentive, irritating, annoying and bloody persistent sods they are.
Yeah, aren't they wonderful? Honestly, once I started to learn how to work with QA (part of which was, don't rely on them accurately telling you what they did to break your software), I started enjoying the process, because it did improve the quality of the product, as well as my code and I learned better architecture (ok, fancy word for automatic logging) as well as a result of my QA experiences. The best thing though was when we got to a point of working together, and I could ask them "I found this weird bug in my code and I can't figure out how to reproduce it, could you try?" That was great.
In our little system we have email sending configured as a Boolean. Down when we're instantiating the class that sends the email, we look at that. If false, we instantiate an implementation of the class which writes to a local file instead of sending the email.
So, we can check content etc in development without the risk of "oops that was a real email address."
I wonder if something similar could be wired up for your error condition. Once you're in the catch block, fire off the email send, but pass the magic param which says "write to log/file/send up a flare/whatever."
I did something similar. My program connects to a SQL database and when that database connection is broken an exception is thrown and logged to a message processor which also tries to log it to the, wait for it, SQL database. Which then throws the exception again.....
Not exactly his area of expertise, but he's right. You could see a living cell as a very complicated biochemical machine. Everything that can directly modify the DNA or interfere with its replication can eventually cause cancer.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
you have to die from something - shortness of breath, whatever - you can be the healthiest person in the world and get hit crossing the street (or these days, get an lead injection from some maniac with a gun) ... so you may as well do everything in moderation, enjoy, be a nice person, and not beat yourself up