4 ms·

> it’s basically unreadable to very most of developers The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sen

> it’s basically unreadable to very most of developers The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options. And it's not intrinsically less readable than say, something like: https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01115_source.html https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0111...

doublesCs 6y ago
> The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options. Are you sure? Plenty of languages[1,2] allow you to treat code as data and they don't need that many parenthesis. [1] https://docs.python.org/3.8/library/ast.html https://docs.python.org/3.8/library/ast.html [2] https://docs.julialang.org/en/v1/manual/metaprogramming/index.html https://docs.julialang.org/en/v1/manual/metaprogramming/inde...
- kgwgk 6y ago
  That's not code as data, that's parsed code as data. julia> :(a + b*c + 1) == Meta.parse("a + b*c + 1") == Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1) true Why not just use a single representation (+ a (* b c) 1) ?
  - doublesCs 6y ago
    > That's not code as data, that's parsed code as data. I would say: you can execute it, therefore it's code. What am I missing? > Why not just use a single representation (+ a (* b c) 1) ? Are you saying you don't like the default print? You can write a println method for type Expr which prints it any way you want. Seems like a miniscule thing to nitpick.
    - deleted 6y ago
      [deleted]
      - deleted 6y ago
        [deleted]
    - kgwgk 6y ago
      You've convinced me, there is no difference. Why wouldn't anyone want to write code like this: Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)
      - snicker7 6y ago
        If you remove the Expr, you get something that kind of looks like Lisp.
        kgwgk 6y ago
        Yes, if you remove a few elements you get (+ a (* b c) 1), as I said a few messages back, which is lisp code and is also lisp data. So you can treat code as data! You can of course parse code in any language and treat it as data (and it may resemble lisp code!) but it’s not quite the same thing.
- ken 6y ago
  "Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this: >>> parse("2 + 2") ['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison', ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor', ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']] "This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use." -- Peter Norvig, https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
- voldacar 6y ago
  python and julia's way of accomplishing this is infinitely uglier and more adhoc than lisp's

doublesCs 6y ago

> The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options. Are you sure? Plenty of languages[1,2] allow you to treat code as data and they don't need that many parenthesis. [1] https://docs.python.org/3.8/library/ast.html https://docs.python.org/3.8/library/ast.html [2] https://docs.julialang.org/en/v1/manual/metaprogramming/index.html https://docs.julialang.org/en/v1/manual/metaprogramming/inde...

kgwgk 6y ago
That's not code as data, that's parsed code as data. julia> :(a + b*c + 1) == Meta.parse("a + b*c + 1") == Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1) true Why not just use a single representation (+ a (* b c) 1) ?
- doublesCs 6y ago
  > That's not code as data, that's parsed code as data. I would say: you can execute it, therefore it's code. What am I missing? > Why not just use a single representation (+ a (* b c) 1) ? Are you saying you don't like the default print? You can write a println method for type Expr which prints it any way you want. Seems like a miniscule thing to nitpick.
  - deleted 6y ago
    [deleted]
    - deleted 6y ago
      [deleted]
  - kgwgk 6y ago
    You've convinced me, there is no difference. Why wouldn't anyone want to write code like this: Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)
    - snicker7 6y ago
      If you remove the Expr, you get something that kind of looks like Lisp.
      - kgwgk 6y ago
        Yes, if you remove a few elements you get (+ a (* b c) 1), as I said a few messages back, which is lisp code and is also lisp data. So you can treat code as data! You can of course parse code in any language and treat it as data (and it may resemble lisp code!) but it’s not quite the same thing.
ken 6y ago
"Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this: >>> parse("2 + 2") ['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison', ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor', ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']] "This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use." -- Peter Norvig, https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
voldacar 6y ago
python and julia's way of accomplishing this is infinitely uglier and more adhoc than lisp's