Many of our languages are heavily influenced by mathematical influences. This is largely because early uses for computers involved mostly physical calculations such as the path of military projectiles or simulating nuclear weapons. However, most actual applications these days involve very little math or very basic math.

Infix notation is not necessary, and de-mathing would '''free up keyboard symbols''' for other uses, and simplify the syntax structure.

If we follow something akin to UniversalStatement that potentially allows unlimited dynamic parameters, then concatenation could be done with something like:

   bigString = concat(a, b, c, d, e, "foo");
Instead of:
   bigString = a + b + c + d + e + "foo";  // JavaScript-style
The OOP style is also becoming popular (below), although I still like the option of a multiple concatenator like the above "concat" function for complex formatting-related uses.
   bigString.append(a);
   bigString.append(b); // etc...
And math could be done with something like:
   a = times(b, plus(c, d));
Instead of:
   a = b * (c + d);
Granted finance, engineering, and science-centric languages would still be math-centric. No need to change that.

Something to think about.

--top

''Is this serious or a joke? Why do this? Not trying to be argumentative - I just don't get it.''

{Trolling and/or a drunken rant, though "Most actual applications these days involve very little math or very basic math" made me laugh out loud.  I wonder if Top is aware that LISP preceded him in pointing out that "infix notation is not necessary" by around 1958.}

Lisp does ''other'' things wrong, structurally. As far as math usage, without a formal study/survey, it appears to be yet another AnecdoteImpasse here. And I don't appreciate the insults, Toad Face! -t

{Considering that every application programming domain requires math except simple data entry and retrieval, this doesn't look like an AnecdoteImpasse.  It just looks like you're wrong.}

I didn't say outright get rid of it, only don't waste syntax on it. It appears you read it with exaggeration-colored glasses on. 

I would gander only one out of every 300 statement has more than one arithmetic operator in typical dynamically typed apps I encounter, heavy graphic apps aside.

{Sounds like the typical dynamically typed apps you encounter are data entry and retrieval.}

No, they do a lot of different things. Often, they are "gluing" services together, for example. I would note that most of the heavier computation in terms of CPU cycles I encounter is done by the RDBMS, not the app language. For example, summarizing or averaging large chunks of data. (I DON'T suggest de-mathing SQL, by the way.) Perhaps my viewpoint of dynamic language usage is somehow skewed, but I just don't observe a lot of heavy math done in such languages and I've worked for or contracted with almost 3 dozen companies over the years. And it also gave me a chance to informally "snoop around" other projects that I wasn't directly involved with. I challenge people to list math-heavy apps they've done with dynamic languages. Graphics were the most math intensive I can think of, but this was often because "the bosses" didn't want to buy graphics packages such that I rolled my own. (It wasn't a rational use of resources from a bigger perspective, but sometimes the Dilbertian office politics make labor more plentiful than procurement.) -t

{Math-heavy apps in dynamic languages:  I've done 2D and 3D graphics (including videogames), data visualisation, regression analysis, financial analysis, and statistical data analysis.}

* Well, those are math-centric sub-domains. If you are doing heavy graphics or statistics, obviously you need a math-friendly language. That's not news. Most programmers I observe working with/on such apps have a math or physics degree of some type. A 4-year CS graduate typically would not, unless it was relatively trivial, or predefined via a math analyst. And often they use dedicated statistics software such as R or SPSS.

* ''Some 4-year CS graduates are more mathematically capable than others, and yes, some of us have (say) a joint math & CS degree.  You challenged "people to list math-heavy apps they've done with dynamic languages", so I did.''

* Well, I agree we need ''some'' dynamic math-oriented languages. The real question is what proportion. The above tells me very little about frequency of need, only its existence.

I wonder if Lisp fans miss infix. Comments? -t

{I do, and in Forth, too.}

A wider survey would be interesting. 

---------------

Note that I am not "anti-math", I just feel math-oriented syntax/features/complexity/symbols are "wasted" on math that could be better used for other things in a language. Complicating the occasional math-related parts of code to improve more-common areas of code may be a worthwhile tradeoff. --top

---------
-----
" I just feel math-oriented syntax/features/complexity/symbols are "wasted" on math that could be better used for other things in a language" Do you have any ideas where they could be better used?. How is using these symbols for math stopping you using them for this. As an example in C++ you can use the << for math or output depending on the context.

''Context-dependent symbols can get confusing for both writer and parser if "done wrong". Symbols are usually best used for language-oriented issues instead of operations. For example, one shortcut I'd like considered is:''

   mything = foo(mything, bar);   // the usual approach

   mything = foo(*, bar);   // shortcut referencing assigning variable
''At least for the way I like to code, that's a pretty common pattern I'd like to see simplified with some of the symbols freed up.''

{There's nothing grammatically ambiguous about using '*' this way, so why not overload it to represent "same identifier as the one on the left side of the assignment" as you've done above, and multiplication when used as an infix operator?}

* ''If one forgets the comma in the second version, they may get an error message something like, "Multiplication is missing left-side operand" or the like, leading to confusion. The parser/interpreter/compiler can't know what was intended by the app coder. A "clean" grammar without symbol overloading often results in better error messages and perhaps fewer accidental cross-uses (that can still pass parsing). Whether this is important enough to toss infix is an open question. I also suspect more would write code processing tools and smarter IDE's if parsing the language was easier. -t''

Do you have any examples of "done wrong".?

''I'll can't think of an easy way to describe it yet. I'll ponder presentation ideas.''
-----------

Note that in a similar fashion to the "concat()" example function, arithmetic operators could potentially take more than two parameters:

   x = add(a, b, c, 4);  // equiv to: x = a + b + c + 4;
   x = times(a, b, c, 4);  // equiv to: x = a * b * c * 4;
Two is kind of arbitrary if you think about it outside of usual habits. It's one of the limits of in-fix syntax.

To get fancier on the same thought track, one could borrow from FunctionalProgramming's "fold" and have something like this to build ad-hoc versions of such:

  x = fold2(myFunc, a, b, c, 4)
Here, myFunc is a pre-defined function that takes two parameters. "fold2" means it's expecting a function that takes at least two parameters. (If it takes more than 2, the subsequent ones would be ignored here.)

Some may note we are drifting into MaspBrainstorming-like territory here.

--top

''Just for the record, having addition, multiplication, and exponentiation be binary operators isn't arbitrary. They are defined in terms of repeated successor, addition, and multiplication. One of the operands is the base, and the other is how many times to perform the operand. (Some creativity is needed to define what partial applications of these operators are, but the basic point still remains.) In fact, it would be very difficult to define the list versions without the binary ones. That said, there is no need for the language to provide a binary operator if it provides the list version. I suspect that this was really your point. (Though you then go back to only providing a binary version and a general fold to get the list version. And yes, the binary operator with a generic fold is more flexible since we can use fold any user-defined operators as well as the built in ones.)''

----- 
CategorySyntax, CategoryLanguageDesign
----
JanuaryFourteen