31–40 of 66 posts
Another reason this is interesting beyond "Lispiness" instead: implementing a (compliant) Scheme takes on some interesting problems that other languages punt - proper tail recursion, delimited continuations (off the top of my head, I don't know other methods apart from CPS), and hygienic macros.
I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…
I think people underestimate how pragmatic meta programming can be because there are some obvious downsides. Arguably one of things that made Rust so popular was its inclusion of procedural macros. But beyond that the thing I don't understand about the modern hate towards macros is that they are simply very fun.
I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…
I was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.
Programs are rarely linear; why do you expect code to be?
Earlier quoted context omitted.
As someone who is "into" programming languages (and making toy implementations of them), I think some of the most important macros are along the lines of Rust/Haskells `derive/deriving` for quickly enabling serialization, printing etc. Using a language without such capability quickly becomes frustrating once you move to any kind of "real" task.
In any kind of real task, serialization is not the hard part. If you can write a meta program for it, you can execute that in CI and spit out generated code and be done with it. This is a viable approach in any programming language that can print strings to files. It’s not frustrating, but maybe it feels tacky. But then you shrug and move on to the real task at hand.
I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…
Lisp is versatile as all get-out, so you can program however you want. For example, we can roll like it's 1969: (prog ((a 0) (b 1) (c 0)) (declare (type Fixnum a b c)) :fb-start (print a) (incf b a) (setf a (- b a)) (incf c) (when (
let a, b, c = 0, 1, 0
fb_start:
writen(a)
b +:= 1
a := b - a
if c Earlier quoted context omitted.
This is a common reaction/belief but usually from people who have not actually managed a team of Lisp devs. Lisp devs are managed in the same way as any other: You have style guidelines, design review, code review, etc. Sometimes a new macro is good and vastly simplifies code. It's accepted as a PR and documented like anything else. Sometimes a new macro is bad, and it's promptly rejected by the team. It's a persiste…
It's hard to reconcile that with the comment they were responding to that claimed that lisp requires you to be the designer of the language a bit. I don't know enough to know who is right, but if the majority of the code is "just" regular functions and classes then I'd argue that it doesn't require custom design as a much as allow it, and the solution you're proposing is to mostly disallow it by convention. Like the…
Lisp has a handful of language features that allow the definition of new syntactic abstractions: form level (DEFMACRO) and character level (SET-MACRO-CHARACTER). Just like it has operators to define new data structures (DEFSTRUCT and DEFCLASS). Just like it had operators to define new functions (DEFUN, DEFGENERIC, DEFMETHOD). Each of these defining forms materially change the way a programmer writes code. You don't need to add new syntax to change the language, and each kind of language change comes with its own tools and practices for working with them, debugging them, documenting them, and so on. All of this is to say: I don't see a good reason to have all of these remarks about syntactic abstraction when they very well could be made about data abstraction or control abstraction.
A useful language feature isn't something that needs to be maximized in idiomatic code. Syntactic abstraction is useful when it's useful, and when it is useful, it's usually extraordinarily useful—typically because a new syntactic abstraction allows a programmer to specify something much more directly or correctly than otherwise. (Other languages frequently resort to external processors or code generators to the same effect. Anybody who has used them knows how frustrating and difficult to debug they can be. But nonetheless, it's not that people do or don't want syntactic abstractions—they clearly do—it's more a matter of how accessible we want to make it to the programmer.)
I did not suggest disallowing it anymore than I suggested we should disallow the definition of new classes in Java. Being judicious and deciding when it's worth it is key, and there are few general statements we can make about this without additional context.
I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…
I was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.
Earlier quoted context omitted.
Lisp is versatile as all get-out, so you can program however you want. For example, we can roll like it's 1969: (prog ((a 0) (b 1) (c 0)) (declare (type Fixnum a b c)) :fb-start (print a) (incf b a) (setf a (- b a)) (incf c) (when (
Which actually supports the OP's original argument that even with training and getting used to, this syntax reads harder than let a, b, c = 0, 1, 0 fb_start: writen(a) b +:= 1 a := b - a if c
I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…
Earlier quoted context omitted.
I was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.
Lisp code is written top to bottom, left to right. Is your grievance more to do with expression-oriented—as opposed to statement-oriented—languages? "Do this" (statement) vs "represent this" (expression)? For instance, do Haskell, OCaml, etc. also irk you in similar ways?
Haskell and OCaml are, by comparison, not very nested.