Hacker News new | ask | show | jobs
by jchendy 2746 days ago
> // no curly braces, semicolons or parentheses

Is this a good thing? It feels like saying "It's English without the periods or line breaks or capital letters."

5 comments

Curly braces - F# is a whitespace-significant language, so contexts are still plenty visible.

Semicolons - If that's the main thing telling you where an expression ends, it's time to start taking your code formatting more seriously.

Parentheses - Still exist, but only for expression grouping and tuples. It's just that they aren't used as a function application operator. This admittedly takes some getting used to, but starts feeling easy and natural surprisingly quickly.

Importantly, function application without parens feels a lot nicer in F# than it does in Scala or Nim. I think the difference is that, in F#, adding parens around a function's argument list would actually change the meaning of the expression, and likely cause a compiler error.† In Scala or Nim, they're (sometimes) optional, which just creates this unnecessarily confusing situation, not entirely unlike optional semicolons in JavaScript.

† - If it's a 1-ary function, you'd be fine, because it would interpret the parens as grouping operators around the argument. If it's a 2-ary function, then it would probably cause a compile error, because parens around a space-delimited list are (I'm pretty sure - it's been a while since I last worked in F#) not valid syntax. If you add commas, so that it looks like a C# method call, it would then interpret it as a tuple, which would probably mean a compile error, unless the function has an overload that accepts a tuple of that arity as its first argument, and, even then, only if applying that version of the function doesn't somehow lead to a type error.

(Edited for clarity and extra babbling.)

For me it's about code clutter or cognitive load.

curly braces or semicolons do not serve a purpose most of the time.

as F# is a functional language you do not require them to seperate statements as you always pass values...I hope you know what I mean.

It is because those things are simply not needed to parse or understand the code.

Everyone indents anyway. So why need braces?

Most people write one statement per line. Who needs semicolons. I've often called it the most useless character in programming language history. Whenever I switch from a language that doesn't use them to one that needs them, it's a horrible transition. I have to mentally remember to add this character at the end of most lines.

Parentheses for function calls - in some contexts they are helpful. In most, though, they are not needed. Wherever they are needed, you will have them in F#. For people who went from Python 2 to Python 3, you'll know the pain of suddenly needing parentheses for print statements, and for most of those people, you will not see any benefit to adding those parentheses. Extend that to other functions.

"Everyone indents anyway. So why need braces?"

I don't indent. I let the editor do it based on braces.

My editor understands when to indent in Python, and often when to dedent. When it doesn't know to dedent, I just hit Backspace on the next line to close the indented block.

I understand it's a matter of taste, but I don't understand why people insist on repeating themselves -- you're already going to have something indent your code for readability, why not have that just be what the language uses, too?

That said, you should know that in Python, at least, there is famous first-class support for the brace styles of many other languages, invoked by the brace operator "#". For example, if you want C-style braces you can simply write like so, using the brace operator to tell Python what you're doing:

    def hello(): # {
        print("Hello, world!")
    # }
And Python will automatically understand it correctly!

A more complex example uses Ruby-style "end" and conditionals:

    def odd_or_even(num):
        if num % 2:
            return "Odd"
        else:
            return "Even"
        # end
    # end
Python's advanced brace-style parsing AI will correctly handle this. You can even mix and match brace styles within a single codebase, or even a single file, for times when your team just can't agree on one approach.
Fair enough. I save on keystrokes by not inserting braces. I do have to manually indent once in a while, but the editor will usually figure out what I mean.

As an example, in a for loop in Python, I need to press a single key for indenting[1]. In a language like C, it would be 4 keystrokes - 2 for each brace. Come to think of it, this is true for if conditions, functions, etc. Pretty much all places you'd need braces in C. I'm having trouble figuring out where in regular programming in Python a braces would mean less work for the programmer.

Indenting is simply less work than inserting braces.

[1]Strictly speaking, for dedenting when I'm done with the for loop.

All you are saying is personal taste and familiarity. Nothing wrong with that but I could argue every one of your points exactly the other way and would be as right as you are.

In the end you get used to almost everything.

It's not entirely accurate either.

Curly braces are everywhere, but they aren't used to distinguish contexts or end logical blocks, so you don't have the noise everywhere (increasing readability substantially).

Semicolons are used to logically distinguish list items. Semicolons are supported, but not required to terminate lines. This makes copy n paste easier for C# code.

Parentheses? It's a functional language... "()" is a valid value. Every lambda, tuple, parameter set, and value can be wrapped in them, and often must to be valid code.

In every case the reduction in line noise, superfluous characters, and inconsistent formatting is replaced with strict formatting requirements and strict variable definition requirements. That means better readability. It also means you can support multiline string literals and escaped variable names easily, further improving redability.

That’s honestly how I feel when using these functional languages. Syntax isn’t everything, but it isn’t nothing either.