Did you like how that looked? I didn't. The resolution wasn't ready. The resolution certainly didn't support going lighter.
I'm trying to understand why lightweight Lisp parentheses haven't been a thing for 50 years. It's so obviously right once one tries it, with sufficient resolution. My guess is that "sufficient resolution" is both key, and recent.
I'd guess that most people who value typographic nuance and clarity find Lisp's lack of concessions to syntax makes reading code an extremely clunky experience. I think Lisp's (lack of) syntax adds up to a set of tradeoffs that actively repels visual thinkers/typography folks, compared to Miranda-style syntax.
NB Haskell folks are not any more likely than Lispers to think visually. A lot of Haskell code is difficult to read. But it does feel like the Miranda-style syntax (particularly pattern matching) has made the first few steps towards eliminating unnecessary structure-related cognitive load on the programmer.
Lisp partisans will probably reject this opinion, but IMO the presence of strings of matching parens in Lisp isn't something that needs to be restyled with a better font, it's something that needs to be designed out of the language.
Edit: I know this ground has been well-covered in the past. Usually the advice is that by using a proper editor and relying on indentation, parens just stop being a noticeable problem. Whether just restyling parens is cosmetic or not, it seems less powerful even than that advice.
Scheme is a stunningly beautiful language with inferred parentheses:
define | edge? g e
let
$ es | edges g
e2 | reverse e
or (member e es) (member e2 es)
I used to rely on a preprocessor that translates back and forth to standard Scheme:
(define (edge? g e)
(let
( (es (edges g))
(e2 (reverse e)))
(or (member e es) (member e2 es))))
One gives up being able to use standard tools. For Emacs or Vim, one can write one's own tools, but it's nice to be able to try out everyone else's work first.
The central question for any programming language isn't how comfortably it welcomes casual newcomers; it's how effectively it creates a human:machine interface for the committed. Most criticisms of how Lisp looks can be likened to criticisms of a frozen screen from a crashed video game. One needs to play the video game. Lisp acquires its meaning in short time scales from the experience of syntax-aware editing, a live experience. Lisp acquires its meaning in long time scales from the experience of using macros to rewrite the language to exactly suit the problem at hand. Haskell is safer, faster, more densely expressive, but not as plastic. Lisp appeals to woodworkers; other languages appeal to people who like to buy nice furniture, sit in it and get to work. I can see both sides, and I've worked hard to experience both sides.
> beautiful language with inferred [...] a preprocessor that translates back and forth to standard
Most focus is on transforming code for machine consumption (compilation). But underappreciated I think, is that code can also be transformed for humans. Reversibly (editing), and not (analysis). Colorization and outlining are common. Less common are syntax transforms like yours. Fortress-like mathification. Reverse templating and macros. Intensional programming. The idea of a collaborative-compilation environment with an editor-like UI.
So much potential fun. But so little R&D funding. And a discoordinated profession. So decades slide by.
I don't have much experience with Lisp, so I'm definitely trying to convey the impression of a typography enthusiast rather than a coder. I'm familiar with the kind of claims you are making for Lisp, but I'm also conscious of the bad PR that Lisp enthusiasts get sometimes. That might sound like a superficial thing to be worried about, but it absolutely is not, for those inside and outside the Lisp world, because every newbie has to choose whether or not to invest time in a particular programming culture.
In terms of Lisp vs the ML family of languages (including Haskell), "absence of syntax" as a guiding principle of Lisp seems to be in contrast to a language community, like Haskell's, that spends more time considering how it will write its own compiler than anything else.
With that in mind, I think it's a bit tendentious to dismiss Haskell users as passive consumers who don't consider the nuts and bolts of their programming language, and Lisp programmers as woodworkers. It's actually very difficult to get anywhere significant in Haskell without deeply committing to learning the Haskell way of doing things (currying, evaluation strategies, monoids and monads, type classes, even continuations etc.) I'd say, from what I've seen, that Haskell has more of a particular, distinct flavour than Lisp, which goes along with coming from that "MetaLanguage" tradition, concerned with codifying (in the language) the routine ways to manipulate structures. It's a culture, and one that happens to be a little bit elitist and not very good at transmitting itself to outsiders. But maybe the only languages that have no fixed cultural elements (abstractions/tropes) to speak of are rudimentary Turing tarpits.
Metaphors about craft vs consumerism aside, a good Lisp programmer and a good Haskell programmer will both know the techniques they are applying. It's not like Haskell is a high-performance car with the hood bolted shut. It can appear that way because they're always trying to polish the abstract principles of the thing and make it more elegantly expressive—it's a research project in that sense. But by the same token, to get the real benefits you have to buy into that academic culture and do the same kind of conceptual thinking you would in Lisp.
Though, in which mainstream non-Lisp language can you feasibly work without a good editor and relying on indentation for grokking the program structure?
> I think Lisp's (lack of) syntax adds up to a set of tradeoffs that actively repels visual thinkers/typography folks
It's more of being aware that Lisp syntax works different from what most people are used to. The current Lisp syntax was originally an accident, but it survived because it has some interesting and unique properties.
Lisp code is relatively unique because it is written on top (!) of a data syntax.
Thus is has a two stage syntax: a the bottom there is a syntax for s-expressions - which is purely about light-weight syntax for data - not a programming language.
On top of that there is Lisp syntax, which is defined in terms of structured data. This enables code manipulation in terms of programs over hierarchical list-like data. It also enables user extensible syntax via Lisp macros. Thus a program in Lisp syntax can be written as text by serialized data, but it can also be computed in memory.
Thus we'll see code which visually has more of a layout in terms of hierarchical nested lists. For this programs have been written which can produce such a layout from code as data.
Lisp has an aspect of direct manipulation of code as data. You may want to design it out of the language, but few actual Lisp users would do want that - additionally it has been tried multiple times and it has often failed. For example there was a large effort to design a Lisp 2 (as a 'second generation Lisp') with non-s-expression-based syntax. A large effort, which failed and which in the end had very little influence on how Lisp programs look like. There are versions of Lisp like RLISP which had a syntax not based on s-expressions and which is still used in a software which is a computer algebra system. Dylan was another attempt of a Lisp-like language without s-expression based language.
> Usually the advice is that by using a proper editor and relying on indentation, parens just stop being a noticeable problem.
Another advice is to use an interactive programming environment for Lisp to actually make practical use of the unique features of Lisp syntax.
To a Lisp programmer it is more useful to support this dynamic aspect of code as data AND its visual representation - more than losing these capabilities and supporting the idea of code as static text. Tools which support Lisp were for example the Interlisp-D structure editor for Lisp code and the Lisp listener for Symbolics Genera. The latter keeps the connection of the external textual representation of Lisp data and code with their underlying data representation.
Otherwise we would be using ML (nowadays SML or OCAML), which was initially a functional language on top of Lisp written without s-expressions. Languages with more conventional syntax exist already - languages which combine syntax with a data representation are not so common...
Really? Bolded keywords and other tweakery was common on 512×342 OG Mac screens.