5 ms·

I love new programming languages and the concepts they bring to the table. But I feel PL designers should think about Dev experience. Is it just me or is the "

I love new programming languages and the concepts they bring to the table. But I feel PL designers should think about Dev experience. Is it just me or is the "\" in front of parenthesis (func params) is just off-putting. I wonder, what purpose does it solve? Familiar syntax makes it much easier to adopt and easily convince devs in your team to try it for real.

cormacrelf 5y ago
Probably looks like lambda. Haskell has them. \x -> x + 1
ulrikrasmussen 5y ago
I agree, but lambdas do not really have a canonical syntax in the same way that braces have become synonymous with delimiters for statement blocks. This particular syntax comes from Haskell, where e.g. \x -> f x denotes an anonymous function that applies its first argument to `f`. But I have seen at least these forms in other languages of varying popularity: [x] f x |x| f x { f(it) } { x -> f(x) } fn x => f x function(x) { return f(x); } x -> f(x) (x: A) => f(x) In other words, I think it is really hard to pick a syntax for this construct that every programmer is going to feel familiar with, especially if your language is supposed to cater both to programmers coming from FP and more traditional languages. Edit: Fixed error in JS example; added Java and Scala.
- chrismorgan 5y ago
  > function(x) { f(x); } Slight correction (presuming JavaScript): that’d be `function(x) { return f(x); }`.
  - ulrikrasmussen 5y ago
    Thank you, fixed!
  - marcle 5y ago
    This could also be R, which allows for `function(x) {f(x)}` and (since version 4.1) `\(x) {f(x)}`.
- boondaburrah 5y ago
  for clojure there's #(f %) or (fn [x] (f x))
- kennywinker 5y ago
  Examples 3 and 4 are cursed, to my eye. Curly braces denote a block, so why is there some magic syntax inside the block that denotes that this block happens to be a lambda? surely the block is the closure itself. The syntax to say what the block is goes outside. Imagine if i wrote a conditional like that: if x > y { return x; } else { return y; } as { if x > y; return x; } { else; return y; } It completely erases the usefulness of {}, and is cursed, cursed I say! And I’m looking at you, rust, swift, ruby, etc.
  - ulrikrasmussen 5y ago
    I wholeheartedly agree. Whether {} denotes a block or a lambda is context-dependent in the language I took these examples from (Kotlin). I think they adopted the syntax from Groovy. It is "useful" for creating DSLs because you can implement constructs like `.forEach` so they look like imperative constructs, e.g. list.forEach { x -> ... } But it becomes harder to read code outside an IDE, especially if the implicit `it` construct is used.
    - zorr 5y ago
      That's the thing that annoys me most about Kotlin (even though aside from that it is my personal 10X language). In a large project that uses DSL's, coroutines and flow it quickly becomes a curly brace mess and it gets hard to see what code runs where, when and in which context.
      - ulrikrasmussen 5y ago
        Same, I use Kotlin daily, and I would choose it over Java any day as it really solves a lot of its quirks very nicely. There are however some parts of the syntax that keep confusing me on a daily basis, curly braces being one of them. The other is the weird unintuitive asymmetry that is going on between function types and lambdas. For example, a lambda of type (Int, Float) -> Boolean is written as { i, f -> ... body ... } but a lambda of type (Pair<Int, Float>) -> Boolean is written as { (i, f) -> ... body ... } because `(x, y)` is a destructuring pattern that projects the first and second components into `x` and `y`, respectively. The pattern in the lambda has to use tuple syntax exactly when the type doesn't, and vice versa. Gets me on a weekly basis even though I completely understand what's going on, it's just not very ergonomic.
- thewakalix 5y ago
  I can’t believe the canonical anonymous function notation is omitted: (lambda (x) (f x)) On the other hand, this is a discussion about syntax, and Lisp is the “syntaxless” language…
  - bidirectional 5y ago
    How is that canonical? λ x . f x is the original syntax of Church, Lisp came around decades later.
    - amw-zero 5y ago
      Canonical from a programming languages perspective.
iammisc 5y ago
This is canonical syntax in any functional programming language. This is like a Haskell programmer complaining that in most post-haskell languages, the keyword class means an oop type instead a class of types.
- pharmakom 5y ago
  All true, but perhaps it’s better to use something more familiar to more developers, such as x => f x Or x -> f x
  - isaacimagine 5y ago
    Passerine[0] uses the latter syntax. [0]: https://github.com/vrtbl/passerine https://github.com/vrtbl/passerine
- Zababa 5y ago
  No it's not. It's used mostly by Haskell, but ML/SML/OCaml and Scala use a different syntax.
deleted 5y ago
[deleted]
tempodox 5y ago
“λ” is a bit inconvenient to type on most keyboards. And supporting Unicode at the source code level is still surprisingly rare in programming languages.
amw-zero 5y ago
By that logic we would never get new programming language ideas, because we could only reuse what has already been done.

cormacrelf 5y ago

Probably looks like lambda. Haskell has them. \x -> x + 1

ulrikrasmussen 5y ago

I agree, but lambdas do not really have a canonical syntax in the same way that braces have become synonymous with delimiters for statement blocks. This particular syntax comes from Haskell, where e.g. \x -> f x denotes an anonymous function that applies its first argument to `f`. But I have seen at least these forms in other languages of varying popularity: [x] f x |x| f x { f(it) } { x -> f(x) } fn x => f x function(x) { return f(x); } x -> f(x) (x: A) => f(x) In other words, I think it is really hard to pick a syntax for this construct that every programmer is going to feel familiar with, especially if your language is supposed to cater both to programmers coming from FP and more traditional languages. Edit: Fixed error in JS example; added Java and Scala.

chrismorgan 5y ago
> function(x) { f(x); } Slight correction (presuming JavaScript): that’d be `function(x) { return f(x); }`.
- ulrikrasmussen 5y ago
  Thank you, fixed!
- marcle 5y ago
  This could also be R, which allows for `function(x) {f(x)}` and (since version 4.1) `\(x) {f(x)}`.
boondaburrah 5y ago
for clojure there's #(f %) or (fn [x] (f x))
kennywinker 5y ago
Examples 3 and 4 are cursed, to my eye. Curly braces denote a block, so why is there some magic syntax inside the block that denotes that this block happens to be a lambda? surely the block is the closure itself. The syntax to say what the block is goes outside. Imagine if i wrote a conditional like that: if x > y { return x; } else { return y; } as { if x > y; return x; } { else; return y; } It completely erases the usefulness of {}, and is cursed, cursed I say! And I’m looking at you, rust, swift, ruby, etc.
- ulrikrasmussen 5y ago
  I wholeheartedly agree. Whether {} denotes a block or a lambda is context-dependent in the language I took these examples from (Kotlin). I think they adopted the syntax from Groovy. It is "useful" for creating DSLs because you can implement constructs like `.forEach` so they look like imperative constructs, e.g. list.forEach { x -> ... } But it becomes harder to read code outside an IDE, especially if the implicit `it` construct is used.
  - zorr 5y ago
    That's the thing that annoys me most about Kotlin (even though aside from that it is my personal 10X language). In a large project that uses DSL's, coroutines and flow it quickly becomes a curly brace mess and it gets hard to see what code runs where, when and in which context.
    - ulrikrasmussen 5y ago
      Same, I use Kotlin daily, and I would choose it over Java any day as it really solves a lot of its quirks very nicely. There are however some parts of the syntax that keep confusing me on a daily basis, curly braces being one of them. The other is the weird unintuitive asymmetry that is going on between function types and lambdas. For example, a lambda of type (Int, Float) -> Boolean is written as { i, f -> ... body ... } but a lambda of type (Pair<Int, Float>) -> Boolean is written as { (i, f) -> ... body ... } because `(x, y)` is a destructuring pattern that projects the first and second components into `x` and `y`, respectively. The pattern in the lambda has to use tuple syntax exactly when the type doesn't, and vice versa. Gets me on a weekly basis even though I completely understand what's going on, it's just not very ergonomic.
thewakalix 5y ago
I can’t believe the canonical anonymous function notation is omitted: (lambda (x) (f x)) On the other hand, this is a discussion about syntax, and Lisp is the “syntaxless” language…
- bidirectional 5y ago
  How is that canonical? λ x . f x is the original syntax of Church, Lisp came around decades later.
  - amw-zero 5y ago
    Canonical from a programming languages perspective.

iammisc 5y ago

This is canonical syntax in any functional programming language. This is like a Haskell programmer complaining that in most post-haskell languages, the keyword class means an oop type instead a class of types.

pharmakom 5y ago
All true, but perhaps it’s better to use something more familiar to more developers, such as x => f x Or x -> f x
- isaacimagine 5y ago
  Passerine[0] uses the latter syntax. [0]: https://github.com/vrtbl/passerine https://github.com/vrtbl/passerine
Zababa 5y ago
No it's not. It's used mostly by Haskell, but ML/SML/OCaml and Scala use a different syntax.

deleted 5y ago

[deleted]

tempodox 5y ago

“λ” is a bit inconvenient to type on most keyboards. And supporting Unicode at the source code level is still surprisingly rare in programming languages.

amw-zero 5y ago

By that logic we would never get new programming language ideas, because we could only reuse what has already been done.