7 ms·

> It's crazy that in these slides he says "I wanted a hipster language" -- most languages use [] for arrays so I used (). WHY!!!!? Just to be different? No actu

by eklavya 12y ago

> It's crazy that in these slides he says "I wanted a hipster language" -- most languages use [] for arrays so I used (). WHY!!!!? Just to be different? No actual real advantage? That's a terrible reason and a great way to make it hard for new people to adopt your language. func<Future<List<Option<String>>>> vs func[Future[List[Option[String]]]] Which one is easier on your eyes?

trhway 12y ago
>>func<Future<List<Option<String>>>> vs func[Future[List[Option[String]]]] >Which one is easier on your eyes? i don't get the joke here. Or are you seriously implying that one is in someway better than the other? (i'm curious as i've been in the industry for more than two decades, so my eyes just filter that crap automatically anyway)
- eklavya 12y ago
  I am seriously implying that one is easier on the eyes than other.
- jghn 12y ago
  Granted I'm biased as I'm primarily a scala dev these days but I've always preferred the square brackets over the angle brackets. At least for me it is actually more readable.
  - seanmcdirmid 12y ago
    Angle brackets aren't even very readable, couple that with the fact that they are also OPERARTORS and you are looking at some major complexity in your parser to distinguish between bracket usage and operator usage (possible, but requires looking ahead, worse syntax errors).
    - frowaway001 12y ago
      Or just terrible syntax choices like in Java or Rust.
outworlder 12y ago
Or, maybe, perhaps: func(Future(List(Option(String))))
- smenko 12y ago
  Err, no... One is a type construction, the other is function application. It sure helps if these are different...
  - platz 12y ago
    Conceivably, it could be application of a type constructor to type arguments, where parens control precedence, not application: Func (Future (List (Option String)))
imh 12y ago
That's really not a fair comparison here. With a monospaced font, it's much more comparable: func<Future<List<Option<String>>>> func[Future[List[Option[String]]]]

by eklavya 12y ago

trhway 12y ago

>>func<Future<List<Option<String>>>> vs func[Future[List[Option[String]]]] >Which one is easier on your eyes? i don't get the joke here. Or are you seriously implying that one is in someway better than the other? (i'm curious as i've been in the industry for more than two decades, so my eyes just filter that crap automatically anyway)

eklavya 12y ago
I am seriously implying that one is easier on the eyes than other.
jghn 12y ago
Granted I'm biased as I'm primarily a scala dev these days but I've always preferred the square brackets over the angle brackets. At least for me it is actually more readable.
- seanmcdirmid 12y ago
  Angle brackets aren't even very readable, couple that with the fact that they are also OPERARTORS and you are looking at some major complexity in your parser to distinguish between bracket usage and operator usage (possible, but requires looking ahead, worse syntax errors).
  - frowaway001 12y ago
    Or just terrible syntax choices like in Java or Rust.

outworlder 12y ago

Or, maybe, perhaps: func(Future(List(Option(String))))

smenko 12y ago
Err, no... One is a type construction, the other is function application. It sure helps if these are different...
- platz 12y ago
  Conceivably, it could be application of a type constructor to type arguments, where parens control precedence, not application: Func (Future (List (Option String)))

imh 12y ago

That's really not a fair comparison here. With a monospaced font, it's much more comparable: func<Future<List<Option<String>>>> func[Future[List[Option[String]]]]