4 ms·

People are used to math infix operators and can use them efficiently. But working with infix operators in other contexts would be a complete nightmare. Limitin

People are used to math infix operators and can use them efficiently. But working with infix operators in other contexts would be a complete nightmare. Limiting what a given expression can "bind" to, what it can form a large expression with, is a way to limit the processing needed to understand a given piece of code. Being able to say one thing a hundred different ways isn't good if the read has to search for a hundred different maybe-meanings a given string might have.

yccs27 5y ago
Yeah, relying on operator precedence makes for some of the most infuriating to read code.
- abrudz 5y ago
  Yeah, infix doesn't go well with that. Even traditional mathematical notation ends up being ambiguous because of it. However, if all infix operators are given equal precedence, it all becomes very neat. See APL (https://apl.wiki https://apl.wiki) for an example of that.
  - maximus-decimus 5y ago
    At the same time Q (which is based on apl) only allows built in functions to be infix because otherwise your code gets unreadable Especially if you also have prefix notation. in `one two three`, are one and two functions using prefix notation or is two an infix function that takes both one ant three as arguments? It's not too bad if you have a small amount of infix functions to remember, but I don't want to second guess everything while reading code.
- mkl 5y ago
  Code written by people who don't know operator precedence and so put brackets around absolutely everything is significantly harder to read IME. I've seen students end up with "))))))" at the end of a line. Brackets are better as a signal that something unusual's happening.
ogogmad 5y ago
Sometimes it's nice to be able to do piping: object | dothis | dothat | dosomething I suppose the piping operator is infix. I feel like some of the advantages of the notation object.f() over f(object) in object oriented programming are due to this.
- andreareina 5y ago
  An interesting feature of D is Uniform Function Call Syntax (UFCS) where any function with first parameter of type T can be called as a method on T: https://dlang.org/spec/function.html#pseudo-member https://dlang.org/spec/function.html#pseudo-member
  - xigoi 5y ago
    Other languages I know of that have this feature are Nim, Koka and VimScript.
  - codethief 5y ago
    That is indeed an interesting feature! I wish more languages implemented it! In Python, of course, one argument against implementing it is that there already is the getattr magic method (and the getattribute one), so even if it'd be possible to implement UFCS without breaking changes, it would at least complicate the way attribute access works even further. But, of course, one could always introduce a new operator/token (instead of ".").
- runevault 5y ago
  I love |> in f# because of this type of thing, piping operations together instead of nesting or the like just reads so much cleaner. And yes in cases where they are all methods on the type you can have the function return self and then do value.Func1().func2().func3().etc() but only if they are methods on the class. But I also don't care for arbitrary infix operators (which I'm pretty sure f# supports but I haven't used it in a way where I run into them). I know I'm crazy but I almost wish we did away with ALL infix operators, even stuff like +/-* and just do everything as functions. You know, like Lisp :P Edit: I guess I should clarify as it sounds back and forth. For traditional stuff everything functions, with exceptions for things like piping that are purely about chaining operations together (both |> and >> in f# are examples of infix that's specific use case is different enough from say +-/* I think they warrant it).
smaudet 5y ago
> Being able to say one thing a hundred different ways isn't good if the read has to search for a hundred different maybe-meanings a given string might have. This the absurd notion that there is some one "best" way to do things...hard core disagree. If this were true, there should only be one library, one way of doing anything, one codebase, and therefore only one program, nay even there should only be one programmer, and Python should be a pet project of this one programmer doing everything one way... The fact that you can obfuscate python, means python has failed its ethos in this respect (https://pypi.org/project/python-obfuscator/ https://pypi.org/project/python-obfuscator/). Compatibility is good, a thriving ecosystem is better. Critically, a thriving ecosystem is made by a hundred different ways of doing something, all doing something similar, not by making everything similar, so that the first time if fails, its game over.

yccs27 5y ago

Yeah, relying on operator precedence makes for some of the most infuriating to read code.

abrudz 5y ago
Yeah, infix doesn't go well with that. Even traditional mathematical notation ends up being ambiguous because of it. However, if all infix operators are given equal precedence, it all becomes very neat. See APL (https://apl.wiki https://apl.wiki) for an example of that.
- maximus-decimus 5y ago
  At the same time Q (which is based on apl) only allows built in functions to be infix because otherwise your code gets unreadable Especially if you also have prefix notation. in `one two three`, are one and two functions using prefix notation or is two an infix function that takes both one ant three as arguments? It's not too bad if you have a small amount of infix functions to remember, but I don't want to second guess everything while reading code.
mkl 5y ago
Code written by people who don't know operator precedence and so put brackets around absolutely everything is significantly harder to read IME. I've seen students end up with "))))))" at the end of a line. Brackets are better as a signal that something unusual's happening.

ogogmad 5y ago

Sometimes it's nice to be able to do piping: object | dothis | dothat | dosomething I suppose the piping operator is infix. I feel like some of the advantages of the notation object.f() over f(object) in object oriented programming are due to this.

andreareina 5y ago
An interesting feature of D is Uniform Function Call Syntax (UFCS) where any function with first parameter of type T can be called as a method on T: https://dlang.org/spec/function.html#pseudo-member https://dlang.org/spec/function.html#pseudo-member
- xigoi 5y ago
  Other languages I know of that have this feature are Nim, Koka and VimScript.
- codethief 5y ago
  That is indeed an interesting feature! I wish more languages implemented it! In Python, of course, one argument against implementing it is that there already is the getattr magic method (and the getattribute one), so even if it'd be possible to implement UFCS without breaking changes, it would at least complicate the way attribute access works even further. But, of course, one could always introduce a new operator/token (instead of ".").
runevault 5y ago
I love |> in f# because of this type of thing, piping operations together instead of nesting or the like just reads so much cleaner. And yes in cases where they are all methods on the type you can have the function return self and then do value.Func1().func2().func3().etc() but only if they are methods on the class. But I also don't care for arbitrary infix operators (which I'm pretty sure f# supports but I haven't used it in a way where I run into them). I know I'm crazy but I almost wish we did away with ALL infix operators, even stuff like +/-* and just do everything as functions. You know, like Lisp :P Edit: I guess I should clarify as it sounds back and forth. For traditional stuff everything functions, with exceptions for things like piping that are purely about chaining operations together (both |> and >> in f# are examples of infix that's specific use case is different enough from say +-/* I think they warrant it).

smaudet 5y ago

> Being able to say one thing a hundred different ways isn't good if the read has to search for a hundred different maybe-meanings a given string might have. This the absurd notion that there is some one "best" way to do things...hard core disagree. If this were true, there should only be one library, one way of doing anything, one codebase, and therefore only one program, nay even there should only be one programmer, and Python should be a pet project of this one programmer doing everything one way... The fact that you can obfuscate python, means python has failed its ethos in this respect (https://pypi.org/project/python-obfuscator/ https://pypi.org/project/python-obfuscator/). Compatibility is good, a thriving ecosystem is better. Critically, a thriving ecosystem is made by a hundred different ways of doing something, all doing something similar, not by making everything similar, so that the first time if fails, its game over.