[afarrell]

> There is a fundamental rule in programming, it relates to absolutely any technology or language, this rule says that explicit is always better that implicit.

Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.

[grandalf]

Correct. It is actually opposed by ruby on rails, which is why when Rails apps get sufficiently large they become difficult to understand/maintain.

One example is overriding an association proxy to have other side effects. Sure it makes for a few very sort lines of code to cause whatever those effects are, but unless someone has read the implementation of the code that behavior becomes completely opaque.

Similarly, acts_as_foo plugins that add implicit behavior everywhere.

The core idea was clever at the time -- that one could do better domain modeling than a few sql statements in a file by using AR and callbacks, but after the app gets a bit complex the domain model classes typically become very tightly coupled and much logic has been flushed away into implicit behaviors to make the remaining code halfway readable.

I have yet to see a Rails app that can stick with the basic structure with over 20 models and still feel remotely well engineered.

[needusername]

Yes it is. That's why explicit memory management is still the standard today and implicit memory management with garbage collectors will never lead to understandable or maintainable systems.

[grandalf]

more realistically:

app.php

   <?php
    // logic and state here

    include 'some_other.php' // modifies or adds state in unknown ways

    // more logic

    $some_variable = 3; // does the include below depend on this? who knows.

    include 'yet_another.php' // expects state, who knows what
                             // also modifies state

    echo $state; // not sure if we can remove/replace any of those includes and this will be as expected.

   ?>

The includes are being used like sloppily defined function calls which do a muddled combination of rendering and state modification.

The same can be found in Rails in partials.

Also, in Rails, helpers are essentially crippled presenters that have access to lots of effectively global state and thus cannot be reused.

[arcatek]

And is that why each C++ iteration is adding more tools to finally implement C++ garbage collectors?

[eatonphil]

"Explicit" ties in to readability and from there, long-term support-, maintain-, and debug-ability. While OP did issue a blanket statement, this idea is fairly language/framework independent.

[yxhuvud]

Yes, but it still isn't that clear cut. IMO and generally speaking, implicit is better when there is an obvious default behaviour that should be used in most cases. It may still be necessary to be able to override that default behaviour, but having to restate the obvious everywhere is not something that is good or desirable for the points you mention, since it will only make it harder to see what the differences are compared to the common case.

Of course, not all problems have default solutions and those should usually not have default behaviours.

To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.

[afarrell]

The problem is that the "obvious thing" relies on implicit knowledge of whoever is designing the API and might be nonobvious to someone else.

[mackwic]

I don't think so, check what ActiveSupport brings to ruby (http://guides.rubyonrails.org/active_support_core_extensions...).

TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.