On: Factor 0.96 now available – over 1,100 commits

[bjourne]

It takes a few hours to get used to, but once you get the hang of it it becomes an amazing language. For most things postfix notation that Factor uses reads better than applicative (prefix) notation other languages uses. It's like jQuery's or linq's method chaining, only better :) and with less syntax. For example here is the solution to problem 22 in Project Euler (http://projecteuler.net/problem=22):

    : names ( -- seq )
         "names.txt" ascii file-contents [ quotable? ] filter "," split ;
    : score ( str -- n ) [ 64 - ] map sum ;
    : solution-22 ( -- n )
        names natural-sort [ 1 + swap score * ] map-index sum ;

[thomasfl → bjourne]

Reverse polish notation means you have to start reading from the end of the expression:

    "hello world" print

This is also why ternary expressions in C like languages is hard to read.

[pestaa → thomasfl]

I find the ternary expressions very easy to read and understand and never understood why others find it difficult at all.

I see no semantical difference between

    if(expr1) expr2 else expr3;

and

    expr1 ? expr2 : expr3;

Okay you need to learn the syntax, but it should be second nature after a few times. I also think the question mark is very intuitive.

[benbataille → pestaa]

If it was that simple, people wouldn't have any issue with the conditional operator. The problem is there actually is a semantic difference between the two lines you wrote in most languages.

If-Then-Else is a statement. It doesn't return a value. It's just a branching operation between the two blocks.

The conditional operator is an expression. It returns a value hence it has a type. And that's where things start to be messy. Typing rules for the conditional operator are, well, not trivial and varie from language to language. Let's use an exemple from Java Puzzlers (Joshua Bloch and Neal Gafter) :

char x = 'X'; int i = 0; System.out.print(true ? x : 0); System.out.print(false ? i : x);

will print X88 but the same thing in C++

        char x = 'X';
        int i = 0;
        cout << (true ? x : 0);
        cout << (false ? i : x);

will print 8888.

And I am not even talking about the priority mess when you try to use a conditional operator in a conditional operator.

[barrkel → benbataille]

That has nothing to do with the semantics ternary operator per se, but rather to do with how Java and C++ respectively type it. If you inserted the relevant casts to make sure both result halves have the same type, the difference would disappear.

You could expose the same semantic difference your example relies on with overload resolution, without needing to refer to the ternary operator at all. But I hope you wouldn't take that to mean that overloads are also a bad idea.

I also believe that the ternary operator is particularly nice when used in combination:

    x = a ? foo :
        b ? bar :
        c ? baz :
            blah;

The idiom tastes a little like pattern matching. Of course, you need to be a little cautious about your precedence, but I've never used a language supporting infix operators that didn't have gotchas around precedence.

[pestaa → benbataille]

Yes, you are absolutely right. I forgot about this one major difference. However, you cannot generally say if-then-else is a statement; there are languages such as CoffeeScript in which if-then-else works exactly like the conditional operator and therefore has a type and return value.

As for the priority mess, I spend my brain cycles elsewhere and use parentheses, which also helps the next guy as well as me.

[fosap → pestaa]

Or virtually every language that is functional in a way. For example Lisp and Haskell.

[nightski → benbataille]

How is this any different than saying "Avoid the + operator at all costs, because behavior is non-trivial and varies from language to language". Of course there are going to be differences. You just have to learn the rules for the language you are working in.

[benbataille → nightski]

> How is this any different than saying "Avoid the + operator at all costs, because behavior is non-trivial and varies from language to language".

I never ever remotely said that. You are putting words in my mouth and I don't like it. I just rightfully pointed that there actually is a semantic difference between the two mentioned lines. I never implied using any of them was wrong. I didn't even emit a judgement of value on either construct.

Now, I don't have problem per see against the conditional operator. It's just not as simple as some people like to pretend and it makes your code depends on some non obvious and not broadly known language feature for what is usually a minimal gain. So, yes, I do tend to avoid it in anything which is going to end in the hand of others (in the same way I try to avoid any un-obvious language idiom as much as possible). It's like nested comprehensions in Python, the slightly shorter code produced is just not worth the added complexity.

[gosub → thomasfl]

But you can read left to right to get the order in which operations/transformations are performed:

    "hello world" uppercase print

While in languages where function application is prefix, you have to go inside to outside, right to left:

    print(uppercase("hello world"))

Additionally, if there are infix operators, the direction is switched mid statement:

    print(uppercase("hello" + "world"))

hello -> world <- uppercase <- print

[djhworld → gosub]

I like the way Haskell uses it's composition function operator (.), it's very clean, e.g.

  λ>putStrLn . reverse .  map toUpper $ "hello world"
  DLROW OLLEH

[j4_james → thomasfl]

And yet that's very much how object-oriented languages are typically structured.

  object.method()

  "hello world".print()

If you're used to speaking a language like English where the word order is subject-verb-object, you'd probably consider a subject-object-verb language to be "backwards" too. But native speakers of that language certainly wouldn't have a problem.

I'm sure it's just a matter of what you're used to.