Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

Post reply on HN
Print view View original

241–250 of 276 posts

Re: Not Lisp again (2009)

#241

Post by kazinator »

DigitalJack wrote: post #229
grey-area wrote: post #226

Earlier quoted context omitted.

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview div…

I think that objection is likely true of scheme. Scheme is like the Assembly language of lisps. To build it up to the level of usefulness requires a lot of wheel re-inventing, and those wheels are likely to be not quite standard. Clojure and Common Lisp are larger languages and don't really suffer this problem.

However, mainstream machine languages have defined orders of evaluation and specified results.

Re: Not Lisp again (2009)

#242

Post by mark_l_watson »

lisper wrote: post #138
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

> 1 - All those parenthesis. (Still a top objection) If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the…

+1, couldn't agree more. Especially about Quicklisp: Zach had an idea, implemented it, and made the lives of most CL programmers easier.

Re: Not Lisp again (2009)

#243

Post by [deleted] »

Jach wrote: post #141
icc97 wrote: post #133

Earlier quoted context omitted.

> SICP uses Scheme, which is not Lisp. Wikipedia [0]: > Scheme is a functional programming language and one of the two main dialects of the programming language Lisp. [0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

Keyword: dialect . But Erik Naggum, 2002 [0]: > The "Lisp" Scheme is a dialect of is no longer the current meaning of "Lisp". It is somewhat like calling English a dialect of German because of ancient history that has since between invalidated by each of their separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and Pennsylvania to the contrary notwithstanding. There is also a very limited value in talkin…

[deleted]

Re: Not Lisp again (2009)

#244

Post by icc97 »

jhbadger wrote: post #217
Jach wrote: post #168

Earlier quoted context omitted.

Is Python a LISP? Is JavaScript a LISP? Is Java a LISP? What do you mean by LISP, by its core principles? What does a different set of core principles look like that lends itself to a different family? I threw in my vague classification above: sexps and macros. But you can have macros without sexps, and sexps without macros (lots of "toy lisp interpreters" do that), are they LISPs? Lastly one wonders why we don't go…

Is Picolisp a Lisp? Is Newlisp a Lisp? Is Emacs Lisp a Lisp? Maybe it's because I first learned programming in the 1980s in BASIC, but I'm pretty used to the idea of programming languages having dialects. Apple ][s, Commodore 64s, and Atari 800s all supposedly were programmable in BASIC, but it didn't mean you could take a program written on one and expect to run it without changes on another.

Sorry - I think I was just proving your point...

Re: Not Lisp again (2009)

#245

Post by KingMob »

krapp wrote: post #209
lisper wrote: post #204

Earlier quoted context omitted.

Why? (And what language do you use where you don't have to rely on the editor to format your code?)

To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression.

And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance.

What we rely on is proper indentation to indicate the important groupings.

Re: Not Lisp again (2009)

#246

Post by Chris2048 »

chongli wrote: post #24
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

You left out a rather glaring objection: 7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page. [0] http:…

I think one problem with certain 'declarative' styles, is that imperative code is, in a sense, temporarily ordered.

When you lose this, you need to replace it with some other enforced order, that helps you navigate the code.

Think how much debugging is based on locating buggy code by walking through the execution path and/or data-path. When you lose that kind of strictly linear execution, you still need a layer of heavy modulation to compensate.

Consider reaching a state of https://www.emacswiki.org/emacs/DotEmacsBankruptcy you can easily modify the editor in any way from any file, so you really need to use in-build tools to navigate how the environment is affected by the config files.

Re: Not Lisp again (2009)

#247

Post by sigjuice »

KingMob wrote: post #245
krapp wrote: post #209

Earlier quoted context omitted.

To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.

Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.

Re: Not Lisp again (2009)

#248

Post by lisper »

chriswarbo wrote: post #240
lisper wrote: post #206

Earlier quoted context omitted.

F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. But compare to, say, C where no one complains about the parens: int fact(int n) { if (n==0) { return 1 } else { return n*fact(n-1); } } That's six pairs of parens. The only reason it's not more is because some function calls in C are disgu…

> F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. It makes a lot of sense when all functions are curried. Parenthesised function calls treat all of these as different things: f(a, b, c, d) f(a, b, c)(d) f(a, b)(c, d) f(a, b)(c)(d) f(a)(b, c, d) f(a)(b, c)(d) f(a)(b)(c, d) f(a)(b)(c)(d)…

You can curry in Lisp too, and if you do you can get rid of all but one of the unnecessary parens as well.

    (curry f a b c d)

Re: Not Lisp again (2009)

#249

Post by oxryly1 »

grey-area wrote: post #226
oxryly1 wrote: post #153

Earlier quoted context omitted.

Using Lisp (in the form of Racket) for many years in a production environment, I've observed: 1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down. 2. This is a similar complaint, and does scare people off from jumping in if they have a real choice. 3. Racket in particular solves this one to an…

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview div…

With Racket, at least, the language encourages you to build very small pieces and assemble them into larger systems. It's fairly straightforward to connect the pieces together to share code.

It does also encourage you to create mini-languages, but our approach was usually a large amount of modular Racket-y code with many fairly thin layers of syntax transformation used in each mini-language case. In that sense the problem of mutually incompatible languages didn't really arise (in fact, separate mini-languages coincided with separate usage areas quite well).

Performance was an issue, and we generally needed to use the precompilation feature of Racket to be successful. The issue we ran into is that Racket's precompilation system produces fairly fragile and coupled binary files -- and is generally difficult to separate cleanly from the execution environment.

Re: Not Lisp again (2009)

#250

Post by kazinator »

lelandbatey wrote: post #183
Chyzwar wrote: post #156

Earlier quoted context omitted.

Lisp style is more elegant, almost everything is either data or function. Other languages you mention are massively more complex and difficult to understand. For me C++ is some kind of clusterfuck of symbols/keywords/operators and plain magic. After you learn prefix notation, Lisp is super easy. Unfortunately in the world were "worse is better" we discard beautiful and smart: Smalltalk, Lisp and ML. Instead we build…

It is not. When it comes to learning anything, we humans have a massive tendency to prefer that which is familiar. This means that when a human is faced with an obstacle and must choose between: - An unfamiliar tool or paradigm which is custom built to solve this and all future problems (should they arise) such that time and effort is saved - A familiar tool which has been extended this one time to solve this one pro…

Yes.

If you introduce basic Lisp like (+ 2 2) to kids that don't know infix arithmetic yet, it's very revealing.

Post reply on HN