False Cognates and Syntax: The Importance of Syntax in Programming Languages

if x > y -> true; otherwise -> false; end

Using otherwise makes it a loss less ugly, and I guess fixes the false cognate.

For instance in Lua:

    function abs(x)
        test = {
           [true]=-x,
           [x>0]=x,
           [x==0]=0}
        return test[true]
    end

    > print (abs(-3))
    3

It's not the best way to do this, but maybe it'will help understand the above construct.

(defun is-greater-than (x y) (cond ((< x y) T) (T nil)))

As with the erlang example, I need a T test to get an else clause, although in this particular example, the result of the cond is nil if nothing matches anyway.

A typical example of a confusing return in haskell is this. Note that this always prints "hi".

  foo bar = do
    if bar > 5
       then plugh
       else do
         xyzzy
         return ()
    print "hi"

You do get used to this pretty quickly, but there's also a tendency to move away from that style of haskell. I'd write the above more like this, using guards rather than the if, and using void to force both plugh and xyzzy to return the same type.

   foo bar = go >> print "hi"
     where
       go 
         | bar > 5 = void plugh
         | otherwise = void xyzzy

http://en.wikipedia.org/wiki/Uniform_access_principle

It does put more onus on the API implementer to be careful about hiding non-trivial work, like you say.

The issue being that attributes can be accessed at all of course.

> Of course, Ruby, Scala, etc, are not immune to this criticism.

Well they are — or at least Ruby is — in that they don't allow attribute accesses from third-parties at all. Just consider that Python is the same (it is).

Hell, in Python `.` is already a method call. In fact it's a whole sequence of method calls.

Python is different because the style guide explicitly discourages [1] computationally expensive accessor methods (as well as accessor methods with side effects) specifically so that programmers can treat accessor methods the same way they would treat a data field. Assuming that x.y is a field access in Python is not supposed to lead to problems, and if it does, it's the fault of the class implementer and not the user.

[1] http://www.python.org/dev/peps/pep-0008/#designing-for-inher...

Yes it is - that's always a method call: http://docs.python.org/reference/datamodel.html#invoking-des...

The problem is that you're unclear whether it's a mutating method or not, as well as whether it's an expensive operation. But that can be solved a number of ways - immutability and lazy evaluation would be one approach, though unfortunately neither Python nor Ruby enforces immutability, and both use absurdly eager evaluation.

(Regarding that last point, try doing [x.y() for x in foo][0] and you'll see that y is called for every x!)

On the other hand, I think the article's point that it's tricky is valid. The way it is usually used makes it appear that it is causing the procedure being defined to exit. If a user thinks that's what it's actually doing (which they tend to do when coming from other languages), they will try to write things like "when (i == 0) (return x)", which does not mean what they think it means.

  do if condition
       then do putStrLn "bailing out early"
               return ()
       else putStrLn "carrying on"
     putStrLn "Launching missiles..."

`return` in Haskell is a false cognate and it causes beginners difficulties. Some of them post to StackOverflow asking confused questions about it.

if-then-else in Haskell is also a false cognate (and there are formatting issues to trip up the unwary as well). It's actually the same as C's/Java's/etc ?: operator, so it's unfortunate the standard library doesn't contain something similar to that instead of adding if-then-else to the language.

Having said all that, I don't think being a false cognate should automatically be a disqualifying attribute. Haskell's new <> operator (a synonym for mappend) looks like Basic's/Pascal's not-equal-to operator. But I think few Haskellers come from that immediate background.

You can use sequences of punctuation characters, e.g. <:= and =:> for brackets, or =>> for an operator, or :*; for a separator. Or use punctuation characters not in ASCII: there's hundreds of them in the symbols blocks of Unicode.

(edit: The author of the comment I responded to added another two paragraphs.) C# beating Java is not something I think is as clear-cut as you seem to believe (from my vantage, C# is used by Windows developers, and Java is used by everyone else: the dividing line has little to do with syntax preferences and much more to do with the quality of the IDEs and the integration of the runtimes; before MS was legally required to stop distributing it, J++ was gaining ground), but to the extent to which it is true you have to remember that C# also is not making breaking language changes, and in fact didn't even make drastic changes to Java (which one might argue is the legacy that C# continued). In fact, C# was so compelling to a lot of us who adopted it early because it had such amazing backwards-compatibility in the form of interop with native C and C++ code with the ability to nearly natively interact with our existing COM objects.