I have seen the light of Lisp. There is no code but #Lisp and #Racket is its earthly consummation.



Between DrRacket and Scribble, I am quite transfigured. The yak is clean shaved. This is everything I’ve ever wanted in a programming language but never known. It’s a little like love. 💕

Thanks, @emacsomancer

@Shufei @emacsomancer What are the features of Racket (and Lisp in general) that you find this compelling?

I've used Lisps and I generally find they're fun, but it takes a lot of thinking to use, and reading lisp can be extremely challenging.

Moreover, of the lisps I've used, Clojure (for all its problem) is the easiest to read, not Racket.

@emacsen @emacsomancer The elegance appeals to me. That “everything is a list”, and everything works as expression. It just fits my cognitive style better, as a dilettante writer rather than “a coder”. I like the fluidity. I’m visually oriented so like the idea of DrRacket allowing pictures. And nesting everything including conditionals with brackets rather than opening and closing. I get distracted by the “yak shaving” of other langs. I’m just looking at this now, but liking it heaps.

@Shufei @emacsomancer These are great answers. Thank you.

There are debates around even the question of "What is a lisp?" - it's a topic that @cwebber and I may do a show on in the future (we started planning it then things got pretty crazy for both of us).

I agree with you regarding DrRacket.

I agree with you that Lisps are the purest form of languages and have an incredible beauty and elegance to them.

Now I'm going to knock Lisp...

@Shufei @emacsomancer @cwebber

Lisps are incredibly hard to read.

Look at the analysis done by ArneBab, and his resulting project Wisp:


SO much easier to read...

And "everything is a list" is, in practice, not such a great idea.

Compare a Racket define with a Clojure one:

(define (hi name)
(print (string-append "Hello " name)))


(defn hi [name]
(print (str "Hello" name)))

It's not just superficial, having vectors on the reader matters for other reasons

Hi, @emacsen - thanks for providing some counterbalance (I did reference some links to 'why lisp failed' earlier in the thread as well).

I will maintain that the readability issue is rather subjective. I honestly find the straight lisp versions more readable than the wisp versions. I can unfocus the parentheses most of the time, but being able to focus on them when desired I find crucial.

Though the Python whitespace-as-syntax sounds initially appealling, in practice I find I prefer whitespace as formatting for humans, and not as computer-meaningful syntax.

The parentheses/bracketing issue is an interesting one. I pretty strongly disagree with Hickey on his notion that ()s get semantically-overloaded in Lisp. There is disambiguating context which usually balances this.

Also, in Racket your example can also be expressed as:

(define [greet name]
(print {string-append "Hello " name}))

In Racket (and I think in R6RS Schemes?) []s and {}s are alternatives to ()s, and so can be used where desired.

@Shufei @cwebber

@emacsomancer @emacsen @Shufei Although, Wisp is a lot harder, at present, to write :)

I've been a big proponent of Wisp, because I think an alternative simple syntax that maintains Lisp's beauty to be a big feature, but admittedly when I load lisp code and wisp code in my editor, I find lisp a *little bit* easier to read, but a *lot* easier to write. Wisp needs tooling to be made manageable.

@cwebber @emacsen @Shufei

I think it's tricky to simplify basic lisp syntax since using some overt markers of sexp boundaries like ()s makes the code wear its structure on its sleeve, at the small cost of Lots of Irritating Superfluous Parentheses for those who aren't used to looking at lisp syntax. Removing a clear, consistent marker in favour of a combination of meaningful whitespace and other boundary markers (:, .) at least for me doesn't feel like a cognitive win for the writer.

I also feel obligated to repost...

@emacsomancer @emacsen @Shufei The real litmus test of "is lisp syntax good": if you remove the ability to define macros, would you still prefer a parenthetical syntax?

And for myself, I would say "yes":
- Clarity of code flow
- Better editing tools (smartparens/paredit/rainbow delimeters)
- Unbeatable transition from "experimental code at the repl" right into your main codebase.

@cwebber @emacsomancer @emacsen @Shufei me too. Honestly I barely use macros, they're not easy to test or for other folks to read.

@cwebber @emacsomancer @emacsen @Shufei

I like this take a lot and I love lisp syntax but I'll always be biased as it was the first language I wrote substantial programs in.

When you say clarify of code flow though, I feel like that speaks more to the simplicity of the evaluation model than anything else. (I.e. SICP chapter 1 stuff, no operator precedence, etc) Am I missing something or is that more a semantic than syntactic issue?

@kingcons @emacsomancer @emacsen @Shufei Infix operators are very, *very* hard to figure out the order of, for instance.

Flow is possible to reason about in general because it's clear where it is delimited. This allows for such things as putting a conditional during the argument list of a function call and have it be very natural:

(call-me (if (evening? cur-time)

Python can't handle that kind of thing and doesn't even try.

@kingcons @emacsomancer @emacsen @Shufei And yes it doesn't look as readable as it would be if you aren't using a monospace font ;P

@cwebber @kingcons @emacsomancer @emacsen @Shufei that example has little to do with syntax; you can do that in Ruby and probably Smalltalk too. it's more a consequence of Python having statements instead of making everything an expression. (it's just that nearly every language that makes the mistake of having statements coincidentally has an algol-like syntax.)

@technomancy @kingcons @emacsomancer @emacsen @Shufei That's true, though I'd also say that in many languages that do support it, support is ugly / hard to read due to if having a very "different" syntax in many algol'ish languages

@cwebber This seems to be honing in on it to me. "Everything is an expression" + parens as primary syntactic construct leads to the boundaries of an expression being obvious.

This in turn makes refactoring more obvious. You can get used to seeing "expression boundaries" in other langs too, but it feels exceptionally crisp in Lisp due to the "exposed plumbing" of the representation.

@kingcons @cwebber "everything is an expression" is something that makes its way into almost any modern language these days (even Java! switch expression is coming, Javascript too where each declaration is an expression, even class). Examples are Kotlin & Rust at least (is it a "statement"? It returns Unit!) because it makes everything *much* more smooth.
Actually it's almost always conditions which are the problem and "ternary operator" is available almost everywhere.

@technomancy @cwebber @kingcons @emacsomancer @Shufei

Dirty secret is that I find Ruby to be a better Python in terms of syntax because it's more consistent. Sadly it brings with it a whole ton of other stuff I find less appealing.

@cwebber @kingcons @emacsomancer @emacsen @Shufei `callme({True: eveningNumber, False: dayNumber}[isEvening(time.time())]` is one possible Python impl...

@apg @cwebber @kingcons @emacsomancer @emacsen @Shufei callme(evening_number if is_evening(time.time()) else day_number)

It's postfix, not infix. Means you need more parens if there's more than one argument

@cwebber @emacsomancer @emacsen @Shufei

To me, a syntax must answer "yes" to one of two questions:

1. (For DSLs) Does it express specialized solutions that humans can understand?
2. (For multi-paradigm langs) Is it homoiconic?

If the answer is "no" to both questions, then I'd probably feel too limited in the host language over time. If the answer to #2 is "yes", then the syntax is probably going to look like Lisp or Rebol anyway. Once you know the benefits, it's easy to appreciate their form!

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!