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

Lisp at the Frontier of Computation [video]

youtube.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#71

Post by michaelsbradley »

meken wrote: post #70
michaelsbradley wrote: post #69

Earlier quoted context omitted.

I guess ParEdit has staying power, but isn't Smartparens[+] the way to go these days? https://github.com/Fuco1/smartparens

YMMV but for what it's worth I became frustrated with smartparens when I couldn't figure out how to do something very simple. I think it was traversing down into the next sexp. I got different behavior when my cursor was right up against the sexp versus one space before. Also whereas paredit really pushes me to have a mental model that the lisp source code forms a tree (e.g. up, down, left, and right being the main o…

Interesting. I wonder if it has to do default settings, or something like that. I'm using bbatsov/prelude[+], for several years now, and Smartparens (per prelude's config) has always behaved for me like a better ParEdit.

[+] https://github.com/bbatsov/prelude

Re: Lisp at the Frontier of Computation [video]

#72

Post by sedachv »

dreamcompiler wrote: post #34
nafizh wrote: post #7

Every time, I see one of these links or videos, I feel the urge to learn Lisp. But after some time, I lose the motivation. I think that is because I don't know what benefit learning lisp will provide me concretely. Anyone has any suggestion?

Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.

Python is in no way a Lisp. Python is not homoiconic, does not have first-class identifiers (symbols), and does not have full support for dynamically loading code (https://news.ycombinator.com/item?id=14666300). All that makes Python much closer to BASIC than to other dynamic programming languages. I think of Python as a BASIC with an object system and a couple of incorrectly borrowed ideas from Scheme (lexical scoping and first-class functions). There is not much "simplified" there compared to Lisp 1.5, just less features with more complexity.

Re: Lisp at the Frontier of Computation [video]

#73

Post by astrange »

gnufx wrote: post #40
goatlover wrote: post #14

Earlier quoted context omitted.

Lisp seems to take the exact opposite approach as Go. The power of languages like Lisp appeal to me, so I have a hard time understanding why people want a language that intentionally limits itself. Read Graham's book and he's talking about how macros are great for writing maintainable code because you can make it both short and very readable because it's close to the domain. But then you hear the arguments in favor o…

An old epi²gram: There should be only one way to do it. — Python There's more than one way to do it. — Perl Do the right thing. — Lisp

"Do the right thing" is a brave statement for a language with no typechecking!

Re: Lisp at the Frontier of Computation [video]

#74

Post by meken »

michaelsbradley wrote: post #71
meken wrote: post #70

Earlier quoted context omitted.

YMMV but for what it's worth I became frustrated with smartparens when I couldn't figure out how to do something very simple. I think it was traversing down into the next sexp. I got different behavior when my cursor was right up against the sexp versus one space before. Also whereas paredit really pushes me to have a mental model that the lisp source code forms a tree (e.g. up, down, left, and right being the main o…

Interesting. I wonder if it has to do default settings, or something like that. I'm using bbatsov/prelude[+], for several years now, and Smartparens (per prelude's config) has always behaved for me like a better ParEdit. [+] https://github.com/bbatsov/prelude

Ah thanks for the recommendation. For what it's worth I was using the evil-mode smartparens layer bundled with spacemacs.

Re: Lisp at the Frontier of Computation [video]

#75

Post by peatmoss »

flavio81 wrote: post #52
xstartup wrote: post #30

Earlier quoted context omitted.

What's the most popular Lisp in use today? Does it come with a static compile type checking?

> What's the most popular Lisp in use today? At least if based in 2016 GitHub popularity: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang.... #1 Emacs Lisp #2 Common Lisp #3 Scheme #4 Racket Unless you consider Clojure a Lisp (yes it is, and no, it isn't...), in which case #1 would be Clojure, and then the others listed above.

You can mostly combine 3 & 4 on that list. Racket (formerly PLT Scheme) has moved beyond Scheme in many ways (language features, batteries), but is still exceptionally similar.

Re: Lisp at the Frontier of Computation [video]

#76

Post by dreamcompiler »

dreamcompiler wrote: post #34
nafizh wrote: post #7

Every time, I see one of these links or videos, I feel the urge to learn Lisp. But after some time, I lose the motivation. I think that is because I don't know what benefit learning lisp will provide me concretely. Anyone has any suggestion?

Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.

It's funny that I've been downvoted for this comment, given that I've made a living writing Common Lisp for most of my career (including working with the presenter in this video at one of the companies he describes). Of course Python is nowhere close to CL. (If anything, Javascript is closer because it has first-class closures.) But I've found that if you tell people the whole truth up front -- rather than letting them discover it for themselves -- it comes off as condescending.

Re: Lisp at the Frontier of Computation [video]

#77

Post by flavio81 »

astrange wrote: post #73
gnufx wrote: post #40

Earlier quoted context omitted.

An old epi²gram: There should be only one way to do it. — Python There's more than one way to do it. — Perl Do the right thing. — Lisp

"Do the right thing" is a brave statement for a language with no typechecking!

"Do the right thing", in this context, goes beyond just the presence or absence of typechecking.

But regarding type checking, Lisp (at least Common Lisp) is strongly typed. Really, very strongly typed (for example it will complain about putting a "byte" in a "character" array; or of using an "array" when a "simple-vector" was expected... Lisp is very nitpicky regarding types!), but the type checks happens mostly at runtime. Some checking also happens at compile time, even more if you intentionally include type declarations. (Type declarations are part of the ANSI Common Lisp standard.)

Re: Lisp at the Frontier of Computation [video]

#78

Post by lispm »

gnufx wrote: post #43
flavio81 wrote: post #19

Earlier quoted context omitted.

Note that Clojure is not really a Lisp dialect, so you will need a different tutorial if you want to try a Lisp like Scheme, Common Lisp, Racket, TXR Lisp, etc.

How is Hickey wrong about that?

Take any Lisp book from 1958 onwards: not a single example program will work in Clojure. Most would need a complete rewrite, because the concepts are different.

Re: Lisp at the Frontier of Computation [video]

#79

Post by yorwba »

geokon wrote: post #62
Slackwise wrote: post #20

Earlier quoted context omitted.

Whenever I want someone to understand Lisp being a homoiconic metaprogramming language, I link them this: http://www.defmacro.org/ramblings/lisp.html

maybe someone can help me understand. I now get homoiconisity but the example he uses doesn't seem to explain why the macro is needed. He explains a problem that can be solved by writing a function. Instead he presents what seems to be in effect an unevaluated function... so what's the point?

I agree that the macro example is not chosen well. Macros are just functions that take their arguments unevaluated and output code, so each macro call could be replaced by a function call where the arguments are wrapped in a list and the function executes the code directly instead of generating it.

Then the only reason you'd have to use macros is if you want to do something at compile time. Like generating specialized code so the compiler can optimize it, instead of reinterpreting the describing data on each invocation. Or like reading the database schema to generate accessors.

Re: Lisp at the Frontier of Computation [video]

#80

Post by didibus »

sillysaurus3 wrote: post #41
xstartup wrote: post #30

Earlier quoted context omitted.

What's the most popular Lisp in use today? Does it come with a static compile type checking?

Rather than most popular, I propose using the most useful. That'd be Lumen. http://github.com/sctb/lumen It's the only lisp that can interface seamlessly with any JS library you want. Just `npm i leftpad && LUMEN_HOST=node lumen` and type `(require 'leftpad)`. $ npm i leftpad $ LUMEN_HOST=node lumen > (require 'leftpad) function > ((require 'leftpad) "foo" 5) "00foo" Other lisps are nice, but they all try to build th…

Immutability is optional in Clojure, though it is the default. Also I'm confused what you mean with size and speed mattering, ClojureScript does better then most by going through the Google Closure compiler for minification and dead code elimination.
Post reply on HN