"Doc O'Leary" <droleary / subsume.com> wrote in message
news:271120011226175855%droleary / subsume.com...
> In article <PtzM7.49351$RG1.25980882 / news1.rdc1.sfba.home.com>, David
> Simmons <david.simmons / smallscript.com> wrote:
>
> > "Doc O'Leary" <droleary / subsume.com> wrote in message
> > news:261120011559596827%droleary / subsume.com...
> > >
> > > I never said namespaces weren't a solution, I just said they were a
> > > poor, indirect solution to what developers really want.  Namespaces
> > > muck up the code far too much for the benefits they offer.  It doesn't
> > > take much imagination to come up with a system that better suits your
> > > needs at a higher level instead of suffering with the hackery that
> > > namespaces provide.
> >
> > I sense that you are focused on design and getting things right, and
> > anything less must be excluded from your world view. If my assertion is
> > correct, then it ignores human nature (path of least resistance/easiest
> > course) and a natural proclivity thereby to what staunch-advocates of
the
> > "right-design" way would term laziness.
>
> Quite the opposite.  It is you who seems fixated on namespaces while I
> am encouraging you to explore different solutions that might better
> solve the problem.

I don't see myself or my work as being personally fixated on namespaces. The
reality is that I have sooo... many other areas of implementation and design
to worry about I can't be fixated on this one area :). Namespaces are just
one small but fundamental key in the overall puzzle of the problem space(s)
covered by my work. However, the post itself was specifically on an aspect
of namespaces and thus it did focus entirely on that area and its potential
value.

> I have never once claimed that you could completely
> eliminate the root problem of a poor design or bad management
> influences.  Because I am aware of problems in the *entire* development
> lifecycle, I know that namespaces fall short of what developers really
> need to properly integrate systems.  Yeah, you can make due, but it's
> pure hackery to throw namespaces at all the problems that crop up.
>
> > My personal view is to strive to always design and get it right. Balance
> > that against other real-world goals and constraints; recognize that
designs
> > need to evolve based on experience and changing requirements so
iterative
> > processes are essential [assume un-anticipated changes will happen].
That's
> > one of the main reasons why after 25 years of professional software
> > engineering experience I am such a staunch advocate of dynamic
languages.
>
> I have a feeling we disagree far less than you think.

That's good to hear <g>

> I simply think
> that stopping at namespaces is a mistake when there are more direct and
> powerful solutions out there to address the issues.  My abstraction of
> a class or an object method doesn't involve the string of characters
> used to name it, and as such I see the introduction of namespaces as
> completely missing the mark.

The idea [I think you are alluding to] of modules and renaming/aliasing of
classes and messages is a "namespace" system; just with a different name (no
pun intended). The assumption that a "string of characters" is involved in
the internals/implementation would not be correct for SmallScript's
implementation (my work in this area) -- SmallScript/AOS actually flattens
[and tracks] the textual-namespace view through strong-names using uuid's
[otherwise, namespaces can be very problematic in versioning and
refactoring].

> I'll leave it to others to figure out if
> this means I have more or less than "25 years of professional software
> engineering experience".

<g>. That comment was specifically focusing on the fact that I've had more
time-spent/experience/projects than I can remember, working with a very wide
range of problem areas, languages, tools, and solutions. And based on that
experience, I've come to believe/recognize that dynamic languages offer some
crucial characteristics for managing complexity and integration in the face
of change, which are not offered by static languages.

>
> > I've seen far too many projects and companies get blamed for "failures"
in
> > "carefully designed" systems that failed not because they were "at
fault",
> > but because some 3rd-party late-integration element couldn't run
properly
> > because the primary system was intolerant and inflexible [frequently
through
> > versioning]. The result was failure to deploy successfully/properly; the
> > impact was loss of business [money, clients, reputation, etc] and
ultimately
> > that prevented [or negatively impacted resources for] ever polishing it
> > iteratively to get it "right".
>
> You've seem to have mixed up the issues.  The can of course "at fault"
> and deserving of blame for "failures", but it would be because the
> system *wasn't* "carefully designed" as they had claimed.  I would
> never make such claims when 3rd party integration issues (late or
> otherwise) were still a factor, regardless of language or system
> features that would purportedly address them.  I've lived through too
> much hype and "silver bullet" solutions to believe that namespaces are
> the One True Solution(tm) to the ills of integration.

I'm with you on the design comments up to the last sentence on "silver
bullets".  For me, the business outcome is still what ultimately matters and
that is where I perceive we differ [I prioritize business success as being
an essential requirement, so when hard choices must be made, it outweighs my
strong feelings about design]. I.a., no matter how much "good design there
is", given a complex system integration 3rd/other party issues can always
come into play to break a design surreptitiously and heaven knows where the
finger pointing ends -- and the clients don't care they just want a working
solution.

My specific comments/post on selector namespaces (not namespaces for
variables) were not intended to suggest a "silver bullet" to all integration
woes. They were intended to present an important and powerful tool/technique
for addressing specific problems in that space. A technique which directly
evolved from exploring many of the versioning, integration, and
fragility/brittleness issues that other techniques do not address in a
just-in-time fashion. As such the technique/facility of selector namespaces
is not and was never meant to be a substitute for other design practices,
but rather to extend the range of solutions to existing
[inadequately-solved] problems.

-- Dave S. [www.smallscript.org]