4 ms·

To the contrary, Scheme's prefix notation reads quite well, particularly if you use indentation well. But that's just my opinion. Several of the statements in

To the contrary, Scheme's prefix notation reads quite well, particularly if you use indentation well. But that's just my opinion. Several of the statements in this article about Scheme are, however, objectively wrong. -Scheme isn't functional. It makes no effort to control side-effects, and a lot of Scheme is heavily stateful. In fact, the very Scheme example you wrote isn't functional at all! -Scheme isn't uncomfortable for OO. Multiple OO frameworks have been written in Scheme (most of them based upon CLOS), and many of them are very comfortable and quite excellent. If you don't like multiple-dispatch functions, it's also possible to implement smalltalk-style object-message syntax (and indeed, people have done so). In fact, if you look into the history of Scheme, it was orginally written by Sussman and Steele to help them understand the Actor Model, which is quite similar to OO: a program is modeled as many stateful actors, which can only communicate through messages. Finally, the "confusing" Scheme code in this article is not very well written. If you split the definitions like so, it becomes much more readable (also, vector-map! is already defined in many schemes, so you don't even have to evaluate the top part): (define (vector-map! f v) (do ((i 0 (+ i 1))) ((= i 0) v) (vector-set! v i (f (vector-ref v i))))) (define (make-matrix rows columns) (vector-map! (lambda (a) (make-vector columns)) (make-vector rows))) Again, there are several common extensions (in various SRFIs) that would make this even cleaner. In the upcoming R7RS-large (the Red standard, which has these functions, has just been released), I would merely need to import one library, and vector-map! would be defined for me, as is already true in many implementations.

mpweiher 10y ago
> Scheme isn't functional. "Scheme is a functional programming language ..." -- https://en.wikipedia.org/wiki/Scheme_(programming_language) https://en.wikipedia.org/wiki/Scheme_(programming_language)
- Johnny_Brahms 10y ago
  Well, the style in which most people write scheme and you are encouraged to write scheme is functional, but it is very much a multi-paradigm language.
- nickpsecurity 10y ago
  Two explanations on why people say it's not a functional language: http://letoverlambda.com/index.cl/guest/chap5.html http://letoverlambda.com/index.cl/guest/chap5.html https://www.quora.com/Should-Lisp-be-considered-a-functional-programming-language https://www.quora.com/Should-Lisp-be-considered-a-functional...
  - qwertyuiop924 10y ago
    Well, that's the whole lisp family (and knowing Doug Hoyte's distaste for Scheme, he's probably explicitly talking about CL), but the arguments still apply.
kazinator 10y ago
Any readability problem in vector-map! there is an issue with some given Scheme and the available primitives that it has out of the box for writing it. TXR Lisp: (defun inplace-vec-map (f v) (each ((i (range (length v)))) (set [v i] [f [v i]]))) I should provide mappers that iterate over the places in a sequence. ;; Fantasy: (each-place ((elem seq)) ;; seq is vector, string or list or whatever (set elem [f elem])) ;; elem is mutable place alias Good idea. Like non-const iterators in C++ or whatever. If `[v i]` is repeated a lot in the body of the each, we can currently approximate this now with placelet, an invention of mine: (each ((i (range (length v)))) (placelet ((elem [v i])) ;; once-only evaluation of [v i]! (set elem [f elem]))) ;; elem can be used many times That translation for the each-place fanatasy construct would work, but would be inefficient for lists; it has to use some type-specific iterator object under the hood to designate the place with constant-time access. Lisp is forever malleable and can overcome any ergonomic problem that anyone wants; you just have to articulate the requirements clearly: "I don't like writing X; why can't it be expressed as Y".
- qwertyuiop924 10y ago
  Well, part of my point was that new primitives (vector-map!) are being introduced that makes this more convenient (and already exist in most Schemes). To your point, there are numerous loop macro sets that make the do in my vector-map! simpler, but I didn't want to introduce any external dependancies (or implementation dependancies), and I thought it was clear enough.
nickpsecurity 10y ago
I don't think it reads well. I came from ALGOL family as you'd expect. I always hated LISP syntax unless I was doing a parser or 4GL. LISP lovers have always acted like it's impossible to give in on this point to increase adoption whereas some had saner strategies: https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) Much more beautiful to read. You could almost turn syntax that looks like that into a scripting language with a good standard library. Would probably get widespread, commercial and FOSS adoption plus make Hacker News a lot. Just speculation on my part over ten years ago. Maybe give it a cute-looking, snake logo to symbolize making people like something they hate. Nah, I'm sure lispers will miss this obvious strategy for success of their favorite language. :P
- deleted 10y ago
  [deleted]
- qwertyuiop924 10y ago
  I do get your point, Nick, but I'm not sure I agree. Dylan, Nim, and other programming languages that try to have Lisp's macro facilities (which are the main reason we stick to the sexpr code format) may be nice to program in, but they're am absolute pain to metaprogram in. Just look at Nim's procedural macros, for crying out loud! Also, many of us lispers like the regularity and simplicity of syntax that sexprs allow (no syntax, no precedence). OTOH, a more direct sexpr mapping might work, a la wisp. Seriously, if your main object to lisp is the syntax, wisp may be something you want to try.
  - nickpsecurity 10y ago
    Another thing to consider is how often people need to write macros. The vast majority of programmers will just use base language and libraries. The libraries contain the macros. Advanced programmers can create the macro libraries. This provides the massive benefit on adoption for regular programming without the drawback of metaprogramming. Further, the macro language might even use s-expr syntax that prettier language is converted to in first pass of parsing. So, instead of paren language as default, it's an ALGOL-like language as default with syntax extensions or mods being made for macro work. In reverse of of lispers normally do it. Re WISP. Looks better but still prefix. The prefix notation is the problem as it's designed to be easy for computers & compiler writers, not humans reading it.

mpweiher 10y ago

> Scheme isn't functional. "Scheme is a functional programming language ..." -- https://en.wikipedia.org/wiki/Scheme_(programming_language) https://en.wikipedia.org/wiki/Scheme_(programming_language)

Johnny_Brahms 10y ago
Well, the style in which most people write scheme and you are encouraged to write scheme is functional, but it is very much a multi-paradigm language.
nickpsecurity 10y ago
Two explanations on why people say it's not a functional language: http://letoverlambda.com/index.cl/guest/chap5.html http://letoverlambda.com/index.cl/guest/chap5.html https://www.quora.com/Should-Lisp-be-considered-a-functional-programming-language https://www.quora.com/Should-Lisp-be-considered-a-functional...
- qwertyuiop924 10y ago
  Well, that's the whole lisp family (and knowing Doug Hoyte's distaste for Scheme, he's probably explicitly talking about CL), but the arguments still apply.

kazinator 10y ago

Any readability problem in vector-map! there is an issue with some given Scheme and the available primitives that it has out of the box for writing it. TXR Lisp: (defun inplace-vec-map (f v) (each ((i (range (length v)))) (set [v i] [f [v i]]))) I should provide mappers that iterate over the places in a sequence. ;; Fantasy: (each-place ((elem seq)) ;; seq is vector, string or list or whatever (set elem [f elem])) ;; elem is mutable place alias Good idea. Like non-const iterators in C++ or whatever. If `[v i]` is repeated a lot in the body of the each, we can currently approximate this now with placelet, an invention of mine: (each ((i (range (length v)))) (placelet ((elem [v i])) ;; once-only evaluation of [v i]! (set elem [f elem]))) ;; elem can be used many times That translation for the each-place fanatasy construct would work, but would be inefficient for lists; it has to use some type-specific iterator object under the hood to designate the place with constant-time access. Lisp is forever malleable and can overcome any ergonomic problem that anyone wants; you just have to articulate the requirements clearly: "I don't like writing X; why can't it be expressed as Y".

qwertyuiop924 10y ago
Well, part of my point was that new primitives (vector-map!) are being introduced that makes this more convenient (and already exist in most Schemes). To your point, there are numerous loop macro sets that make the do in my vector-map! simpler, but I didn't want to introduce any external dependancies (or implementation dependancies), and I thought it was clear enough.

nickpsecurity 10y ago

I don't think it reads well. I came from ALGOL family as you'd expect. I always hated LISP syntax unless I was doing a parser or 4GL. LISP lovers have always acted like it's impossible to give in on this point to increase adoption whereas some had saner strategies: https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) Much more beautiful to read. You could almost turn syntax that looks like that into a scripting language with a good standard library. Would probably get widespread, commercial and FOSS adoption plus make Hacker News a lot. Just speculation on my part over ten years ago. Maybe give it a cute-looking, snake logo to symbolize making people like something they hate. Nah, I'm sure lispers will miss this obvious strategy for success of their favorite language. :P

deleted 10y ago
[deleted]
qwertyuiop924 10y ago
I do get your point, Nick, but I'm not sure I agree. Dylan, Nim, and other programming languages that try to have Lisp's macro facilities (which are the main reason we stick to the sexpr code format) may be nice to program in, but they're am absolute pain to metaprogram in. Just look at Nim's procedural macros, for crying out loud! Also, many of us lispers like the regularity and simplicity of syntax that sexprs allow (no syntax, no precedence). OTOH, a more direct sexpr mapping might work, a la wisp. Seriously, if your main object to lisp is the syntax, wisp may be something you want to try.
- nickpsecurity 10y ago
  Another thing to consider is how often people need to write macros. The vast majority of programmers will just use base language and libraries. The libraries contain the macros. Advanced programmers can create the macro libraries. This provides the massive benefit on adoption for regular programming without the drawback of metaprogramming. Further, the macro language might even use s-expr syntax that prettier language is converted to in first pass of parsing. So, instead of paren language as default, it's an ALGOL-like language as default with syntax extensions or mods being made for macro work. In reverse of of lispers normally do it. Re WISP. Looks better but still prefix. The prefix notation is the problem as it's designed to be easy for computers & compiler writers, not humans reading it.