Stack Exchange
log in

Ben Aaronson

 Discussion on answer by mxyzplk: Is t…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Jun 21, 2018 21:11
@Barmar Imagine a different conversation, in which Morty says "Good morning" and Rick says "Thanks for the sentiment, but from experience I've found that I'm so much smarter than everyone around me that any form of communication with other people brings me down closer to their level. I'd appreciate if in future you don't talk to me and ideally remain out of my line of sight. Thanks in advance" Can you see how the unreasonable assessment he's making there is inextricably linked to the rudeness of his request?
 

 Discussion on answer by Kate Gregory:…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Jan 10, 2018 19:34
"They generally are set up for things that will never really happen" Like unit testing?
 

 Discussion on question by Beofett: I …

Imported from a comment discussion on interpersonal.stackexcha...
Ben Aaronson
Jan 3, 2018 02:26
@Beofett Well I was wondering if he could be convinced that a) Whoever's fault these conflicts are, he isn't very good at predicting them, b) It would be a good idea to a conflict if he can, even if it wouldn't be his fault. But that probably would be a tough sell.
Ben Aaronson
Jan 3, 2018 02:26
Is your father aware of his inability to empathise? Is there reason you can't have an honest conversation like: "Hey dad, remember X, Y and Z occasions where somebody acted very differently from how you expected? Well I think this might be another situation like that..."
 

 Discussion on answer by Tolegen Izbas…

Imported from a comment discussion on softwareengineering.stac...
Ben Aaronson
Oct 10, 2017 18:24
@Maybe_Factor But this is talking about Lombok, which just generates "boilerplate" getters and setters and hides them from you. It's for the exact use case where you're not adding any custom validation
 

 Discussion on question by Ellen Spert…

Imported from a comment discussion on cseducators.stackexchang...
Ben Aaronson
Jul 28, 2017 17:05
It would be very interesting to see that "medical professions" line separated out a bit more
 

 Discussion between Ben Aaronson and P…

Imported from a comment discussion on softwareengineering.stac...
Ben Aaronson
Jul 24, 2017 15:32
If you think it's worth editing the answer to make that clearer, let me know
Ben Aaronson
Jul 24, 2017 15:31
Whether or not the compiler internally moved declarations about, to a person reading the source code, they'd see something being declared twice (or not at all) in certain code paths.
Ben Aaronson
Jul 24, 2017 15:31
If so, then I think you're right, the compiler could massage your code in an unambiguous way into something correct. But the same is true of, say, writing a = 1 before ever declaring a. C# is deliberately strict about that sort of thing, and my answer was talking about the logical rules of variable declaration as understood by a human.
Ben Aaronson
Jul 24, 2017 10:31
"We then can simulate the OP's scheme by moving all declarations outside the try block." Sorry, you lost me here. Are you saying this is something the compiler could do automatically, to support the OP's suggestion?
Ben Aaronson
Jul 21, 2017 13:56
Also the difference between assignment and declaration is significant. int a; try { a = 1; } catch { a = 2; } is legal. But try { int a = 1; } catch { int a = 2; } and try { int a = 1; } catch { a = 2; } can't be because you might end up declaring something twice (first example) or assigning to it before declaring (second example)
Ben Aaronson
Jul 21, 2017 13:50
Well, if the OP's suggestion was allowed, what code could be written that the definite assignment mechanism would verify WAS definitely assigned, where the variable was declared inside the try block? If there isn't any, then the kind of thing the OP wants to do would be impossible anyway, so there'd be no reason to make an exception to the scoping rules
Ben Aaronson
Jul 21, 2017 13:46
@PeteKirkham So it takes a consistent approach to both: disallow at compile-time if it can't verify for sure at compile time that it is valid (i.e. that it has been declared and initialised). Allowing the OP's suggestion would prevent it from doing that, and so make it inconsistent. Does that answer your point? I may still be misunderstanding what you're saying, in which case could you expand on what you mean?
Ben Aaronson
Jul 21, 2017 13:46
@PeteKirkham The advantage the OP suggested to not creating scope is so that you could declare a variable in a try, then use it outside. As I showed, this can lead to a situation where the compiler doesn't know whether or not what you're written is valid- you may or may not have declared the variable by the time you use it. So instead, the compiler says this is always invalid, so you're safe at compile time. In the situation you're talking about (initialise in try, but not in catch), the compiler also says this is always invalid.
Ben Aaronson
Jul 21, 2017 13:46
@PeteKirkham I'm not sure what you mean by "better than"? The compiler disallows both of these
Ben Aaronson
Jul 21, 2017 13:46
@svick Yes, that's true. In fact if you declare a variable outside a try...catch, then make sure to initialize it in both the try and the catch, the compiler does allow using that variable after the try...catch. The difference between that and what you're describing is just where the variable is declared. So perhaps I should undo my last edit.
Ben Aaronson
Jul 21, 2017 13:46
@jpmc26 Good point, I've updated the answer
Ben Aaronson
Jul 21, 2017 13:46
@SebastianRedl I think Peter's reason is just as important as this one, if not more. But the OP explicitly said "Consistency-sake aside", so I was demonstrating that even if you wanted to make a special case for try/catch blocks (for some reason), you'd run into problems making it work
 

 Discussion on answer by richard: Is i…

Imported from a comment discussion on cseducators.stackexchang...
Ben Aaronson
Jul 18, 2017 16:07
@Wildcard I feel like you're conflating what somebody should learn with the best order in which to teach it. The fact that courses which aim only to give a shallow understanding of the subject start from a high level doesn't mean that a course aiming for a deeper understanding shouldn't also start the same way.
 

 Discussion on answer by Joe Strazzere…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Jul 11, 2017 20:58
I feel like this answer slightly misses the point. Companies offer employees a mix of benefits and salary. For full-time employees, benefits form a higher percentage of their overall renumeration than part-time. So the question is: why? It depends on industry but for software development employers often offer a lot more than the bare minimum required by law, so I don't think that's the full explanation
 

 Discussion on question by Markus: Sho…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Jul 5, 2017 09:55
If not, though, I'd worry that you're putting yourself at legal risk by doing that. Handing someone a flyer that seems implausibly tailored to their current situation might not be believed
Ben Aaronson
Jul 5, 2017 09:55
From the way your question is worded, it sounds like you noticed "she always scans Western Union money sendings" without any rule-breaking. Is that right? If that's right then Jeroen's comment/DCON's answer sound perfect. Western Union transfers are very frequently associated with scams, so it's perfectly plausible that you'd have some sort of policy to mention the risk
 

 Discussion on answer by amon: Am I to…

Imported from a comment discussion on softwareengineering.stac...
Ben Aaronson
Jun 8, 2017 08:03
@Erik Also "Keep it simple and straightforward"
 

 Discussion on answer by DepressedDani…

Imported from a comment discussion on softwareengineering.stac...
Ben Aaronson
Dec 17, 2016 14:37
@Aliester I agree, I was more adding that in as a piece of trivia. I'm not sure why Java didn't just copy extension methods directly
Ben Aaronson
Dec 17, 2016 14:37
@Aliester IIRC, default methods on interfaces really were added to make up for the lack of extension methods. Without either, writing an equivalent to C#'s LINQ extensions which allows chaining would be very hard because you'd have to implement each one on every interface implementation.
 

 Discussion on question by human being…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Feb 27, 2016 11:29
@TechnikEmpire Right, but that's not the extent of what's going on. A closer analogy would be if you spent those 25 hours working 5 hours a day over a week, but at the end of each day, told your client you'd worked 8 hours that day. That's fraud. Not lying about your hours spent isn't the same as volunteering a refund
 

 Discussion on question by Nelson Alex…

Imported from a comment discussion on philosophy.stackexchange...
Ben Aaronson
Jan 7, 2016 18:17
One thing to keep in mind is that before you start flipping coins, your expected result is as many heads as tails. After you flip the first coin and get heads, your new expected result is one more heads than tails. And so on.
 

 Discussion on answer by gbjbaanb: Is …

Imported from a comment discussion on programmers.stackexchang...
Ben Aaronson
Jul 2, 2015 18:44
@gbjbaanb I've yet to see an example of a test tool forcing you to twist code into a less maintainable structure. Personally as a maintainer if a test tool has forced my predecessor not to litter her code with static dependencies, then that would make me cheer rather than cry.
Ben Aaronson
Jul 2, 2015 18:44
@gbjbaanb I don't think anyone's disputing that well written code is necessary for maintainability, just whether or not it's sufficient. No testing method can give you absolute perfect confidence that you haven't missed an edge case, but for cases that exist at the unit level, it means the difference between a high level of confidence and almost 0 (which is what integration tests alone give). You can also reread the previous sentence and swap the words "unit" for "integration" when they occur, and that's true too.
Ben Aaronson
Jul 2, 2015 18:44
@gbjbaanb MichaelAnderson specifically mentioned that the problem was failure to test for edge cases. Just writing good code doesn't magically vanish edge case considerations
Ben Aaronson
Jul 2, 2015 18:44
@anaximander For code to be maintainable, you have to be able to make changes and be confident after a reasonable length of time that you haven't introduced bugs. I just don't see how anything can substitute for unit tests in giving you that confidence
Ben Aaronson
Jul 2, 2015 18:44
I don't really see how the attitude of a unit being a class rather than a method implies less granular. If I have a class that's some kind of simple storage with a void Add(object key, object value) method and object Get(object key) method, then trying to test those two methods as their own units in isolation of each other would be hard. Testing the whole class together as a single unit fits a lot better. But choosing between those two approaches seems like an orthogonal decision to choosing the level of granularity to test at.
 

 Discussion on question by Benubird: H…

Imported from a comment discussion on workplace.stackexchange....
Ben Aaronson
Jun 2, 2015 17:23
These disagreements sound like examples of both sides missing nuance. Whether performance is more or less important than clean code depends entirely on how performance-critical the section of code is. Causing the users noticeable delay to be able to write "nice" code is silly, but so is bearing the burden of bad code to shave microseconds off a web request. Similarly, if an ORM is causing performance problems, the question should be what caused that, can it reasonably and safely be avoided in future, and if not, what are the alternatives. Not "ORMs rule!" vs "ORMs suck!"
 

 Discussion between IntelliData and Be…

Imported from a comment discussion on programmers.stackexchang...
Ben Aaronson
Jun 1, 2015 18:15
Ah, thanks! I think it might be better if you asked a question through the site as usual. I'll possibly see it, and if not you could point me at it. I may not be able to answer every question very well, though.
Ben Aaronson
May 31, 2015 15:28
By the way, if you're planning to award the bounty you need to do it in the next couple of days or it'll auto-assign
Ben Aaronson
May 30, 2015 08:34
Yeah, I guess that's right.
Ben Aaronson
May 28, 2015 19:02
But if the data exists only to aid some kind of behavior, it's much preferred to have the class that holds the data provide the behavior instead of the data, if possible. That's what Tell Don't Ask is essentially about.
Ben Aaronson
May 28, 2015 19:00
If you really, really just need the data (e.g. you want to print a customer's name to the screen), then a dto is perfectly appropriate. Tell, Don't Ask isn't relevant in that situation
Ben Aaronson
May 28, 2015 18:59
I don't like the name Tell Don't Ask precisely because of that kind of confusion. When I hear "tell" I think of commands (change state, don't return data) and when I hear "ask" I think of queries (leave state the same, return something). But that's not what they refer to in Tell Don't Ask
Ben Aaronson
May 28, 2015 18:58
No, I don't think Tell Don't Ask means never return data.
Ben Aaronson
May 28, 2015 18:55
@IntelliData Yeah I understand. I agree toDTO it may mitigate that, but as I mentioned in the comment, there are other problems (violation of "Tell, Don't Ask"), which it does not.
Ben Aaronson
May 28, 2015 18:55
@IntelliData Keeping the Customer domain object's data relatively fresh (in sync with the db) is a matter of managing its lifecycle, which is also not its own responsibility, and would again probably end up living in a repository or a factory or an IOC container or whatever instantiates Customers.
Ben Aaronson
May 28, 2015 18:55
@IntelliData 2. This is difficult to answer without knowing the behaviour. But probably, the answer is: you wouldn't. What behaviour could a Customer class have that requires being able to mutate its telephone number? Perhaps the customer's telephone number changes and I need to persist that change in the database, but none of that is the responsibility of a behaviour-providing domain object. That's a data-access concern, and would probably be handled with a DTO and, say, a repository.
Ben Aaronson
May 28, 2015 18:55
@IntelliData 1. When you say "change the fields", you mean change the class definition or mutate the data? The latter can just be avoided by removing public setters but leaving the getters, so the dto aspect is irrelevant. The former isn't really the (whole) reason that public getters are "evil". See programmers.stackexchange.com/questions/157526/… for example.
 

 Discussion on answer by Mike Nakis: I…

Imported from a comment discussion on programmers.stackexchang...
Ben Aaronson
Apr 30, 2015 08:50
@MikeNakis Visitor pattern only needs to be a hassle if you want to be able to access or visit non-public members, which doesn't seem to be the case here.
Ben Aaronson
Apr 30, 2015 08:50
Also RE your example, I'm not sure what situation you'd say "I want to do one, field-specific thing if I'm holding a field, and another, method-specific thing, if I'm holding a method, but I don't know which I have".
Ben Aaronson
Apr 30, 2015 08:50
I'm unclear why you've rejected the visitor pattern. This is the traditional OO route to deal with precisely the scenario you're describing.
 

 Discussion on answer by JLee: Monty H…

Imported from a comment discussion on puzzling.stackexchange.c...
Ben Aaronson
Apr 29, 2015 20:08
@JLee I think the OP complicates it unnecessarily by saying that you "don't know" the host's motive. But if the host chooses the door randomly, for sure switching doesn't help. It's not that hard to crunch the numbers on this.
 

 The 2nd Monitor

General discussion about codereview.stackexchange.com - Welcom...
4
1
Ben Aaronson
Apr 16, 2015 21:49
Yep, any excuse to type ": IEnumerable" makes me feel warm and fuzzy
Ben Aaronson
Apr 16, 2015 21:46
Ahah, I was wondering why I suddenly got several votes in a row!