4 ms·

> Written in a memory-safe-ish language that a plebeian like me can understand, review and contribute to, like rust and go or even lua or V, but please no lisp,

> Written in a memory-safe-ish language that a plebeian like me can understand, review and contribute to, like rust and go or even lua or V, but please no lisp, elisp or haskell. Would "a plebeian like them" care to explain why they don't like Lisp? Lisp as I see it is just the ultimate syntax of "(function argument argument)" and there is nothing more to learn unless you take a specific Lisp and compare it to others. I hardly even understand why do people keep inventing languages which are not lisps (and why does everybody seemingly find C-like syntax more intuitive).

nerdponx 5y ago
One possible reason: Lisp-like languages more or less require decent text editor support for productivity, otherwise you'll be stuck counting close parens. The same is not necessarily true for most other languages.
- kazinator 5y ago
  1980's original Bill-Joy-derived vi can do this: it has a :set lisp mode for indentation, and % for jumping between matching parentheses. "Can it match and indent parentheses" is pretty much a minimal viability test for any programming editor from the past 40 years.
  - qwerty456127 5y ago
    If only somebody at Microsoft had willpower to ad this in Notepad Lisp would quickly become much more popular. IMHO.
    - deleted 5y ago
      [deleted]
jstimpfle 5y ago
> why do people keep inventing languages which are not lisps Apparently people like to make syntax optimized for what they do most frequently. I like C programming, and not having a concise syntax to dereference, index, and access struct members would drive me nuts. Something like foo->bar.baz += quux(42); is not too rare to have to write, but feels very natural to write this way. In Lisp, that would be terrible in comparison. Sometimes, just sometimes, I try to add some metaprogramming and imagine how nice it would be to code in Lisp, only to realize soon after that I was overthinking it. It's a rare situation that the "special" syntax that is in my preferred language causes friction for what I do. 99% of the time, it is there to support me, to help me read and write code faster.
- kazinator 5y ago
  I am very attuned to this specific problem. Whereas the lack of infix for numeric calculation is hardly an impediment, good ways of dealing with objects and structures strike at the heart of program organization. Numeric calculations are confined to small isolated pieces of code; they do not involve reference and collaboration. In some ways, parenthesized prefix improves the readability of nested expressions by eliminating ambiguity, and n-ary operators like * and + taking multiple arguments can even reduce clutter. But struct access; it helps that have that convenient. This is why in TXR Lisp there is a comprehensive referencing dot notation. What's more, there is also a blueprint for how to integrate that into any Lisp. This is the thing about Lisp; the research is not over. Here is some example code. (defmeth win-drawing draw-text (fe x y fonttype fontsize align colour text) (whenlet ((dstat fe.drawstatus)) (if (eq dstat :printing) (upd fontsize (* fe.printpixelscale) toint)) (let ((xy (win-transform-point fe x y)) (key (cons fonttype fontsize))) ;; find or create the font. ;; ;; NB: We don't implement the C versions "font stack marker" for ;; allocating printing fonts within the array and then discarding them. ;; In Lisp, it's trivial to save and clear the entire font list before ;; printing, and restore it after. (let* ((font (or (find key fe.fonts) (win-new-font fe fonttype fontsize))) (oldfnt (SelectObject fe.hdc font.font)) (tm (new TEXTMETRIC)) (size (new SIZE))) (if (GetTextMetrics fe.hdc tm) (if (logtest align align-vcentre) (dec xy.y (trunc (+ tm.tmAscent tm.tmDescent) 2)) (dec xy.y tm.tmAscent))) (if (GetTextExtentPoint32 fe.hdc text (len text) size) (if (logtest align align-hcentre) (dec xy.x (trunc size.cx 2)) (dec xy.x size.cx))) (SetBkMode fe.hdc TRANSPARENT) (win-text-colour fe colour) (ExtTextOut fe.hdc xy.x xy.y 0 nil text (len text) NULL) (SelectObject fe.hdc oldfnt))))) (defun win-new-font (fe fonttype fontsize) (let ((lf (znew LOGFONT lfHeight (- fontsize) lfWeight (if (eq fe.drawstatus :printing) 0 FW_BOLD) lfCharSet DEFAULT_CHARSET lfOutPrecision OUT_DEFAULT_PRECIS lfClipPrecision CLIP_DEFAULT_PRECIS lfQuality DEFAULT_QUALITY lfPitchAndFamily (if (eq fonttype :font-fixed) (logior FIXED_PITCH FF_DONTCARE) (logior VARIABLE_PITCH FF_SWISS))))) (push (new font font (CreateFontIndirect lf) type fonttype size fontsize) fe.fonts) (car fe.fonts))) This is a translation of the following function, which is from Simon Tatham's Puzzles. The code to get the font was factored out into a separate function in the above Lisp: static void win_draw_text(void *handle, int x, int y, int fonttype, int fontsize, int align, int colour, const char *text) { frontend *fe = (frontend *)handle; POINT xy; int i; LOGFONT lf; if (fe->drawstatus == NOTHING) return; if (fe->drawstatus == PRINTING) fontsize = (int)(fontsize * fe->printpixelscale); xy = win_transform_point(fe, x, y); /* * Find or create the font. */ for (i = fe->fontstart; i < fe->nfonts; i++) if (fe->fonts[i].type == fonttype && fe->fonts[i].size == fontsize) break; if (i == fe->nfonts) { if (fe->fontsize <= fe->nfonts) { fe->fontsize = fe->nfonts + 10; fe->fonts = sresize(fe->fonts, fe->fontsize, struct font); } fe->nfonts++; fe->fonts[i].type = fonttype; fe->fonts[i].size = fontsize; memset (&lf, 0, sizeof(LOGFONT)); lf.lfHeight = -fontsize; lf.lfWeight = (fe->drawstatus == PRINTING ? 0 : FW_BOLD); lf.lfCharSet = DEFAULT_CHARSET; lf.lfOutPrecision = OUT_DEFAULT_PRECIS; lf.lfClipPrecision = CLIP_DEFAULT_PRECIS; lf.lfQuality = DEFAULT_QUALITY; lf.lfPitchAndFamily = (fonttype == FONT_FIXED ? FIXED_PITCH | FF_DONTCARE : VARIABLE_PITCH | FF_SWISS); fe->fonts[i].font = CreateFontIndirect(&lf); } /* * Position and draw the text. */ { HFONT oldfont; TEXTMETRIC tm; SIZE size; WCHAR wText[256]; MultiByteToWideChar (CP_UTF8, 0, text, -1, wText, 256); oldfont = SelectObject(fe->hdc, fe->fonts[i].font); if (GetTextMetrics(fe->hdc, &tm)) { if (align & ALIGN_VCENTRE) xy.y -= (tm.tmAscent+tm.tmDescent)/2; else xy.y -= tm.tmAscent; } if (GetTextExtentPoint32W(fe->hdc, wText, wcslen(wText), &size)) { if (align & ALIGN_HCENTRE) xy.x -= size.cx / 2; else if (align & ALIGN_HRIGHT) xy.x -= size.cx; } SetBkMode(fe->hdc, TRANSPARENT); win_text_colour(fe, colour); ExtTextOutW(fe->hdc, xy.x, xy.y, 0, NULL, wText, wcslen(wText), NULL); SelectObject(fe->hdc, oldfont); } }
jeffreyrogers 5y ago
Structure helps people understand programs better. Because lisp has basically the minimal amount of structure required to make it parseable it is harder for people to understand than other languages that enforce structure via syntax. Yes, I know that lisp programmers often structure their programs well, but there is a reason most of the good parts of lisp got incorporated into other languages and yet lisp stayed relatively niche.

nerdponx 5y ago

One possible reason: Lisp-like languages more or less require decent text editor support for productivity, otherwise you'll be stuck counting close parens. The same is not necessarily true for most other languages.

kazinator 5y ago
1980's original Bill-Joy-derived vi can do this: it has a :set lisp mode for indentation, and % for jumping between matching parentheses. "Can it match and indent parentheses" is pretty much a minimal viability test for any programming editor from the past 40 years.
- qwerty456127 5y ago
  If only somebody at Microsoft had willpower to ad this in Notepad Lisp would quickly become much more popular. IMHO.
  - deleted 5y ago
    [deleted]

jstimpfle 5y ago

> why do people keep inventing languages which are not lisps Apparently people like to make syntax optimized for what they do most frequently. I like C programming, and not having a concise syntax to dereference, index, and access struct members would drive me nuts. Something like foo->bar.baz += quux(42); is not too rare to have to write, but feels very natural to write this way. In Lisp, that would be terrible in comparison. Sometimes, just sometimes, I try to add some metaprogramming and imagine how nice it would be to code in Lisp, only to realize soon after that I was overthinking it. It's a rare situation that the "special" syntax that is in my preferred language causes friction for what I do. 99% of the time, it is there to support me, to help me read and write code faster.

kazinator 5y ago
I am very attuned to this specific problem. Whereas the lack of infix for numeric calculation is hardly an impediment, good ways of dealing with objects and structures strike at the heart of program organization. Numeric calculations are confined to small isolated pieces of code; they do not involve reference and collaboration. In some ways, parenthesized prefix improves the readability of nested expressions by eliminating ambiguity, and n-ary operators like * and + taking multiple arguments can even reduce clutter. But struct access; it helps that have that convenient. This is why in TXR Lisp there is a comprehensive referencing dot notation. What's more, there is also a blueprint for how to integrate that into any Lisp. This is the thing about Lisp; the research is not over. Here is some example code. (defmeth win-drawing draw-text (fe x y fonttype fontsize align colour text) (whenlet ((dstat fe.drawstatus)) (if (eq dstat :printing) (upd fontsize (* fe.printpixelscale) toint)) (let ((xy (win-transform-point fe x y)) (key (cons fonttype fontsize))) ;; find or create the font. ;; ;; NB: We don't implement the C versions "font stack marker" for ;; allocating printing fonts within the array and then discarding them. ;; In Lisp, it's trivial to save and clear the entire font list before ;; printing, and restore it after. (let* ((font (or (find key fe.fonts) (win-new-font fe fonttype fontsize))) (oldfnt (SelectObject fe.hdc font.font)) (tm (new TEXTMETRIC)) (size (new SIZE))) (if (GetTextMetrics fe.hdc tm) (if (logtest align align-vcentre) (dec xy.y (trunc (+ tm.tmAscent tm.tmDescent) 2)) (dec xy.y tm.tmAscent))) (if (GetTextExtentPoint32 fe.hdc text (len text) size) (if (logtest align align-hcentre) (dec xy.x (trunc size.cx 2)) (dec xy.x size.cx))) (SetBkMode fe.hdc TRANSPARENT) (win-text-colour fe colour) (ExtTextOut fe.hdc xy.x xy.y 0 nil text (len text) NULL) (SelectObject fe.hdc oldfnt))))) (defun win-new-font (fe fonttype fontsize) (let ((lf (znew LOGFONT lfHeight (- fontsize) lfWeight (if (eq fe.drawstatus :printing) 0 FW_BOLD) lfCharSet DEFAULT_CHARSET lfOutPrecision OUT_DEFAULT_PRECIS lfClipPrecision CLIP_DEFAULT_PRECIS lfQuality DEFAULT_QUALITY lfPitchAndFamily (if (eq fonttype :font-fixed) (logior FIXED_PITCH FF_DONTCARE) (logior VARIABLE_PITCH FF_SWISS))))) (push (new font font (CreateFontIndirect lf) type fonttype size fontsize) fe.fonts) (car fe.fonts))) This is a translation of the following function, which is from Simon Tatham's Puzzles. The code to get the font was factored out into a separate function in the above Lisp: static void win_draw_text(void *handle, int x, int y, int fonttype, int fontsize, int align, int colour, const char *text) { frontend *fe = (frontend *)handle; POINT xy; int i; LOGFONT lf; if (fe->drawstatus == NOTHING) return; if (fe->drawstatus == PRINTING) fontsize = (int)(fontsize * fe->printpixelscale); xy = win_transform_point(fe, x, y); /* * Find or create the font. */ for (i = fe->fontstart; i < fe->nfonts; i++) if (fe->fonts[i].type == fonttype && fe->fonts[i].size == fontsize) break; if (i == fe->nfonts) { if (fe->fontsize <= fe->nfonts) { fe->fontsize = fe->nfonts + 10; fe->fonts = sresize(fe->fonts, fe->fontsize, struct font); } fe->nfonts++; fe->fonts[i].type = fonttype; fe->fonts[i].size = fontsize; memset (&lf, 0, sizeof(LOGFONT)); lf.lfHeight = -fontsize; lf.lfWeight = (fe->drawstatus == PRINTING ? 0 : FW_BOLD); lf.lfCharSet = DEFAULT_CHARSET; lf.lfOutPrecision = OUT_DEFAULT_PRECIS; lf.lfClipPrecision = CLIP_DEFAULT_PRECIS; lf.lfQuality = DEFAULT_QUALITY; lf.lfPitchAndFamily = (fonttype == FONT_FIXED ? FIXED_PITCH | FF_DONTCARE : VARIABLE_PITCH | FF_SWISS); fe->fonts[i].font = CreateFontIndirect(&lf); } /* * Position and draw the text. */ { HFONT oldfont; TEXTMETRIC tm; SIZE size; WCHAR wText[256]; MultiByteToWideChar (CP_UTF8, 0, text, -1, wText, 256); oldfont = SelectObject(fe->hdc, fe->fonts[i].font); if (GetTextMetrics(fe->hdc, &tm)) { if (align & ALIGN_VCENTRE) xy.y -= (tm.tmAscent+tm.tmDescent)/2; else xy.y -= tm.tmAscent; } if (GetTextExtentPoint32W(fe->hdc, wText, wcslen(wText), &size)) { if (align & ALIGN_HCENTRE) xy.x -= size.cx / 2; else if (align & ALIGN_HRIGHT) xy.x -= size.cx; } SetBkMode(fe->hdc, TRANSPARENT); win_text_colour(fe, colour); ExtTextOutW(fe->hdc, xy.x, xy.y, 0, NULL, wText, wcslen(wText), NULL); SelectObject(fe->hdc, oldfont); } }

jeffreyrogers 5y ago

Structure helps people understand programs better. Because lisp has basically the minimal amount of structure required to make it parseable it is harder for people to understand than other languages that enforce structure via syntax. Yes, I know that lisp programmers often structure their programs well, but there is a reason most of the good parts of lisp got incorporated into other languages and yet lisp stayed relatively niche.