Virtuous Code - Latest Comments

Re: The Moderately Enthusiastic Programmer

Stevo — Sat, 28 May 2016 18:34:55 -0000

Well stated. the word passion needs to die when talking about programming.

Re: Boolean Externalities

Matthew Boehlig — Fri, 19 Sep 2014 12:58:32 -0000

Lazarus Form Recovery is easier than heap snapshots. :-)
http://getlazarus.com/

Re: Boolean Externalities

Ilya Vorontsov — Fri, 19 Sep 2014 11:04:37 -0000

I tried to write a probing proxy, storing every method call and its result, but stucked with booleans. I think my proposition to a ruby language (https://bugs.ruby-lang.org/... possibly could make it possible.

Concisely, if conditionals took care of object's #to_boolean method, one could design a proxy object behaving exactly like an underlying one. Another way to do it is a superclass NullObject which is a simple Object in any regards but conditionals where it's falsy.

Re: Boolean Externalities

Filipe Giusti — Thu, 18 Sep 2014 23:07:15 -0000

Go also extensively uses this. I guess they have exceptions now, but initially they used that for all error handling, even exceptional.

In Ruby, it would mean something along the lines of

class EmailVerification
# ...
def confirmed?
return !!confirmed_at, "EmailVerification#confirmed_at: #{confirmed_at.inspect}"
end
# ...
end

def verified_email?
email_verification.confirmed?
end

# ...

class Episode
# ...
def available_to_user?(user)
puts free? || user.current_subscriber?
end
# ...
end

# [false, "EmailVerification#confirmed_at: nil"]

Pretty neat!

Re: Boolean Externalities

findchris — Thu, 18 Sep 2014 14:52:00 -0000

I was just thinking to build something like this for Ruby. I could see that being super handy.

Re: Boolean Externalities

Kenny — Thu, 18 Sep 2014 14:22:47 -0000

In general, I'm not very confident that you can really do much to make debugging acceptance (integration) tests easier. When you're troubleshooting something that consists of a long chain of links, any of which might be the cause of the failure, there's nothing that can (generally) save you from searching the chain.

This seems like a pretty general problem with 'large' tests too – think of failures in large or complex mechanical or electrical systems, or even reconciling a bank account. Sometimes there are clues as to the likely location or identity of the failure, but often only a methodical search is able to discover it.

Re: Boolean Externalities

Avdi Grimm — Thu, 18 Sep 2014 13:41:11 -0000

That response state gem is something I've been thinking about building. Thanks for pointing me to it!

--
Avdi Grimm
http://avdi.org

Re: Boolean Externalities

Alex Peachey — Thu, 18 Sep 2014 13:36:06 -0000

So I think the primary problem is you seem to be doing a lot of asking on your public interfaces. So you've got all these objects working together asking each other if they can do something. So you are quite right, you don't get any good information other than yes/no.

Taking more of a Tell Don't Ask approach, you could instead have a useful class who's responsibility it is to Authorize access to the episode for the user.

AuthorizeEpisode.new(episode, user).call

And it would be swell if that returned some kind of response that had the answer you wanted as to whether the user is authorized or not, and if not, perhaps a message why. A nice little response struct would work well here.

Taking it a step further we can layer in some Ruby magic and get to a pattern my co-worker Brian Hughes came up with. He calls it Response State and we build a gem around the idea. (https://github.com/Originat...

Ruby makes it so nice to have little predicate methods to ask if something is true or false, however, having the public interface on your objects hosting a whole slew of these methods leads to a lot of code that is constantly asking questions and then creating if/else structures to deal with the answer.

Re: Boolean Externalities

Avdi Grimm — Thu, 18 Sep 2014 12:18:42 -0000

Thanks, I'll check that out!

--
Avdi Grimm
http://avdi.org

Re: Boolean Externalities

singpolyma — Thu, 18 Sep 2014 12:00:46 -0000

After thinking about this for awhile, I had some thoughts that were to long to include as a comment, so I wrote up a blog post in response to this one: https://singpolyma.net/2014...

Re: Boolean Externalities

Edward J. Stembler — Thu, 18 Sep 2014 10:58:11 -0000

Another option, aside from the functional approach you're looking for, would be to refactor your code to work more in-line with the Validator concept. As you know, validators contain an error collection which is usually displayed to a user.

In one of my projects, I've created my own generic validators which are not tied to Rails, though they behave in a similar fashion. For my use case, I have a custom report language DSL which my user can validate before submitting a report job. The validation itself runs as a background job and will send the user an e-mail containing any validation messages.

Re: Boolean Externalities

Rodrigo Rosenfeld Rosas — Thu, 18 Sep 2014 10:47:59 -0000

First, let me say that I share your feeling that sometimes we not only want to know about a truthy information but sometimes we also need to take some actions on some of them and to be honest I don't have a single solution to the problem in my applications.

Sometimes I use earlier returns when handling invalid data in a controller's method, sometimes I use some filter, sometimes I use throw-catch, other times raise-rescue and in other contexts I use events/promises. Each of the approaches has their pro and cons and I usually have to resort to my common sense to decide what to do depending on the situation.

If your code is too modular and you don't want each module to be aware of the controller for instance, you could use some thread-local or request object to store some object to which you could register the events you're interested on in the controller's action and trigger the exceptional situations you want to handle in each module if you think it worths the effort.

Now, with regards to code quality, you say the code is self-evident. I'd just like to point out that it may be self-evident to you, but it wasn't to me as I was reading. For example "current_subscriber?" is not a clear name to me and I guess it would mean something like "has_valid_subscription?". Then I have no idea on what "fully_authenticated" could mean and even less idea on what would be an open subscription. And the pause was longer as I was reading "authenticated_accounts". Why would an user have multiple accounts? I simply assumed that it would be called "authenticated?" instead and then I'd get rid of "fully_authenticated?" and implement "has_valid_subscription?" as "subscription.valid? && verified_email?" and would move the authenticated check to some filter in the controller since I don't really think it makes sense to ask a user whether it's authenticated because this is not something inherent to the user but it's something you extract from the request environment instead.

Also, as I was reading the code I noticed that the user wasn't being notified about an e-mail that has not been confirmed. From my point of view, access verification is responsability of the controller serving the content. As such, I think it would be fine to add such verification as some kind of before filters. If you want to be able to test them in isolation, fine, just move them to some module and test the module and make sure you include the right modules to your controller.

Rails controller's filters are already a pattern supposed to not only validating data/access but also to take some action, so I think of them as being a great fit for such scenarios.

Other possibilities would include adding some rescue_from statements to the controller and raise the exceptions in your verifying modules even though they should use throw-catch ideally. Or you could override "process" in your controller or in ApplicationController to wrap it in a "catch" block.

If you ask me, from the code readability point of view according to my preferences I find regular simple filters much easier to grab the whole flow quickly.

As for the print debugging, there's no need for much confusion, you can simply use "p" which returns the value being printed. Ex.:

def method
puts "method output:"
p(statement here)
end

Re: Boolean Externalities

JoelMcCracken — Thu, 18 Sep 2014 08:37:46 -0000

These aren't monads, though. These are just types. Would be analogous to Either.new(:left, "something wrong"), Either.new(:right, "something right").

This still makes for ugly ruby code. I *guess* you could do something like `include Either` and then do Left.new or Right.new.

Makes me think of something akin to:

(logic { first_condition? } .and { second_condition? }).or { third_condition? }

... where the logic system knows how to handle condition metadata.

def first_condition?
logic(:false, {here: :is, some: :metadata})
end

... etc.

Re: Boolean Externalities

Bill Dueber — Thu, 18 Sep 2014 08:06:26 -0000

Isn't the fundamental "problem" here (I'm not convinced it's a problem) that as Rubyists we're both (a) discouraged from using exceptions for control flow, and (b) prevented from allowing an arbitrary object to be falsy? Exceptions can be handled and contain useful information but totally change the flow of your program; a complex object that evaluates to `false` could convey reason-data without affecting the flow of the code, but of course we Can't Do That.

I wish I had a solution instead of a complaint...

Re: Boolean Externalities

rich — Wed, 17 Sep 2014 23:38:09 -0000

I think this would be addressed by Tell, Don't Ask. That keeps errors localised to the place where they can be best handled. FP is not a huge help here, lazy evaluation tends to have a similar effect as your externalities.

Re: Boolean Externalities

Jared Ning — Wed, 17 Sep 2014 22:14:33 -0000

I also prefer simple output before resorting to a debugger when possible. I like to use Object#tap.

free?.tap {|b| puts("free?: #{b}")} || user.current_subscriber?.tap(&method(:puts))

2nd use of tap is easy to tack on if you don't need a lot of other output noise, Both preserve return value. And it's slightly simpler to undo than the multi-line alteration you demonstrated.

Re: Boolean Externalities

Christopher Vollick — Wed, 17 Sep 2014 19:53:44 -0000

This is not Haskell code I'd want to ship, but it's perhaps good enough.

If you run the code, it will spit out "Woah baby, error: Wrong input"

If you take off the line marked with the comment from the someThing function (the one that passes in 17 to sub_meow) then it will say "Success! Big Meow"

In this case the return type is a string, but it could be whatever.
https://gist.github.com/psy...

Re: Boolean Externalities

jrbl — Wed, 17 Sep 2014 19:16:03 -0000

Actually on further reflection I realize that wouldn't help you here, this is the opposite problem. You don't want to know where your context came from, but where your locals came from. It seems like it shouldn't be hard to write a similar tracer though that lets you wrap a method or attribute and watch its resolution, though...

Re: Boolean Externalities

jrbl — Wed, 17 Sep 2014 19:11:20 -0000

I'm a Python programmer who recently had a similar problem with a large code base making use of lots of dynamism. I had an object and needed to inject information into it's calling context and didn't know all the places it could be created, so I didn't know where I needed to make the context injection.

Anyway, I banged out a quick hack to examine the execution stack and tell me both what-called-what, and the values of particular variables along the way. (Super shitty PoC at http://github.com/jrbl/pyth.... If you had a similar utility for Ruby, then in your outermost method you would insert a call to the tracer and get a dump of all the calls along the way. I haven't instrumented calling parameters and return values in python-wtf but now that I read your post, I see that that's a really good idea, so I'll probably do that RSN.

As far as disciplinary changes... I don't know what to tell you. I think this kind of thing just happens sometimes when you're living in a highly dynamic world. My money's on tools to audit after the fact.

Re: Boolean Externalities

Tibor Olah — Wed, 17 Sep 2014 18:22:44 -0000

Hello Avdi,

First I want to say that I'm not a professional programmer so the following thoughts you might find irrelevant, and maybe they are.

I think your code is not yet at the level of evolution where it can behave so that it follows your subjective expectations.
See, the code computes (more or less) perfectly the needed result. It does so by the collaboration of several objects, each of which has no idea why it behaves the way it does. They are created with a purpose in your mind, but they themselves have no purpose. All they do is interact with each other, where their interaction is similar to calculations like this:
(0,0,1,0) -> 1
(1,1,1,1) -> 1
(0,1,0,1) -> 0
etc. Stripped from the semantics given by the text of the code, it is much harder to ask the "why" question. Is the user now happy when the result of the calculation 1? Or zero? The discrepancy is between the interaction of the brain cells of your (potential) subscriber and the interaction of your objects.
Boolean values are value-free. Value in the human sense is subjective.
Coming back to your analogy with externalities. The way the phenomenon is taught in most schools end after the second interaction (a third party not part of the original transaction is harmed). Mostly this is cited as an example why markets don't work and government action creates a better society.
But of course the chain of interactions does not stop here. The 3rd party harmed by the original transaction is going to act upon his interest. It is expected that the harmed party will use possibilities available to him to incorporate the costs incurred to him to the original parties in the transaction. (For example, by suing them) As a result, a new price for future transactions is born. Which will change the behaviour of future parties potentially willing to transact, which will result in a different transaction, which might lead to another 3rd party effected by the transaction, and so on. What is the meaning of the price at each transaction? Hard to say, but somehow it incorporates the values of each involved party on its evolutionary path.
So the story in externalities should not be, how markets do not work, but this is exactly how they work. Given the universe we live in, there are always unintended consequences. Prices reflect our journey in discovering reality.

So yes, your objects do not have a purpose. Asking them why do they behave the way they do makes no sense to them, the answer is "because it is the way I am". They are the result of the evolutionary selection of your intentions. They do not care if the subscriber is happy. But once they are selected, adapted, arranged for long enough, their sum (your program) will show an emergent behaviour as if they did.

Re: Boolean Externalities

Avdi Grimm — Wed, 17 Sep 2014 16:02:31 -0000

That's neat the way it handles multiple returns in a way that you don't have to care if you don't want to.

--
Avdi Grimm
http://avdi.org

Re: Boolean Externalities

Matt Jones — Wed, 17 Sep 2014 15:48:13 -0000

I'm unclear how this solution actually helps - a method like `fully_authenticated?` is still going to need to decide which message to include in the output. *Something* is still getting lost in that case, and there's a significant increase in complexity.

Re: Boolean Externalities

Will Sargent — Wed, 17 Sep 2014 15:42:21 -0000

This sounds like something where you'd return a Validation object that returns a list of errors -- usually you'd see this in an Either, a disjunct union structure.

Re: Boolean Externalities

Joe W. — Wed, 17 Sep 2014 14:54:05 -0000

Common Lisp has the concept of multiple return values, where all but the primary return value is discarded unless you explicitly ask for the rest. I could maybe imagine a predicate here returning both the boolean value and the reason, and then discarding the reason where it's not needed. More details here: http://www.gigamonkeys.com/...

Re: Boolean Externalities

mark mceahern — Wed, 17 Sep 2014 14:04:37 -0000

Generally, predicate methods are a shortcut to something more useful. Here's a simple refactor to tease out the information that predicates typically smash:

def unavailable_reasons
[:some, :list, :of, :reasons, :why, ...]
end

def unavailable?
unavailable_reasons.any?
end