5 ms·

Only the parentheses look like brackets. Everything else looks quite nice. But for lisp programming, those bracket-looking parentheses are ugly...

Syzygies 8y ago
Lisp is the canary in the mind shaft. 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). http://input.fontbureau.com/ http://input.fontbureau.com/ The Input download can be customized to look nearly identical to B612, only better, and without the O0 and () problems.
- burfog 8y ago
  Lighter??? You mean thin? Lowercase is what, short like the 'x'? 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.
  - Syzygies 8y ago
    I'm using the standard terminology in the font industry. My borrow font for brackets is called SourceCodePro-ExtraLight, not SourceCodePro-ExtraThin. And yes, lowercase as in the same height as lowercase letters. That was an interesting experiment that I rejected. I prefer light (thin) brackets that enclose everything, as you say. 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.
    - thaumasiotes 8y ago
      > lowercase as in the same height as lowercase letters Lowercase letters are just as tall as capitals...
      - jdietrich 8y ago
        AaCcEeGgMmNnOoPpQqRrSsUuVvWwXxYyZz.
        thaumasiotes 8y ago
        You're missing some letters. And even among the ones you listed, g, p, q, and y are fully as tall as every capital except Q.
    - jacobolus 8y ago
      Instead of using thinner glyph shapes, just change your syntax highlighting to reduce contrast on the brackets.
- pvg 8y ago
  Until the recent advent of 4K and "retina" displays, it wasn't practical to have significant weight variations in screen fonts for programming. Really? Bolded keywords and other tweakery was common on 512×342 OG Mac screens.
  - Syzygies 8y ago
    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.
    - theoh 8y ago
      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.
      - Syzygies 8y ago
        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.
- marcosdumay 8y ago
  > All programming languages have a bracket problem 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.

Syzygies 8y ago

Lisp is the canary in the mind shaft. 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). http://input.fontbureau.com/ http://input.fontbureau.com/ The Input download can be customized to look nearly identical to B612, only better, and without the O0 and () problems.

burfog 8y ago
Lighter??? You mean thin? Lowercase is what, short like the 'x'? 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.
- Syzygies 8y ago
  I'm using the standard terminology in the font industry. My borrow font for brackets is called SourceCodePro-ExtraLight, not SourceCodePro-ExtraThin. And yes, lowercase as in the same height as lowercase letters. That was an interesting experiment that I rejected. I prefer light (thin) brackets that enclose everything, as you say. 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.
  - thaumasiotes 8y ago
    > lowercase as in the same height as lowercase letters Lowercase letters are just as tall as capitals...
    - jdietrich 8y ago
      AaCcEeGgMmNnOoPpQqRrSsUuVvWwXxYyZz.
      - thaumasiotes 8y ago
        You're missing some letters. And even among the ones you listed, g, p, q, and y are fully as tall as every capital except Q.
  - jacobolus 8y ago
    Instead of using thinner glyph shapes, just change your syntax highlighting to reduce contrast on the brackets.
pvg 8y ago
Until the recent advent of 4K and "retina" displays, it wasn't practical to have significant weight variations in screen fonts for programming. Really? Bolded keywords and other tweakery was common on 512×342 OG Mac screens.
- Syzygies 8y ago
  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.
  - theoh 8y ago
    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.
    - Syzygies 8y ago
      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.
marcosdumay 8y ago
> All programming languages have a bracket problem 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.