why () is () and [] is [] work in other way?

[Adam Skutt]

On Apr 26, 1:34 pm, rusi <rustompm... at gmail.com> wrote:
> On Apr 26, 7:44 pm, Adam Skutt <ask... at gmail.com> wrote:
> > On Apr 26, 10:18 am, rusi <rustompm... at gmail.com> wrote:
>
> > > On Apr 26, 4:42 pm, Adam Skutt <ask... at gmail.com> wrote:
>
> > > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > > f(x) is somehow more "direct" (whatever the hell that even means) than
> > > > using 'x+2'.  That's just not true.  We freely and openly interchange
> > > > them all the time doing mathematics.  Programming is no different.
>
> > > If f(x) and x+2 are freely interchangeable then you have referential
> > > transparency, a property that only purely functional languages have.
> > > In python:
>
> > I think you misunderstood what I was trying to explain.  Steven is
> > trying to claim that there's some sort of meaningful difference
> > between calling an operation/algorithm/function by some name versus
> > handing out its definition.  I was merely pointing out that we
> > routinely substitute the two when it is appropriate to do so.
>
> > My apologies if you somehow took that to mean that I was implying
> > there was referential transparency here.  I couldn't think of a better
> > example for what I was trying to say.
>
> > Adam
>
> And my apologies... I forgot to state my main point:
> Programmer accessible object identity is the principal impediment to
> referential transparency.
> In a functional language one can bind a name to a value -- period.
> There is nothing more essence-ial -- its platonic id -- to the name
> than that and so the whole can of worms connected with object identity
> remains sealed within the language implementation.

Yes, I agree that object identity is a major hold up, but I think side
effects are a bigger problem.  It's possible in C++ to create types
that behave like the primitive types without too much difficulty,
hence making object identity unimportant.  However, it's considerably
more difficult in C++ to write side-effect free code[1].  This is a
bit of an apple and orange thing, though. ;)

I often wonder what the world would be like if Python, C#, and Java
embraced value types more, and had better support for pure functions.
Unfortunately, building a language where all types behave like that is
rather difficult, as the Haskell guys have shown us ;).

Adam

[1] Or even just code that only uses side-effects the compiler
understands.