Comments by "p11" (@porky1118) on "Uncle Bob LOVES Functional Programming | Prime Reacts" video.

  1. ​ @isodoubIet  Every language has some kind of parser. In case of Lisp it's just a simple parser, which is not really related to the semantics. It only parses lists, and the semantics are defined in terms of these lists. I also don't think, Lisp is necessarily about the syntax. You could have Lisps using totally different Syntax, as long as they are internally parsed as lists (preferably stored as arrays, not linked lists).
    12
  2. 9:38 Clojure should use SLN, the Scopes List notation. It is an indentation based syntax, where indentation implicitly creates inner list. And the outer list doesn't require any parentheses. This code would look like this in SLN: defn square [x] * x x println take 25 map square (range)
    3
  3. ​ @isodoubIet  What doesn't matter? I said, it's not about the syntax. You could have a direct mapping between C and S-Expressions. I also disagree about writing AST by hand. You write (+ 1 2 3) in Lisp, and the AST after macro expansion would be something like FunctionCall("+", PrimitiveValue::Number(1), FunctionCall("+", PrimitiveValue::Number(2), PrimitiveValue::Number(3))) Besides that, it's a good thing if the syntax the user sees is just a simple representation for the AST, which is the internal representation of the logic. This makes writing AST based macros much easier.
    3
  4.  @fredoverflow  caar :)
    2
  5. I also never really cared about these many parentheses. But I always wondered why I can't just write "print x" instead of "(print x)" in Lisp. That's why I prefer SLN (the Scopes List Notation) over pure S-Expressions nowadays. And in Scopes, you can do both, infix ("x + y + w + z") and prefix ("+ x y w z") notation for most operators.
    2
  6.  @yjlom  I know why it's not possible in most Lisps. But it would be an useful feature. Especially the Repl could implicilty just add parentheses before and after the expression in case there are multiple arguments in one line. Besides that "print x" in a repl is not equivalent to (progn (print) (x)) but to (progn print x)
    2
  7.  @josephs1732  You might have fallen into a cult. Maybe you're one of these "ruined" developers now ;)
    2
  8. 10:38 I would have written this code around the time I started programming. Probably 10 years ago. One thing I would have done different: I would have used one instead of two spaces for indentation.
    2
  9. I also prefer the rust way. But I'd like if rust allowed one liners, at least for early returns. @Khwerz 
    2
  10. 17:50 Third comment about Scopes on this video: Scopes also being a Lisp like Closure is statically typed, but you almost never specify any type. All functions where you don't specify types are generic functions. Here some comparison of the same code in Rust and Scopes: Scopes: fn mul (x y) * x y Rust: fn mul<X, Y>(x: X, y: Y) -> <X as Mul<Y>>::Output where X: Mul<Y> { x * y }
    1
  11. I had a similar experience for some time. When I got into Lisp, I didn't want to use another language for a few years. I ocassionally tried a few other Lisps or Lisp inspired languages, but it took me a few years to use other languages again. Now my main language for private projects is Rust, but Scopes being a Lisp is still the most powerful language I know. @josephs1732 
    1
  12. ​ @freesoftwareextremist8119  Reader macros don't seem that useful, though. Is writing "#(1 2 3)" really more difficult than writing "(# 1 2 3)" (where "#" would be a macro which generates a vector at compile time). Or writing "`(list 1 ,b 3)" wouldn't be more complicated than writing "(qq list 1 (uq b) 3)", right? (I think Dale and Scopes do it like this)
    1
  13.  @freesoftwareextremist8119  I think Scopes also allowed some custom syntax at symbol level. For example "." isn't a special character in Scopes. It's just a valid character for symbols. So when I define a point p and a value p.x, p.x is the value, but p.y is the y component of the point. It does some post processing of non existant symbols.
    1
  14.  @gagagero  Macro generating macros aren't bad. That's the point of macros. You define a while loop in terms of goto, you define a for loop using a while loop, and you might define an iterator based for loop using a for loop. Not sure why you bring in reader macros now. I just mentioned I'm not the biggest fan of reader macros.
    1
  15. 1:35 Yay, Lisp! I think he has a point there. Lisp was my first programming language, I really got into. It seemed so weird at first. Everything just looked the same, no matter if it was a function call, a macro call, control flow, type definitions or function definitions. But the different syntax is just an abstraction for humans. It's not necessary. Before I only used Java in school. And I did a bunch of programming in GML (Game Maker) to create many unfinished games. Then I started to get into C++ for Graphics Programming (with old OpenGL), and also tried a few others, one of them being Go. But I never really used a standard library. But when I got into Lisp, I really learned all of the language features, including the more obscure non-standardized ones like the CLOS MOP, and I also used a package manager for the first time (quicklisp). I used Common Lisp for around 3 years almost exclusively. Whenever I didn't like something about the language I thought, I could simply fix it by using macros, preventing me from really getting into other languages, especially if they weren't S-Expression based. Aferwards I had another phase, where I tried a bunch of PLs, most of them being inspired by Lisp, like Stanza, Dale, Scopes, and also started to get into Rust. I still think Scopes has potential to be the best programming language. It's basically Lisp, but using an indentattion based syntax, being more low level than C, having a borrow checker, havnig three kinds of macros, useful multiple value return semantics like Lua. Basically Common Lisp, but everything is better. I think, the best programming language is basically Rust, but with S-Expression based intermediate format. I think, the programming language should not be monolithic, but be devided into two layers: The semantic layer and the syntax layer. The semantic layer defines the core features, and it's defined in S-Expressions. It only is about thinks like if it's statically or dynamically typed (by default), if it's garbage collected, does it have classes, interfaces, etc, a borrow checker, etc. The syntax layer is just a syntax, which could work for different languages. It is just a different format for S-Expressions. So a C-like syntax, a python-like syntax, a node based visual language, a voice based programming language, etc. all map some format to the same S-Expression format. I hope, this will happen to Rust one day, too.
    1
  16. 10:55 I don't put sqirly (?) braces behind my code, but usually if it's a short statement, and I put it in the same line. while (true) { if (condition) continue; if (otherCondition) ++x; if (whatever) return f(x * x); ... }
    1
  17. ​ @Khwerz I was pretty sure you were talking about Rust here, since it doesn't require () but {}. if condition { return; } And I'd prefer to be able to write it like this: if condition: return;
    1
  18. I don't think, it's best to have as many keywords as possible. I'd rather prefer less keywords. I really like Penne in that regard. It only has infinite loops (you can use break or continue) and goto (only forward). And everything else should be implemented as Macros (like Lisp macros). The macros could also provide some optimizaiton details to the compiler.  @Khwerz 
    1