Popular posts

I have no beef against specific naming conventions (as long as they are consistently followed), but I somehow never got to appreciate operator overloading.

I have been learning F# recently and operator overloading here is a common practice :

In a popular web framework, this is how you do routing:

let app =
  choose
    [ GET >=> choose
        [ path "/hello" >=> OK "Hello GET"
          path "/goodbye" >=> OK "Good bye GET" ]
      POST >=> choose
        [ path "/hello" >=> OK "Hello POST"
          path "/goodbye" >=> OK "Good bye POST" ] ]

The "fish operator" is for kleisi composition.

Another interesting case from api documentation:

^^    : Search a list of key-value option pairs and return the value (or None if not found)

I have always felt that operator overloading destroys readability. It is disheartening to see even well-designed new languages like swift (touted as elegant) allowing this practice:

class MyFormViewController: FormViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        form = Section("Section1")
            <<< TextRow(){ row in
                row.title = "Text Row"
                row.placeholder = "Enter text here"
            }
            <<< PhoneRow(){
                $0.title = "Phone Row"
                $0.placeholder = "And numbers here"
            }
        +++ Section("Section2")
            <<< DateRow(){
                $0.title = "Date Row"
                $0.value = NSDate(timeIntervalSinceReferenceDate: 0)
            }
    }
}

Ruby has taken a very pragmatic approach towards this.

A very restricted form of operator overloading is allowed - so you can override how +, -, '<<' etc. behave for specific classes, but can not define new arbitrary operators.

---

I occasionally use a language called livescript which compiles to javascript. While the rest of the language is nice, succinct and compiles to readable javascript, a few eccentric design choices keep bugging me:

kebab-case and camelCase are interchangeable - and both compile to camelCase in javascript:

For example:

x.hasEntity! # the trailing bang implies invocation without arguments
x.has-entity!

both of the above compile to x.hasEntity().

Also we can use \x for 'x' (if string is just a single word). And this works for property accessors as well: x.\entity compiles to x['entity']. But obviously once you have a string the kebab-case to camel case conversion can not be reliably done.

So x.\has-entity! compiles to x['has-entity!']. Not only the kebab case conversion doesn't happen, the bang now is a part of string and there is no run time error and expected function is silently never invoked.

At one point this was a recurring source of bugs in my code.

There is the problem of poor naming convention, and then there is the problem of no name at all:

fn = (.schema.drop-table \users)

This defines a function with an implicit argument:

var fn = function(it){
  return it.schema.dropTable('users');
};

While this is useful in small callbacks, this can make code hard to read if overused.