Only the parentheses look like brackets. Everything else looks quite nice. But for lisp programming, those bracket-looking parentheses are ugly...
All programming languages have a bracket problem; Lisp just has a more intense bracket problem. Until the recent advent of 4K and "retina" displays, it wasn't practical to have significant weight variations in screen fonts for programming. It's now practical, and it's easy in font editors such as Glyphs Mini to swap in or modify brackets to be a lighter weight.
I've made many Lisp coding experiments: with preprocessors that eliminate most parentheses, with alternate symbols, and with various weights and sizes of parentheses. There's something to be said for the theory that parentheses should be lower case, just like identifiers. (I'm reminded of the "GET OFF MY LAWN" effect in Common Lisp; one can shut off the upper case defaults but most people don't stay around long enough to find out.) However, my favorite approach is to make parentheses light, but not too light. There's a sweet spot where you actually love the lightweight brackets, in Lisp code and everywhere else. You're conducting an orchestra, not engaging in a knee-jerk debate; if the trumpets play too loud, teach them to play at the right volume.
It took me ten minutes to swap in ()[]{} from SourceCodePro-ExtraLight, and copy a period into the center of the zero. This a fine Lisp font but not my favorite. I like Input Mono, or Courier Prime Code (both similarly modified).
The Input download can be customized to look nearly identical to B612, only better, and without the O0 and () problems.
That is exactly the opposite of a good programming font. These characters should be extra-tall. They should go at least as low as any other ASCII character, and at least as high as any other ASCII character. An extra pixel (or several on a 4K display) upward would be even better, up there with the accented uppercase letters like A-with-ring.
Lisp is in decline in part because of the community tendency to circle the wagons in the face of any criticism. My single point is that Lisp parentheses are always too heavy, and readability improves with lighter parentheses.
I've also long used Unicode replacements for => and other combined symbols in Haskell. Then I discovered Hasklig, solving this problem instead through ligatures. Any problem one can solve in the font itself is transparent to the rest of one's tool chain. I'm a convert.
Lowercase letters are just as tall as capitals...
And even among the ones you listed, g, p, q, and y are fully as tall as every capital except Q.
Really? Bolded keywords and other tweakery was common on 512×342 OG Mac screens.
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.
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.
define | edge? g e
let
$ es | edges g
e2 | reverse e
or (member e es) (member e2 es)
(define (edge? g e)
(let
( (es (edges g))
(e2 (reverse e)))
(or (member e es) (member e2 es))))
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.
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.
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.
It's called pretty-printing. The name is underwhelming, but there are some advanced techniques for it.
Including rudimentary, POSIX vi.
E.g. in the normal Scheme code, I can put the cursor on this line:
( (es (edges g))
(e2 (reverse e)))
( (es (edges g)) (e2 (reverse e)))
—
1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...
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...
Haskell doesn't. It's possible to fix the bracket problem, but it's not C-like so people will be forever complaining and refusing to learn your stupid crazy language.